「プロジェクトの進め方」は１つじゃない！８つのタイプ別に考える推進アプローチ

この記事について

この記事は、近年ますます重要性が指摘されている「プロジェクト推進」の技法について解説します。プロジェクト（未知なる価値を生み出す試みや取り組み）は、とても多様です。「ITプロマネ」的なものを習得すれば、プロジェクト推進力が身につくと思っている方も多いですが、実はそれが誤解です。取り組みの類型別に、どのような技法が適しているのか、そのアプローチの違いについて解説します。

もくじ
1　着目する問題：予定通り進まないプロジェクト。どうやって進めたらいい？
2　プロジェクト状況の、８つの分類
3　8類型別の「勝負どころ」の違い
4　プロジェクト管理の代表的な方法論
5　まとめ：「方法論」と「状況」の適切な組み合わせが、プロジェクトを前に進める
6　おすすめ記事のご紹介

着目する問題：
予定通り進まないプロジェクト。どうやって進めたらいい？

　「◯◯プロジェクト」と名のつく取り組みが、なかなかどうも、スムーズにいかない、という経験はないでしょうか。

　実行する担当者として向き合う悩みの代表例としては、以下のようなものがあります。

「そもそも、目的や目標を、どうやって設定したらいいのか、迷う」
「やりたいことはあるけれど、どうやって実現するのか、情報や手段が乏しい」
「スケジュール通りにならない　お金が足りない、人が足りない」
「決めたはずのことが、くつがえる」
「成果物が、思った通りのクオリティに仕上がらない」
「関係者どうしの話し合いが、うまく決着させられない」

　あるいは、企業組織におけるビジネス・プロジェクトの責任者や評価者として向き合う悩みの代表例としては、以下のようなものがあるかと思います。

「マイクロマネジメントを避けるため、良かれと思って任せていたら、いつのまにか迷走していた」
「もう少し我慢して、そっと見守っていたが、アクションが停滞し、状況が悪化した」
「こんなの当たり前だろう、と思うことが、メンバーにはなぜか、できない」
「安心して任せられるようになるまで育成するのには、長い時間がかかる」
「PMスキルを客観的に評価することが難しい」
「自分の時間の限界が、事業のボトルネックになってしまう」

　そんな悩みを解決するために、なにか方法がないかと探してみると「プロジェクトマネジメント」の言葉に出会います。実際に、その教えのとおりにやってみたことがある、という人も、多くおられることでしょう。

「プロジェクト・マネジメント」の一般的なイメージ

　たとえば「プロマネ」という言葉を聞くと、以下の図のようなものを連想する方が多いのではないでしょうか。企画書とタスク表、議事録、この三種の神器を用いて、チームをマネジメントし、タスクを消化していく、というようなイメージです。

　たしかに、こうした考え方は、プロジェクト進行の「基本のキ」であるといえます。しかし、実際のところ、こうしたものを勉強し、実践しても、根本的な悩みは解決せず、困っている方も多いのです。

プロジェクト状況の、８つの分類

　「プロマネ」って、結局のところ、どうなの？なんなの？という疑問を持たたれる方に、このコラムでお伝えしたい、たったひとつのメッセージがあります。

本当に物事を前に進めたいなら、その取り組みの「性格」を理解しよう

　このコラムで、覚えていただきたい唯一の図は、こちらです。

　図の左側に行けば行くほど、その取り組みに関わる関係者が明示的で、いわゆる「甲」と「乙」の間の業務委託契約が発生するようなものになります。右側に行けば行くほど、明示的な契約関係が存在しないなかで、行動変容を訴えたり、問題解決をはかっていく、というものになります。

　上下について補足しますと、上側は、受益者の要望や課題が先にあって、プロジェクト活動を通して、それを叶えるものです。下側は、製品や技術、メソッドなどの手段やコンテンツが先にあって、それを受益者に対して提供していく、というものです。

　どんなプロジェクトでも、スケジュール管理やタスク管理は、必要です。しかし、そうしたマネジメントスタイルが、あらゆるプロジェクトに、必ず有効なものではありません。

　大事なのは、向き合っているプロジェクトの状況に対して、適した情報管理を行うことであり、とりあえず、世間でよく言われる「プロマネっぽいこと」をすればいい、というわけではないのです。「人間」とひとくちにいっても、色んな性格を持った、多様な人間がいるのと同じで、「プロジェクト」とひとくちにいってもやはり実に様々な性格を持った、多様なプロジェクトが存在します。

