プロジェクトを成功させるための「計画の立て方」入門#1

Last updated at 2025-09-24Posted at 2025-09-24

最近、私はプロジェクトマネジメントの勉強を始めました。
本を読み進める中で、「プロジェクトの失敗の多くは、最初の計画段階で決まっている」という衝撃的な事実を知りました。

振り返ってみると、過去に僕が経験してきたことも、以下のような問題に直面していました。

この記事は、そんな僕のようなPM未経験者が、プロジェクトを成功に導くためにまず何をすべきか、本から学んだことをまとめてアウトプットしたものです。

一緒に「計画の立て方」の基本を学び、プロジェクトの成功率をグッと上げていきましょう！

正直、最初は「開発しながら考えればいいじゃん」と思っていました。でも、本を読んでその考えは変わりました。

プロジェクト計画は、野球でいう「作戦ボード」のようなものです。チーム全員が同じボードを見て、誰が、いつ、どこに走るかを共有することで、効率的なゲーム運びができます。

計画を立てることで、以下の3つのメリットが得られます。

本で紹介されていたのは、プロジェクトの規模に関わらず共通する3つの基本的なステップです。

このステップの目的は、「何をやるか（In Scope）」と「何をやらないか**（Out of Scope）**」をハッキリさせることです。

ポイント：
「やらないこと」を定義するのが、僕にとって新鮮な気づきでした。「SNSログイン機能は今回は実装しない」のように、事前に決めておくだけで、後から「あれも、これも」と作業が増えるのを防げます。

WBSは「Work Breakdown Structure」の略で、プロジェクトの全作業を洗い出し、細かく分解するプロセスです。

WBS作成の流れ（僕が本から学んだこと）：

大きなタスクに分ける：要件定義、デザイン、開発、テスト、リリースなど。
さらに細かく分ける：「開発」を「ユーザー登録機能」「商品一覧機能」といった機能単位に分ける。
具体的な作業まで落とし込む：「ユーザー登録機能」を「UI/UX設計」「API実装」「バックエンド実装」のように、「誰が・何を・いつまでに」が明確になるレベルまで分解する。
担当者と見積もり時間を設定する：各タスクに誰が担当するか、どのくらいの時間がかかるかを記入します。

ガントチャートは、WBSで分解したタスクを時間軸に沿って並べた表です。これを使えば、タスクの進捗状況や「どの作業から始めるべきか」がひと目で分かります。

ガントチャートの作り方：
WBSのタスクを縦軸に、日付を横軸に設定し、各タスクの期間をバーで表現します。

本を読んでわかったのは、計画は一度作ったら終わりではないということです。完璧な計画を目指すほど、プロジェクトの成功は遠ざかってしまいます。

私のような初心者が陥りがちなワナと、そこから抜け出すヒントを3つ紹介します。

「よし、完璧な計画を立てるぞ！」と意気込んで、詳細な計画作りに何日も費やしてしまうことがあります。しかし、プロジェクトは常に不確実なものです。いくら綿密な計画を立てても、予期せぬ問題は必ず発生します。

💡 回避策：まずは70%の完成度でOK！
計画はあくまでスタート地点の地図です。走り出しながら、状況に合わせて柔軟に修正していくことが大切です。

上司やクライアント、チームメンバーに確認せず、自分だけで計画を立ててしまうと、後から「このタスクは不要だった」「作業量が全然足りない」といった問題が起きがちです。

💡 回避策：関係者全員を巻き込もう
計画段階で、「このタスク、どう進められそう？」と担当者に意見を聞いたり、ブレインストーミングでメンバー全員のアイデアや懸念点を引き出したりすることで、計画の精度は劇的に上がります。

せっかく計画を立てても、日々の業務に追われて進捗を確認しなくなってしまうと、計画は意味をなしません。

💡 回避策：定期的に「計画と現状」を照らし合わせる
週に一度、または二週間に一度など、チームで計画と現状を照らし合わせる時間を必ず設けましょう。そこで「遅れているタスクはないか？」「計画通りに進んでいるか？」を確認し、必要に応じて軌道修正を行います。

本を読んでわかったのは、計画は一度作ったら終わりではない、ということです。プロジェクトは生き物なので、計画はあくまでスタート地点の地図です。

この地図を頼りに進んでみて、もし道が違ったら、進捗状況に合わせて柔軟に修正していく必要があります。

次回の記事では、この地図を頼りにうまく進むための「進捗管理」について、僕が学んだことをシェアしたいと思います。

この記事は以下の書籍の内容を参考にしています。