社内サービスのUI改善

by gree_tech

Embed

Start on current slide

Slide 1

Slide 1 text

社内サービスのUI改善 #bcu30 #client_10 2018/04/21

Slide 2

Slide 2 text

⾃⼰紹介 • 名前/Twitter • 松岡紀⾏/@nemupm • 略歴 • 2016/03 ⼤阪⼤学⼤学院修了 • 2016/04 グリー株式会社新卒⼊社 • 業務 • データ分析基盤の開発・運⽤尾道で撮った猫

Slide 3

Slide 3 text

社内サービス使ってますか？

Slide 4

Slide 4 text

社内サービスとはのことではなく内製で運⽤している独⾃サービス

Slide 5

Slide 5 text

グリーの分析基盤サービス Powers-of-Ten（PoT） • 社内の様々なプロダクトのログを分析するための基盤サービス • 有名な分析基盤サービスの例 • Treasure Data • Google BigQuery • Amazon Redshift

Slide 6

Slide 6 text

グリーの分析基盤サービス Powers-of-Ten（PoT） • グリーでは様々な理由によりPoTを内製している • 分析のクラウドサービスが少なかった時代に内製されたサービスの後継であるため • 社内の要求を満たすように開発されてきた全ての機能を外部のサービスで提供することが難しいため • コストの削減のため • 使⽤⼈数規模：300⼈以上、使⽤プロダクト数：約40

Slide 7

Slide 7 text

この分析基盤サービスPoTが抱える問題

Slide 8

Slide 8 text

UIのユーザビリティが低い

Slide 9

Slide 9 text

ユーザビリティが低い例① 分かりにくいUI

Slide 10

Slide 10 text

分かりにくいUI例（実際のPoTの画⾯）

Slide 11

Slide 11 text

分かりにくいUI例（実際のPoTの画⾯）メニューが多くアイコンも無い

Slide 12

Slide 12 text

分かりにくいUI例（実際のPoTの画⾯）よくわからない沢⼭のフォームが乱雑に置かれている

Slide 13

Slide 13 text

ユーザビリティが低い例② 最低限のUI

Slide 14

Slide 14 text

最低限のUI例（実際のPoTの画⾯）

Slide 15

Slide 15 text

最低限のUI例（実際のPoTの画⾯） PoTをよく使う⼈にとっては物⾜りない（⾮効率な）UI

Slide 16

Slide 16 text

なぜUIがなかなか改善されないのか • 各メンバーの考える問題点・改善案が異なるため • もとのUIが昔の内製サービスの継ぎ接ぎであり、根本的なUIの設計を変えづらいため • UIに詳しいエンジニアがチームに居ないため

Slide 17

Slide 17 text

なぜUIが⼤事なのか UIが分かりにくいと • 初学者にとってサービス利⽤のハードルが⾼くなる →ユーザ数が増えない UIが最低限しか無いと • 熟練者にとって冗⻑な操作が多くなる →ユーザの業務効率を下げてしまう

Slide 18

Slide 18 text

そこで、UI改善プロジェクトを⽴ち上げました

Slide 19

Slide 19 text

今⽇話したいこと UIのプロが居ないチーム、という⽴場から、 UIを改善するプロジェクトを進める上で • やってよかったこと • 苦労したことを話します注：プロジェクトはまだ終わってないため、あくまで現時点での所感です

Slide 20

Slide 20 text

プロジェクト概要 • ⽬的 • データ分析基盤サービスPoTのフロントエンド部分について利⽤者視点からUI/UXを再考してリプレイス • システム構成 APIサーバリプレイス部分 EMR, S3などのデータ基盤バックエンド

Slide 21

Slide 21 text

やってよかったこと５つ

Slide 22

Slide 22 text

１．スクラム開発 • バックエンドだと最初に設計をすべて決めることが多い（多分） • 今回のようにフロントエンドのUIを真⾯⽬に考えた時、最初に理想的なUIをすべて決めるのが難しかった • 考えたUIが良いか悪いか判断できない • そもそも具体的な案が出づらい仮UIを触りながら仕様を考えることで、納得感をもって仕様を議論できた

Slide 23

Slide 23 text

２．仕様チームと開発チームに分割⼯数を考えない議論の場を仕組みとして担保できるため実装しやすい仕様に偏ることを防げた仕様チーム理想的なUIを議論仕様チーム開発チーム全員で改めて実現可能性も含めて議論

Slide 24

Slide 24 text

３．定期的な社内公開 • 1ヶ⽉に1回ほど、社内のいくつかのチームに向けてβ版を公開 • 途中でだれない • フィードバックが貰える • 開発のアピールになる β１公開 β２公開クエリ機能の開発グラフ機能の開発

Slide 25

Slide 25 text

４．β版公開ごとにKPTの実施 • スクラム開発に則り KPT（Keep, Problem, Try）を実施 • 楽しく議論できるようにお菓⼦やコーヒーも導⼊プロジェクトの進め⽅について合意形成しながら改善できたお菓⼦を買いすぎた図

Slide 26

Slide 26 text

５．デザイン⾯は社内の専⾨チームに相談 • 定期的に相談してフィードバックを貰う⾒た⽬・UIの品質が⼤幅に上がりユーザに印象良く触ってもらうことが出来たプロジェクト初期に参考として→ 作ってもらった画⾯イメージ

Slide 27

Slide 27 text

⼀⽅で、苦労していることもあります

Slide 28

Slide 28 text

開発チームのエンジニアの⽴場から⾒て、フロントエンドについて苦労したこと２つデータ注：フロントエンドに限らない問題ではありますが悪しからず

Slide 29

Slide 29 text

１．ベストプラクティス分からない問題 • （SPAの）設計ベストプラクティスが分からない • みんな⾔ってることが違ったりする • ライブラリが多すぎて選定が難しい • 同じようなライブラリが乱⽴してたりする現状の対策 • 関連記事を徹底的に探す・OSSを参考にする • Githubのスター数やGoogle trendsを参考にする

Slide 30

Slide 30 text

２．⼯数⾒積が難しい問題 • 今回、仕様チームにUIの仕様ごとにチケットを作成してもらった仕様1を実装するタスクA チケットごとにかかる時間がばらばら（数⼗分〜数⽇）仕様2を実装するタスクB 仕様チームが作成したチケット開発チームが考える実際のタスク • モデルの設計（Rails/Angular） • APIの作成 • データベース作成 • JSライブラリの検証・選定 • レイアウト作成粒度のずれ … …

Slide 31

Slide 31 text

２．⼯数⾒積が難しい問題結果、進捗の遅れの検知が困難になる現状の対策 • 開発チーム側でもチケットを作成する • 開発しやすい粒度で⼩⽬標を⽴てる

Slide 32

Slide 32 text

このように⼯夫・苦労しながら進めているプロジェクトその現状について

Slide 33

Slide 33 text

画⾯例① BEFORE

Slide 34

Slide 34 text

画⾯例① AFTER（開発中）

Slide 35

Slide 35 text

画⾯例② BEFORE

Slide 36

Slide 36 text

画⾯例② AFTER （開発中）

Slide 37

Slide 37 text

慣れてない分野のためにつまずくことは多々ありますが

Slide 38

Slide 38 text

⼤事なのは⽇々改善する意識と、そのための仕組みづくりだと感じます

Slide 39

Slide 39 text

皆さんの⼿で⾝の回りの『当たり前』を改善していきましょう！

Slide 40

Slide 40 text

ありがとうございました