　つまり、世の中に数多く提唱されているプロジェクト進行方法論とは、その取り組みの性格とのマッチングが必要なのです。

8類型別の「勝負どころ」の違い

　では、その取り組みの性格とは、どういうものなのでしょうか。
　まずは、表形式で概要をお示します。

大分類	8類型	プロジェクト推進者が大事にすべきこと
第一類型 委託受託的なもの	①要望実現	●受益者の表層的なリクエストに振り回されない ●最初から思い込みで、実現手段を限定せず、問題や要望を、とにかく深く理解する
	②メソッド導入	●あらかじめ、必要な資源やプロセス、期間や管理帳票等の計画を詳細に描く ●関係者の責任範囲や業務分掌を明らかにし、スコープが乱れないようにする
第二類型 製品開発的なもの	③マーケット・イン	●いわゆるMBA経営学的な、マーケティング戦略の王道をキチンと立てる ●最上流におけるコンセプト設計を、とことんまでこだわる
	④プロダクト・アウト	●製造側の関係各位がスムーズに連携できるよう「すり合わせ」を大切にする ●ユーザー側の声が適切に製品に反映されるような仕組みやプロセスを導入する
第三類型 事業開発的なもの	⑤需要開発	●推進者や責任者自身が、受益者の声の、できる限り近くに立つ ●そのうえで、受益者の期待や想像を超える解決策を考え抜く
	⑥発明主導	●シーズの持つポテンシャルや未来の価値を、当事者自身がとにかく信じる ●特定の市場やターゲットを想定して動きつつも、こだわり過ぎず、試行を増やす
第四類型 改善変革的なもの	⑦外圧	●外部環境に見たくない要素があったとしても、現実から目を背けず、向き合う ●本当に起きていることの実態を理解するために、現場に飛び込み、一次情報を得る
	⑧内発	●向き合うべき矛盾に妥協せず、短期的な変化に惑わされない骨太な構想をする ●遠大な計画を見据えつつも、焦らず、伏線を張り巡らせる

第一類型　委託受託的なもの

　プロジェクトには、発注する側とそれを引き受ける側、契約書で甲と乙にわかれるタイプのものがあり、これを委託・受託型と呼びます。
　これをさらに分解すると、発注側に主導権と指導力がある場合と、委託を受ける側に権威やノウハウがある場合があります。全社は、ゼネコンやSIerが二次、三次の委託先にスコープを分解するようなイメージで、後者は、コンサルタント会社や教育機関が知識や技能を伝授するようなイメージです。

　参考　実体験から解説！　委託・受託型プロジェクトのよくある問題と対応策

第三類型　事業開発的なもの

　そもそも顧客探しから始めるようなものもあり、これを事業開発型と呼びます。事業開発型も、市場の需要やニーズに向けて企画をする場合と、作り手側の技術や発想をもとに訴えていく場合の2通りがあります。

　製品開発の場合は、部品メーカーや制作パートナーなど、業界的な縦横のつながりがすでに存在し、そのなかで、既存のプロダクトをマイナーチェンジする、ということが主となりますが、事業開発の場合はよりゼロイチ的な色彩が強いため、自由度と不確実性が高い特徴があります。

　参考　理念とリアルの相克！　事業開発の成否は「テーマとコンセプト」が握る

プロジェクト管理の代表的な方法論

　多少なりとも本格的にプロジェクトマネジメントの方法論を学びたい、と、思ったときに出会うのは「ウォーターフォール」や「アジャイル」などの言葉です。これらの代表的な方法論を理解したうえで、自身の取り組みに合致するものを選び、組み合わせると、スムーズに進めやすくなります。

ウォーターフォール

　「ウォーターフォール」とは、いわゆる「プロジェクト・マネジメント」という言葉の元祖といいましょうか、もっとも中心的にある考え方です。

　複雑な取り組みは、その最初のうちに、しっかりと企画や計画を立て、成果物や作業工程を詳しく定義し、必要な資源をそろえたうえで、効率的に進めていきましょう、という考え方です。
　言葉そのものは現代に発生したものですが、建設業や製造業、SIer（情報システム開発サービス業）など、大規模な人工物や機械製品を作り上げるうえで、絶対に避けて通れないものですので、考え方の根本的な部分は、文明史の発展のなかで、長い年月をかけて熟成されてきた方法論である、とも言えます。

