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
LLM翻訳ツールの開発と海外のお客様対応等への社内導入事例
gree_tech
PRO
0
890
ヘブンバーンズレッドのレンダリングパイプライン刷新
gree_tech
PRO
0
900
ヘブンバーンズレッドにおける、世界観を活かしたミニゲーム企画の作り方
gree_tech
PRO
0
900
「魔法少女まどか☆マギカ Magia Exedra」のグローバル展開を支える、開発チームと翻訳チームの「意識しない協創」を実現するローカライズシステム
gree_tech
PRO
0
880
「魔法少女まどか☆マギカ Magia Exedra」での負荷試験の実践と学び
gree_tech
PRO
0
980
「魔法少女まどか☆マギカ Magia Exedra」の必殺技演出を徹底解剖! -キャラクターの魅力を最大限にファンに届けるためのこだわり-
gree_tech
PRO
0
900
ヒューリスティック評価を用いたゲームQA実践事例
gree_tech
PRO
0
890
ライブサービスゲームQAのパフォーマンス検証による品質改善の取り組み
gree_tech
PRO
0
890
コミュニケーションに鍵を見いだす、エンジニア1年目の経験談
gree_tech
PRO
0
150
Other Decks in Technology
See All in Technology
Shirankedo NOCで見えてきたeduroam/OpenRoaming運用ノウハウと課題 - BAKUCHIKU BANBAN #2
marokiki
0
190
やる気のない自分との向き合い方/How to Deal with Your Unmotivated Self
sanogemaru
0
490
リーダーになったら未来を語れるようになろう/Speak the Future
sanogemaru
0
390
PHPからはじめるコンピュータアーキテクチャ / From Scripts to Silicon: A Journey Through the Layers of Computing Hiroshima 2025 Edition
tomzoh
0
130
セキュアな認可付きリモートMCPサーバーをAWSマネージドサービスでつくろう! / Let's build an OAuth protected remote MCP server based on AWS managed services
kaminashi
3
310
Simplifying Cloud Native app testing across environments with Dapr and Microcks
salaboy
0
140
Reflections of AI: A Trilogy in Four Parts (GOTO; Copenhagen 2025)
ondfisk
0
110
サイバーエージェント流クラウドコスト削減施策「みんなで金塊堀太郎」
kurochan
0
270
Git in Team
kawaguti
PRO
3
360
ニッポンの人に知ってもらいたいGISスポット
sakaik
0
120
AI時代こそ求められる設計力- AWSクラウドデザインパターン3選で信頼性と拡張性を高める-
kenichirokimura
3
300
綺麗なデータマートをつくろう_データ整備を前向きに考える会 / Let's create clean data mart
brainpadpr
3
440
Featured
See All Featured
How to Think Like a Performance Engineer
csswizardry
27
2k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
359
30k
A Tale of Four Properties
chriscoyier
161
23k
The Invisible Side of Design
smashingmag
302
51k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
34
6.1k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
Navigating Team Friction
lara
190
15k
Context Engineering - Making Every Token Count
addyosmani
6
240
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
333
22k
Stop Working from a Prison Cell
hatefulcrawdad
271
21k
What's in a price? How to price your products and services
michaelherold
246
12k
Done Done
chrislema
185
16k
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 (開発中)
慣れてない分野のために つまずくことは多々ありますが
⼤事なのは⽇々改善する意識と、 そのための仕組みづくりだと感じます
皆さんの⼿で⾝の回りの『当たり前』を 改善していきましょう!
ありがとうございました