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
『「改善Dayを作ろう!」って言ってたけど気づいたらなくなったよね…』を繰り返さないために /...
Search
Tomohiro Imaizumi
November 22, 2018
Programming
0
2k
『「改善Dayを作ろう!」って言ってたけど気づいたらなくなったよね…』を繰り返さないために / Things to Achieve Continuous Improvement in Your Development
Diverse Tech #1 〜レガシーシステムを語らう夜〜 での発表資料です。
https://diverse.connpass.com/event/107355/
Tomohiro Imaizumi
November 22, 2018
Tweet
Share
More Decks by Tomohiro Imaizumi
See All by Tomohiro Imaizumi
Feature Flagを使った開発で高速かつストレスフリーなデリバリーを実現する / Fast and stress-free delivery with Feature Flag-based development
imaizume
2
3.5k
プロダクトグロースと技術のベースアップを両立させるRettyのアプリ開発スタイル / Achieve Product Growth and Tech Update
imaizume
1
750
git branchを自由に操れるようになろう / Let's Play with Git branch!
imaizume
2
1.1k
スナップショットテスト実戦投入 / Practical Snapshot Testing
imaizume
13
7k
コーディング以外のエンジニアリング / About Engineering Without Coding
imaizume
1
1.7k
Firebase Remote Configの運用で知ったこと・知っておくと良いこと / Things I Learned from Operation of Firebase Remote Config
imaizume
6
3.9k
iOSアプリのテストを書きたいのに書けないあなたへ / How You Should Start to Write Your First Unit Test for iOS
imaizume
6
4.9k
循環的複雑度を上げないためのSwiftプログラミングTips / Tips of Swift Programming to Reduce Code Complexity
imaizume
11
8k
シングルトンではじめる状態管理と依存注入 / A way to control state using singleton pattern
imaizume
0
4.7k
Other Decks in Programming
See All in Programming
3 Effective Rules for Using Signals in Angular
manfredsteyer
PRO
0
120
Macとオーディオ再生 2024/11/02
yusukeito
0
370
TypeScriptでライブラリとの依存を限定的にする方法
tutinoko
3
690
距離関数を極める! / SESSIONS 2024
gam0022
0
290
レガシーシステムにどう立ち向かうか 複雑さと理想と現実/vs-legacy
suzukihoge
14
2.2k
Nurturing OpenJDK distribution: Eclipse Temurin Success History and plan
ivargrimstad
0
960
Micro Frontends Unmasked Opportunities, Challenges, Alternatives
manfredsteyer
PRO
0
110
EMになってからチームの成果を最大化するために取り組んだこと/ Maximize team performance as EM
nashiusagi
0
100
3 Effective Rules for Using Signals in Angular
manfredsteyer
PRO
0
100
cmp.Or に感動した
otakakot
3
200
WebフロントエンドにおけるGraphQL(あるいはバックエンドのAPI)との向き合い方 / #241106_plk_frontend
izumin5210
4
1.4k
Why Jakarta EE Matters to Spring - and Vice Versa
ivargrimstad
0
1.1k
Featured
See All Featured
A Modern Web Designer's Workflow
chriscoyier
693
190k
Happy Clients
brianwarren
98
6.7k
Facilitating Awesome Meetings
lara
50
6.1k
How GitHub (no longer) Works
holman
310
140k
What's new in Ruby 2.0
geeforr
343
31k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
48k
Unsuck your backbone
ammeep
668
57k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
26
1.4k
YesSQL, Process and Tooling at Scale
rocio
169
14k
jQuery: Nuts, Bolts and Bling
dougneiner
61
7.5k
Art, The Web, and Tiny UX
lynnandtonic
297
20k
Building Flexible Design Systems
yeseniaperezcruz
327
38k
Transcript
『「改善Dayを作ろう!」 って言ってたけど 気づいたらなくなったよね…』 を繰り返さないために Diverse.tech #1 〜レガシーシステムを語らう夜〜 @imaizume
‣ 今泉 智博 @imaizume ‣ 2017年株式会社ミクシィ新卒入社 ‣ 現在株式会社 所属 ‣
iOS利用経験0から iOS版開発担当に ‣ 完全栄養食 COMP歴2年目に突入(健康です!) ‣ Gitの勉強会とかやってます(Speaker Deck)
とは❓
Diverseが運営する カジュアルマッチングアプリ❤
今日のテーマは「レガシーシステム」 (言語/仕様/開発環境 etc..) ですが、もう少し話題を広げて 「改善の話」をします
https://twitter.com/hiroki_daichi/status/1055447434560602118
https://twitter.com/hiroki_daichi/status/1055447434560602118 「ソフトウェアは腐る」 新規実装も時間経過により腐敗する 「腐敗」=「レガシー」と捉えた場合 継続的なレガシーの返済が必要
言語変更 普段の業務と並行でやるのは難しい… ところがレガシー返済で やるべきことはたくさん❗ ライブラリ更新 テスト導入 自動化 マイクロサービス Fat Controller解体
数値計測 仕様整理 リファクタリング クラウド化 ドキュメンテーション
そこであなたは チームメンバーにこう言います 「毎週金曜日を改善Dayにしよう!!」 改善Day(的なもの)をTryした経験のある人
ところが数週間後のあなたは… 突然の仕様変更 差し込みタスク 不意のバグ発生 PMからの要求 残業 終わらぬQA 仕様漏れの発覚 見積もり通りに仕事が終わらない!!
『「毎週金曜日を改善Dayにしよう!!」 って言ってたけど気づいたらなくなったよね...』 改善Day(的なもの)をTryして失敗した経験のある人 そして振り返ってこう思います
毎週の工数見積と 改善DayをTRYしたが… かつてのPoiboyもそうでした ほぼ守られなかった当時の工数見積 継続しなかった ノーアーキテクチャ ノーテスト 手動ビルド/アーカイブ 複雑な仕様 無限に湧き出るバグ
Fat ViewController
しかしその後数々のTryを経て チームに改善Dayが定着 Poiboyはどのようにして 改善Dayを手に入れたのか
「組織的な改善活動を成功させる手順」 (川瀬武志. IE問題の基礎, 2007) 1. 問題・現状の認識 2. 意識的努力 3. 目標達成度を測る定量的尺度の作成
4. 人・お金・時間・行動の自由度 1. 問題・現状の認識と共有 2. (マンパワー依存を捨てる)意識的努力 3. 定量的尺度+目標達成感 4. 人・お金・時間・行動の自由 imaizume流にUpdateすると… 実はこっちが大切 = 改善Day
問題・現状の認識と共有 改善/レガシー返済に対する価値を チームが理解すること
PMから見えていた問題 • 仕様の複雑化をやめたい • 見積り通りの工数で作業したい • ボトムアップの改善策をやりたい エンジニアから見えていた問題 • 短期間で数値目標を達成したい
• 施策をどんどん投入したい • 数字に直結するタスクの優先度を上げたい エンジニアへ要求 PMへ要求 改善したい!! 頑張ってほしい!!
PM陣から見えていた問題 • 仕様の複雑化をやめたい • 見積通りの工数で作業したい • 継続的改善をしたい 当時のiOSチームから見えていた問題 • 短期間で数値目標を達成したい
• 施策をどんどん投入したい • 数字に直結するタスクの優先度を上げたい エンジニアへ要求 PM陣へ要求 改善したい!! 頑張ってほしい!! 互いの意見がぶつかり 価値観が合わない状態
しかし改善の効果は不確実 効果測定が難しい 本当はやりたかった説得の例 Poiboyが変わった本当のきっかけとは❓ ✓ 売り上げUPには開発速度が必要 ✓ 開発速度向上には◦◦の導入が必要 ✓ 導入にはX時間必要
✓ 1ヶ月に発生する作業がN回と仮定 ✓ トータルではY時間短縮できる ✓ なので改善時間をX時間ください!
見えない終わり オーバーワークで開発メンバーが疲弊 サービス開発が楽しくない 改善見込み無し 無謀なスケジュール 締切だけが決定 勝手に決まる施策 優秀なメンバーが外部へ流出 レガシーな開発体制 当時の現場の様子
見えない終わり オーバーワークで疲弊 サービス開発が楽しくない 改善見込み無し 無謀なスケジュール 締切だけが決定 勝手に決まる施策 優秀なメンバーが外部へ流出 レガシーな開発体制 サービス・会社の成長のため
人材流出を防ぎたい!! 盤石な開発体制を作りたい!! 働く環境・開発体制を見直し
2018年4月 Poiboyはスクラム開発に移行 同年8月 PoiboyでOKRを試験導入
Poiboyでのスクラム開発の流れ スプリント バックログに TODOを追加 工数見積もりと 内容共有を実施 WANT TODO DOING OKRの重要度と緊急度
の2軸でマッピングし 両者が高いものを優先 スプリント終わりに 振り返りとKPTを実施 毎朝の朝会で 進捗や困り事を 全員に共有 スプリント内に タスクを完了できるよう 作業
Poiboyでのスクラム開発の流れ スプリント バックログに TODOを追加 工数見積もりと 内容共有を実施 WANT TODO DOING OKRの重要度と緊急度
の2軸でマッピングし 両者が高いものを優先 スプリント終わりに 振り返りとKPTを実施 毎朝の朝会で 進捗や困り事を 全員に共有 スプリント内に タスクを完了できるよう 作業 エンジニア以外 から提案が可能 チームの能力を 考慮した開発へ 全員で問題認識を共有 全員のTODOと 進捗が可視化 タスクの重要性を 説明する機会 無理のない 柔軟な計画変更 全員で改善策を 考え共有する 早く終われば 他のタスクをやって良い
Poiboyでのスクラム開発の流れ スプリント バックログに TODOを追加 工数見積もりと 内容共有を実施 WANT TODO DOING OKRの重要度と緊急度
の2軸でマッピングし 両者が高いものを優先 スプリント終わりに 振り返りとKPTを実施 毎朝の朝会で 進捗や困り事を 全員に共有 スプリント内に タスクを完了できるよう 作業 エンジニア以外 から提案が可能 チームの能力を 考慮した開発へ 全員で問題認識を共有 全員のTODOと 進捗が可視化 タスクの重要性を 説明する機会 無理のない 柔軟な計画変更 全員で改善策を 考え共有する 早く終われば 他のタスクをやって良い 開発体制の見直し + 「継続的改善がグロースには必要」 という認識の共有
(補足)スクラム開発導入時のポイント スクラム導入はスタート 継続的改善ができるまで改良する 見積もり精度を上げることで徐々に余裕が生まれる (最初は見積もり通りには終わらないので頑張る) スプリント期間2週間のうち2日間を改善Dayに (ただしチームで必要性が認められてから生まれた) レガシー返済の価値を分かりやすく提案する必要性 (「価値がある」とチームに判断してもらうため)
定量的尺度+目標達成感 改善活動の効果測定と認識
改善の効果を測定する 例: タスク見積もりの精度を計測する GitHubに工数をコメントすると SpreadSheetへ記録してくれるGAS作りました github.com/imaizume/github-record-time > ⾒積りと実績を⽐べて正確さを増していくという繰り返しをすれば、 ⾒積りの精度は⾼くなっていきます。 (広木大地.
エンジニアリング組織論への招待, 2018) チーム全体の工数測定の様子 個人タスクの工数測定の様子
改善の効果を測定する 例: タスク見積もりの精度を計測する githubに工数をコメントすると SpreadSheetへ記録してくれるGAS作りました github.com/imaizume/github-record-time > ⾒積りと実績を⽐べて正確さを増していくという繰り返しをすれば、 ⾒積りの精度は⾼くなっていきます。 (広木大地.
エンジニアリング組織論への招待, 2018) チーム全体の工数測定の様子 個人タスクの工数測定の様子 どんな改善でも 効果を数値測定できるのか??
言語置き換えの効果予測・測定は困難… 効果測定しにくい改善 例: レガシーな言語をモダンな言語で置き換える 会社・サービスの状況 • サービス/チームの目標 • サービスの成長度合い •
立ち上げ期 or 安定期 • チーム/予算規模 レガシーのデメリット • 目標に対する足かせ度合い • 安全性(サポート切れとか) • 採用における劣位性 • サービス信頼性への影響 会社・サービス目標/状況との関係性を明らかに
言語置き換えの効果予測・測定は困難… 効果測定しにくい改善 例: レガシーな言語をモダンな言語で置き換える レガシーのデメリット 会社・サービスの状況 • サービス/チームの目標 • サービスの成長度合い
• 立ち上げ期 or 安定期 • チーム/予算規模 • 目標に対する足かせ度合い • 安全性(サポート切れとか) • 採用における劣位性 • サービス信頼性への影響 会社・サービス目標/状況との関係性を明らかに 「ビジネス要求に応えるための改善」 であることを伝えていく
スプリント最終日にウィンセッションを開催 飲食しながら全員の作業進捗と成果報告を行う 「進捗感」をチームで共有する 定量化できない進捗も 可視化してチームで認識・共有
まとめ 継続的改善を行うために 問題認識と共有 効果測定 開発体制 チームメンバーが同じ課題意識を持つ 改善の意義を考え効果を測る・振り返る 継続的改善をエンジニアだけのものにしない 改善Dayを作る前に見直してみましょう!