はじめに

あるとき、こんなことを考えていました。

防犯カメラって、何台置いたら効果が出るかわからない。でも予算は組まないといけない。あの感覚、プロジェクト管理に似ていないか、と。

この着想は、以前「SREへの投資はなぜ軽視されるのか」を警察・消防の比喩で書いたときに生まれたものです。

/ja/tech/why-sre-investment-undervalued

うまく言語化できていなかった何かが、その問いの中にあった気がして。

不確実性の高いプロジェクトにおいて、私たちはずっと「不確実性を排除しようとする計画」を立て続けてきました。詳細なWBS、精緻なガントチャート、リスク一覧。でも現実には、計画が詳細であるほど、外れたときのコストが大きくなります。

では、どうするか。

この記事では、「不確実性は排除するのではなく、構造化する」という考え方と、そこにAI（LLM）を組み込んだプロジェクト管理のコンセプトを整理します。

根っこにある考え方の転換

不確実性の高いプロジェクトで行き詰まる理由は、多くの場合「計画への執着」にあると思っています。

従来のウォーターフォール型の発想は「計画が正しければ、実行は計画通りに進む」という前提に立っています。でも現実はそうじゃない。前提条件が変わる、要件が変わる、技術的な壁が出てくる。

そこで「計画を守る」ことにエネルギーを使うか、「計画を更新しながら学び続ける」ことにエネルギーを使うか、という選択が生まれます。

不確実性が高い状況では、後者のほうが圧倒的に機能します。

アジャイル・スクラムが提唱する「短いサイクルで動くものを作り、フィードバックを得る」というアプローチは、まさにここを突いています。スプリントの振り返りで問うべきは「タスクが終わったか？」ではなく「何を学んだか？次の計画をどう修正するか？」です。

進捗の報告軸も変わります。「完了率」ではなく「リスク消化率」——「重大な前提条件のうち、何個検証済みか」「残っている最大のリスクは何か」を中心に置く。開発チームの健全性を測る指標としてはDORAメトリクス（デプロイ頻度・リードタイム・変更失敗率・復旧時間という4つの指標群）が知られていますが、それも「何を学んでいるか」を見るための道具として使うのが本旨です。

もう一つ、個人的に効果的だと感じているのが**「リスク管理」から「前提条件管理」への転換**です。

「リスクを予測する」という発想だと、起きていないことをリストアップするだけになりがちです。一方で「このプロジェクトが成立するための前提条件は何か」を洗い出して、影響度×不確実性でマトリクスを作り、危険な前提条件から潰していく——これを「リスク駆動型の優先順位付け」と呼んでいます。

「いつ終わりますか？」という問いへの答えも変わってきます。

「現時点では○月〜△月の間を想定しています。□□の前提条件が確認できれば、○月末に絞れます」

ピンポイントではなく、範囲で答える。不確実性を正直に伝える。プロマネとして「確実性を演じる」ことをやめると、むしろステークホルダーとの信頼関係が安定することが多いです。

AIを「構造化の道具」として使う

ここからが本題です。

不確実性への対応（アジャイル的なアプローチ）とAI活用は、これまで別々の文脈で語られてきました。でも組み合わせると、面白い構造が生まれます。

AIが不確実性を可視化し、人がそれを使って判断する。

その起点になるのが、LLMによるチケット難易度判定というアイデアです。

なぜチケットの難易度判定が面白いか

開発現場では、チケット（タスク）の難易度認識が人によって異なるままプランニングが進みます。「これ2日で終わる」と思って着手したら、5日かかった。バグも出た。でも振り返っても「なんとなくそう思っていた」以上の根拠がない。

LLMにチケットの説明文・関連コンポーネント・依存関係・類似チケットの過去実績などをインプットして難易度を判定させると、チームの中に「共通の出発点」が生まれます。

チケット作成
　↓
LLMが難易度・バグリスクを判定（根拠付き）
　↓
プランニング時に参考値として提示
　↓
開発者が合意・調整
　↓
実績（時間・バグ発生）を記録
　↓
LLMの判定精度を継続改善

ここで一つ、設計上の大事な点があります。

「人間による上書き」を許容しない設計にするということです。

難易度判定を「評価」に使うと、開発者がチケットの記述を操作するインセンティブが生まれます。「難易度を高く見せたほうが評価が良くなる」となった瞬間、この仕組みは形骸化します。

