見積もりは何を約束しているのか
— 不確実性・機会費用・見えないコストを見積もりに含めるということ
1. 見積もりが外れる方向は、実は決まっている
見積もり通りにいかないこと。
開発に関わったことがある人にとっては馴染みのある話だと思う。
予定より早く終わることもあるけれど、遅れる側に偏っている。
「2週間でできます」が3週間になる。「来月リリースできそう」が再来月にずれる。
予測能力の問題というより、見積もりに何を含めて何を含めなかったかの問題のように思う。
外れること自体が問題と言いたいわけでもなく、「なぜ外れたか」を説明できないかあやふやにしている気がする。
何を暗黙に除外していたかが言語化されていないと、次も同じように外れる。何度繰り返してもあやふやなものになる。
これは見積もりの精度を上げる方法ではなく、見積もりで何を可視化しておくかの話。
何が含まれていて何が含まれていないかが見えていれば、外れた時にはどんな前提が崩れたかが分かって、次の判断に繋げられると思う。
「3週間でできます」が、実際は何を意味しているのか。
それを受け取る側という側がどこまで分かった状態で合意しているのか。
長期では見積もり通りに進むかどうかより、効いてくる気がしている。
2. 見えていない作業
「2週間でできます」の2週間の中身は具体的に何か？
実装している時間だけを思い浮かべて答えているのか、他にもやることを含めているのか。
実際には、その期間の中に複数の作業があり得る。
要件の確認と整理、エッジケースの方針、既存コードとの統合判断、テスト、ドキュメント、デプロイ、関係者とのコミュニケーション。
実装そのものより、その周辺の作業の方が時間がかかることもある。
特に要件確認と技術検証とか。
依頼を受ける時点で要件が確定していないことは多い。
「だいたいこういうことをやりたい」という状態から、実際に作れる粒度まで詰める。
これを2週間の中に含めているのか、含めずに「要件は確定している前提」なのかでも、実態が変わる。含めずに答えていることもあると思う。
技術検証については、二つのパターンがあると思う。
一つは、新しい技術や分野、ツールを使う場合。
動かしてみて分かることが多く、ドキュメントの記述と実際の挙動が違ったり、想定していた使い方ができなかったりする。検証の結果、最初に考えていた方針を変えることもある。
これは「やってみないと分からない」性質のもので、確実な見通しは立てにくい。
時々、フィジビリティの確認なしに「これくらいでできるはず」という見積もりが先に決まっていることがある。
実際にやり始めると、サービスの不具合があったりして、想定通りには動かないと分かる。それでも期間は動かせなくて、休日対応とかして無理に進めることもある。
結果的に、最初に考えていた方法ではなく、無理やり作ったものになる。
検証を後回しにしたコストは、実装する側が負担することになり得る。
もう一つは、確立された作業でも、その人の経験にはないこと。
技術やツールの新しさの問題ではなく、その人にとっての未知かどうかの話。
すでに同じ経験がある人なら数時間で済むことでも、初めてだともっとかかるパターン。
どちらも、「検証で時間がかかる可能性」を含めるかどうかで、見積もりも変わる。
含めないで答えると、検証で予期せぬことが見つかった時に「想定外」として扱うことになる。実際は想定外ではなくて、最初から未確定なことが見積もりに含まれていなかっただけなのに。
エッジケースも似ていて、主な動作が動いた後で、想定外なデータパターン、想定外のユーザー操作、想定外の負荷で問題が出る。
最初は見えていなかったもの。放置するかハンドリングできるように実装するかの判断や作業で、リードタイムが伸びることもある。
動作確認を進めるたびに次の課題が見つかって、気づくとPRのDiscussionやコメントが数十まで膨らんでいる、みたいなことだってある得る。
共通するのは、「やってみないと正確には分からない」性質を持っていること。
確実な見通しを立てられていないないことに、確実な期間を割り当てることが、成り立っていないように思う。
3. 「なんとなく対応」の機会費用
対応するかどうかを、それ自体の重さだけで判断していることは多い。
「これくらいならすぐに終わる」と思って対応し始める。
実際にすぐに終わっても、その間に進められなかった別の作業はある。
見積もりの中には出てこない機会費用。
「すぐにできます」と答えた時、代わりに何が止まるかは答えられない。見ているのは目の前の対応だけ。
一つ一つは確かに小さくても、複数を引き受けると、他のことは少しずつ遅れる。
気づくと、本来やりたかった大きい仕事に時間が使えていない、って状態になっている。
小さな対応をやり始めると、派生して別の作業を生むこともある。
ログを吐くように設定したら、ログの出力先・保存場所などの細かい設定が必要になる、その方法を調べているうちに本来の対応からそれていく。出てきた対応をどこまで、気にする・対応する必要があるかどうかの判断はされないまま、目の前の小さな作業だけが重なる。
頭を切り替える時間もそこに含まれる。
一つの作業から別の作業に移る時、すぐに動けるわけでもない。
30分で済む依頼に答えるために、1時間以上の集中が途切れることがある。
機会費用を見積もりに含めるなら、「2日でできます」が「2日かかります、その間〇〇は止まります」になる。
何を判断するかの材料が増える。
判断する側からすると、「〇〇を後回しにしてもやるか、優先しておくか」を判断できる。
「両方やってほしい」と言って、中途半端になるのも防げる。
対応する側からすると、依頼を受けるかどうかを目先の利益や緊急度ではなく、抱えている全体の中で判断できる。引き受けることで何を失うかを整理できる。
4. 正直な見積もりの形
不確実性と機会費用を見積もりに入れるとどうなるか？
「2週間でできます」が、
「2〜3週間。要件の確認に2〜3日、検証で1週間、実装と動作確認で1週間ほど。検証で想定外のことが見つかれば、もう1週間伸びる可能性がある。 この期間、AとBは進まない。 推奨はこのまま進めること。途中で要件が大きく変わるようなら、その時点で見積もりは変わる」
「結局いつできるのか」と聞かれるなら、その時には確度を添えることになる。
「早くて2週間、想定通りなら2.5週間、何かあった場合は3週間以上」のように。
それでも、片方の数字に固定されてしまいやすい。
「何もなく終われば2週間、何かあればそれ以上」と伝えても、「じゃあ2週間で引いておきます」となるだけだったりする。
実際に余計な対応が増えても、続ける続けないの判断はなくただ決めた期間の対応にコミットする、という状態になりやすい。
見積もりの形を整えても、受け取る側が単一の数字に戻すと、想定していた・していなかった結果が見えなくなる。
見積が変わるきっかけは、書き出してみると意外と小さな項目で済むことに気づく。
「要件が大きく変わったら」「予定の作業が想定の倍以上かかりそうだと分かったら」「前提が変わったから」。
明示しておくと、その時点で「やるかやらないか」の判断が一度入る。
明示していないと、何かあっても判断は省かれて、そのまま実行が進む。
気づいた時には大幅な手間をかけて対応している。
5. 固定的な見積もりが選ばれやすい理由
不確実性と機会費用を入れた見積もりは、手間がかかると思う。
だから、選ばれやすいのは固定的な見積もりの方だとも思う。
言う方か言われる方のどちらかが手を抜いているという話ではなく、構造的にそうな気がする。
短期で見ると、固定的な見積もりの方が合理的に見える場面が多い。
「3週間です」と言える方が、社内の合意形成が早かったり、経営層への説明もシンプルになったり。
「2〜3週間、前提が崩れたら4週間」と言うと、「で、結局いつなんですか」と詰められたりする。詰める側にも、別の人に説明する義務があったりする。
範囲つきの見積もりは、その先の説明を難しくする。
同じように、比較するときも確証がある方がえらばれやすかったり。
A社が3週間、B社が「2〜4週間、状況による」と言ってきたら、A社の方が頼もしく見える。実際にA社が3週間で出せるかは別問題でも、その場の判断ではA社が選ばれたりする。
競争環境の中だと、失注のリスクと隣り合わせになっている。
だから、数字を合わせに行きたくなる。失注すると次の仕事が来ない不安があるから。
個人のやり方の問題ではなく、選ばれる側に置かれている人への構造的な圧力。
数字を求める側にも、独自の事情があるように思う。
「この期間でこんなものを作ってほしい」という願望と、依頼を始めてからのサンクコスト。
最初に立てた計画を引っ込めにくい状態で、見積もりを聞く。だから、不確実性を入れた見積もりが返ってきても、最初の計画に合う数字を引き出そうとする。
技術的な判断ができる人がいないと、やりたいことに対して稼働時間や期間がとりあえずで決められていたりもする。増えたら増えたで調整しますというスタンス。
振れ幅や不明瞭な点は明示されずに。
こういうのが重なって、固定した見積もりで進めることが、自然な選択になっていると思った。
それぞれが置かれた構造の中で合理的に振る舞った結果。
ただ、短期的には合理に見えても、長期的にも合理かは別の話だとも思う。
6. コストは、どこに溜まっていくか?
無理に固定した見積もりは、短期では扱いやすい。
ただ、代わりに品質の議論は後回しになる。
「3週間でやります」と決めた後、その期間に間に合わせるための物事が優先される。
設計が妥協される。
後から扱いにくくなる構造のまま実装が進む。
難しいから・複雑になるから今は断念しよう、という判断は、受注した段階で消えていること。
取り決めの場に技術的に具体的なことがわかる人が関わっていないと、さらに起きやすくなる。
こういうのは事業の数字には現れにくい。
コストは、見えにくい場所に溜まっていってると思う。
1つは、コードと設計。
期限に間に合わせようして、テストが薄くなる。
ドキュメントの更新が止まっている。
後の機能追加などの変更の手間やインシデントのリスクが増える。
小さいけれど積み重ねると、新しい機能を作る速度も下がっていく。
事業の数字に現れる頃には、解消するのも大掛かりになる。
他には、開発する人。
無理な期限に合わせるために、残業する。
要件が決まらないまま開発の期間が減る不快感。
将来のリスクや「こうしておいた方がいい」という提案は出しにくくなる。
期限と稼働時間で管理する文化で、こういうことが当たり前になる。
結果、開発者はその現場から離れたくなる気持ちが積み重なる。
エンジニアが離れる時の理由として言われることもあまりない。
採用などの面から徐々に見えてくるかもしれないけれど。
こういうコストは見えないだけで、評価サイクルの外では溜まっていっているように思う。
事業の数字に現れないから些細なコストというより、後になって大きく現れる、気がする。
7. 不確実性を想定することが、長期で生むものは？
不確実性を想定して見積もっても、すぐに事業の数字に出るわけでもない。
けれど、見えにくい場所で積み重なっていってると思う。
例えば、期間にコミットすること以外の学び。
無理に決めようとすると、たいていバッファが持たれる。
時には、間に合わせるために残業する。
どちらにしても、決まった期間を使い切る前提。
パターンで見積もると、何も起きなければ早めに終わらせられる。
「早ければ1週間」と伝えていれば、想定通りに進んだ時に1週間で終わっても、それは見積もりの範囲内。
早く終わった分、別の作業に進める。
不確実なことが起きた時には、うしろの期限まで延ばされる。
その分大きな対応になる。
終わってみて割に合う対応だったか、何があったからかを見直す機会になる。
他には、事業の数字に少しずつ現れるもの。
インシデントや不具合が減って、顧客の信頼に繋がる。
品質の議論が後回しにならない構造から起きるもの。
コストが評価サイクルの外で積み上がっていくのと反対に、不確実性を含めた見積もりは、利益として積み上がっていく。
明確に何かが解決するわけではない。
けれど、見えにくいコストと利益を判断材料にすることは、長期で効果があると思う。
8. 固定するメリット、その代わりに失うもの
一方で、固定した見積もりにもメリットはあると思う。
先に書いたコミュニケーションの構造以外にも。
なんとかして決めた期間内に終わらせようとすることや、不確実性を早い段階で解消しようと動きやすくなることだと思う。
「3週間で出さないといけないから、最初の数日で技術検証を済ませよう」っていうふうに、時間の制約があるからこそ、判断が前倒しされること。
こういうのは、外側から決まった締切がある時に起きやすい。
イベントの日程、契約の期限、法規制への対応とか。
動かせない期限があると、不確実性の対処の検討よりも、決まった期限に間に合わせる動きの方が強くなる。
短く固定した期間で区切るのも1つのメリットだと思う。
不確実なことが多すぎる場面で、期間を短く切って一度止まる。
その度に続けるかやめるかの判断を入れる。
最初のゴールのために長く時間を投下する前に、判断材料が増えるごとに見直すやり方。
こういう場面によっては機能するけれど、失うものあると思う。
期限を優先することで、品質の議論が後回しになる。
本来時間をかけるべき検討内容が浅くなる。
問題は、見積もりを固定すること・期限を設定することで、何を切り捨てているかが見えなくなることだと思う。
「期限があるから集中する」は、「それ以外のことを諦めている」。
「早く判断する」は、「その後を考えない選択をしている」。
そういうのにコミットする時には、代わりに失うものも、判断の中に入れておきたいと思った。
9. 見積もりへのコミットが、何に向かっていくか
見積もりを固定して、それにコミットし続けると、どうなるか。
大きく二つの方向に向かうと思っている。
一つは、提供する価値が市場相場の中に収まっていくこと。
発注と受注の関係では、案件ごとに「これくらいの規模なら、これくらいの人と、これくらいの期間で、これくらいの金額」という相場ができている。
範囲外の金額を出すと、他で頼んだ方が安いと思われて発注されなくなる。
固定の見積もりを出し続けることは、この相場の範囲に近づくことになる。
1つの安定の形だと思う。
ただ、提供しているものが「他でもできること」になっていくということでもある。
リーズナブルだから選ばれる構造。
他でも作れるものを、他より速く・安く・安定して提供することが、価値の中身になっている。
他でできないことをしていれば、相場とは関係ない金額でも妥当になる。
作るコストに見合った金額ではなく、相手が割に合うと判断する金額になり得る。
リソースの計算ではなく、提供するものが生む価値が判断基準になる。
相場の中で動き続けると、こういう議論の機会は減っていくと思う。
「速く、安く、予定通り」がブランド価値の中身になり、それを維持するために同じことを続けることになる。
中期的な自転車操業を続けることが、提供できる価値の中心になっていく。
他に、自社サービスの事業会社だとすると。
評価サイクルの期間内（四半期や半期など）で見える/出せる/説明できる成果が選ばれるようになる。
つまり、期間内では成果が見えないけど、その後で大きな価値に繋がるかもしれないものは、選ばれにくくなる。
3年かけて利益に繋がるものを作る。その見込みを検証する。
こういうことが、評価サイクルの中では成果として説明しにくい。説明しにくいと、実行されづらい。
結果、場当たり的なものづくりが続きうる。
共通しているのは、動ける範囲が固定されることだと思う。
市場相場の中、または評価サイクルの中では、安定して動けるようになる。その範囲で何を作るかは決まりやすく、迷いが少ない。
ただ、その範囲の外で生まれるはずだった価値には届かなくなる。
どちらが正解とは言えない。
市場相場の中で安定して受け続けることも、評価サイクルの中で確実な成果を積み上げることも、事業として成り立つ。
ただ、見積もりを固定してコミットし続ける選択をしている時、自分がどこに向かっているかの自覚はあった方が良い気がする。
決まった範囲の外で生まれるかもしれない価値を、暗黙に手放している可能性があるから。
10. 両者で決める見積もり
ここまでは、見積もりに何を含めて何を含めないかの話。
範囲を出すか、固定するか。
不確実性や機会費用をどう扱うか。
見えない場所にコストが溜まっていくこと。
市場相場や評価サイクルの中に動きが閉じていくこと。
見積もりの作り方によって、後で起きることが変わると思う。
それを踏まえて、「見積もりは出す側が作って受け取る側が判断する」やり方以外に、「両者で作る」やり方もあると思う。
誰かが一方的に言ったものに従うのではなく。
言う側は、範囲、確度、含まれる作業、機会費用、出し直すトリガーを言語化する。
受け取る側は、パターンをそのまま判断材料として使うか、事業の都合で期間を固定する必要があるなら、どこを最優先にするかを選ぶ。
例えば、リリース日は固定したいけれど、入れる機能は細かく区切れるようにする。
もしくは、機能は固定したいけれど、期間には幅を持たせる。
ズレた場合にはその原因や学びも成果物として残す。
固定するかしないかの二択や一方的な決め方・受け取り方ではなく、何をどこまで固定するかを、揃えるやり方。
ただ難しいのは、両者が同じ言葉で話せる必要があること。
見積もりを固定することのコスト、不確実性を扱うこと、機会費用が動くことの影響。
ある程度共通で理解していないと、詳細を出しても、単一の数字に丸めてしまったりする。
出し方だけでなく、受け取り方も変える話。
必ずしも正解とは言えないけれど、選択肢の一つとして考えておくと、幅が少し広がるように思う。
11. それでも残るモヤモヤ
見積もりの話だけでは解消しない部分もあると思う。
一つは、事業価値と作る人の利益の紐付き。
作ったものが生む価値と、作る人が得るものが繋がっていないと、作る側は経験や納品物を目的にしやすくなる。発注する側も、その場しのぎの成果を求めることになる。
議論の中身が長期に向きにくい。
ストックオプションのような形で繋ぐのも一つだけれど、そういう仕組みが用意されていない場面の方が多い。
働き方の構造もあると思う。
何時間働いていくらもらうという形だと、「どれだけの稼働時間か」が基準になる。
下請けの階層が深いと、上から降ってきた数字をそのまま下に渡すことが増える。
最後に、誰と長期で組むかの選択もある。
不確実性を織り込んで品質を求めるか、その時々の結果やコミットメントを求めるか。
自分がどちらを取りたいかと、自分と一緒に働く人はどちらを取る人か。
組織を扱う立場なら、その構造を決めることになる。
すぐに変わるものでもないけれど、続けることで、少しずつ動いていく気がする。
出てきた見積もりが妥当か、社内で判断できないとき：https://yoshiakihayashida.com/consulting/
