「納期コミットのオーダーは結果的に納期を遅らせること」を逆手にとる

これは Recruit Engineers Advent Calendar 2022 - Adventarの13日のエントリーです。（書いているのは21日です。）

1. 納期コミットのオーダーは結果的に納期を遅らせる

先日、興味深いエントリーを読んだ。

bufferings.hatenablog.com

これにつてはほぼ同じようなことを社内のtimesチャネルでも会話しており、スケジュールへの向き合い方についてメタ的理解に昇華させたい。

我々が納期をコミットしなさい、確実に守れる日を教えてと言われたときにやることは、、、
確実に納期を守れるように、余裕をみる。である。

------------------------------------------------------------
■：実作業日（問題なければできそうな工数）
□：バッファ日（例えば50％の確率で問題おきたときに使う予備日。数字てきとー。）
設計工程　■■■■■■■■□□□□　（■：8日、■＋□：12日）
実装工程　■■■■■■■■□□□□　（■：8日、■＋□：12日）
試験工程　■■■■■■■■□□□□　（■：8日、■＋□：12日）

合計 ■■■■■■■■□□□□■■■■■■■■□□□□■■■■■■■■□□□□（■：24日、■＋□：36日）
------------------------------------------------------------

36日後にリリースできます。とコミットする。（便宜上、土日ぬいてるよ） 仮に予定よりも前倒しにおわったとはいえ、バッファがあるから、「念の為」「不安だし」「より良いものを」という理由でバッファは善の活動により費消される傾向がある。リリース直前のバッファが余った状況であれば、誰しもが「念の為」強化試験をしたくなる。そういうもの。つまり、使わないという手はない。それが大規模開発になればなるほど。別に悪だとはいっていない、そういうもの。人間だもの。（参考：パーキンソンの法則）
------------------------------------------------------------
※ また、以下のようなCCPMバッファ的な話はそれについて言及したいわけではないので今回はスコープアウトする。
â– â– â– â– â– â– â– â– â– â– â– â– â– â– â– â– â– â– â– â– â– â– â– â– â–¡â–¡â–¡â–¡â–¡â–¡â–¡â–¡â–¡â–¡â–¡â–¡
------------------------------------------------------------

このとき、ポイントとしては、納期コミットのオーダーを出したひとは、実は、自ら納期を遅延させたということに気づいていないケースがある。というか、99%が気付いていない。営業広報とかが現場オペレーションとして走るため日にちを確定させたいような場合は、確定させることが大事なのでよいのである(日付により他のオペレーションと同期をとることが要件であると認識する)が、例えば、早ければ早いほどよいもの。リリースと同時に事業実利がリアルに積み上がるようなものの場合、早く出した日数分だけ、実利が多く積み上がる。

2. 納期コミットのオーダーは結果的に納期を遅らせることを逆手にとる

そのため、思考実験。

□が混入している理由は、納期を確定させるために見積もりという行為をしたから。早ければ早いほど良い場合は、逆に考えると、実は、（コミットのための）見積もりをしない。（コミットのための）納期を確定させない。ただし、成功確率は50％（数字てきとう）。というギャンブルをやるかどうかという捌きが前段にあってもよいのかもしれない。自分たちの作業精度を上げるための自分たちのための見積もりはそれはするとして。また、事業KPIにコミットしているモチベーションの高いチームであることは大前提である。

納期確定で動くなら、36日後にリリースできます。確実に。
------------------------------------------------------------
■■■■■■■■□□□□■■■■■■■■□□□□■■■■■■■■□□□□（■：24日、■＋□：36日）
------------------------------------------------------------

納期未確定で成功確率50%でよければ、24日後にリリースできます。多分。失敗したら、36日〜へたしたら40日くらいかかるかもね。このギャンブルのる？のらない？
------------------------------------------------------------
■■■■■■■■■■■■■■■■■■■■■■■■（■：24日）
------------------------------------------------------------

事業実利の期待値をみて、その積分値を最大化するための、ギャンブル。（＝プログラムマネジメント的思考）
遅延リスクバッファをすべて削り、それを時間短縮可能性に変換している。

3. 納期という日付すらも実はビジネス要件なのである

つまり、約束すると遅くなるというメカニズムを前提とした上で、約束する（日付の確定）をビジネス要件とするか、約束しない（リリース速度）をビジネス要件とするか。これすらも要件として扱うことが大事である。これによって開発プロセス自体もビジネス要件にあわせて変化することになる。（例えばウォーターフォールと言われているタイプから、一個流し的なカンバン方式へ変化したり。締め切りにフォーカスではなく、優先順位にフォーカスしていくことになる。積み上がるKPIの総量が最大化するには、バッファを詰んで日付を確定させることが最も効くのか、日付を確定させず（ゆるく決めるだけ）に遅延リスクを飲むほうが効くのか。）
今まで前提としてしまっていた納期というもの自体もビジネス要件と捉え、他のバックログ的なリストに混ぜ込むイメージである。納期がビジネス上最も重要度が高いのであれば、それに対して遅延リスクバッファをたくさん積むべきであり、そのバッファ分の原資になるリソースは例えばチームのキャパシティから割り当てられることになる。これが意味することは、その開発サイクルにおいて、同時に開発出来る案件は減ることを意味する。特定の案件の日付を確定させることがビジネス上、最重要なのであれば、他の案件は優先度が下がるはずである。

イメージで補足すると以下のようになる。最も事業実利が積み上がるように開発をするべきである。納期を約束するかどうかはそのための手段の1つである。

また、付け加えると、「見積もりは予測であり約束ではないのである」とか正しい理屈を説いても基本的に意味がなくて、期日守るからリリース日遅くなる or 期日なしでリリース日早まるけど確度80%、のようなトレードオフの形にして選択可能な状態にすることが重要である。レバーとして実装できればあとは選ぶだけであり、「見積もりは〜予測で〜」のような開発の正義みたいなものを説いて理解していただくような労力すら必要なくなる。

おまけ. 小難しい理屈は「全員が」理解している必要はない

合わせて、フロー効率やリソース効率みたいな開発としての正義のようなものも同様である。そういう小難しい理屈を関係者全員が理解している必要はなく、その考え方が染み込んで浸透した状態の選択肢をいくつか用意出来れば良い。結果的にフロー効率がよくなる構造 or リソース効率が良くなる構造を作れれば良いわけで、何を捨てて何を取るかという状態になっていることが実行性が高い状態である。しかしながら、なぜか、小難しい理屈を我々は説明したくなってしまうのである。合気道すべきところを何故か正拳突きをしてしまうのである。そんなこと知らなくても良いのに。
思想みたいなものはあえて声高に説明するのではなく構造の中にそっと織り込んでなじませておけば良くて、そうすれば無意識下におかれ自然とスケールする。思想を理解しないと適用できないみたいな状態だと理解出来る人にしかスケールしないため効率が悪いのである。しかし、、、、、、方法論者は、その小難しい理論が如何に正しいか・素晴らしいかを説明してしまうのである。という自戒を込めて。

関連しそうなテーマをyoutubeで勝手に定義して解説しています youtu.be