　ウォーターフォール型の進行の基礎的なイメージを図示しますと、以下のようなものになります。

　ウォーターフォールは第一類型における進め方の基本となります。

アジャイル

　「アジャイル」の言葉は、インターネットの普及が本格化した2000年前後に登場しました。
　インターネット上で展開されるソフトウェア産業は、建設や製造業と異なり、技術環境や市場動向の変動が激しいため、あらかじめ壮大な青写真を描くのではなく、とにかく早く（あるいは速く）成果物を世に出して、その反応を確かめたうえで、何度も何度も反復的に拡張していこう、という考え方が発生したのが、その始まりです。
　あらかじめ、ある程度事業やサービスの方向性は見定めておき、まずは最低限のものを作って、出す。反応を見て、また出す。時々、事業モデルそのものも、大きく見直す、という格好で進めよう、という考え方です。

　イメージとしては、以下のようなものです。

　もともとは、IT・ネットビジネスのベンチャー、スタートアップ企業が積極的に取り組んでいた方法論ですが、2025年現在では、ものづくりの分野や大企業でも、広く取り入れられています。「デザイン思考」や「ビジネスモデル・キャンバス」といったビジネス方法論ともあわせて活用されています。
　ちなみに、このアジャイル的な世界観は「最終的な一つの成果物を作るゴールを目指す」のではなく「常に拡張し、成長させていく事業や製品を作る」というニュアンスを色濃く持っています。

　それゆえ、いわゆる「プロジェクト」という言葉の有期性のあるイメージは、少しずれる、ということで「プロジェクト・マネジメント」ではなく「プロダクト・マネジメント」と呼ぶほうが適切だ、という感覚も広く共有されています。

　アジャイルは第三類型における進め方の基本です。

　「ウォーターフォール」と呼ばれる方法論は制作プロジェクトの、特に「メソッド導入」型には、ぴったりしています。一方、いわゆる「アジャイル」と呼ばれる方法論は、事業開発の、特に「需要開発」型にはぴったりしています。このコラムの冒頭で申し上げた「進め方はひと通りではないし、狭義のITプロマネの方法論だけを学んでも、万能ではない」とはこのことを意味しています。

コンカレント

　ちなみに、例えば日本の製造業は、ずっとウォーターフォールをやってきたのか、というと微妙に違います。先に上げた2つの言葉よりは、少し知名度が下がりますが、日本の製造業の強みとして「コンカレント開発」という言葉が長年使われてきました。
　これは、ウォーターフォール的にマイルストンを分離させるのではなく、あえて重ねることで、コミュニケーションの改善やアイデアの発展、全体的なスピード感の向上を目指す、というものです。

　製品開発ではコンカレント進行を意識すると進めやすくなります。

インクリメンタル

　さらにちなみますと、ソフトウェア産業も、2000年頃まではウォーターフォール型での開発が当然のように取り入れられてきましたがその過渡期に「インクリメンタル開発」という考え方も提唱されました。

　こちらと製造業におけるコンカレント開発を比較しますと、工程そのものについての考え方は異なっていますが、先に一旦後工程までやっておいて、また戻ってやり直す、という意味では、感覚として近いところがあります。

　改善変革ではインクリメンタル開発がお勧めです。DXプロジェクトをウォーターフォール型でやろうという人はさすがに少ないかと思いますが、ではアジャイルがよいかというとそうでもありません。どの方向に向かうべきで、そのためにはどんな成果物が必要なのかということを、あらかじめしっかりと考えておく。そのうえで、一番大事な、そしてハイリスク・ハイリターンな部分を見定めて大きな山を動かしていく。変革には、そんな呼吸が求められます。

まとめ：「方法論」と「状況」の適切な組み合わせが、プロジェクトを前に進める

プロジェクト活動に慣れていない人は、つい、

プロジェクトがうまく進められない
　↓
「プロマネ」のやり方を学べばいいらしい
　↓
よし、ここはひとつ、スタンダードな教科書を読んでみよう！

と、考えてしまいがちです。

実はそれは、大いなる誤りを含んだ発想です。

「とりあえず、プロマネの勉強をすればよいのだろう」
「とりあえず、プロマネといえば、ITプロマネが王道なのだろう」といった具合に、その取り組みに、本来は合わないはずの手法論を学んでしまい、かえって逆効果になってしまっていることが、とても多いのです。

