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.8k
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
7.9k
シングルトンではじめる状態管理と依存注入 / A way to control state using singleton pattern
imaizume
0
4.7k
Other Decks in Programming
See All in Programming
飲食業界向けマルチプロダクトを実現させる開発体制とリアルな現状
hiroya0601
1
390
デプロイを任されたので、教わった通りにデプロイしたら障害になった件 ~俺のやらかしを越えてゆけ~
techouse
52
32k
/←このスケジュール表に立ち向かう フロントエンド開発戦略 / A front-end development strategy to tackle a single-slash schedule.
nrslib
1
590
GCCのプラグインを作る / I Made a GCC Plugin
shouth
1
150
From Subtype Polymorphism To Typeclass-based Ad hoc Polymorphism- An Example
philipschwarz
PRO
0
160
Modern Angular: Renovation for Your Applications
manfredsteyer
PRO
0
200
とにかくAWS GameDay!AWSは世界の共通言語! / Anyway, AWS GameDay! AWS is the world's lingua franca!
seike460
PRO
1
530
アジャイルを支えるテストアーキテクチャ設計/Test Architecting for Agile
goyoki
7
2.8k
Importmapを使ったJavaScriptの 読み込みとブラウザアドオンの影響
swamp09
4
1.2k
Honoの来た道とこれから
yusukebe
19
3k
役立つログに取り組もう
irof
26
8.6k
Amazon Neptuneで始めてみるグラフDB-OpenSearchによるグラフの全文検索-
satoshi256kbyte
4
310
Featured
See All Featured
BBQ
matthewcrist
85
9.3k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
47
5k
GitHub's CSS Performance
jonrohan
1030
460k
The Pragmatic Product Professional
lauravandoore
31
6.3k
The Art of Programming - Codeland 2020
erikaheidi
51
13k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
364
22k
GraphQLとの向き合い方2022年版
quramy
43
13k
Keith and Marios Guide to Fast Websites
keithpitt
408
22k
Java REST API Framework Comparison - PWX 2021
mraible
PRO
28
7.9k
Producing Creativity
orderedlist
PRO
341
39k
Navigating Team Friction
lara
183
14k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
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を作る前に見直してみましょう!