はじめに
これまで複数のプロジェクトを担当してきた中で、プロジェクトチャーターやインセプションデッキを作らずに進めて痛い目に遭った経験が何度かあります。
一方で、途中参画したプロジェクトでプロジェクトチャーターを作成することで混乱状態から立ち直った経験もありました。
正直なところ「プロジェクトチャーターは重要」というのは一般的によく言われることなので、わざわざ記事にするほどのことでもないかもしれません。
ただ、実際にそれを作らずに燃えたり失敗する確率は結構高いと感じており、少しずつでもいいから書きだすことをおすすめします。
書き出していないことで、同じような質問や指摘を色々な人から何度もされるので、とりあえずでも書き出して定めていくのが良いと経験から感じています。
今回は、自分の経験を例として交えながら最低限抑えておくべき要素と、途中からプロジェクトに参画する立場としてプロジェクトチャーター不在に対してどう振る舞うべきかについて書いてみます。
プロジェクトチャーターとは
プロジェクトチャーター（プロジェクト憲章）は、プロジェクトの存在を正式に認可しプロジェクトマネージャーやチームに権限を与える文書です。
その中身には一般的に以下のような要素が含まれます：
| 要素 | 内容 |
|---|---|
| 🎯 プロジェクトの目的と背景 | なぜこのプロジェクトを行うのか |
| 📋 プロジェクトの目標と成果物 | 何を達成するのか、何を作るのか |
| ⚠️ プロジェクトの制約事項 | 期間、予算、リソースなどの制限 |
| 📝 プロジェクトの前提条件とリスク | 前提となる条件と想定されるリスク |
| 👥 ステークホルダーの定義 | 関係者の明確化 |
| 🔑 プロジェクトマネージャーの権限と責任 | 権限範囲の明確化 |
似たような概念として、アジャイル開発でよく使われるインセプションデッキというものもあります。
どちらも「プロジェクトの共通認識を作る」という目的は同じです。
では、早速事例からの学びを示していきます。
🔥 失敗例：SaaSコア機能刷新プロジェクトでのやらかし
担当していたSaaSにおいて、コア機能を刷新するプロジェクトがありました。
このプロジェクトでは、プロジェクトチャーターを作らずに進めたことで強く失敗を感じたプロジェクトでした。
当時の状況
プロダクト責任者とエンジニアチームリーダーを兼任していた私は、当該コア機能に対する自身の問題意識が明確だったこともあり、「とりあえずこの概念で進めましょう」という勢いで進めてしまいました。
ステークホルダーやチームメンバーとも「コア機能を良くしたい」という方向性は一致していたため、詳細な合意形成を後回しにしていました。
何が問題だったか
プロジェクトが進行していく中で、以下のような問題が浮上し始めました：
- 制約事項の認識齟齬：開発した機能をリリースするタイミングによって事業運営に大きな影響が出る可能性があることを認識していなかった
- ステークホルダーの巻き込み不足：顧客と接する機会が多いチームに対する初期段階からのコミュニケーションが不十分で、想定していた構想では不都合が生じる顧客がいることを認識しきれていなかった
- 技術的な意思決定によるスコープ拡大：エンジニアのチームリーダーとして下した技術的な意思決定によって、想定していたよりもスコープが拡がり工数が膨らんでしまった
結果として、プロジェクト全体の期間と工数が膨らんでしまいました。
失敗例：機械学習プロジェクトでのゴール迷子
別のプロジェクトでクローリングと機械学習を用いたプロジェクトを立ち上げた際も、プロジェクトチャーターを作らずに進めて苦労しました。
当時の状況
研究開発色が強いプロジェクトだったため、「構想に向けてとりあえず動き始めよう」というスタンスでした。
データサイエンス領域の新規チーム立ち上げも兼ねていたため、学習要素も多く含まれているプロジェクトでした。
何が問題だったか
研究開発的なプロジェクトであるがゆえに、以下のような問題が発生しました：
- ゴールの曖昧さ：機械学習を使って改善したいこと自体は明確だったものの、達成目標が曖昧で具体的な成功指標が定まっていなかった
- マイルストーンの形骸化：調査検証を進める過程で遭遇する新たな発見に遊撃手的に取り組みをすることによって、当初設定したマイルストーンがプロジェクト進行とともに意味をなさなくなっていった
- 学習と成果のバランス：新技術の学習時間と成果創出のバランスが取れず、メンバーのモチベーション維持が困難になった
このプロジェクトは最終的に別のアプローチによって一定の成果は得られたものの、もう少し効率的に進められたのではないかという反省が残りました。
成功例：AIプロジェクトでの立て直し
一方で、途中参画した別のAIプロジェクトでは、プロジェクトチャーターを作成することで混乱状態から立て直すことができました。
参画時の状況
プロジェクトが間延びしており、理想論と現実論が空中戦を繰り広げて具体的な進展を見せられていない状況でした。
各メンバーがそれぞれ異なる解像度で課題を捉えており、議論が噛み合わない状態もありました。
打ち手
まず、プロジェクトの思想を基にして簡単にプロトタイプ化してみました。
その上で関係者に対して「プロトタイプを作ってみたんだけど、こんなケースが懸念される。これまで具体的に言及はあったか？そのときはどんな判断だったか？」という形で質問によって問題意識を実感してもらうアプローチを取りました。
この会話を通じて、各種懸念に対して参画メンバーが考えていたことを整理し、最終的にプロジェクトチャーターに相当するドキュメントを作成しました。
結果
プロジェクト関係者間で共通の理解を得られるようになり、マイルストーンごとのゴールを見据えたプロジェクト進行ができるようになりました。
もちろん、自己評価として満点とは言えない部分もありましたが、当初の状態からは明らかに脱却できました。
📋 現実的に最低限抑えておくべき要素
これらの経験を通して、完璧なプロジェクトチャーターを作ることよりも、最低限の要素を抑えることの方が重要だと感じています。
🎯 プロジェクトの目的
「なぜこのプロジェクトをやるのか」 を明確にしておくことが最も重要です。
目的が曖昧だと、途中で判断に迷った際の拠り所がなくなります。
SaaSコア機能刷新プロジェクトでは、「このコア機能を良くしたい」という目的は共有していましたが、「なぜ今それが必要なのか」という背景の共有が不十分でした。
結果として、パフォーマンス改善と機能追加のどちらを重視するかで迷った際に、判断基準がない状態になってしまいました。
⚠️ プロジェクトの制約事項
期間、予算、リソース、技術的制約 など、プロジェクトを進める上での制約を明確にしておくことが重要です。
制約を認識していないと、理想論ばかりが先行して現実的でない計画を立ててしまいがちです。
特に既存システムとの互換性や、他チームとの兼ね合いなど、一見技術的でない制約も重要です。
これらを事前に整理しておかないと、後から「そんな制約があるなんて聞いてない」という状況になりかねません。
実体験からの教訓
例えば、私が経験したSaaSコア機能刷新プロジェクトでは、リリースタイミングが事業運営に与える影響という制約を見落としていました。
またAIプロジェクトでは、活用するデータのホスティング環境とその環境仕様による制約によって、想定されない要件への対応も必要になりました。
📍 プロジェクトの実現ステップ（マイルストーン）
プロジェクトゴールまでのマイルストーンと各マイルストーンでの成果物 を定義しておくことで、進捗の可視化と軌道修正がしやすくなります。
機械学習プロジェクトでの反省を踏まえると、研究開発色が強いプロジェクトこそ、「学習」と「成果創出」のバランスを取れるようなマイルストーン設定が重要だと感じています。
👥 ステークホルダーの確認とコミュニケーション計画
プロジェクトに関わる人、影響を受ける人を明確にし、コミュニケーション方法を決めておく ことで、後から「聞いていない」というトラブルを回避できます。
エンジニアチーム内だけで完結すると思っていたプロジェクトでも、実際には営業チームや顧客サポートチームに影響することが多々あります。
事前にステークホルダーを洗い出し、適切なタイミングでコミュニケーションを取る計画を立てておくことが重要です。
途中参画時の提言方法
既に動いているプロジェクトに途中から参画する場合、ストレートに「プロジェクトチャーターがないから作りましょう」と言ってもどうしても抵抗感が出ます。
💡 問題意識を実感してもらうアプローチ
AIプロジェクトで成功したアプローチは、まず問題意識を実感してもらう ことでした。
- プロジェクトの思想を具体的に体現できるプロトタイプを提示
- プロトタイプを通じて、想定される懸念を具体化
- 懸念点について、これまでの検討経緯を問いかけ
- 問いかけに対する回答を書き起こし
- 書き起こしついでにプロジェクトチャーターの項目にあわせて整理
- ついでに他の項目についても共通認識として整理することでプロジェクトチャーターを育てる
このアプローチの良い点は、批判ではなく協力的な姿勢 で問題提起できることです。
「プロジェクトチャーターがないから良くないよ！」という指摘ではなく、「みんなで整理しましょう」という提案になるため、受け入れられやすくなります。
📈 段階的な整理
いきなり完璧なプロジェクトチャーターを作ろうとせず、段階的に整理していく ことも重要です。
| ステップ | 内容 |
|---|---|
| 1️⃣ | まずは目的と制約事項だけ整理 |
| 2️⃣ | 次にマイルストーンを大まかに設定 |
| 3️⃣ | 最後にステークホルダーとコミュニケーション計画を追加 |
この段階的なアプローチにより、メンバーの負担を軽減しながら必要な要素を整理できます。
⏰ いつプロジェクトチャーターを作るべきか
理想的にはプロジェクト開始前に作成すべきですが、現実的には以下のタイミングでも効果があります：
- ✅ プロジェクト開始直後（キックオフと同時）
- ⚠️ 最初の大きな課題や認識齟齬が発生したとき
- 👥 チームメンバーやステークホルダーが追加されるタイミング
- 🌪️ プロジェクトの方向性に混乱が生じたとき
重要なのは「作るべきタイミングを待つよりも、必要性を感じたときに作る」ことです。
それを感じたこの瞬間！今なんです！！！ 🔥🔥🔥
📝 まとめ
プロジェクトチャーターやインセプションデッキは、プロジェクトの失敗確率を減らすための投資 だと考えています。
作成に時間はかかりますが、後から発生する手戻りや混乱のコストを考えると、十分に価値のある投資です。
特に以下のような状況では、プロジェクトチャーターの作成を強く推奨します：
- 🏢 複数チームが関わりステークホルダーが多いプロジェクト
- 🔬 新しい技術領域に挑戦するプロジェクト
- ⏳ 期間が長期に渡るプロジェクト
完璧なドキュメントを作る必要はありません。
最低限の要素を抑えながらチームの共通認識を作ること が重要です。
そして、既に動いているプロジェクトであっても、途中からでもプロジェクトチャーターを作ることは可能です。
問題意識を共有し、協力的な姿勢で提案することで、チーム全体でプロジェクトの方向性を整理できるはずです。
プロジェクトが燃える前に、ぜひ一度立ち止まって整理してみることをおすすめします。