不確実性と向き合う ─ あえて今、“プロジェクトの常識”をふりかえる

まえがき

カンリーでシニアプロダクトマネージャーをしている越智(X : @ochi__san)です。
「当たり前」が実は「勝手な前提」だった。
そんなことがあったので、散々コスられている「プロジェクトの常識」についてふりかえってみました。非エンジニアにも「そういうことね！」と思ってもらえる…と思います。

はじめに

今回は、プロジェクトの初期フェーズにおける「見積もり*」と「優先順位」についての考え方です。出てくるワードは以下の2つです。

1. 不確実性のコーン
2. トレードオフスライダー

いまさらかよ！！という声も聞こえてきますが…ふりかえりなのでご了承ください。
*「見積もり」≒「開発工数」

プロジェクトについて

全ての機能を最速で高品質でリリースしましょう！できるだけ予算を抑えて！

夢のようなオーダーの実現は難航します。「選択と集中」「優先と犠牲」その狭間でプロジェクトリーダーは苦戦を強いられます。
不確実性を前提とするソフトウェア開発において、工数やスケジュールを正値で宣言することは難しく、リスクも大きい。
ではなぜ、ソフトウェア開発は見積もりをしたくなるのか、なぜスケジュールを確定させたがるのでしょうか。

不確実なものに確実性を与え、安心したいから

限られた予算と資源の中で、「いつまでにいくらで」が見えないプロジェクトは、投資対象として扱いづらくなります。見積もりやスケジュールは心理的な安心感を与えるとともに、判断と意思決定の材料として機能します。
しかし、不確実性が前提とされていないスケジュールがいつしかコミットメントとなり、期待値が擦り合わないままプロジェクトが進むことがあります。そうすると、状況の変化が反映されない「歪み」が蓄積し、その歪みは次の歪みを生みます。これが「遅れ」と勘違いされる要因です。

ソフトウェア開発において、不確実性が高くなる原因をいくつかご紹介します。

1. お願い事が増える
2. やったことのない方法を試す
3. メンバーが入れ替わる
4. 外部の都合に振り回される

旅行の計画をしていても天気や交通の事情で計画が変わったり、料理を味見しながら味の調整をしたり、日常にも当たり前のように「変化」は起こるものです。
では、プロジェクトの状態として、どのような状態を目指すべきなのでしょうか。

「計画は変わる」ことを前提とし、その変化に柔軟に適応できること

そのために大事なのは、「進捗管理」ではなく「期待値のコントロール」だと考えています。

不確実性のコーン

不確実性のコーンは、ソフトウェア開発における不確実性を表した概念です。
X軸はプロジェクトの開始と終了を時系列で、Y軸のコーン(三角形)は、開発工数などの見積もりの誤差を倍率で表現しています。
「プロジェクトの初期に正確な計画を立てることは困難」ということを意味します。プロジェクトが詳細化され、開発が安定する終盤になるにつれて誤差が収束されていくイメージです。

なぜこんなことが起こるのか。

最初から全ての要求を揃えることは不可能であり、減らずに増える一方だから

市場や事業状況、顧客を取り巻く環境は常に変化します。それに伴ってプロジェクトの中盤、終盤においても要求は増します。
私のポリシーである「あったらいいな、はなくていい」はこういう事象から生まれた言葉です。

不確実性と向き合う

「4倍の誤差を許容する」ではなく、それを「前提」とし不確実性を減らしていくアプローチが重要です。
スコープや開発アイテムを小さくして完成形をイメージしやすくし、誤差を最小限に抑える努力は必要です。変化を受け入れ、柔軟にスコープをコントロールすることが大事なアクションです。
不明確なスケジュールは、ステークホルダーにとって大きな不安要素になります。
だからこそ「勝手な前提」を「共通認識」にした上で、小さなバッチサイズ・短いイテレーションで現状を見える化し続けることが大切です。誤差が抑えられ、変化も小さくなり、ステークホルダーとのコミュニケーションも軽やかになります。

トレードオフスライダー

懐かしのアジャイルサムライでは「時間・品質・予算・スコープ」を荒ぶる四天王と表現されていましたが、トレードオフスライダーはこの4つをどういう優先順位で意思決定するかを定める際に用いられるツールです。もともとはインセプションデッキというフレームワークの中の1つのコンテンツですが、それを切り出しています。
「選択と集中」「優先と犠牲」をあらかじめ明確にし、合意するためのツールとして有用です。
絶対に譲れないもの(守りたいもの)と調整可能なものの認識のズレや責任の押し付け合いを未然に防ぎ、プロダクトマネージャーとして意思決定の説明責任を果たす際に機能します。

プロジェクトの本質

ソフトウェア開発においての最大のリスクは「ズレること」ではなく「ズレに気づかないこと」です。
求めるべきは、完璧な計画ではなく──変化への適応と関係性の強さだと考えています。

前提を疑い、変化を受け入れ、期待値を揃える

「完璧よりも完成」を目指し、「始めることをやめて、終わらせることを始める」。
この姿勢こそが、プロジェクトを前に進める原動力になると信じています。

あとがき

ソフトウェア開発現場では数十年前に当たり前化したことを、今回改めてふりかえってみました。ビジネス職の方々には馴染みがない話だと思います。
AIで生産性を高め業務効率を図ることも大事ですが、現場で人が対峙する部分こそ丁寧さが求められると感じています。実際、ステークホルダーとの会話には時間もお金もかかります。
身近で直面した「勝手な前提」を改め、丁寧にお仕事をしたいなと思いました。