• 更新日 : 2026年9月17日

プロジェクトの流れとは？5つの工程と各段階でやることを解説

プロジェクトの流れは、立ち上げ・計画・実行・監視・終結という工程で進みます。順番を覚えるだけでは現場は回らず、どの段階で何を決めて誰に渡すのかがあいまいなまま走り出すと、終盤の手戻りにつながります。この記事では、プロジェクトの進め方を工程ごとに整理し、流れが崩れる原因や小規模な案件への当てはめ方まで紹介します。

プロジェクトの流れとは？全体像はどうなっている？

プロジェクトの進行は、立ち上げから終結までの工程に分かれます。ただし一直線に並ぶわけではなく、同時に動く工程や、前に戻る場面もあります。

立ち上げから終結までの5工程で進む

プロジェクトの流れは、1.立ち上げ、2.計画、3.実行、4.監視・管理、5.終結の順で進みます。

この区切りは、PMBOK（ピンボック）で長く使われてきた分け方です。PMBOKとは「Project Management Body of Knowledge」の略で、米国のPMI（プロジェクトマネジメント協会）がまとめたプロジェクト管理の知識体系を指します。特定のソフトや手法ではなく、世界中の現場で積み上げられた進め方の共通ルールとして、業種を問わず参照されています。

システム開発から社内の業務改善まで、規模や業種を問わず共通の骨格になります。前の工程の結論が次の工程の入り口になるため、順番を飛ばすと後戻りが増えます。

監視・管理は実行と並行して動き続ける

監視・管理は実行が終わったあとに始まる工程ではなく、実行と同時に走り続けます。

進捗の遅れや予算の超過は、作業がすべて終わってから確認しても手の打ちようがありません。実行中に週単位で数字を突き合わせ、計画とのズレが小さいうちに直すことで、納期への影響を小さく抑えられます。工程を図にすると直線に見えますが、実際には3と4が重なった状態で数週間から数か月続くと考えてください。

工程の回し方は選ぶ型によって変わる

同じ工程でも、一度だけ流す型と、短い周期で繰り返す型があります。

どちらを選ぶかで、計画工程にかける時間の配分も、変更が出たときの戻し方も変わります。型の違いは次の章でくわしく見ていきます。

プロジェクトの進め方にはどんな型がある？

工程をどう回すかは選ぶ型で変わります。要件がどこまで固まっているかによって、向いている型が分かれます。

ウォーターフォール型は工程を一巡だけ進める

ウォーターフォール型は、工程を上流から下流へ一度だけ順に流す進め方です。

前の工程が終わってから次に移るため、計画の段階で全体の作業量と期日を固めます。途中で仕様を変えると前の工程まで戻ることになり、後半ほど修正の負担が重くなります。基幹システムの入れ替え、工場の設備導入、法改正に合わせた社内規程の改定など、決めるべきことが最初からはっきりしている案件に向いています。

アジャイル型は短い周期で工程を繰り返す

アジャイル型は、計画から終結までを短い周期で何度も回す進め方です。

1周ごとに動くものを作り、使った人の反応を次の周回に反映します。優先度の高いものから手を付けるため、途中で方針が変わっても無駄になる作業を抑えられます。Webサービスの新規開発やアプリの機能追加など、作りながら正解を探る案件で選ばれます。

ハイブリッド型は工程ごとに使い分ける

ハイブリッド型は、立ち上げと計画を一度で固め、実行だけを短い周期で回す進め方です。

予算と期日は先に確定させたいが、中身は作りながら詰めたい場面に合います。委託元へ出す計画書は作り込み、実行はスプリントと呼ばれる区切りで進めます。ECサイトのリニューアルなど、委託先と社内チームが混ざる案件で採られる形です。

プロジェクトの各工程の流れ

ここからは基本の形であるウォーターフォール型を前提に、工程1から5まで順番に見ていきます。工程ごとの中身はアジャイル型で繰り返す場合も同じです。イメージしやすいよう、次の案件を例として工程5まで追いかけます。

工程1｜立ち上げでは目的と成功基準を決める

立ち上げでは、そのプロジェクトをやる理由と、何をもって成功とするかの数値を決めます。

