保留も意思決定

C1上限付きの試行
1. 上限を決める
2. 試す
3. 続けるか止める
支払いを止める。まだ何もその上に作られていない
C2プラットフォーム、認証基盤、言語
1. 比較
2. 決定
3. 最初のサービスを載せる
4. すべてを載せる
印の付いた手順までは自由に決め直せる
C3顧客が根拠にできる約束
1. 設計
2. 契約に書く
3. 運用する
戻せません。先に検証します。

3種類の技術的な意思決定と、それぞれを撤回する費用です。2行目が安く抜けられなくなるのは印の付いた手順で、プロセスを置くべき場所もそこです。請求書に署名する瞬間ではありません。

承認も却下もどちらも意思決定であり、どちらも何かを後に残します。記録、責任者、日付、次に起きること。そのどちらでもない提案は、何も残しません。何かを置いておくのに最も安い状態であり、置き続けるのに最も高い状態です。どの報告にも現れないからです。不在には成果物がありません。

00 / 経過日数が測るのはカレンダーであって意思決定ではない

誰もが手を伸ばす指標は、チケットの経過日数です。集めるのは簡単ですが、問いには答えません。依存するアーキテクチャがまだ選ばれていなかったために数か月待った提案は、正しく待っていました。3週間待ったために、要件をリリースに入れる唯一の機会を逃した提案は、そうではありません。同じ指標で、正反対の読み方になります。

経過時間は、複数の原因を持つ症状です。そして原因ごとに、取るべき対応は逆になります。

本当にまだ解決していない依存を待っている。正しく、そして口に出して言う価値があります。
今四半期に考えるべきこととして優先度が高くないので、意図的に先送りしている。これも正しく、それ自体が一つの意思決定です。
誰にも依頼されていない情報を待っている。依頼が欠けています。
誰も責任を負っていない判断を待っている。責任者が欠けています。
答えが「いいえ」で、それを言いたい人がいないために待っている。「いいえ」が欠けています。

最後のものは、はっきり名前を付ける価値があります。「いいえ」は意思決定です。待っている人を解放し、異議を申し立てることができ、状況が変われば見直すこともできます。沈黙はそのどれもしないまま、同じ費用がかかります。

01 / その場にいなかった人にも読める保留

判定の基準はこうです。その場にいなかった人が保留を読んで、自分が動くべきかどうか分かるか。「対応中」はこの基準を満たしません。満たすのは5つの項目です。

なぜ待っているのか。
何が保留を解くのか。日付ではなく条件です。
誰が解くのか。チームではなく、名前の挙がった1人です。
いつ、いずれにせよ見直すのか。
今何を止めているのか。多くの場合は何も止めておらず、だからこそ止めている場合には書く価値があります。

費用は1文です。代わりに起きるのは、3か月後に、最初の会話を忘れた人たちへ提案をもう一度説明することです。同じ議論が二度行われ、二度目は違う結論に着くのは、こうして起きます。

02 / プロセスを決めるのは可逆性であり、金額ではない

よくある規則は金額の閾値です。ある額までは管理者が承認し、それを超えると委員会が承認する。運用は簡単ですが、測っている性質が違います。全員の作業手順の中に入り込んだ月額の小さなサブスクリプションは、その10倍の一度きりの購入よりも抜けるのが難しくなります。

私が繰り返し例に出すのは認証基盤です。導入が最も安く、離れるのが最も高い構成要素であり、しかも最初の環境を立てた人が半日で決めてしまうのが普通です。ユーザー単位の課金についてのノートは、その半日のあいだに行われない計算についてのものです。請求書を見ても、このどれも分かりません。

つまり軸は別のところにあります。間違っていた場合の費用と、その道をどこまで進んでしまったかです。

