Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
社内サービスのUI改善
Search
gree_tech
PRO
April 24, 2018
Technology
0
120
社内サービスのUI改善
Battle Conference U30にて発表された資料です
https://bcu30.jp/
gree_tech
PRO
April 24, 2018
Tweet
Share
More Decks by gree_tech
See All by gree_tech
kustomizeをいい感じに使う方法
gree_tech
PRO
4
2.3k
スケーラビリティとコスト管理 Google Cloud Spanner 費用最適化の取り組み
gree_tech
PRO
0
760
「アナザーエデン 時空を超える猫」の5年前のログを引っ越してデータドリブンで事業運用プロセスを改善した話
gree_tech
PRO
0
490
Unity,PHP+Jenkins+GAS 多言語対応を意識させない開発を目指したシステム構築
gree_tech
PRO
0
1k
全社総会における「REALITY Spaces」の活用と、Addressableを用いたコンテンツ配信技術について
gree_tech
PRO
0
630
AWSのEKS環境でログ機能を構築/リリースしたお話
gree_tech
PRO
0
490
「ヘブンバーンズレッド」の大規模アップデートにおける国内及び翻訳QAの取り組み
gree_tech
PRO
0
580
アプリ「REALITY」の12言語対応プロセスの仕組みと品質向上の取り組み
gree_tech
PRO
0
870
REALITYアプリのメンテナンスなしでの機能リリースを実現する、Istio導入とB/Gデプロイ実現の取り組み
gree_tech
PRO
0
700
Other Decks in Technology
See All in Technology
クラウド利用者の「責任」をどう果たす?AWSセキュリティ対策のススメ #AWSSummit
hiashisan
0
280
GoとアクターモデルでES+CQRSを実践! / proto_actor_es_cqrs
ytake
1
160
シフトレフトで挑む セキュリティの生産性向上
sekido
PRO
0
270
AWSでRAGを作る法方
sonoda_mj
1
140
累計ダウンロード数1億8000万を超えるアプリケーションプラットフォームのレガシーシステム脱却とモダン化への道
kmitsuhashi
0
120
開発生産性をむしろ向上させる セキュリティパートナーの作り方 / Dev Productivity Con 2024
flatt_security
0
380
ペパボのオブザーバビリティ研修2024 説明資料
kesompochy
0
1.1k
AWSで”最小権限の原則”を実現するための考え方 /20240722-ssmjp-aws-least-privilege
opelab
10
4.4k
「単なる OAuth 2.0 を認証に使うと、車が通れるほどのどでかいセキュリティー・ホールができる」のか検証してみた
terara
0
380
サービス開発を前に進めるために 新米リードエンジニアが 取り組んだこと / Steps Taken by a Novice Lead Engineer to Advance Service Development
nologyance
0
180
Git 研修 Advanced【MIXI 24新卒技術研修】
mixi_engineers
PRO
0
200
20240724_cm_odyssey_hibiyatech
hiashisan
0
110
Featured
See All Featured
BBQ
matthewcrist
82
9k
Creatively Recalculating Your Daily Design Routine
revolveconf
214
11k
The Power of CSS Pseudo Elements
geoffreycrofte
64
5.2k
Documentation Writing (for coders)
carmenintech
63
4.2k
For a Future-Friendly Web
brad_frost
173
9.2k
How to Ace a Technical Interview
jacobian
274
23k
Infographics Made Easy
chrislema
238
18k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
36
9.1k
Facilitating Awesome Meetings
lara
46
5.8k
Java REST API Framework Comparison - PWX 2021
mraible
PRO
20
7.2k
Stop Working from a Prison Cell
hatefulcrawdad
266
20k
Put a Button on it: Removing Barriers to Going Fast.
kastner
58
3.3k
Transcript
社内サービスのUI改善 #bcu30 #client_10 2018/04/21
⾃⼰紹介 • 名前/Twitter • 松岡 紀⾏/@nemupm • 略歴 • 2016/03
⼤阪⼤学⼤学院 修了 • 2016/04 グリー株式会社 新卒⼊社 • 業務 • データ分析基盤の開発・運⽤ 尾道で撮った猫
社内サービス使ってますか?
社内サービスとは のことではなく 内製で運⽤している独⾃サービス
グリーの分析基盤サービス Powers-of-Ten(PoT) • 社内の様々なプロダクトのログを分析するための基盤サービス • 有名な分析基盤サービスの例 • Treasure Data •
Google BigQuery • Amazon Redshift
グリーの分析基盤サービス Powers-of-Ten(PoT) • グリーでは様々な理由によりPoTを内製している • 分析のクラウドサービスが少なかった時代に 内製されたサービスの後継であるため • 社内の要求を満たすように開発されてきた全ての機能を 外部のサービスで提供することが難しいため
• コストの削減のため • 使⽤⼈数規模:300⼈以上、使⽤プロダクト数:約40
この分析基盤サービスPoTが 抱える問題
UIのユーザビリティが低い
ユーザビリティが低い例① 分かりにくいUI
分かりにくいUI例(実際のPoTの画⾯)
分かりにくいUI例(実際のPoTの画⾯) メニューが多く アイコンも無い
分かりにくいUI例(実際のPoTの画⾯) よくわからない沢⼭のフォームが 乱雑に置かれている
ユーザビリティが低い例② 最低限のUI
最低限のUI例(実際のPoTの画⾯)
最低限のUI例(実際のPoTの画⾯) PoTをよく使う⼈にとっては物⾜りない(⾮効率な)UI
なぜUIがなかなか改善されないのか • 各メンバーの考える問題点・改善案が異なるため • もとのUIが昔の内製サービスの継ぎ接ぎであり、 根本的なUIの設計を変えづらいため • UIに詳しいエンジニアがチームに居ないため
なぜUIが⼤事なのか UIが分かりにくいと • 初学者にとってサービス利⽤のハードルが⾼くなる →ユーザ数が増えない UIが最低限しか無いと • 熟練者にとって冗⻑な操作が多くなる →ユーザの業務効率を下げてしまう
そこで、UI改善プロジェクトを ⽴ち上げました
今⽇話したいこと UIのプロが居ないチーム、という⽴場から、 UIを改善するプロジェクトを進める上で • やってよかったこと • 苦労したこと を話します 注:プロジェクトはまだ終わってないため、あくまで現時点での所感です
プロジェクト概要 • ⽬的 • データ分析基盤サービスPoTのフロントエンド部分について 利⽤者視点からUI/UXを再考してリプレイス • システム構成 APIサーバ リプレイス部分
EMR, S3などの データ基盤 バックエンド
やってよかったこと5つ
1.スクラム開発 • バックエンドだと最初に設計をすべて決めることが多い(多分) • 今回のようにフロントエンドのUIを真⾯⽬に考えた時、 最初に理想的なUIをすべて決めるのが難しかった • 考えたUIが良いか悪いか判断できない • そもそも具体的な案が出づらい
仮UIを触りながら仕様を考えることで、 納得感をもって仕様を議論できた
2.仕様チームと開発チームに分割 ⼯数を考えない議論の場を仕組みとして担保できるため 実装しやすい仕様に偏ることを防げた 仕様チーム 理想的なUIを議論 仕様チーム 開発チーム 全員で改めて 実現可能性も含めて 議論
3.定期的な社内公開 • 1ヶ⽉に1回ほど、社内のいくつかのチームに向けてβ版を公開 • 途中でだれない • フィードバックが貰える • 開発のアピールになる β1公開
β2公開 クエリ機能の開発 グラフ機能の開発
4.β版公開ごとにKPTの実施 • スクラム開発に則り KPT(Keep, Problem, Try)を実施 • 楽しく議論できるように お菓⼦やコーヒーも導⼊ プロジェクトの進め⽅について
合意形成しながら改善できた お菓⼦を買いすぎた図
5.デザイン⾯は社内の専⾨チームに相談 • 定期的に相談して フィードバックを貰う ⾒た⽬・UIの品質が⼤幅に上がり ユーザに印象良く触ってもらうことが出来た プロジェクト初期に参考として→ 作ってもらった画⾯イメージ
⼀⽅で、苦労していることもあります
開発チームのエンジニアの⽴場から⾒て、 フロントエンドについて 苦労したこと2つ データ 注:フロントエンドに限らない問題ではありますが悪しからず
1.ベストプラクティス分からない問題 • (SPAの)設計ベストプラクティスが分からない • みんな⾔ってることが違ったりする • ライブラリが多すぎて選定が難しい • 同じようなライブラリが乱⽴してたりする 現状の対策
• 関連記事を徹底的に探す・OSSを参考にする • Githubのスター数やGoogle trendsを参考にする
2.⼯数⾒積が難しい問題 • 今回、仕様チームにUIの仕様ごとにチケットを作成してもらった 仕様1を実装するタスクA チケットごとにかかる時間がばらばら(数⼗分〜数⽇) 仕様2を実装するタスクB 仕様チームが作成したチケット 開発チームが考える実際のタスク • モデルの設計(Rails/Angular)
• APIの作成 • データベース作成 • JSライブラリの検証・選定 • レイアウト作成 粒度のずれ … …
2.⼯数⾒積が難しい問題 結果、進捗の遅れの検知が困難になる 現状の対策 • 開発チーム側でもチケットを作成する • 開発しやすい粒度で⼩⽬標を⽴てる
このように⼯夫・苦労しながら 進めているプロジェクト その現状について
画⾯例① BEFORE
画⾯例① AFTER(開発中)
画⾯例② BEFORE
画⾯例② AFTER (開発中)
慣れてない分野のために つまずくことは多々ありますが
⼤事なのは⽇々改善する意識と、 そのための仕組みづくりだと感じます
皆さんの⼿で⾝の回りの『当たり前』を 改善していきましょう!
ありがとうございました