Diverse Tech #1 〜レガシーシステムを語らう夜〜 での発表資料です。 https://diverse.connpass.com/event/107355/
『「改善Dayを作ろう!」って言ってたけど気づいたらなくなったよね…』を繰り返さないためにDiverse.tech #1〜レガシーシステムを語らう夜〜@imaizume
View Slide
‣ 今泉 智博 @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 DOINGOKRの重要度と緊急度の2軸でマッピングし両者が高いものを優先スプリント終わりに振り返りとKPTを実施毎朝の朝会で進捗や困り事を全員に共有スプリント内にタスクを完了できるよう作業
Poiboyでのスクラム開発の流れスプリントバックログにTODOを追加工数見積もりと内容共有を実施WANT TODO DOINGOKRの重要度と緊急度の2軸でマッピングし両者が高いものを優先スプリント終わりに振り返りとKPTを実施毎朝の朝会で進捗や困り事を全員に共有スプリント内にタスクを完了できるよう作業エンジニア以外から提案が可能チームの能力を考慮した開発へ全員で問題認識を共有全員のTODOと進捗が可視化タスクの重要性を説明する機会無理のない柔軟な計画変更全員で改善策を考え共有する早く終われば他のタスクをやって良い
Poiboyでのスクラム開発の流れスプリントバックログにTODOを追加工数見積もりと内容共有を実施WANT TODO DOINGOKRの重要度と緊急度の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を作る前に見直してみましょう!