社内サービスのUI改善

Battle Conference U30にて発表された資料です
https://bcu30.jp/

Transcript

1. 社内サービスのUI改善 #bcu30 #client_10 2018/04/21
2. ⾃⼰紹介 • 名前/Twitter • 松岡 紀⾏/@nemupm • 略歴 • 2016/03 ⼤阪⼤学⼤学院 修了 • 2016/04 グリー株式会社 新卒⼊社 • 業務 • データ分析基盤の開発・運⽤ 尾道で撮った猫
3. 社内サービス使ってますか？
4. 社内サービスとは のことではなく 内製で運⽤している独⾃サービス
5. グリーの分析基盤サービス Powers-of-Ten（PoT） • 社内の様々なプロダクトのログを分析するための基盤サービス • 有名な分析基盤サービスの例 • Treasure Data • Google BigQuery • Amazon Redshift
6. グリーの分析基盤サービス Powers-of-Ten（PoT） • グリーでは様々な理由によりPoTを内製している • 分析のクラウドサービスが少なかった時代に 内製されたサービスの後継であるため • 社内の要求を満たすように開発されてきた全ての機能を 外部のサービスで提供することが難しいため • コストの削減のため • 使⽤⼈数規模：300⼈以上、使⽤プロダクト数：約40
7. この分析基盤サービスPoTが 抱える問題
8. UIのユーザビリティが低い
9. ユーザビリティが低い例① 分かりにくいUI
10. 分かりにくいUI例（実際のPoTの画⾯）
11. 分かりにくいUI例（実際のPoTの画⾯） メニューが多く アイコンも無い
12. 分かりにくいUI例（実際のPoTの画⾯） よくわからない沢⼭のフォームが 乱雑に置かれている
13. ユーザビリティが低い例② 最低限のUI
14. 最低限のUI例（実際のPoTの画⾯）
15. 最低限のUI例（実際のPoTの画⾯） PoTをよく使う⼈にとっては物⾜りない（⾮効率な）UI
16. なぜUIがなかなか改善されないのか • 各メンバーの考える問題点・改善案が異なるため • もとのUIが昔の内製サービスの継ぎ接ぎであり、 根本的なUIの設計を変えづらいため • UIに詳しいエンジニアがチームに居ないため
17. なぜUIが⼤事なのか UIが分かりにくいと • 初学者にとってサービス利⽤のハードルが⾼くなる →ユーザ数が増えない UIが最低限しか無いと • 熟練者にとって冗⻑な操作が多くなる →ユーザの業務効率を下げてしまう
18. そこで、UI改善プロジェクトを ⽴ち上げました
19. 今⽇話したいこと UIのプロが居ないチーム、という⽴場から、 UIを改善するプロジェクトを進める上で • やってよかったこと • 苦労したこと を話します 注：プロジェクトはまだ終わってないため、あくまで現時点での所感です
20. プロジェクト概要 • ⽬的 • データ分析基盤サービスPoTのフロントエンド部分について 利⽤者視点からUI/UXを再考してリプレイス • システム構成 APIサーバ リプレイス部分 EMR, S3などの データ基盤 バックエンド
21. やってよかったこと５つ
22. １．スクラム開発 • バックエンドだと最初に設計をすべて決めることが多い（多分） • 今回のようにフロントエンドのUIを真⾯⽬に考えた時、 最初に理想的なUIをすべて決めるのが難しかった • 考えたUIが良いか悪いか判断できない • そもそも具体的な案が出づらい 仮UIを触りながら仕様を考えることで、 納得感をもって仕様を議論できた
23. ２．仕様チームと開発チームに分割 ⼯数を考えない議論の場を仕組みとして担保できるため 実装しやすい仕様に偏ることを防げた 仕様チーム 理想的なUIを議論 仕様チーム 開発チーム 全員で改めて 実現可能性も含めて 議論
24. ３．定期的な社内公開 • 1ヶ⽉に1回ほど、社内のいくつかのチームに向けてβ版を公開 • 途中でだれない • フィードバックが貰える • 開発のアピールになる β１公開 β２公開 クエリ機能の開発 グラフ機能の開発
25. ４．β版公開ごとにKPTの実施 • スクラム開発に則り KPT（Keep, Problem, Try）を実施 • 楽しく議論できるように お菓⼦やコーヒーも導⼊ プロジェクトの進め⽅について 合意形成しながら改善できた お菓⼦を買いすぎた図
26. ５．デザイン⾯は社内の専⾨チームに相談 • 定期的に相談して フィードバックを貰う ⾒た⽬・UIの品質が⼤幅に上がり ユーザに印象良く触ってもらうことが出来た プロジェクト初期に参考として→ 作ってもらった画⾯イメージ
27. ⼀⽅で、苦労していることもあります
28. 開発チームのエンジニアの⽴場から⾒て、 フロントエンドについて 苦労したこと２つ データ 注：フロントエンドに限らない問題ではありますが悪しからず
29. １．ベストプラクティス分からない問題 • （SPAの）設計ベストプラクティスが分からない • みんな⾔ってることが違ったりする • ライブラリが多すぎて選定が難しい • 同じようなライブラリが乱⽴してたりする 現状の対策 • 関連記事を徹底的に探す・OSSを参考にする • Githubのスター数やGoogle trendsを参考にする
30. ２．⼯数⾒積が難しい問題 • 今回、仕様チームにUIの仕様ごとにチケットを作成してもらった 仕様1を実装するタスクA チケットごとにかかる時間がばらばら（数⼗分〜数⽇） 仕様2を実装するタスクB 仕様チームが作成したチケット 開発チームが考える実際のタスク • モデルの設計（Rails/Angular） • APIの作成 • データベース作成 • JSライブラリの検証・選定 • レイアウト作成 粒度のずれ … …
31. ２．⼯数⾒積が難しい問題 結果、進捗の遅れの検知が困難になる 現状の対策 • 開発チーム側でもチケットを作成する • 開発しやすい粒度で⼩⽬標を⽴てる
32. このように⼯夫・苦労しながら 進めているプロジェクト その現状について
33. 画⾯例① BEFORE
34. 画⾯例① AFTER（開発中）
35. 画⾯例② BEFORE
36. 画⾯例② AFTER （開発中）
37. 慣れてない分野のために つまずくことは多々ありますが
38. ⼤事なのは⽇々改善する意識と、 そのための仕組みづくりだと感じます
39. 皆さんの⼿で⾝の回りの『当たり前』を 改善していきましょう！
40. ありがとうございました