フロー効率性とリソース効率性を読んで

フロー効率性とリソース効率性について（QCDのトレードオフなんて本当は無かったんだ） - @i2key のBlog

バイモーダル戦略
- バイモーダルITとは何か？企業がITの「2つの流儀」を使い分ける方法小野和俊「次世代IT企業」への道
  - コスト削減や効率化を重視するSystem of Record（SoR）向けの「モード1」
  - 柔軟性や俊敏性が求められるSystem of Engagement（SoE）向けの「モード2」
TPS
- トヨタ式アジャイル開発TPS（Toyota Production System）を基礎から解説
  - TPSは無駄を極力排除し、「ジャストインタイム」の原則に基づいて生産します。さらに、従業員の意見を尊重し、絶えず改善を追求する文化が根付く。
    - 無駄の排除
      - ムダ: 余分なフィーチャーや要求、不要なミーティング。
      - ムリ: チームに過度なタスクを割り当て、疲弊させること。
      - ムラ: タスクの進行が一定でなく、ばらつきが生じること。
  - アジャイルとTPSの共通点
    - 継続的な改善への強いコミットメント
    - フィードバックの重視
  - アジャイルで「ムダ・ムリ・ムラ」を排除する方法
    - 定期的なレトロスペクティブの活用
      - ムダ・ムリ・ムラの改善
    - 明確な役割と責任の定義
      - ムダ・ムリの改善
    - WIP（Work In Progress）の制限
      - ムラの改善
LEAN
- リーン開発とアジャイル開発の違い
  - リーン開発とは事業を展開するなか、メリハリを持って業務に取り組みつつ、長所は引き伸ばして無駄な部分を削ぎ落す経営手法です。市場や顧客の開発を目的としています。
    - 開発は、仮説と構築、検証、改善を進める
  - 【NOTE】リーン開発の枠の中に、アジャイル開発、その枠の中に、スクラム開発。の枠組みがある。リーン開発はビジネスサイドより、アジャイルは開発より。リーン開発しているのに、ウォーターフォールを採用はサイクル的に悪手。

共通の価値観としての「リードタイム」

