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

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. ありがとうございました