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
330
社内サービスの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
コミュニケーションに鍵を見いだす、エンジニア1年目の経験談
gree_tech
PRO
0
140
REALITY株式会社における開発生産性向上の取り組み: 失敗と成功から学んだこと
gree_tech
PRO
2
1.9k
『ヘブンバーンズレッド』におけるフィールドギミックの裏側
gree_tech
PRO
2
650
セキュリティインシデント対応の体制・運用の試行錯誤 / greetechcon2024-session-a1
gree_tech
PRO
1
670
『アナザーエデン 時空を超える猫』国内海外同時運営実現への道のり ~別々で開発されたアプリを安定して同時リリースするまでの取り組み~
gree_tech
PRO
1
620
『アサルトリリィ Last Bullet』におけるクラウドストリーミング技術を用いたブラウザゲーム化の紹介
gree_tech
PRO
1
730
UnityによるPCアプリの新しい選択肢。「PC版 Google Play Games」への対応について
gree_tech
PRO
1
1.1k
実機ビルドのエラーによる検証ブロッカーを0に!『ヘブンバーンズレッド』のスモークテスト自動化の取り組み
gree_tech
PRO
1
720
"ゲームQA業界の技術向上を目指す! 会社を超えた研究会の取り組み"
gree_tech
PRO
1
890
Other Decks in Technology
See All in Technology
microCMS 最新リリース情報(microCMS Meetup 2025)
microcms
0
120
つくって納得、つかって実感! 大規模言語モデルことはじめ
recruitengineers
PRO
25
6.8k
LLMエージェント時代に適応した開発フロー
hiragram
1
420
Preferred Networks (PFN) とLLM Post-Training チームの紹介 / 第4回 関東Kaggler会 スポンサーセッション
pfn
PRO
1
250
VPC Latticeのサービスエンドポイント機能を使用した複数VPCアクセス
duelist2020jp
0
270
Evolution on AI Agent and Beyond - AGI への道のりと、シンギュラリティの3つのシナリオ
masayamoriofficial
0
190
mruby(PicoRuby)で ファミコン音楽を奏でる
kishima
1
290
Product Management Conference -AI時代に進化するPdM-
kojima111
0
220
Go で言うところのアレは TypeScript で言うとコレ / Kyoto.なんか #7
susisu
7
1.9k
会社にデータエンジニアがいることでできるようになること
10xinc
9
1.6k
Devinを使ったモバイルアプリ開発 / Mobile app development with Devin
yanzm
0
190
AIとTDDによるNext.js「隙間ツール」開発の実践
makotot
6
720
Featured
See All Featured
Making Projects Easy
brettharned
117
6.3k
How to train your dragon (web standard)
notwaldorf
96
6.2k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
234
17k
Building Better People: How to give real-time feedback that sticks.
wjessup
367
19k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
10
1k
Embracing the Ebb and Flow
colly
87
4.8k
4 Signs Your Business is Dying
shpigford
184
22k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
23
1.4k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
49
3k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
667
120k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
139
34k
We Have a Design System, Now What?
morganepeng
53
7.7k
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 (開発中)
慣れてない分野のために つまずくことは多々ありますが
⼤事なのは⽇々改善する意識と、 そのための仕組みづくりだと感じます
皆さんの⼿で⾝の回りの『当たり前』を 改善していきましょう!
ありがとうございました