Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

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

Tomohiro Imaizumi

November 22, 2018
Tweet

More Decks by Tomohiro Imaizumi

Other Decks in Programming

Transcript

  1. 『「改善Dayを作ろう!」
    って言ってたけど
    気づいたらなくなったよね…』
    を繰り返さないために
    Diverse.tech #1
    〜レガシーシステムを語らう夜〜
    @imaizume

    View Slide

  2. ‣ 今泉 智博 @imaizume
    ‣ 2017年株式会社ミクシィ新卒入社
    ‣ 現在株式会社 所属
    ‣ iOS利用経験0から iOS版開発担当に
    ‣ 完全栄養食 COMP歴2年目に突入(健康です!)
    ‣ Gitの勉強会とかやってます(Speaker Deck)

    View Slide

  3. とは❓

    View Slide

  4. Diverseが運営する
    カジュアルマッチングアプリ❤

    View Slide

  5. 今日のテーマは「レガシーシステム」
    (言語/仕様/開発環境 etc..)
    ですが、もう少し話題を広げて
    「改善の話」をします

    View Slide

  6. https://twitter.com/hiroki_daichi/status/1055447434560602118

    View Slide

  7. https://twitter.com/hiroki_daichi/status/1055447434560602118
    「ソフトウェアは腐る」
    新規実装も時間経過により腐敗する
    「腐敗」=「レガシー」と捉えた場合
    継続的なレガシーの返済が必要

    View Slide

  8. 言語変更
    普段の業務と並行でやるのは難しい…
    ところがレガシー返済で
    やるべきことはたくさん❗
    ライブラリ更新
    テスト導入
    自動化
    マイクロサービス
    Fat Controller解体
    数値計測
    仕様整理
    リファクタリング
    クラウド化
    ドキュメンテーション

    View Slide

  9. そこであなたは
    チームメンバーにこう言います
    「毎週金曜日を改善Dayにしよう!!」
    改善Day(的なもの)をTryした経験のある人

    View Slide

  10. ところが数週間後のあなたは…
    突然の仕様変更
    差し込みタスク
    不意のバグ発生
    PMからの要求
    残業
    終わらぬQA
    仕様漏れの発覚
    見積もり通りに仕事が終わらない!!

    View Slide

  11. 『「毎週金曜日を改善Dayにしよう!!」
    って言ってたけど気づいたらなくなったよね...』
    改善Day(的なもの)をTryして失敗した経験のある人
    そして振り返ってこう思います

    View Slide

  12. 毎週の工数見積と
    改善DayをTRYしたが…
    かつてのPoiboyもそうでした
    ほぼ守られなかった当時の工数見積
    継続しなかった
    ノーアーキテクチャ
    ノーテスト
    手動ビルド/アーカイブ
    複雑な仕様
    無限に湧き出るバグ
    Fat ViewController

    View Slide

  13. しかしその後数々のTryを経て
    チームに改善Dayが定着
    Poiboyはどのようにして
    改善Dayを手に入れたのか

    View Slide

  14. 「組織的な改善活動を成功させる手順」
    (川瀬武志. IE問題の基礎, 2007)
    1. 問題・現状の認識
    2. 意識的努力
    3. 目標達成度を測る定量的尺度の作成
    4. 人・お金・時間・行動の自由度
    1. 問題・現状の認識と共有
    2. (マンパワー依存を捨てる)意識的努力
    3. 定量的尺度+目標達成感
    4. 人・お金・時間・行動の自由
    imaizume流にUpdateすると…
    実はこっちが大切
    = 改善Day

    View Slide

  15. 問題・現状の認識と共有
    改善/レガシー返済に対する価値を
    チームが理解すること

    View Slide

  16. PMから見えていた問題
    • 仕様の複雑化をやめたい
    • 見積り通りの工数で作業したい
    • ボトムアップの改善策をやりたい
    エンジニアから見えていた問題
    • 短期間で数値目標を達成したい
    • 施策をどんどん投入したい
    • 数字に直結するタスクの優先度を上げたい
    エンジニアへ要求
    PMへ要求
    改善したい!!
    頑張ってほしい!!

    View Slide

  17. PM陣から見えていた問題
    • 仕様の複雑化をやめたい
    • 見積通りの工数で作業したい
    • 継続的改善をしたい
    当時のiOSチームから見えていた問題
    • 短期間で数値目標を達成したい
    • 施策をどんどん投入したい
    • 数字に直結するタスクの優先度を上げたい
    エンジニアへ要求
    PM陣へ要求
    改善したい!!
    頑張ってほしい!!
    互いの意見がぶつかり
    価値観が合わない状態

    View Slide

  18. しかし改善の効果は不確実
    効果測定が難しい
    本当はやりたかった説得の例
    Poiboyが変わった本当のきっかけとは❓
    ✓ 売り上げUPには開発速度が必要
    ✓ 開発速度向上には○○の導入が必要
    ✓ 導入にはX時間必要
    ✓ 1ヶ月に発生する作業がN回と仮定
    ✓ トータルではY時間短縮できる
    ✓ なので改善時間をX時間ください!

    View Slide

  19. 見えない終わり
    オーバーワークで開発メンバーが疲弊
    サービス開発が楽しくない
    改善見込み無し
    無謀なスケジュール
    締切だけが決定
    勝手に決まる施策
    優秀なメンバーが外部へ流出
    レガシーな開発体制
    当時の現場の様子

    View Slide

  20. 見えない終わり
    オーバーワークで疲弊
    サービス開発が楽しくない
    改善見込み無し
    無謀なスケジュール
    締切だけが決定
    勝手に決まる施策
    優秀なメンバーが外部へ流出
    レガシーな開発体制
    サービス・会社の成長のため
    人材流出を防ぎたい!!
    盤石な開発体制を作りたい!!
    働く環境・開発体制を見直し

    View Slide

  21. 2018年4月
    Poiboyはスクラム開発に移行
    同年8月
    PoiboyでOKRを試験導入

    View Slide

  22. Poiboyでのスクラム開発の流れ
    スプリント
    バックログに
    TODOを追加
    工数見積もりと
    内容共有を実施
    WANT TODO DOING
    OKRの重要度と緊急度
    の2軸でマッピングし
    両者が高いものを優先
    スプリント終わりに
    振り返りとKPTを実施
    毎朝の朝会で
    進捗や困り事を
    全員に共有
    スプリント内に
    タスクを完了できるよう
    作業

    View Slide

  23. Poiboyでのスクラム開発の流れ
    スプリント
    バックログに
    TODOを追加
    工数見積もりと
    内容共有を実施
    WANT TODO DOING
    OKRの重要度と緊急度
    の2軸でマッピングし
    両者が高いものを優先
    スプリント終わりに
    振り返りとKPTを実施
    毎朝の朝会で
    進捗や困り事を
    全員に共有
    スプリント内に
    タスクを完了できるよう
    作業
    エンジニア以外
    から提案が可能
    チームの能力を
    考慮した開発へ
    全員で問題認識を共有
    全員のTODOと
    進捗が可視化
    タスクの重要性を
    説明する機会
    無理のない
    柔軟な計画変更
    全員で改善策を
    考え共有する
    早く終われば
    他のタスクをやって良い

    View Slide

  24. Poiboyでのスクラム開発の流れ
    スプリント
    バックログに
    TODOを追加
    工数見積もりと
    内容共有を実施
    WANT TODO DOING
    OKRの重要度と緊急度
    の2軸でマッピングし
    両者が高いものを優先
    スプリント終わりに
    振り返りとKPTを実施
    毎朝の朝会で
    進捗や困り事を
    全員に共有
    スプリント内に
    タスクを完了できるよう
    作業
    エンジニア以外
    から提案が可能
    チームの能力を
    考慮した開発へ
    全員で問題認識を共有
    全員のTODOと
    進捗が可視化
    タスクの重要性を
    説明する機会
    無理のない
    柔軟な計画変更
    全員で改善策を
    考え共有する
    早く終われば
    他のタスクをやって良い
    開発体制の見直し
    +
    「継続的改善がグロースには必要」
    という認識の共有

    View Slide

  25. (補足)スクラム開発導入時のポイント
    スクラム導入はスタート
    継続的改善ができるまで改良する
    見積もり精度を上げることで徐々に余裕が生まれる
    (最初は見積もり通りには終わらないので頑張る)
    スプリント期間2週間のうち2日間を改善Dayに
    (ただしチームで必要性が認められてから生まれた)
    レガシー返済の価値を分かりやすく提案する必要性
    (「価値がある」とチームに判断してもらうため)

    View Slide

  26. 定量的尺度+目標達成感
    改善活動の効果測定と認識

    View Slide

  27. 改善の効果を測定する
    例: タスク見積もりの精度を計測する
    GitHubに工数をコメントすると
    SpreadSheetへ記録してくれるGAS作りました
    github.com/imaizume/github-record-time
    > ⾒積りと実績を⽐べて正確さを増していくという繰り返しをすれば、
    ⾒積りの精度は⾼くなっていきます。
    (広木大地. エンジニアリング組織論への招待, 2018)
    チーム全体の工数測定の様子 個人タスクの工数測定の様子

    View Slide

  28. 改善の効果を測定する
    例: タスク見積もりの精度を計測する
    githubに工数をコメントすると
    SpreadSheetへ記録してくれるGAS作りました
    github.com/imaizume/github-record-time
    > ⾒積りと実績を⽐べて正確さを増していくという繰り返しをすれば、
    ⾒積りの精度は⾼くなっていきます。
    (広木大地. エンジニアリング組織論への招待, 2018)
    チーム全体の工数測定の様子 個人タスクの工数測定の様子
    どんな改善でも
    効果を数値測定できるのか??

    View Slide

  29. 言語置き換えの効果予測・測定は困難…
    効果測定しにくい改善
    例: レガシーな言語をモダンな言語で置き換える
    会社・サービスの状況
    • サービス/チームの目標
    • サービスの成長度合い
    • 立ち上げ期 or 安定期
    • チーム/予算規模
    レガシーのデメリット
    • 目標に対する足かせ度合い
    • 安全性(サポート切れとか)
    • 採用における劣位性
    • サービス信頼性への影響
    会社・サービス目標/状況との関係性を明らかに

    View Slide

  30. 言語置き換えの効果予測・測定は困難…
    効果測定しにくい改善
    例: レガシーな言語をモダンな言語で置き換える
    レガシーのデメリット 会社・サービスの状況
    • サービス/チームの目標
    • サービスの成長度合い
    • 立ち上げ期 or 安定期
    • チーム/予算規模
    • 目標に対する足かせ度合い
    • 安全性(サポート切れとか)
    • 採用における劣位性
    • サービス信頼性への影響
    会社・サービス目標/状況との関係性を明らかに
    「ビジネス要求に応えるための改善」
    であることを伝えていく

    View Slide

  31. スプリント最終日にウィンセッションを開催
    飲食しながら全員の作業進捗と成果報告を行う
    「進捗感」をチームで共有する
    定量化できない進捗も
    可視化してチームで認識・共有

    View Slide

  32. まとめ
    継続的改善を行うために
    問題認識と共有
    効果測定
    開発体制
    チームメンバーが同じ課題意識を持つ
    改善の意義を考え効果を測る・振り返る
    継続的改善をエンジニアだけのものにしない
    改善Dayを作る前に見直してみましょう!

    View Slide