上限付きの試行。 承認するのはツールではなく上限です。何人で、どれだけの期間、いくらまで、そして答えが出ることを期待している問いはこれ、という形にします。撤回は更新しないことです。最も少ないプロセスで足りるのに、最も過剰に管理されがちな種類です。
構造的な選択。 プラットフォーム、認証基盤、言語、データモデル。最初の何かがその上に作られるまでは可逆で、それ以降は可逆ではありません。だからこそ、会話ではなくPoC（技術検証）の書かれた評価軸、代替案、期限に値します。
約束。 契約上の要件、配布済みのモバイルアプリ、送信済みのメール、破壊的な移行など、顧客に対する約束として届くものすべてです。ここでの問いは金額に見合うかではなく、それが間違っていた場合に自分たちはどういう立場に立つのかであり、その答えは事前に文書として存在していなければなりません。リリース計画とは戻す計画は、1回のデプロイという単位で見た同じ議論です。

03 / ツールの申請は2つの主張であり、聞き取られるのは片方だけ

エンジニアはツールを申請するとき、最も言いやすい理由を挙げます。これがあると作業が速くなる、というものです。しかし実際に欲しいものは、別のことが多いです。自分が書いていないコードベースを理解する手段、あるいは新しく入った人が1か月ではなく1週間で貢献を始められる状態です。

管理側は、聞き取った主張を評価します。コードを打つ速さという尺度で見れば、そのツールはいずれ持っていてよいものなので、実装が律速になる時期に合わせて予定されます。双方とも筋が通っており、それぞれ違う問いに答えています。ずれているのは人ではなく申請の側です。ツールが何をするかは書かれていて、何のためか、誰のためか、3か月遅れると何が変わるのかが書かれていません。

これを埋めるのは4つの文です。問題、それを抱えているのは誰か、遅れることの費用、そして効いたと判断するために何を測るか。この4つは、相手が速く「はい」と言えるようになる4つでもあり、それが本来の目的です。

04 / 調べることと決めることは別の仕事

「Xを評価する」という1項目は、4つの別のことを混ぜています。知りたいのかどうか、誰が調べるのか、いつまでにか、そして答えをどうするのか。失われるのは4つ目です。最初の3つは前進のように見えるからです。調査は終わり、答えはコメントに収まり、その答えが支えるはずだった意思決定は起きません。問いには答えが出て、何も決まっていない状態です。

隣に並ぶもう一つの壊れ方は、前提より長生きした調査です。依存が項目の想定と違う形で解決したとき、項目は自分の想定を保ち続けます。すでに保留になっているものを、誰も読み返さないからです。つまり意思決定は、下された時点では終わっていません。それを待っていたものすべてが更新または終了された時点で終わります。この手順こそ機械的にする価値があります。純粋な事務作業であり、誰も楽しめないからです。

05 / プロセス自体にも費用がある

ここまでのすべては、やらない場合より仕事が増えます。意思決定ごとに文書を求める仕組みは、速くするために作ったはずの意思決定を遅くします。そして最初にそれを感じるのは、小さく可逆な選択をしている人たちです。その仕組みを最も必要としていない人たちです。ですから、管理のための手間も観測する数値の一つに入ります。記録を書く時間が意思決定にかかった時間より長いなら、記録が長すぎます。

記録が何のためにあるのかは狭く、そこは正直に言う価値があります。この事例の梱包業向けSaaSでは、データモデルの文書が最新ではありませんでした。そのためシステムが現にどう動いているかの共通像を誰も持っておらず、それについての問いはすべてコードの読み解きから始まりました。私は性能改善の作業のあとにそれを更新しました。次の変更がそこから始まらないようにするためです。意思決定の記録は、それと同じ仕組みを一段上でやるものです。次の人が同じ議論を導き直さないために、そして前提が変わったときに誰かが気づけるために存在します。

作る価値があるのは、速い承認ではありません。開いているすべての提案について、何を待っていて誰が保留を解くのかを、いつでも言える状態です。多くの場合、直すべきものはそれで全部だと分かります。