なので、チケットの記述文だけで判定しない設計が重要です。関連コンポーネントの過去バグ頻度、変更ファイル数・コードの複雑度など、開発者が書く文章以外のシグナルをメインに使います。そして、あくまで「チームの設計改善」「意思決定の補助」として位置づける。

目的の透明性を組織として担保することが、仕組みを長持ちさせる根本だと思っています。

難易度データが「連動」すると、何が起きるか

チケットの難易度が構造化されてデータとして蓄積されると、それ単体で終わらない広がりが出てきます。

graph TD
    A[チケット難易度判定 LLM] --> B[アサイン最適化]
    A --> C[バグリスク管理]
    A --> D[育成ロードマップ]
    A --> E[工数見積もり精度]
    B --> F[組織の学習速度向上]
    C --> F
    D --> F
    E --> F

アサインの最適化

人によって、モチベーションが上がる仕事のタイプが違います。難しい課題に没頭することにやりがいを感じる人もいれば、細かいタスクをどんどんこなすことが好きな人もいる。

難易度データと「開発者ごとの好みのチケットプロファイル」を照合すると、アサインを「経験と勘」から「根拠のある選択」に少し近づけられます。

これが評価ではなくアサインに使われると、開発者も正直に答えたほうが自分にとって得になる構造になります。

さらに、「この人は高難易度チケットを好むと言っているが、担当後のバグ率が高い」という場合、スキルと志向のミスマッチが見えてくる。それを1on1の材料にする、という使い方が自然に生まれます。

育成と組織設計

エンジニアのグレード定義を「チケットの難易度分布で表現する」という発想です。

ジュニア：難易度1〜2を安定してこなせる
ミドル　：難易度3〜4を独力でこなせる・5に挑戦できる
シニア　：難易度4〜5を安定してこなしつつ、設計判断ができる

「ちょっと背伸びするチケット」を意図的にアサインして経験を積ませる、半年前と今でチケットの難易度分布がどう変わったかを数字で見る——育成の「見えにくさ」が少し解消されます。

工数見積もりの精度

多くの現場で見積もりは「実装工数」しか見ていません。テスト工数は経験則でざっくり、予期せぬ問題は「バッファ」という名の曖昧な上乗せ。

難易度データと過去の実績が蓄積されると、こういう判断ができるようになります。

難易度3のチケット（過去実績より）
　実装　：平均2日
　テスト：平均1日（実装の50%）
　手戻り：30%の確率で発生、平均0.5日追加
　→ 見積もり：3〜4日のレンジで計画

「バッファを厚めに」という属人的な経験則が、難易度帯に応じた構造的なルールに変わっていきます。

このコンセプトが埋めようとしている空白

アジャイルは「素早く適応する」を説きますが、何を見て適応するかのデータ設計は語っていません。DORAメトリクスはデータを提唱しますが、個人の志向や育成との連動は対象外です。

「AIで不確実性を構造化するPM論」は、その間を埋めようとしています。

不確実性を排除するのではなく、構造化する。その構造化にAIを使う。そして蓄積されたデータを、人の意思決定（アサイン・育成・見積もり）に還元する。

「AIが不確実性を可視化し、人がそれを使って判断する」という役割分担の設計論、とも言えます。

まだ言語化しきれていないこと

正直に言うと、このコンセプトはまだ「思考実験」の段階で、実装・検証まで至っていない部分があります。

特にLLMの判定精度をどう継続改善するか、開発者の「判定はあくまで参考」というスタンスをどう組織として維持するか——ここはやってみないとわからない部分が多い。

ただ、「不確実性は排除できない、だから構造化する」という方向性は、確信を持って言えます。

防犯カメラを何台置けば効果が出るかはわからない。でも、「どこに置いたか」「何が変わったか」を記録し続けることで、次の判断が少しずつ精度を上げていく。

プロジェクト管理も、そういうものだと思っています。

参考：不確実性について学ぶ

不確実性そのものの構造を理解したい方には、以下の書籍が参考になります。経済・社会・テクノロジーにおける不確実性の本質を、幅広い視点から整理した一冊です。

[📦 商品リンク: moshimo-book-pfwiZ]

[📦 商品リンク: moshimo-card-sGMKc]