本当は、以下の順番で、考えてあげなければなりません。

プロジェクトがうまく進められない
　↓
このプロジェクトは、そもそもどんな性格を持っている？
　↓
性格にあわせた進め方を取り入れよう！

　そのプロジェクトの性格を見極めたうえで、そこに適した資質やスキルを持つ人材を配置することができれば、鬼に金棒です。

おすすめ記事のご紹介

　さて、以上、プロジェクトワークの基本的なイメージと世界観について、ご紹介しました。昨今「プロマネ」という言葉が広く普及し、学びたい、という人も増えています。
　一方、いろんな指南書にあたってみたが「ITプロジェクト」「大規模開発」「ウォーターフォール」「アジャイル」など、特定の領域やトピックに特化したものが多く、自分の求めるものとは違った、という人も、とても多いのが、実情です。

　プロジェクトとは、その場その場に固有のものです。どんなプロジェクトにも、必ず個性があります。関わる人によっても変わりますし、扱う題材や、用いる技術や規模によっても、変わります。ゆえに、実は、そもそもプロジェクトの進め方を、一般論として語ることは、原理的にいって、そもそも不可能な話だったりします。

　ゆえに、この連載「Project Pathfinders」では、ありとあらゆる角度から、プロジェクトを、語っています。ぜひ、他の記事も、ご覧になっていただけると幸いです。

プロジェクトワークの、基本的な世界観

　例えば、今回の8つの分類に対して、もう少し詳しく進め方を知りたい、という方には、以下の記事がお勧めです。もう少し具体的な案件のイメージのもと、どんな段取りやプロセスでやるとよいか、ということや、参考書籍も、いくつかご紹介しています。

受託/商品開発/事業開発/変革など、プロジェクトの進め方と勘どころをタイプ別に解説！

　上記に加えて、プロジェクトって、そもそも、なんなんだ！？という根本的な疑問を徹底的に解消するために、お勧めしたいのはこちらです。

「取引」（商談・契約・納品・検収）の一連の流れを「モノ」と「プロセス」の二元的解釈によって読み解く

要望/要求/要件/仕様/設計の違いについて解説！【テンプレートあり】

　「要件」や「仕様」「設計」など、プロジェクトワークでは、いろんな言葉、概念を扱いますが、意外と「なんとなく」で「それっぽい」言葉遣いをしている、ということも、多いものです。ひとつひとつの言葉を丁寧に味わっていくと、その本来の意味や目的が見えてきます。

プロジェクトマネジメントの方法論

　そもそも論というよりは、もう少し具体的かつ実践的に、プロジェクトマネジメントの技法論を知りたい、という方向けの記事もございます。
　プロマネ、というと、昨今ではどうしてもITのイメージが強いところがあるのですが、できる限り、ITに限定しない形で、考え方をご紹介しています。

ITじゃないプロジェクトも！WBSの書き方再入門【テンプレートあり】

タスクの無間地獄に落ちないための、課題管理のコツ【テンプレートあり】

　そうはいってもITに関する素養は求められる、という現実もります。特に、SaaS全盛の世の中で、押さえておくとよいと思われる内容を、以下の記事で解説しています。

ITサービスの導入成功に必要な「プレ・キックオフ・コミュニケーション」のご紹介

SaaSを活かすか殺すかは、情報システム企画構想の質が決める【テンプレートあり】

究極の手戻り対策：作業後の「やっぱ、ここ、こうして」問題はどうするとよいか

プロジェクトを無理に「マネジメント」しようとせず、やわらかく扱う方法

　難しい話や細かい話は飛ばして、とにかく簡単に、シンプルに、とりあえず、これをやるといいよ、という結論だけを知りたい方、あるいは、プロジェクトマネジメントという概念そのものに拭い去り難い違和感がある、という方には「プ譜」をお勧めしたく思います。
　プ譜とは、プロジェクトを進めるための、楽譜のようなものです。プロジェクトを「計画」として堅く考えるのではなく、もっと純粋に「誰がどう動き、どんな状態を目指すか」という、もっと直感的で柔らかな発想をサポートするためのツールです。

プ譜のテンプレートと、書き方のワンポイントアドバイス！

プ譜を書くメリットを、ズバリ解説します！

プロジェクトの構想の真髄を「定時退社」を題材に考える

プ譜を用いた振り返りと再構想

この記事の著者