『「改善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/

1a74617b91d2757b839b9cf3614648ce?s=128

Tomohiro Imaizumi

November 22, 2018
Tweet

Transcript

  1. 2.

    ‣ 今泉 智博 @imaizume ‣ 2017年株式会社ミクシィ新卒入社 ‣ 現在株式会社 所属 ‣

    iOS利用経験0から iOS版開発担当に ‣ 完全栄養食 COMP歴2年目に突入(健康です!) ‣ Gitの勉強会とかやってます(Speaker Deck)
  2. 14.

    「組織的な改善活動を成功させる手順」 (川瀬武志. IE問題の基礎, 2007) 1. 問題・現状の認識 2. 意識的努力 3. 目標達成度を測る定量的尺度の作成

    4. 人・お金・時間・行動の自由度 1. 問題・現状の認識と共有 2. (マンパワー依存を捨てる)意識的努力 3. 定量的尺度+目標達成感 4. 人・お金・時間・行動の自由 imaizume流にUpdateすると… 実はこっちが大切 = 改善Day
  3. 16.

    PMから見えていた問題 • 仕様の複雑化をやめたい • 見積り通りの工数で作業したい • ボトムアップの改善策をやりたい エンジニアから見えていた問題 • 短期間で数値目標を達成したい

    • 施策をどんどん投入したい • 数字に直結するタスクの優先度を上げたい エンジニアへ要求 PMへ要求 改善したい!! 頑張ってほしい!!
  4. 17.

    PM陣から見えていた問題 • 仕様の複雑化をやめたい • 見積通りの工数で作業したい • 継続的改善をしたい 当時のiOSチームから見えていた問題 • 短期間で数値目標を達成したい

    • 施策をどんどん投入したい • 数字に直結するタスクの優先度を上げたい エンジニアへ要求 PM陣へ要求 改善したい!! 頑張ってほしい!! 互いの意見がぶつかり 価値観が合わない状態
  5. 22.

    Poiboyでのスクラム開発の流れ スプリント バックログに TODOを追加 工数見積もりと 内容共有を実施 WANT TODO DOING OKRの重要度と緊急度

    の2軸でマッピングし 両者が高いものを優先 スプリント終わりに 振り返りとKPTを実施 毎朝の朝会で 進捗や困り事を 全員に共有 スプリント内に タスクを完了できるよう 作業
  6. 23.

    Poiboyでのスクラム開発の流れ スプリント バックログに TODOを追加 工数見積もりと 内容共有を実施 WANT TODO DOING OKRの重要度と緊急度

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

    Poiboyでのスクラム開発の流れ スプリント バックログに TODOを追加 工数見積もりと 内容共有を実施 WANT TODO DOING OKRの重要度と緊急度

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

    言語置き換えの効果予測・測定は困難… 効果測定しにくい改善 例: レガシーな言語をモダンな言語で置き換える 会社・サービスの状況 • サービス/チームの目標 • サービスの成長度合い •

    立ち上げ期 or 安定期 • チーム/予算規模 レガシーのデメリット • 目標に対する足かせ度合い • 安全性(サポート切れとか) • 採用における劣位性 • サービス信頼性への影響 会社・サービス目標/状況との関係性を明らかに
  9. 30.

    言語置き換えの効果予測・測定は困難… 効果測定しにくい改善 例: レガシーな言語をモダンな言語で置き換える レガシーのデメリット 会社・サービスの状況 • サービス/チームの目標 • サービスの成長度合い

    • 立ち上げ期 or 安定期 • チーム/予算規模 • 目標に対する足かせ度合い • 安全性(サポート切れとか) • 採用における劣位性 • サービス信頼性への影響 会社・サービス目標/状況との関係性を明らかに 「ビジネス要求に応えるための改善」 であることを伝えていく