もっとも小さなプロジェクトの価値について考えてみた

プロジェクトMVC（Minimum Viable Creation）フレームワーク

基本概念

プロダクトMVP vs プロジェクトMVC

• プロダクトMVP: ユーザー体験（UX）に焦点を当てた最小価値の製品
• プロジェクトMVC: 持続可能性とリスク回避に焦点を当てた最小価値のプロジェクト

プロジェクトMVCの価値定義

「このやり方で今後も進めることで大きく問題が起きることがない」

回避すべき「大きな問題」

1. コストが見積もれなくなる・肥大化する

• 見積もり精度の低下
• 機能追加や変更によるコスト影響の予測困難
• スケール時の予測可能性の欠如

2. 予定期間を超過するタスクが潜在化

• 隠れたタスクやブロッカーの存在
• 依存関係や外部要因による遅延
• チームの実際の開発速度の把握不足

3. エンジニアの習熟度が低い

• 新技術や新手法への適応度不足
• スキルギャップの見積もり困難
• 学習コストや教育期間の予測困難

フレームワークの実行プロセス

Discovery Phase（発見フェーズ）

期間: 要件定義のフィードバック開始〜設計の見通しが立つまで（約1ヶ月）

検証項目:

• 要件の曖昧さの露呈
• 技術選択の妥当性
• 設計アプローチの現実性
• チームの作業リズムとコミュニケーション

重要な問い:

• プロジェクトの大小に関わらず、このタイミングが適切か？
• 要件定義から設計への移行で何が見えてくるか？
• チームの実際の開発ベロシティは予想と合っているか？

Diagnosis Phase（診断フェーズ）

検証: 理想との乖離の検知

乖離のパターン:

• 理想が立っていない（共通認識の欠如）
• 既にルールがおざなりになっている（規律の問題）
• ズレを感じているが言い出せていない（コミュニケーションの問題）

重要な問い:

• 何をもって「理想との乖離」と判断するのか？
• 1ヶ月でルールが破綻するなら、長期プロジェクトではどうなるか？
• チーム内の心理的安全性は確保されているか？

Deliberation Phase（熟議フェーズ）

手法: ブレストによる問題解決
参加者: 有識者 + 内部ステークホルダー
目的: 多角的視点での問題の本質把握と解決策の検討

有識者を含める意味:

• 技術的な問題なのか、プロセスの問題なのか、要件の問題なのかを切り分け
• 過去の類似事例からの学習
• 客観的な視点での現状評価

内部ステークホルダーを含める意味:

• 「ズレを感じているが言い出せない」状況の解消
• 理想の再定義や優先順位の調整
• 現場の実情と経営層の期待のギャップを埋める

重要な問い:

• このタイミングでのブレストが最も効果的か？
• 参加者のバランスは適切か？
• 問題の本質を見極められているか？

Dedication Phase（集中取組フェーズ）

期間: 1週間以内
目的: リソース整理の集中実行

整理対象:

• 力量・教育：現在のスキルレベルと必要なレベルのギャップを明確化
• ルール：形骸化したルールの実情に合わせた再設計
• マネジメントコスト：現在の管理工数の適切性見直し
• 技術リソース：インフラ、ツール、ライブラリの必要水準検証

判断基準: この1週間が計画に沿うか

重要な問い:

• なぜ1週間という期間が適切なのか？
• 短期間の計画すら守れない場合の含意は？
• リソース整理の優先順位はどう決めるべきか？
• この期間の成果で何を判断すべきか？

Decision Phase（決定フェーズ）

選択肢の判断

計画に沿った場合

→ 本格プロジェクトへ移行
「このチーム・このやり方で大きなプロジェクトも進められる」という自信と根拠を獲得

計画に沿わなかった場合

判定: 健全なプロジェクトとならない

選択肢:

1. コスト・予定等を超過させてもやる
2. 一度計画を見直す（推奨）

見直しの制約と方針:

• 体制変更は困難なことが多い
• 「出来る事に絞る」アプローチを採用
• プロダクトMVPとの照らし合わせが必要

重要な問い:

• なぜ「見直し」が推奨されるのか？
• 体制変更が困難な場合の現実的な選択肢は？
• プロダクトMVPとプロジェクトMVCのバランスをどう取るか？
• 「出来る事に絞る」際の優先順位付けの基準は？

判断の基準と指標

マネジメント vs 力量の天秤

基本認識: そこはマネジメントと力量の天秤

判断要素: 不足度合いの定量化

• マネジメント不足：進捗管理、品質管理、コミュニケーション
• 力量不足：技術スキル、ドメイン知識、開発プロセス習熟度
• その他要素の不足：ツール、インフラ、ドキュメント、外部連携

手法: KPTによるリスク許容度の判断

• Keep：現状維持できる部分の確実性
• Problem：不足による具体的な影響度と発生確率
• Try：改善施策の実現可能性とコスト

