Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

社内サービスのUI改善

942 views

Published on

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

Published in: Engineering
  • Be the first to comment

  • Be the first to like this

社内サービスのUI改善

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

×