不確実性を考えてみた

この記事は、Unipos Advent Calendar 2025の9日目の記事です。

Uniposで機能開発のエンジニアリングマネジメントをしている、かっさんです。

不確実性という言葉が割と組織に定着してきているなーと感じており、どのような扱い方を行なっているかをシェアとして書いてみます。

不確実性とは

開発をする中で、「不確実」なものは非常に多いと思います。

• ソリューション不確実
• スケジュール不確実
• リソース不確実

などなど
開発を取り巻く不確実なことをどのように取り除くかはマネジメントの関心ごとの多くを占めていると思います。
今回はスケジュール不確実性についてを、どう捉えて社内で話しているのかについて扱います。

要件が増えるのに、工期が決まっている

これまで前職を含めてシステム開発を仕事としてする中で、ずっと思っていることとして
「リリース日がプロジェクトの最初から決まっているものでいい経験があまりない」
です。
多くの開発者が頷く話だと思いますが、開発にはQCDのバランスがあって、それぞれがトレードオフの関係にあります。

なぜ、クオリティとしての要件が増えるのに、リリース日は決まっているのでしょう？
クオリティが増えるなら、コストかデリバリーが変動するのは当然なことです。
そうしたことが図で表しています。

今日のリリースは本当に完了するのか

リリース日当日に本番環境に適応して、うまくいかない！と慌てふためくことがままある。
最善は尽くしているが、それでも何か問題は出てくるよねと。

• データのマイグレーションがうまくいかない
• フロントエンドで実際に触ると気づかなかったバグがあった
• そもそもインフラ環境がなにかあわない

などなど、本当にリリースしきるまで確証のあることはないよなと思います。

ただ、こうしたリリースまでの問題を今思うと、よりよいフレームワークを企画・開発双方で捉える働きかけができていなかったんだなと強く思います。

Uniposではどうしているか？

社内でスケジュールを共有するときには、不確実性コーンをもとにした考え方で状況共有をしてます。

プロジェクトマネジメントで一定見る図かなと思うのですが、

• 縦軸: スケジュール変動幅
• 横軸: 時間軸

を表しています。
時間が進むほど、スケジュールが確実になっていくことを表しています。

ソフトウェアの完了としてリリースが行われるまでは、変動は多少はあるというのが前提の図になっています。
先程話した当日に慌てるというのも、完了するまで工期は変動はするという意味が含まれているよう思います。

では、この図を見たうえでというのが話なのですが、Uniposでは以下の3フェーズの見積もりルールを決めています。

• 超概算見積もり: 誤差 -50% ~ +100%
• 概算見積もり: 誤差 -25% ~ +50%
• 詳細見積もり: 誤差 -10% ~ +25%

最初に企画が生まれたときに正確な工数を決めれるでしょうか。おそらく大半が不可能です。
そのため、ざっくりな見積もりとしてで超概算見積もりをして出します。
もちろん、誤差として+100%がありうるとして出すので、ズレるというのが前提にあります。

そこから開発が進むに連れ、より詳細な見積もりができるようになるため、リリース日が明らかになっていくという考え方をしています。

もちろん、詳細見積もりをした中で、要件を変えたいときもあります。
そんなときには、概算見積もりに戻そうかという期待値の調整をしていきます。

ただ、この考え方だとリリース日が遅れてもいいということにもなりそうですが、そこはプロジェクトとしての期限としてどうかというのはもちろんあります。
その中でもQCDでデリバリーを明確にする中で、落とすべきクオリティ、他チームに助けを求めてコストをかけるといった話ができると、プロジェクトの完了についての合意が取りやすくなります。

こうした枠組みを開発者だけでなく、開発に関わるステークホルダーとも認識が揃っていると、なぜ工数が変わるのかという理解が深まり、よりよい判断をすることができます。

まとめ

顧客に価値を届ける中でリリースというのは非常に重要ではありますが、そこまでの過程でどう社内・お客様に対して約束をするかというのはプロダクト開発の現場で非常に重要なことであり、大切にしていきたいことです。

だからこそ、現状認識をきちんと共有し、なぜスケジュールが変わるのかの認識があることで、よりよい判断ができると思います。

今回は社内でのスケジュールの扱い方について、シェアでした！！