アーキテクチャモダナイゼーション実行論: 見積もりはいつ締め切りになったのか?
(domainanalysis.io)- レガシーソフトウェアのモダナイゼーションでは、着手前に見えている情報だけで全体範囲を確定するのが難しく、初期見積もりは締め切りではなく調整可能な基準として扱うべきである
- 自動車修理のように、最初は18,000ドル・30日のような見積もりが可能でも、分解や点検の後に隠れた損傷が判明すれば、追加見積もりと再承認が必要になる
- モダナイゼーションプロジェクトでも、統合の失敗や予期しない挙動のような隠れた複雑性が現れ、このとき元の見積もりに無理やり合わせようとすると現実と衝突する
- 健全なリーダーシップは「なぜ見抜けなかったのか」よりも、複雑さ、解決策、トレードオフ、回避策を問い、継続するか中止するかを判断する
- 複雑な文脈では、固定されたルールブックよりも試行・実験・発見の反復が必要であり、リーダーは過度な統制よりもパターンが現れる環境を作るべきである
見積もりは締め切りではなく進行の基準
- 複雑なソフトウェアモダナイゼーションで見積もりを確定した締め切りのように扱うと、実際の作業で明らかになる現実と衝突する
- 初期見積もりは外から見える情報と経験をもとに作られるが、作業開始後に新たな複雑性が明らかになることがある
- 「見積もり」とは実際の値に対する近似値であり、複雑なモダナイゼーションでは開始前にすべての結果を完全に予測するのは難しい
自動車修理の比喩: 見えない損傷と追加見積もり
- 自動車修理では、まず保険鑑定人が損傷見積もりを修理工場に提出し、修理工場も独自の見積もりを保険会社に送る
- 例として保険鑑定人は15,000ドルの損傷を見積もる
- 修理工場は18,000ドルの損傷と30日の修理期間を見積もる
- 保険鑑定人と修理工場の専門家が一緒に損傷を評価し、保険会社が新しい見積もりを承認すると修理が始まる
- 修理中には、最初は見えなかった損傷が見つかることがある
- 部品を分解する中で追加の損傷が見つかることがある
- フレームマシンでunibody frameの損傷を点検できる
- 衝突箇所だけでなく、フレーム後方まで影響が伝わっていないかも確認する必要がある
- 追加の損傷によって20,000ドルの費用がさらに必要になれば、修理工場は追加修理の依頼を保険会社に送り、保険会社は修理を続けるか全損(total loss) とするかを判断する
- 保険会社が、元の見積もりが18,000ドルだったという理由だけで追加の20,000ドルを拒否するやり方は、現実的な修理手順には合わない
レガシーモダナイゼーションでも隠れた複雑性が現れる
- レガシーソフトウェアのモダナイゼーションは複雑なソフトウェアの領域に属する
- 外から明確に見える問題をもとに初期見積もりを作ることはできるが、実際の作業中にはさらに多くの複雑性が現れる
- 自動車修理で隠れた損傷やフレーム損傷が見つかるように、モダナイゼーションでも当初の見積もりになかった問題が発生しうる
- このような状況では、元の見積もりに縛られるのではなく、追加承認と再判断を通じて次の段階を決めるべきである
良いリーダーが問う質問
- 健全なソフトウェア開発環境では、問題が明らかになったとき責任追及よりも判断に必要な質問を投げかける
- この問題はどれほど複雑か
- 解決方法には何があるか
- 各方法のトレードオフは何か
- 回避策や代替ソリューションはあるか
- 逆に、「なぜこの複雑性を見抜けなかったのか」「なぜこんなに時間がかかるのか」「なぜ当初の見積もり日を守れないのか」という流れになると、チームは元の見積もり日に縛られる
- モダナイゼーションプロジェクトには、継続される場合も中止される場合もある
- 追加費用が承認されれば次の段階へ進み、この過程を繰り返して完了に近づく
- 費用が価値を上回れば、プロジェクトは中止されることがある
- 継続と中止を分ける決定は容易ではなく、方向性を定めるためのフレームワークや意思決定ワークショップが用いられることがある
難解な文脈と複雑な文脈の違い
- A Leader’s Framework for Decision Making の Cynefin framework では、自動車修理やオートバイ整備は難解な文脈(complicated context) に近い場合がある
- 自動車修理では、専門家が事故状況を聞き、見えない損傷やフレーム損傷など複数の要素を分析・テストして最善の対応を決める
- 複雑な文脈(complex context) では、試してみた後ではじめて正しいかどうかを判断できる
- 動くはずだと見込んだ統合が失敗することがある
- 知られていなかった新しい挙動を発見し、それを反映しなければならないことがある
- 複雑なレガシーシステムのモダナイゼーションには、固定された道筋や従うべきルールブックはない
- モダナイゼーションは、試し、実験し、発見し、解決し、次の断片へ進む過程を繰り返す
変化球は例外ではなく現実
- アプリケーションモダナイゼーションが complex と complicated の間にあるなら、進捗と成功を判断する適切なダッシュボードが必要である
- 複雑な文脈に単純な見積もりプロセスを適用するのは、すべてのネジやラグナットをハンマーで解決しようとするようなものだ
- モダナイゼーションプロジェクトにおける予期しない変化球は現実である
- すべての結果を事前に予測することはできない
- どれだけ多くの事前分析をしても完璧なデータモデルには到達できない
- ほぼすべての段階で新たな学びが生まれる
- 発見された複雑性に応じてデータモデルを変えなければならない
- 見積もりが変わる状況では、怒ったり非難したり、日程を無理に合わせる分析に固執したりするよりも、前進する方法を見つけるべきである
組織文化が変化球を扱う方法
- Ron Westrumの組織文化モデル は、変化球を知らせる人と失敗を組織がどう扱うかを区別する
- Power-Oriented 組織は、変化球を知らせるメッセンジャーを撃ち、失敗はスケープゴート探しにつながる
- Rule-Oriented 組織は、変化球を知らせるメッセンジャーを無視し、失敗を定義実装の問題として扱う
- Performance-Oriented 組織は、変化球を知らせるメッセンジャーを訓練し、失敗を探究へとつなげる
- 解決しようとしている問題がなお重要で、ビジネス要件を満たしているなら、一度に一歩ずつ進むべきである
- モダナイゼーションしようとしているソフトウェアの最終的な対象はユーザーである
複雑な領域には実験的な管理が必要
- 複雑な領域を認識できていないリーダーは、目指す結果がすぐに出ないと焦りやすい
- 複雑な領域では失敗に耐える能力が重要であり、失敗は実験的理解の不可欠な要素である
- 組織を過度に統制すると、有用なパターンが現れる機会を妨げる
- 複雑な文脈に秩序を無理に押し付けようとするリーダーは失敗する
- 舞台を整え、一歩引き、パターンが現れるに任せ、望ましいパターンを見極めるリーダーは成功しうる
1件のコメント
Hacker News のコメント
経営陣が見積もりを締め切りのように扱い、仕様を変え続ける一方で、なぜ変わり得るのかにはまったく耳を貸そうとしない時期を経験したことがある。
そういう時は、些細ではないことのたびに「ヘッドライトの前の鹿」のような反応を選んでいた。「これはかなり大ごとになるかもしれません。チームの誰かが1時間ほどかけて、実際に何が必要か見たほうがよさそうです」と言うと、マネージャーはいつものように「ざっくりでいいから」と聞いてくる。そこで椅子から飛び上がるくらい大きな数字を出すと、その数字が記憶に残る。その後、1時間の実査をしても、できるだけその概算以外の数字は出さず、最終的には「予定より早く」終わらせて、見栄えをよくしていた。
良いマネージャーにはこんな戦略はまったく必要なく、本当にありがたかったが、自分の職務能力を学ぶ気がない人たちには、こういう対応になっていった。会議もずっと面白くなった。
デザインチーム、フロントエンドチーム、バックエンドチーム、QAチームがそれぞれそうやって膨らませ、プロジェクトマネージャーがその合計をさらに150〜200%上げ、アカウントマネージャーと営業チームも費用見積もりの前にさらに150〜200%を足していた。
結果として、まずまずのWeb/フルスタック開発者8〜10人の専任チームなら十分にこなせるWebサイト保守に、月100万ドル近くかかっていた。24時間サポートを除けば、優秀なRailsやDjango開発者が数人、あるいは1人とパートタイムのグラフィックデザイナーでも可能だったと思う。
数年後、顧客が状況に気づき、会社の経営陣は仕事を完全に台無しにして、約100人が職と未払いの権利を失った。その日、自分も約2万6000ドルを失った。
全体のキャパシティがたとえば40ポイントで、チームメンバーが抜けたり加わったりすると少しずつ変わる。Velocityは人日あたりのポイントで見た平均処理量である。
Volatilityはスプリントがどれだけ変わるかを表す。5ポイントのチケットを1つ外して3ポイントと2ポイントを入れるのは問題ないかもしれないが、2週間スプリントでそれを12回やると、総量が40ポイント以下でもスプリントを終えられない。
毎日スプリントのスナップショットを取り、チケットの追加・削除量を見た。変動性が低いときはほぼ常に完了するが、高いときはVelocityを超えているかどうかに関係なく失敗することを、マネージャーに示せた。きちんと計画し、要件を明確にする時間がないからだ。プロダクトチームに2週間より先を見させるようにすると、ある程度効果があった。
単純な作業に過剰に膨らませた見積もりを出すエンジニアは、低パフォーマーである可能性も高かった。遅い納品を判断しない人や状況を知らないマネージャーには通用するかもしれないが、状況を知っているマネージャーはすぐに見抜く。
単一の固定値ではなく、「3か月、±4週間」のように誤差範囲も一緒に出すべきだ。ほとんどのエンジニアは自分の見積もりに誤差範囲があることを知っているが、なぜかそれを言うのを忘れるように仕込まれている。
管理の面でも、誤差範囲の大きさは見積もりへの確信度をすぐに示し、リスクについて議論できるようにしてくれる。「現時点では両方向に30%の誤差があるが、最大の原因は何で、数日調査すれば一つ二つ減らせるか？」といった会話が可能になる。
エンジニアリング職だというのに、リスク、確率、信頼区間をきちんと語れないのは理解できない。これはマネージャーだけの責任でもない。
経験のないマネージャーや、誰かの穴を一時的に埋めている人は不確実性に慣れていないので理解できるが、それ以外の状況では言い訳の余地はない。
この記事はモダナイゼーションプロジェクトについてのもので、こうしたプロジェクトでは代替品の開発中も既存ソフトウェアが動いているため、緩い締め切りを持つ。
予算上の圧力や約束、新機能に対するユーザーの期待はあっても、代替品が1日遅れたからといって大ごとにはならない。
逆に宇宙探査機を打ち上げるのに、惑星の位置が重力アシストに合わなくなれば、宇宙船は目的地に到達できない。年商1億ドルの小さな工具メーカーがFordから2026 F150生産ライン用の金型を3月までに納品する契約を受け、遅れたら1分あたり2万ドルの罰金を払うなら、2月になって「想定外のことが起きたので無理です」とは言えない。確実にできるときだけ署名すべきだ。
FordやNASAは、見積もりを出すのに数万ドルかかると言われても驚かない。ECOを渡し、手作業なら30分で作れそうな部品に3週間と8000ドルが必要だと言われても、その中に締め切りリスク、受け入れ段階、検査段階、緊急時対応計画などが含まれていることを理解している。
しかしOPのモダナイゼーション・グループで「情報が不完全なので、ボタンの文言を変える30分作業が最大3週間と8000ドルかかる可能性があります」と言えば、門前払いされるだろう。楽観的な見積もりは報われ、悲観的な見積もりは抑え込まれ、正確な見積もりは重要ではなくなる。結局、いつもスケジュールに遅れ、それでも誰もあまり驚かない。
ハードウェア変更、OSアップグレード、新機能対応といった保守が含まれることもある。こうして10年以上並行で走っているプロジェクトも見たことがある。
1505年、MichelangeloはPope Julius IIの墓を完成させるのに5年かかると見積もった。
Sistine Chapelの天井画のような小さな副業のせいで、実際には約40年かかった。
見積もりに基づく締め切りを守れないまま、プロジェクトの規模は大きく縮小された。Pope Julius IIが完成前に亡くなり、顧客であるJuliusと相続人たちからの変更要求、サプライチェーン問題、契約再交渉、労働争議、熟練労働者不足、長期間に伴う資金枯渇があったためだ。
だから少なくとも1505年から、こういうことはあったわけだ。面白いのは、教皇がその墓に埋葬されてもいない点である。
キャリア初期に重要なことを学んだ。最初に出した数字が記憶に残る。
残念ながら実際によくそうで、人々は「最初に X だと言っていなかったか？」と言い続ける。「その通りだが、新しい情報を得た」が常に通用するわけではない。
これを知っている人は、数字を提示するのを避けるようになるという副作用もある。
Scotty: “もちろんです、船長。そうすれば奇跡を起こす男という評判を保てますから”
たとえば日→週、週→月、月→四半期に変える。1日で済む作業なら3週間と言う。多く見えるが、結局は官僚主義、手続き、技術的負債のせいで、たいていそのくらいで終わる。
「保険会社が修理工場に、もともとの見積もりは18,000ドルだったのだから追加の20,000ドルは払えない、と食ってかかるのを想像できるだろうか？ ばかげていないか？ 私もそう思う。幸い現実はそのようには動かない」というくだりがあるが、保険ではそういうことは常に起きる。
自動車保険・住宅保険だけでなく、健康保険も同じだ。合理的な落としどころに交渉されることも多いが、常にそうとは限らないので、「現実はそのようには動かない」という自信満々な口調には驚く。
全損扱いのほうが高くつくことはあっても、上限が明確で請求をクローズできる。保険会社は未決の請求を嫌う。
後者、つまり自動車保険で「優遇料率」とも呼ばれるものは、特定種類の作業を固定された交渉済み料率で請求するという包括契約だ。
これは拘束力のある見積もりとは大きく異なる。拘束力のある見積もりは通常、特定作業に対する一回限りの見積もりであり、見積もり担当者がリスクを負い、予想よりはるかに複雑でもその料率で完了すると約束するものだ。
可能なら常に固定された範囲についてだけ見積もり、未知の未知は除外するのが一つのコツだ。
「機能 X の実装」を見積もるのではなく、「機能 X のエンジン」を見積もるべきだ。追加作業が見つかったら、「既存コードのリファクタリング」「機能 X+Y の統合」のような、発見されたマイルストーンとして追加すべきだ。
ただし、この命名法と理解が上層部まで届いて初めて効果がある。誰かが「機能 X のエンジン」というマイルストーンを、同じ見積もりのまま「機能 X 完了」に変えてしまったら終わりだ。
関連する問題も見たことがある。リーダーシップが締め切りを「動機づけ」だと考える場合だ。家を72Fまで暖めたいのに、「もっと早くそうなるように」とサーモスタットを80Fに設定する人たちのようなものだ。
あるとき、下っ端エンジニアである私がリーダーシップ会議に招かれていることを、ほかの出席者が忘れていたことがあった。誰かが締め切り X を守るのは非常に難しいと認め、もっと現実的な日付に変えるべきかと尋ねると、シニア PM は「私たちは締め切りを絶対に動かさない！ エンジニアリングは与えられた時間を全部使い切る！」と答えた。
その場合、エンジニアリングは私がそのチームを去ることで時間を返した。
多くのエンジニアリングチームが与えられた時間を使い切るのも事実だ。
しかし管理者は、見積もりや計画をエンジニアの前で硬直した締め切りにするのではなく、組織が超過に備えられるようにすべきだ。予想完了時点が近づいたとき、開発者がどの部分がなぜ長くかかったのかを説明できるなら、合理的に理解すべきだ。
管理者は、顧客、営業、上級管理者も計画上の完了時点を締め切りとして扱わないようにすべきだ。約束をしなければならないなら、顧客向けの締め切りは予想完了時点よりかなり後に置くべきだ。
電気ラジエーターでも、実際には効果があるかもしれない。ラジエーター付近の空気だけが暖まったからといって、すぐに切れるわけではないからだ。
あまりにも多くの「ざっくりした当て推量の見積もり」がハードな締め切りに変わるのを経験して以来、ステークホルダーに No Estimates アプローチを推している。
最初は当然抵抗がある。懸念を和らげるには、計画に正当に使えるほどかなり正確な見積もりは、実は次の二つの場合にしか可能ではない、と説明するのが役に立つ。
A) 残りの作業が過去の作業の複製に近い場合。たとえば同じシステムのデータセンターを2回目にプロビジョニングする場合。
B) チームが、残りの新機能作業が最後の四分位に入り、成功を妨げる残りのリスクまで含めて十分に定義されていると判断した場合。
マイクロ見積もりはマイクロマネジメントを可能にする。健全なチームは、プロジェクト成功のリスクを基準に優先順位が最も高い作業を見つけ、高い順に実行する。
0 - https://www.youtube.com/watch?v=MhbT7EvYN0c
1 - https://www.goodreads.com/book/show/30650836-noestimates
以前 HN で見た面白い公式が目に留まった。派手で格好よく見えるが、ほかの見積もり方法と同じく形式的な妥当性はなく、個人の経験に基づく任意の公式にすぎない。
https://news.ycombinator.com/item?id=37965582
私の見積もり数学: R = t × [1.1^ln(n+p) + 1.3^X]
R は実際にかかる時間、t はコミュニケーションが不要な場合に可能な最短時間、n は顧客と開発組織を含めてプロセスに参加する人数、p はプロジェクト内の最長コミュニケーション距離、X はプロセスで使う新しいツール・ライブラリ・手法の数。
たとえば開発者1人がコードを書くプロジェクトが2週間かかり (t=2)、合計5人が関与し (n=5)、新しいツールが1つ (X=1)、最長コミュニケーション距離が4なら、2×(1.1^ln(5+4) + 1.3^1) = 4.5週間となる。
既知の未知だけでなく、未知の未知についても X の数を足すべきだ。
悲しいことに、見積もりは交渉です。先に数字を出した人は、たいてい「しかめっ面」に負けます。
「見積もりはどれくらいですか？」「よく分かりません」「ざっくりでもいいので」
「では、いつまでに必要ですか？」
これが新人マネージャーが毎回はまる罠です。答えを出したらビンゴです。そのときに「しかめっ面」を見せます。歯の間から息を吸い込み、顔をしかめながら「ああ、それはまったく現実的ではありません。その数字はいったいどこから出てきたんですか？」と言って、その何倍もの数字を出すか、作業範囲の縮小を提案します。「いやあ、その期間だと、運が良くても、別プロジェクトのY機能を削らないとX機能だけが可能ですね」といった具合です。
何をするにしても、先に数字を出さないことが重要です。ポーカーや車の購入と同じで、感覚をつかむには少し時間がかかります。大企業でも時間はお金であり、そのように扱うべきです。ゼロサムゲームです。
私の職場では、効率化という名目で見積もりがどんどん低くなり、持ち越し作業も認められません。
回復する時間もなく、1年以上ほぼクランチに近い状態で過ごしてきました。改善することをずっと願っていましたが、むしろ悪化しているように感じます。さらに、全員が製品の別領域へと次々にローテーション配置され、選択肢もありません。まだ走り続けてはいますが、精神的には完全に燃え尽きた感じです。