重要な問い:

• マネジメント重視か力量向上重視かをどう判断するか？
• 短期的な成果と長期的な能力向上のバランスは？
• リスク許容度を定量的に判断する具体的方法は？

コスト算出の重要性

基本認識: プロジェクトは人件費がメイン

算出項目:

• 教育・研修にかかる時間とリソース
• ツールやインフラの導入・整備費用
• マネジメント体制強化のための人的コスト
• 品質向上のための追加作業量

ステークホルダーへの提示:

• 「今投資するコスト」vs「後で問題が発生した時のコスト」の比較
• 複数の改善案のコストパフォーマンス比較
• 具体的な人月数での投資判断材料の提供

重要な問い:

• 人件費の算出で最も誤差が生じやすい部分は？
• コスト算出の精度をどう向上させるか？
• ステークホルダーが判断しやすい形での提示方法は？

成果による測定

基本方針: 厳し目に判断するなら成果。なので測定になる

成果測定の価値:

• 技術選択や個人のスキルに関わらず、実際に「何ができたか」で判断
• 言い訳や理由よりも、具体的な成果物での評価
• ステークホルダーにとって最も分かりやすい指標

指標の考え方:

• 指標はリスクの塊
• フォーカスを絞るが確定はしない
• 結果からステークホルダーに評価をもらう

測定における柔軟性:

• 単一の指標では実態を把握しきれない
• プロジェクトの性質や組織の状況に応じて重要な指標が変わる
• 事前に指標を確定すると、その指標に最適化してしまうリスク

重要な問い:

• 成果の測定で最も重要視すべき指標は？
• 指標の選択肢をどう準備すべきか？
• 「結果からの評価」で何を最も重視すべきか？
• 測定していない領域での問題発生をどう防ぐか？

第三者機関の必要性

プロジェクトコンサルの役割

必要性: ステークホルダーは最終決定者だが正しいとは限らない

ステークホルダー判断の限界:

• 技術的な複雑さや将来的なリスクの理解不足
• 短期的な成果重視で長期的な持続可能性を軽視
• 政治的・感情的要因による判断の歪み

プロジェクトコンサルの機能:

• 技術的妥当性と事業価値の客観的評価
• 複数のプロジェクト経験からの類似事例やリスクパターン提供
• ステークホルダーと開発チーム間の建設的議論促進

内部 vs 外部の選択

判断要因:

• DXの成熟度
• プロジェクトMVCの理解度

成熟度による選択:

• 成熟度が低い組織：外部コンサルが客観的視点と専門知識を提供
• 成熟度が高い組織：内部人材の組織理解の深さを活用

段階的アプローチ:

• 最初は外部コンサルで導入
• 徐々に内部人材に移行

重要な問い:

• 組織のDX成熟度をどう判断するか？
• プロジェクトMVCの理解度の測定方法は？
• 内部と外部のハイブリッド構成は有効か？

現状認識と今後の課題

現状の課題認識

体感と根拠の関係:

• 多くの組織でプロジェクト管理に課題があるという体感
• しかし、それを裏付ける統計的根拠が不足
• プロジェクト成功のための書籍が多数存在することから、問題の存在が推測される

データ収集の必要性

収集すべき統計:

• プロジェクト失敗率（予算超過、期間超過、中止など）
• コスト超過の平均的な割合
• 期間超過の頻度と期間
• 要件変更の発生率と影響度

データ収集の課題:

• 組織にとってセンシティブな情報
• 一晩で済むものではない長期的な取り組み
• 様々なアプローチの組み合わせが必要

データ収集のアプローチ案:

• 既存の調査・レポートの活用
• 小規模からの測定開始
• 間接的な指標の利用
• 匿名性を担保した調査

体系化の重要性

目的:

• 再現性の確保：考えをまとめて一貫した実践を可能にする
• 目的のブレ防止：データ収集や実践の方向性を明確化
• 組織学習の促進：成功パターンの蓄積と共有

重要な問い:

• この体系化で見落としている重要な要素はないか？
• 実際の現場適用での課題は何が予想されるか？
• 継続的な改善と進化をどう組み込むか？

フレームワーク適用時の重要な考慮事項

技術の確実さと個人の素養

見える化の重要性:

• 技術選択の妥当性の実測
• 個人の学習速度や適応能力の把握
• 予定と実績の乖離要因の分析

対応策:

• 短期間での現実露出
• データとしての蓄積
• 次回の見積もり精度向上

組織固有の制約への対応

制約の例:

• 予算制限
• 人事制度
• 既存システムとの連携要求
• 法規制やコンプライアンス要求

対応方針:

• 制約を前提とした現実的な計画
• 段階的な改善アプローチ
• ステークホルダーとの継続的な対話

重要な問い:

• 組織固有の制約をどう事前に洗い出すか？
• 制約の中での最適解をどう見つけるか？
• 制約自体を変更する可能性をどう評価するか？