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
350
社内サービスの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
今この時代に技術とどう向き合うべきか
gree_tech
PRO
2
2k
生成AIを開発組織にインストールするために: REALITYにおけるガバナンス・技術・文化へのアプローチ
gree_tech
PRO
0
37
安く・手軽に・現場発 既存資産を生かすSlack×AI検索Botの作り方
gree_tech
PRO
0
27
生成AIを安心して活用するために──「情報セキュリティガイドライン」策定とポイント
gree_tech
PRO
0
37
あうもんと学ぶGenAIOps
gree_tech
PRO
0
20
MVP開発における生成AIの活用と導入事例
gree_tech
PRO
0
33
機械学習・生成AIが拓く事業価値創出の最前線
gree_tech
PRO
0
48
コンテンツモデレーションにおける適切な監査範囲の考察
gree_tech
PRO
0
20
新サービス立ち上げの裏側 - QUANT for Shopsで実践した開発から運用まで
gree_tech
PRO
0
24
Other Decks in Technology
See All in Technology
そのWAFのブロック、どう活かす? サービスを守るための実践的多層防御と思考法 / WAF blocks defense decision
kaminashi
0
200
Dylib Hijacking on macOS: Dead or Alive?
patrickwardle
0
280
[Codex Meetup Japan #1] Codex-Powered Mobile Apps Development
korodroid
2
980
プロダクトのコードから見るGoによるデザインパターンの実践 #go_night_talk
bengo4com
1
2.6k
名刺メーカーDevグループ 紹介資料
sansan33
PRO
0
930
初めてのDatabricks Apps開発
taka_aki
1
130
GoでもGUIアプリを作りたい!
kworkdev
PRO
0
150
サイバーエージェント流クラウドコスト削減施策「みんなで金塊堀太郎」
kurochan
4
2.1k
ガバメントクラウド(AWS)へのデータ移行戦略の立て方【虎の巻】 / 20251011 Mitsutosi Matsuo
shift_evolve
PRO
2
200
物体検出モデルでシイタケの収穫時期を自動判定してみた。 #devio2025
lamaglama39
0
230
LLMアプリの地上戦開発計画と運用実践 / 2025.10.15 GPU UNITE 2025
smiyawaki0820
1
630
なぜAWSを活かしきれないのか?技術と組織への処方箋
nrinetcom
PRO
5
980
Featured
See All Featured
Docker and Python
trallard
46
3.6k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
234
17k
How to Think Like a Performance Engineer
csswizardry
27
2k
YesSQL, Process and Tooling at Scale
rocio
173
14k
Code Reviewing Like a Champion
maltzj
526
40k
How GitHub (no longer) Works
holman
315
140k
Large-scale JavaScript Application Architecture
addyosmani
514
110k
Writing Fast Ruby
sferik
629
62k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
46
7.7k
The Art of Programming - Codeland 2020
erikaheidi
56
14k
Balancing Empowerment & Direction
lara
5
690
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
333
22k
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 (開発中)
慣れてない分野のために つまずくことは多々ありますが
⼤事なのは⽇々改善する意識と、 そのための仕組みづくりだと感じます
皆さんの⼿で⾝の回りの『当たり前』を 改善していきましょう!
ありがとうございました