『「改善Dayを作ろう!」って言ってたけど気づいたらなくなったよね…』を繰り返さないために / Things to Achieve Continuous Improvement in Your Development

Diverse Tech #1 〜レガシーシステムを語らう夜〜 での発表資料です。
https://diverse.connpass.com/event/107355/

Transcript

1. 『「改善Dayを作ろう!」 って言ってたけど 気づいたらなくなったよね…』 を繰り返さないために Diverse.tech #1 〜レガシーシステムを語らう夜〜 @imaizume
2. ‣ 今泉 智博 @imaizume ‣ 2017年株式会社ミクシィ新卒入社 ‣ 現在株式会社 所属 ‣ iOS利用経験0から iOS版開発担当に ‣ 完全栄養食 COMP歴2年目に突入(健康です!) ‣ Gitの勉強会とかやってます(Speaker Deck)
3. とは❓
4. Diverseが運営する カジュアルマッチングアプリ❤
5. 今日のテーマは「レガシーシステム」 (言語/仕様/開発環境 etc..) ですが、もう少し話題を広げて 「改善の話」をします
6. https://twitter.com/hiroki_daichi/status/1055447434560602118
7. https://twitter.com/hiroki_daichi/status/1055447434560602118 「ソフトウェアは腐る」 新規実装も時間経過により腐敗する 「腐敗」=「レガシー」と捉えた場合 継続的なレガシーの返済が必要
8. 言語変更 普段の業務と並行でやるのは難しい… ところがレガシー返済で やるべきことはたくさん❗ ライブラリ更新 テスト導入 自動化 マイクロサービス Fat Controller解体 数値計測 仕様整理 リファクタリング クラウド化 ドキュメンテーション
9. そこであなたは チームメンバーにこう言います 「毎週金曜日を改善Dayにしよう!!」 改善Day(的なもの)をTryした経験のある人
10. ところが数週間後のあなたは… 突然の仕様変更 差し込みタスク 不意のバグ発生 PMからの要求 残業 終わらぬQA 仕様漏れの発覚 見積もり通りに仕事が終わらない!!
11. 『「毎週金曜日を改善Dayにしよう!!」 って言ってたけど気づいたらなくなったよね...』 改善Day(的なもの)をTryして失敗した経験のある人 そして振り返ってこう思います
12. 毎週の工数見積と 改善DayをTRYしたが… かつてのPoiboyもそうでした ほぼ守られなかった当時の工数見積 継続しなかった ノーアーキテクチャ ノーテスト 手動ビルド/アーカイブ 複雑な仕様 無限に湧き出るバグ Fat ViewController
13. しかしその後数々のTryを経て チームに改善Dayが定着 Poiboyはどのようにして 改善Dayを手に入れたのか
14. 「組織的な改善活動を成功させる手順」 (川瀬武志. IE問題の基礎, 2007) 1. 問題・現状の認識 2. 意識的努力 3. 目標達成度を測る定量的尺度の作成 4. 人・お金・時間・行動の自由度 1. 問題・現状の認識と共有 2. (マンパワー依存を捨てる)意識的努力 3. 定量的尺度+目標達成感 4. 人・お金・時間・行動の自由 imaizume流にUpdateすると… 実はこっちが大切 = 改善Day
15. 問題・現状の認識と共有 改善/レガシー返済に対する価値を チームが理解すること
16. PMから見えていた問題 • 仕様の複雑化をやめたい • 見積り通りの工数で作業したい • ボトムアップの改善策をやりたい エンジニアから見えていた問題 • 短期間で数値目標を達成したい • 施策をどんどん投入したい • 数字に直結するタスクの優先度を上げたい エンジニアへ要求 PMへ要求 改善したい!! 頑張ってほしい!!
17. PM陣から見えていた問題 • 仕様の複雑化をやめたい • 見積通りの工数で作業したい • 継続的改善をしたい 当時のiOSチームから見えていた問題 • 短期間で数値目標を達成したい • 施策をどんどん投入したい • 数字に直結するタスクの優先度を上げたい エンジニアへ要求 PM陣へ要求 改善したい!! 頑張ってほしい!! 互いの意見がぶつかり 価値観が合わない状態
18. しかし改善の効果は不確実 効果測定が難しい 本当はやりたかった説得の例 Poiboyが変わった本当のきっかけとは❓ ✓ 売り上げUPには開発速度が必要 ✓ 開発速度向上には◦◦の導入が必要 ✓ 導入にはX時間必要 ✓ 1ヶ月に発生する作業がN回と仮定 ✓ トータルではY時間短縮できる ✓ なので改善時間をX時間ください!
19. 見えない終わり オーバーワークで開発メンバーが疲弊 サービス開発が楽しくない 改善見込み無し 無謀なスケジュール 締切だけが決定 勝手に決まる施策 優秀なメンバーが外部へ流出 レガシーな開発体制 当時の現場の様子
20. 見えない終わり オーバーワークで疲弊 サービス開発が楽しくない 改善見込み無し 無謀なスケジュール 締切だけが決定 勝手に決まる施策 優秀なメンバーが外部へ流出 レガシーな開発体制 サービス・会社の成長のため 人材流出を防ぎたい!! 盤石な開発体制を作りたい!! 働く環境・開発体制を見直し
21. 2018年4月 Poiboyはスクラム開発に移行 同年8月 PoiboyでOKRを試験導入
22. Poiboyでのスクラム開発の流れ スプリント バックログに TODOを追加 工数見積もりと 内容共有を実施 WANT TODO DOING OKRの重要度と緊急度 の2軸でマッピングし 両者が高いものを優先 スプリント終わりに 振り返りとKPTを実施 毎朝の朝会で 進捗や困り事を 全員に共有 スプリント内に タスクを完了できるよう 作業
23. Poiboyでのスクラム開発の流れ スプリント バックログに TODOを追加 工数見積もりと 内容共有を実施 WANT TODO DOING OKRの重要度と緊急度 の2軸でマッピングし 両者が高いものを優先 スプリント終わりに 振り返りとKPTを実施 毎朝の朝会で 進捗や困り事を 全員に共有 スプリント内に タスクを完了できるよう 作業 エンジニア以外 から提案が可能 チームの能力を 考慮した開発へ 全員で問題認識を共有 全員のTODOと 進捗が可視化 タスクの重要性を 説明する機会 無理のない 柔軟な計画変更 全員で改善策を 考え共有する 早く終われば 他のタスクをやって良い
24. Poiboyでのスクラム開発の流れ スプリント バックログに TODOを追加 工数見積もりと 内容共有を実施 WANT TODO DOING OKRの重要度と緊急度 の2軸でマッピングし 両者が高いものを優先 スプリント終わりに 振り返りとKPTを実施 毎朝の朝会で 進捗や困り事を 全員に共有 スプリント内に タスクを完了できるよう 作業 エンジニア以外 から提案が可能 チームの能力を 考慮した開発へ 全員で問題認識を共有 全員のTODOと 進捗が可視化 タスクの重要性を 説明する機会 無理のない 柔軟な計画変更 全員で改善策を 考え共有する 早く終われば 他のタスクをやって良い 開発体制の見直し + 「継続的改善がグロースには必要」 という認識の共有
25. (補足)スクラム開発導入時のポイント スクラム導入はスタート 継続的改善ができるまで改良する 見積もり精度を上げることで徐々に余裕が生まれる (最初は見積もり通りには終わらないので頑張る) スプリント期間2週間のうち2日間を改善Dayに (ただしチームで必要性が認められてから生まれた) レガシー返済の価値を分かりやすく提案する必要性 (「価値がある」とチームに判断してもらうため)
26. 定量的尺度+目標達成感 改善活動の効果測定と認識
27. 改善の効果を測定する 例: タスク見積もりの精度を計測する GitHubに工数をコメントすると SpreadSheetへ記録してくれるGAS作りました github.com/imaizume/github-record-time > ⾒積りと実績を⽐べて正確さを増していくという繰り返しをすれば、 ⾒積りの精度は⾼くなっていきます。 (広木大地. エンジニアリング組織論への招待, 2018) チーム全体の工数測定の様子 個人タスクの工数測定の様子
28. 改善の効果を測定する 例: タスク見積もりの精度を計測する githubに工数をコメントすると SpreadSheetへ記録してくれるGAS作りました github.com/imaizume/github-record-time > ⾒積りと実績を⽐べて正確さを増していくという繰り返しをすれば、 ⾒積りの精度は⾼くなっていきます。 (広木大地. エンジニアリング組織論への招待, 2018) チーム全体の工数測定の様子 個人タスクの工数測定の様子 どんな改善でも 効果を数値測定できるのか??
29. 言語置き換えの効果予測・測定は困難… 効果測定しにくい改善 例: レガシーな言語をモダンな言語で置き換える 会社・サービスの状況 • サービス/チームの目標 • サービスの成長度合い • 立ち上げ期 or 安定期 • チーム/予算規模 レガシーのデメリット • 目標に対する足かせ度合い • 安全性(サポート切れとか) • 採用における劣位性 • サービス信頼性への影響 会社・サービス目標/状況との関係性を明らかに
30. 言語置き換えの効果予測・測定は困難… 効果測定しにくい改善 例: レガシーな言語をモダンな言語で置き換える レガシーのデメリット 会社・サービスの状況 • サービス/チームの目標 • サービスの成長度合い • 立ち上げ期 or 安定期 • チーム/予算規模 • 目標に対する足かせ度合い • 安全性(サポート切れとか) • 採用における劣位性 • サービス信頼性への影響 会社・サービス目標/状況との関係性を明らかに 「ビジネス要求に応えるための改善」 であることを伝えていく
31. スプリント最終日にウィンセッションを開催 飲食しながら全員の作業進捗と成果報告を行う 「進捗感」をチームで共有する 定量化できない進捗も 可視化してチームで認識・共有
32. まとめ 継続的改善を行うために 問題認識と共有 効果測定 開発体制 チームメンバーが同じ課題意識を持つ 改善の意義を考え効果を測る・振り返る 継続的改善をエンジニアだけのものにしない 改善Dayを作る前に見直してみましょう!