ここで扱うのは、解決したい課題、得られる効果、主な成果物、成功の判断基準です。期限と数値をセットにすると、あとの工程で優先順位に迷いません。

予算や人員の見通しはこの時点では粗くて構わないので、枠だけ置いておきます。関係者の承認が出たら次に進みます。

工程2｜計画ではWBSでタスクを分解する

計画では、作業をWBSで細かく分け、担当者と期日をひとつずつ割り当てます。

WBS（作業分解構成図）は、プロジェクト全体を実行できる大きさのタスクまで分解した一覧です。分解の目安は、1つのタスクを5日程度で終了できる粒度になります。

細かく分けるほど見積もりの精度が上がり、遅れにも早く気づけます。分解したタスクは依存関係を確認しながら並べ、ガントチャートなどで日程に落とし込みます。

工程3｜実行では役割どおりに作業を進める

実行では、割り振られたタスクを担当者が進め、進み具合を決まった形式で共有します。

この工程で成果を左右するのは、作業そのものよりも情報の流れです。誰が何をどこまで進めたのかが見えないと、同じ作業の重複や、担当の決まっていないタスクの放置が起きます。着手時と完了時に状態を更新するなど、報告の型を最初に決めておきます。

工程4｜監視・管理では計画とのズレを早めに直す

監視・管理では、進捗・コスト・品質・スコープを計画と照らし合わせ、ズレを補正します。

見るべきは「予定に対して何%進んだか」ではなく、「残りの作業に何時間かかるか」です。見積もりが増えていれば、担当を増やす、機能を削る、期日をずらすのいずれかを判断します。仕様の追加依頼もこの工程で受け止め、影響する範囲を出したうえで採否を決めます。

工程5｜終結では成果物を引き渡し振り返りを残す

終結では、成果物を依頼元に引き渡し、うまくいった点と改善点を文書にして残します。

引き渡しのときは、受け入れの条件を満たしているかを立ち上げで決めた成功基準と突き合わせます。そのうえでメンバーと関係者から評価を集め、遅れの原因や有効だった工夫を記録にまとめます。次のプロジェクトで見積もりの精度を上げる材料になります。

プロジェクトの流れが崩れる原因は？

途中で止まるプロジェクトには共通の原因があります。多くは工程の切り替え時にできた小さなほころびが、後半で大きな遅れに変わったものです。

立ち上げの目的があいまいなまま次に進む

目的と成功基準が固まらないまま計画に移ると、判断のよりどころがなくなり作業が迷走します。

ゴールが共有されていないと、タスクの優先順位を決められず、メンバーごとに完成のイメージがずれます。途中で「そもそも何のためにやるのか」という議論が蒸し返され、そのたびに手戻りが生まれます。立ち上げの承認を得る場で、成功の判断基準を1行で言い切れるかを確かめておきます。

タスク分解が粗く見積もりが狂う

WBSの粒度が粗いと、作業量を見誤り、スケジュール全体が終盤で崩れます。

「設計」「開発」のような大きな単位のままでは、どこまで終わったのかを測れません。進捗が50%と報告されていても、実際には残りの作業が半分以上あるという事態が起こります。分解できないタスクは、まだ内容を理解しきれていないサインです。

進捗報告が主観で実態とずれる

担当者の感覚で報告された進捗率は、実際の残作業と大きく食い違います。

心配をかけたくない、評価を下げたくないという理由で報告が遅れると、期日の直前になって遅れが表に出て、打てる手が限られてしまいます。報告の頻度と項目をルール化し、悪い情報を上げても責めない空気を作ることが、正確な情報の流れにつながります。

変更が起きても計画に戻さず走り続ける

仕様変更が出たのに計画を直さないまま実行を続けると、残りの工程すべてに無理が出ます。

問題になるのは、追加された作業がWBSにもスケジュールにも反映されないまま、現場の残業で吸収されてしまうケースです。工数が増えたのに期日が変わらなければ、品質が下がるか、どこかのタスクが未着手のまま残ります。

プロジェクトの流れを止めないためのポイントは？

対策は工程の切り替え方と情報の扱い方に絞られます。次の点を先に決めておくと、流れが途中で止まりにくくなります。

工程の切り替え条件を先に決めておく

次の工程に進んでよい条件を、着手前に文章の形で決めておきます。

