迷走しないプロジェクトのために —— 計画づくりで私がよくチェックする4つのポイント

こんにちは。スパイダープラスで開発チームのEMを担当している細矢です。

最近プロジェクトマネジメントに注力するタイミングがあったので、これまで学んだこと・経験してきたことを整理してみようと思います。

まず始めに、

「プロジェクトの開始時は順調そうだったのに、後半になるにつれて想定外の事態が重なり、終わりが見えなくなる……」

ということはありませんか？

プロジェクトマネジメントに完璧な正解はありませんが、大きな失敗を避けるために「ここは気をつけておくべき」というポイントは存在します。
今回は、私が日々の業務で計画を立てる際、特に意識してチェックしているポイントを4つに絞ってお伝えします。

1. プロジェクトの「ゴール」を定義する

プロジェクトとは、「特定の目的を達成するために、明確な開始と終了が定義された、期間の限られた活動」です。
しかし、いつの間にか「作ること」自体が目的になり、ゴールを見失ってしまうことがあります。

「何が」どうなれば完了なのか？
単に機能を作るだけでなく、「何がどのような状態になれば、このプロジェクトは完了と言えるのか」という条件を明確にします。
ゴールの言語化
リリース判定基準や、運用への引き継ぎ条件など、ゴールを客観的な状態として定義しておくことで、プロジェクト終盤の「あとこれも必要かも？」という際限のない追加対応を防ぎます。
- チェックしたい症状：
  「機能はできたはずなのに、いつまで経ってもリリース判定会議が終わらない」「何をもって『完了』とするかが人によってバラバラ」という状況になっていませんか？

2.「いざという時の判断基準」をあらかじめ揃えておく

プロジェクトに不測の事態はつきものです。その際、何を優先し、何を妥協するかの基準を事前にチームやステークホルダーと合意しておく必要があります。

「優先順位」を具体的に合意する
納期・スコープ（機能）・コスト・品質のどれを最優先にするかを決めておきます。
トレードオフスライダーで表現するとわかりやすいです。
優先順位が不透明だと発生するリスク
優先順位は計画を立てる際にも大事になってきます。
例えば納期が最優先なのに、全機能を並行して開発してしまうと、いざという時に「一部の機能を削って納期に間に合わせる」という選択が物理的に不可能になります。
- 陥りがちな状況：
  すべての機能に中途半端に手がついてしまっていると、「低優先機能を含めて全て作り切る」か「大規模な切り戻し作業をする」しか選択肢がなくなり、結局リリース自体が遅れるという本末転倒な状況を招いてしまいます。

3. 関係者と役割を整理する

「誰がどの立場で関わっているか」を整理することは、スムーズな意思決定と実行のために不可欠です。

意思決定者と実行者の明確化
誰が最終判断を下し（Accountable）、誰が実務に責任を持つ（Responsible）のかを可視化します。RACIチャートを作成すると認識を合わせやすくなります。
ボールが落ちることを防ぐ
「誰かがやってくれると思っていた」という思い込みは、プロジェクトの規模が大きくなるほど発生しやすくなります。
- チェックしたい症状：
  
  誰がどんな役割を持つのかを一度も話したことがない、聞いたことがないという状況になっていたら役割分担の解像度が低いサインです。
  何人かのスーパーマンがいればボールを拾いあって事故が起きない可能性もありますが、そういった人がいない、そういった人が抜けてしまったとたん、大事故につながります。
  事故が起きていなかったとしても、一度も役割について話したことがないなと感じたらみんなで会話してみましょう。

4. 時間軸で分けた現実的なリストアップ

プロジェクト後半にタスクがポロポロと出てくるのは、多くの場合、計画段階の「見通し」に課題があります。

短期は詳細に、長期は粗く「予測」する

直近（数週間）

誰が何をいつまでにやるか、タスクを具体的に分解して見積もります。
この時にできるだけタスクは小さく分割するのがポイントです。
タスクが大きい（例えば１週間のタスク）と途中でどこまで進んでいるかわかりづらく、後半になってやっぱり終わらないことがわかると言ったことが発生するので、1日、長くても3日くらいの粒度に分割するのが良いと思います。

また、タスクにはどういった内容が含まれるかも明確にしておく必要があります。
あの内容はどのタスクが完了したら終わりなんだっけ？の認識が揃っていないと抜け漏れにもつながります。

中長期（数ヶ月先）： 詳細は不確実ですが、「予測できる必要な要素（例：セキュリティ審査、外部依存関係、データ移行など）」をあらかじめリストアップしておくことが重要です。
それが後述する計画が破綻していないかのチェックにつながります。

計画が破綻していないかのセルフチェック
昨今のソフトウェア開発は不確実性が高く全てを事前に予測することはできません。
なので、全てを細かく決める（全部洗い出して全部見積もる）必要はありません。
しかし、「今考えられる範囲でリソースは足りているか」「リスクが高い部分はどこか」を早期に確認し、柔軟に対応できるようにしておくことが、完遂への近道です。
- よくある末路：
  存在はわかっていたはずのタスクを「後で考えよう」と放置した結果、終盤にタスクが山積みになり、無理な押し込みで品質が低下する……。
  これは「予期せぬトラブル」ではなく、「予測できたはずのタスクの見落とし」になります。