[リードタイムとは？意味や短縮方法をわかりやすく解説

NECソリューションイノベータ](https://www.nec-solutioninnovators.co.jp/sp/contents/column/20221014_lead-time.html)

リードタイム（Lead time）とは、工程や作業の始めから終わりまでにかかる所要時間（期間）

SoEライクな開発で開発チームとして目指すところは学びの回数を最大化すること(=サイクル効率性を高める)
プロセスサイクルの流れ（実証プロセスのスタートは思考プロセスのゴールから始まり思考プロセスのスタートに終わる）
- 思考プロセス
  - ①仮説(IDEAS) -> ②何を学ぶか(LEARN) -> ③必要なデータは?(DATA) -> ④どうやって計測する?(MEASURE) -> ⑤必要なものは?(PRODUCT) -> ⑥どう構築するか?(BUILD)
- 実証プロセス
  - ⑦構築する(BUILD) -> ⑧完成したMVP?(PRODUCT) -> ⑨データを計測する?(MEASURE) -> ⑩データを元に検証する(DATA) -> ⑪学ぶ(LEARN) -> ⑫仮説を検証する(LEARN)
開発プロセスのバリューストリームマッピング
- バリューストリームマッピング (VSM) とは？ [2023] • Asana
  - バリューストリームマッピング (VSM) は、仕事の現状を分析し、将来的により効率的な状態を作り上げるための手段です。
- LT = PT + ムダのサイクルが「アイデア・検証→要件→…→KPI」まで行われる
  - LT: リードタイム。PT: プロセスタイム（作業者がひとつの作業項目を完了するのにかかる時間）。
- エンジニアが直接結果をコントロールしやすいのは、「設計実装→結合テスト→KPI→総合テスト→リリース承認」の部分。
  - 【IMO】操作可能な部分のLTを改善するのが効率が良さそうと考える。

フロー効率性とリソース効率性の話
- 前提: A機能、B機能、C機能の実装それぞれ15人日かかる場合
- リソース効率性パラダイム（各機能を各人に割り当て並行して進める）
  - メリット: みんなに仕事が割り振られるためリソースの稼働率は高くなる
  - デメリット: 複数のことを同時にやるとプロダクトが届くまでのLTが長くなる。たくさんのことを同時に調整しようとするから会議・定例やらでLTが延びる。
  - 利用パターン: 大規模開発のように大量のものを一括でドン！とリリース
  - 【IMO】並行して行なっているので全ての機能を管理する人が必要に思う。
- フロー効率性パラダイム（1機能を3人に割り当て完了してから次の機能に皆で着手する）
  - メリット: プロダクトが届くまでのLTは短くなる
  - デメリット: どうしても一時的に、手持ちがなくなる人が出て来るためリソースの稼働率は下がる
  - 【IMO】事前にクリティカルパスを洗い出し作業待ち(リソース低下)させない様にする必要あり
- フロー効率性の目線で現場の課題を可視化していき、フロー効率性を高めると結果的にリソース効率性における課題も表出化され改善されることが多いです。
  - 重要点は、制約が現れたときにそれをコントロールの対象とするか、前提とおくかの判断
QCDのトレードオフなんて本当は無かったんだ
- 結論から言うとリードタイムという観点だとQCD全部大事。
  - 品質は悪いと手戻りを生むので速度に跳ね返る。手戻ってる時間は学びをうまない時間。品質を下げるという判断は学びの速度低下を許容するとこと。
- Quality
  - 低下するとリードタイムを悪化させる（＝品質下げるという選択肢がそもそも無い：固定）
  - デリバリへのリードタイムが長くなるパターン
    - プロセス品質下げると手順ミス等により手戻りが発生
      - 【IMO】関係者が多くなるフェーズのプロセスの解像度は上げた方が良い。誰が何を担当するかなどは事前に取り決めたい。
    - 内部品質さげるとバグの発生、コードレビューの指摘、技術的負債による実装の複雑さなどにより手戻りや速度低下を招く
      - 【IMO】機能開発と合わせて、”ついで改善”では行えることは限界があるので許す限り予算の捻出をしたい。
  - 外部品質さげるとUXバグをうみ、本来検証したいことが検証できず学びまでのリードタイムが長くなる。
  - 障害発生により、それの対応に終われリソースが枯渇し本来やるべきことの足かせになり、リードタイムが長くなる
  - 利用時の品質さげると、カスタマーサポートが頻発しその対応に組織のパワーが持って行かれリードタイムが長くなる
    - 【IMO】ヘルプページの作成は利用者並び新規開発陣の知見強化に繋がるので、早めに取り入れたい。
- Cost: 大抵人件費でありチーム体制は頻繁に増減はない（固定）
- Delivery: 出来るだけ短縮したい（伸ばさない、短縮すべき対象）
- Scope
  - 一度にやる量を決めることでリードタイムが結果的に変わってくる(リソース、フロー効率性のバランス)
Scopeが調整のネジ、QCDは調整ネジは固定(=犠牲にしない)
チームが一度に行うタスク量が多い/サイズが大きい場合
- 一度に開発する量が多い/サイズが大きいと、並行作業が発生する。チームメンバは担当する機能が割り当てられ、それぞれ別々の機能の開発(LTは増加)をする。
- POやプロダクトマネージャーがチームに大きな塊を渡す場合に発生する問題
  - 「もっと分割できないですか？」「必要最小限にできないですか？」とエンジニアからのLT増加への不安・不満。
  - 「エンジニアチームの生産性が悪い」「なかなかリリースされない」のようなPO、マネージャー側のLT増加への不安・不満。
- この状況を作り上げている「１つ」の要因はバッチサイズの大きさである。
チームが一度に行うタスク量が少ない/サイズが小さい場合
- (LTの短縮)チームは1つのことにフォーカスできる。
  - 【NOTE】並行しない分、管理コストが下がるため。
- (LTの短縮)1つの機能を全員で実装すると、とある1つの機能は学びまでのリードタイムが短くなる。
- (見積質の向上)チームへ渡される要件のスコープが小さければ小さいほど、チームの見積もりの確度は高まる。
- (健全化)チームは自分たちの本来の適正な生産性で作業を実施できるようになる。
フロー効率性を向上させるプラクティスや事例
- Github-Flow & Feature Flagのコラボ
  - FeatureFlagを仕込んだプルリクのMasterマージで本番環境への自動デプロイ
    - フィーチャーフラグ導入のハードルを下げたい
      - フィーチャーフラグとは環境変数による処理の分岐と考える。
      - フィーチャーフラグにより本番環境へのデプロイしても影響を最小にできる