「立ち上げは、成功基準と予算の枠に依頼元の承認が出たら完了」「計画は、全タスクに担当と期日が入ったら完了」のように、終わりの目印を具体的に置きます。条件を満たさないうちは次に進めない決まりにすることで、あいまいな状態のまま作業が始まる事態を避けられます。

進捗は工数ベースの数値で共有する

進捗は「何%終わったか」ではなく、残りの工数を時間で出して共有します。

感覚による進捗率は人によって基準が違い、並べて比べられません。残作業を時間で出せば、当初の見積もりとの差がそのまま遅れの大きさになります。

変更が出たら計画工程に一度戻す

仕様の追加や削除が決まったら、実行を続ける前にWBSと日程を更新します。

手順は、追加タスクの洗い出し、工数の見積もり、期日への影響の確認、依頼元への提示の順です。影響を数字で示せば、機能を削る、期日を延ばす、人を増やすといった選択を依頼元と一緒に決められます。口頭のやり取りで終わらせず、変更管理表に日付と決定内容を残しておくと、あとの認識違いを防げます。

バッファは個人でなく全体でまとめて持つ

余裕の時間は各タスクに分散させず、プロジェクト全体の後ろにまとめて置きます。

タスクごとに余裕を持たせると、人は与えられた時間をすべて使いきる傾向があり、早く終わっても前倒しになりません。個々の余裕を削って終盤にまとめておけば、突発的な遅れが出たときだけ取り崩せます。

小規模なプロジェクトでも流れは同じ？

数人で数週間の社内案件でも、たどる工程は変わりません。変えるのは工程の数ではなく、それぞれにかける時間と資料の量です。

工程は省かず時間配分を圧縮する

小規模でも立ち上げから終結までを通し、それぞれにかける時間を短く区切ります。

立ち上げを飛ばして計画から入ると、目的の解釈がずれたときに立ち返る場所がなくなります。2週間の案件なら、立ち上げと計画に半日、実行と監視に8日、終結に半日といった配分でも成り立ちます。工程の名前を会議のアジェンダに使うだけでも、いま何を決める場なのかが伝わります。

立ち上げと計画は1枚のシートにまとめる

小さな案件では、企画書とWBSを分けず、A4用紙1枚の企画シートに集約します。

書き込むのは、目的、成功基準、成果物、タスク一覧、担当、期日、想定されるリスクです。1枚に収まる分量に絞れば、関係者も短い時間で内容を確認できます。ExcelやWordのテンプレートを用意しておけば、次の案件でも同じ形式を使い回せ、ガントチャートへの展開も楽になります。

振り返りは30分でも役目を果たす

終結の振り返りは、うまくいった点と次に変える点を3つずつ挙げるだけでも成立します。

時間をかけた報告書を作ろうとすると、忙しさを理由に先送りされ、結局は何も残らないまま終わります。完了した直後の30分で、参加者それぞれに良かった点と改善点を出してもらい、その場で議事録にまとめるほうが確実です。

プロジェクトの流れを工程ごとに捉えて着実に前へ進めよう

プロジェクトの流れは、立ち上げ・計画・実行・監視・管理・終結の順で進み、実行と監視は並行して動きます。

工程ごとに決めることと残す資料を先に決めておけば、次に何をすべきかで迷う場面が減ります。ウォーターフォール型・アジャイル型・ハイブリッド型のどれを選ぶかで回し方は変わりますが、たどる工程そのものは共通です。

遅れの多くは、目的があいまいなまま計画に進む、タスクの分解が粗い、変更を計画に反映しないといった切り替え時のほころびから生まれます。工程の完了条件を先に決める、残工数で進捗を共有する、変更が出たら計画に戻す。

この3つを守るだけでも進行は安定します。小さな案件でも工程は省かず、かける時間を縮めて回してみてください。

• 監修：千葉 清美（日商簿記1級/建設業経理士1級）

  日商簿記1級・税理士科目（簿記論・財務諸表論）の確かな会計理論と、経理実務での決算・税務申告経験を兼ね備える。システム部門での業務効率化ツールの開発経験を活かし、会計・税務の知識に裏打ちされた、実効性の高い業務効率化支援を行っている。建設業経理士1級保有。