プロジェクトマネジメントとは？基本を押さえてプロジェクトを成功に導く

プロジェクトマネジメントとは？

プロジェクトマネジメントとは、プロジェクトを成功させるために必要なマネジメント手法です。具体的には、成功の道筋をイメージするところから始まり、その実現のために計画し、実行していきます。

大昔から人間は、それをプロジェクトと認識していなくても、プロジェクトを実施していました。あるとき人々は、プロジェクトを成功させるためには手順や作法に一定のルールを定めたほうが成功しやすい、と気づきました。この作法・手法こそが、プロジェクトマネジメントです。

Project Managementの頭文字から、PMと略することもあり、ピーエムと読みます。 プロマネと略することもあり、この場合は、プロジェクトマネージャ、つまりプロジェクトマネジメントの執行者を指します。

プロジェクトの定義

プロジェクトとは、非常に広義な表現をすると、ある目的を達成するための取り組みであり、必ず期限（納期）が必要です。期限がない行為はプロジェクトではありません。

例えば私が学生だったとして、次の数学のテストで90点以上とる！という目標を立てたら、「数学テストプロジェクト」の始まりです。 数学のテストでいつか90点以上とる！は期限がないのでプロジェクトにはなりません。これでは、ただの意志か願望にすぎません。

プロジェクトの必要にして十分な条件は、期限と目的・目標があることです。しかし、それらの定義は非常に自由でもあります。そこで、目的・目標をどのように定めていくかが重要になってきます。順を追って解説します。

プロジェクトマネジメントの重要性

プロジェクト自体は非常に多種多様であることがわかってもらえたと思いますが、その中でも一つひとつのプロジェクトを強く特徴づける尺度があります。それが、プロジェクトの大きさ・規模です。

たった一人、たった1日で成し遂げられるプロジェクトがある一方で、10年以上かけて何十人何百人と多くの人々を巻き込み、協力してようやく成し遂げられるプロジェクトもあります。 大きいプロジェクトとしてイメージしやすいところでは、ビルを作る、トンネルを作る、新しい高速道路を作る、などの建築建設系のプロジェクトでしょう。遠い過去で言えば、エジプト人はピラミッドを作りました。IT系では、みずほ銀行の基幹システム統合刷新プロジェクトも巨大なプロジェクトとして非常に有名です。

このような例からわかるように、プロジェクトマネジメントは、主に以下の2点から重要だと考えられます。特に大きなプロジェクトになればなるほど、重要度はより高まるでしょう。

• プロジェクトマネジメントは、多くの人々と効率的に協業して目的を達成するために必要であり重要
• プロジェクトマネジメントは、過去の経験（失敗と反省と成功）を踏まえた改善活動として必要であり重要

ただ、プロジェクトマネジメントを駆使しても、なお困難であるといえるところが、私が冒頭でプロジェクトマネジメントが経験知の集大成と表現した理由の一つです。困難であるからこそ、集積し成長し進化し続ける経験知となるのです。

プロジェクトの成功とは？

プロジェクトの成功は、プロジェクトの定義に即して言えば、定めた期限・納期以内に、定めた目的・目標を成し遂げることでしょう。

そのためには、目的や目標をどう定めていくか、その指標が重要となってきます。

プロジェクト成功の指標

まず有名な指標がQCDです。QCDとは、Quality（品質）、Cost（コスト・予算・費用）、Delivery（納期・期限）の頭文字を取ったもので、プロジェクトにおいて欠かせない要素を表します。

Aさん（自分）が数学のテストで100点をとるというプロジェクトを例に取りましょう。

Quality（品質）

• 10回テストして1回だけ100点を取ればよいのか？
• 10回中5回100点を目指すのか？
• 10回中1回100点で、平均点は90点以上を目指すのか？

得点の品質一つとっても、目標の定め方は色々あります。

Cost（コスト・予算・費用）

100点を取るために、どれだけのコストを許容するのか？

• 参考書を買うのか？
• 学習塾に通うのか？
• 家庭教師を雇うのか？

予算を大きく取れば取るほど、プロジェクトの達成確率が高くなるのはもはや自明です。しかし、一般的にプロジェクトにおいて、同一のことを成し遂げるためにかけるコストは小さいほど良いとされます。

仮に売上があるプロジェクトの場合、コストに当たるのは原価です。儲けである利益額・利益率を上げるためには、原価を下げるほど良いと言えるでしょう。

Delivery（納期・期限）

プロジェクトの定義にかかわる部分でもありますが、いつまでに目標を成し遂げるのか？です。

• 1か月以内か？
• 半年以内か？
• 1年以内か？

納期はコストと密接に連動します。一般的に、時間をかけるほどそのぶんお金もかかるからです。

これら3要素は互いに絡み合い、影響を与え合います。

このようにプロジェクトの目標を明確に定めることは、そのままプロジェクトの成功を定義づけることに直結します。 QCDは、およそどのようなプロジェクトでも共通して言える、汎用的な指標であり、観点です。

では他の指標、観点も紹介しましょう。

顧客満足

プロダクト・サービスの提供を目的としたプロジェクトである場合、顧客満足は見過ごせません。 受託開発であればクライアントやエンドユーザの満足、サービス提供であれば満足感の結果としてお客様に選ばれる製品サービスであることは、極めて重要です。

例えば、継続的なSaaS系プロダクトであれば、

• 解約率を5％以下とする
• リピート率を70％以上とする
• 既存ユーザからの紹介流入率を全体の20%以上とする（悪いものを他人に薦めないでしょう）

という顧客満足度の具体的な指標化もできるでしょう。

（遂行方法に対する）チャレンジ

プロジェクトマネジメントは経験知の集大成です。一度失敗したら、次は別の方法にチャレンジし、成功してもさらなる高みを目指すからこそ、新たな手法が生み出されるのです。誰もチャレンジしなかったら、後述するアジャイルなどの手法は生まれなかったでしょう。新しい社内ノウハウ構築のために、これまで試したことのない新しいやり方を試みる、という判断もあるでしょう。

ブランディング

クラウドサービス系など、販促までスコープとされるプロジェクトであれば、社名や製品名・サービス名などの知名度を上げるという指標もあります。新規事業を立ち上げてサービスを構築しただけでは、企業活動として十分ではないでしょう。今度はそれを売るために、購入してもらえそうな人たちにまずは知ってもらわなければなりません。

プロジェクトマネージャの役割

プロジェクトマネージャは、プロジェクトマネジメントを遂行することで、プロジェクトを成功に導きます。 言い換えると、プロジェクトの成功にコミットメントする（責任を持つ）人がプロジェクトマネージャと言えるでしょう。

さらに付け加えると、プロジェクトマネージャは、大きなプロジェクトを成功させるために存在します。

では改めて、大きなプロジェクトとは何でしょうか？

• 莫大な物量・コストがかかる
• 莫大な期間がかかる
• 莫大な人手がかかる

過去数世紀から現在へ至る技術革新によって、200年前なら巨大と見なされていたプロジェクトも、今ならパソコン1台で解決できる、ということはあるでしょう。ここでいうプロジェクトの大きさは、プロジェクト実施の時点で測った大きさに他なりません。

ソフトウェア開発の手法

プロジェクトマネージャは、プロジェクトを成功させるために、具体的な手法を使います。 その一連の手法をプロジェクトマネジメントと呼びます。

ここからは、ソフトウェア開発系か建設建築系かそれ以外かで、具体的な手法は変わってくるかもしれません。以降では主にソフトウェア開発系をベースに解説します。

ウォーターフォール開発

目的・目標に基づいて、計画をドキュメントとして事前に立案し、計画通りに実行していくスタイルです。 この手法は、計画→実行→評価という、個人の行動プロセスにもよく馴染んでおり、ソフトウェア開発業界でも長く使われている手法です。

大きく以下の工程・段取りで進みます。

1. 要件定義フェーズ：ステークホルダー（クライアント）と何をどこまで作るかを決める
2. 設計フェーズ：目指す成果物の設計をする
3. 開発・実装フェーズ：設計書に基づいて開発する
4. 検証フェーズ：設計書通りに作られていることを検証する

アジャイル開発

かつて、プロジェクト実行前に、千里眼のようにプロジェクトを最後まで見通し計画を立て、その通りに実行することが美徳であるという思想がどこかで独り歩きしました。

実際には、プロジェクトをやる前からすべての計画を立てきることは困難です。プロジェクトを実行している途中で、やりたいことが追加されたり変更されたりするからです。

そこで、計画としてすべてを見通せる小さなサイクル（イテレーション）を規定します。1つの小さなサイクルを実行したら、その結果を踏まえた次のサイクルを回す、というアジャイル開発の発想が生まれました。 アジャイルという言葉が示す通り、素早く小回りの利く開発手法のため、成果物を早く出せ、急な変化にも臨機応変に対応できるという強い特徴があります。

アジャイル開発とスクラム開発

2001年に公開されたアジャイルソフトウェア開発宣言から端を発するとされる、アジャイル開発の手法が広がりを見せるまでは、ソフトウェア業界ではウォーターフォール開発しかないといって良い状態でした。

そして今でも大きな開発手法としては、ウォーターフォール型かアジャイル型の2種に大別されます。

さらに、アジャイル型からはスクラム開発を主としていくつかの派生があります。 実際に自分でプロジェクトを体験してみるとわかりますが、プロジェクトの成否には顧客満足や成果物、チームメイキングやコミュニケーションといった様々な要素が影響します。その中で、どの点にフォーカスを当ててプロジェクトマネジメントを強化するのかによって、開発手法を選択するイメージです。

例えば、チームメイキングやコミュニケーションを重視したアジャイル型がスクラムです。以下では、エクストリームプログラミング（XP）やスクラムも総称でアジャイル型と呼ぶことにします。

アジャイルとウォーターフォールの選び方

一方、ソフトウェア開発業界といっても広く、例えば金融系システム開発や組込系システム開発の世界では、ウォーターフォール型の開発は未だ主流と言えますし、適してもいます。 スピード感のあるクラウドサービス開発やスマホアプリ開発では、アジャイル型を採用するケースが多いかもしれません。

目的から逆算し手法を選ぶことが大切

プロジェクトの性質に合わせたプロジェクトマネジメント手法を選ぶことは確かに重要です。しかし私見としては、手法に振り回されるべきでもないと考えています。 そもそもアジャイル型が生まれた理由は、主にウォーターフォール型の弱点を補うためでした。

以下の要素は、ウォーターフォール型では表立っては出てきません。

• 顧客満足（顧客との協調やコミュニケーション）
• 成果物を早く出す
• チームメイキング
• 追加要求・変更要求にも対応しやすい

ですが、ウォーターフォール型で、顧客満足やチームメイキングが実現できないわけでは全くありません。

• 顧客満足を追求したウォーターフォール型プロジェクト
• チームメイキングを追求したウォーターフォール型プロジェクト

そのようなプロジェクトマネジメントは全く矛盾せず実現可能です。 だからこそ、今でもウォーターフォール型は健在であり、古いから時代遅れ、でもないわけです。

となると、アジャイル型を特徴づけるポイントは以下2点であると言えるでしょう。

• 成果物を早く出す
• 追加要求・変更要求にも対応しやすい

ここが、アジャイル型とウォーターフォール型との最大の相違点です。

重要なことは、何らかの型にハメることではなく、本質を理解し、真に効果のあるプロジェクトマネジメントを実施することです。 とはいえ、これは十分に経験を積んだプロジェクトマネージャだからこそ言えることでもあります。これからプロジェクトマネージャとして経験を積んでいく人にとっては、どちらの型であれ、まずはしっかりプロジェクトを回し切ることもまた大切なプロセスでしょう。

主なプロジェクトマネジメント手法

計画を立てそれを実行するという意味では、どのようなプロジェクトマネジメント手法であれ、行動原則レベルでは共通しています。 それぞれの手法によって、表現方法が変わってきます。

WBS（Work Breakdown Structure）

WBSはプロジェクトを成し遂げるための作業リストです。作業リストは（例えば大分類、中分類、小分類のように）大きな作業分類から分類し、全体を網羅していきます。それらを更に細分化することで、ツリー構成を描きます。

ガントチャート

ガントチャートは、プロジェクトを縦にWBS化・作業化し、横を時間軸として、それぞれの作業をどのように消化していくのか棒グラフで記載したスケジュール表です。棒が長いほど、そのタスクを消化するのに長い期間がかかることを示しており、 ビジュアルで直感的にわかりやすいことが特徴です。スケジュール表といえば、ガントチャートを指し示すことが多いでしょう。

PERT（Program Evaluation and Review Technique）

プロジェクトを作業化、タスク化するところまでは、ガントチャートと同じです。 仮にプロジェクトを作業分解したら100個のタスクがあったとすると、通常、100個のタスクを同時に実行できることはまずありません。タスクA（パーツAの作成）を実施したらタスクB（パーツAを使ってパーツBを作る）を実施する、といった具合に、複数のタスク間には依存関係が成り立ちます。

これらタスク間の依存関係のありなしを描いたものがPERT図です。アローダイアグラムとも呼ばれます。

よく調理手順を例としたPERT図が例示されており、まさしくPERT図の特徴を示すのに好例といえます。 手際の良い料理上手な人は、オムライスを作るために、オムレツとご飯とソースを並列に作っていき、最後にガッチャンコすることで無駄なく素早く作れるでしょう。

並列にできる作業、順序に沿ってやる作業を明確化できることが特徴です。 さらに、クリティカルパス（全工程を達成するために最も時間がかかるタスクルート）とその必要時間を明確にしやすいという大きなメリットもあります。 タスク消化の効率化という観点で、プロジェクトをいかに短納期化できるか、タスク間の相関を考慮しながら検討するためのモデルとして、計画段階で使われるケースが多い手法です。

イテレーション

アジャイル開発では実はあまりWBSやガントチャートという表現は使われません。イテレーションというキーワードで、一定の期間をまず決め、タスクリストの優先度とそのタスクボリュームから、リリース計画を立てます。

例えば、第1イテレーションでは、○○の完成を目標に現時点での総タスク数ざっくり50個のうち、最低限の高優先度の20個のタスクを実施する。第2イテレーションでは、X機能追加のため、15個のタスクを実施する、といった具合の計画を立てるのです。

ポイントは、第1イテレーションを回し終わった後に、そのイテレーションを回し終わらなければ分からなかったであろう、追加タスクが必ず発生することです。最初50個だったタスクは必ず70個のタスクと、当初タスク数より増えます。第2イテレーションの計画段階では、第1イテレーションの結果を踏まえた、追加分20個のタスクの優先度も踏まえた計画として練り直すことができるのです。 素早さや臨機応変さを意味するアジャイルという言葉の由来が、手法によく現れています。 スプリントと表現することもあります。

事例で解説　プロジェクトマネジメント手法の選び方

プロジェクトにおいては、成果物を早く形にできるか、という観点が大切です。アジャイル型を取れるか否かはそこにかかっていると言えるからです。 逆を言えば、ウォーターフォール型は、人間の行動原理に近い型だけあって、どのようなプロジェクトでもこの型をベースにしたやり方で進められます。

選定のポイントはまず、そのプロジェクトがアジャイルベースで行けるか否かの判断です。次に、アジャイルベースが本当にベターかどうかの判断をします。

事例1：大規模な受託システム開発プロジェクト

クライアントの事業がこれまで継続成長し続け、事業が成熟した状態で、保守切れなどの契機で既存システムの大幅刷新を図るようなケースがこれにあたるでしょう。 長年の業務・技術・経営ノウハウの蓄積を新システムでも継承したい、さらに一方では業務効率化も新機能の追加もしたい。大幅な刷新となると要望は膨らみます。

パッケージベースでの追加カスタマイズか、一から構築していくスクラッチ開発か、という大前提の違いでも、とるべき開発手法は異なってくるでしょう。

パッケージベースであれば、既に動くものがあるわけです。そうであれば、機能変更や機能追加を小さく繰り返す進め方もできるため、アジャイル型も選択肢に入るでしょう。 一方、大規模なスクラッチ開発の場合は、アジャイルの弱点とも言える「いつまで経ってもプロジェクトが終わらない」ことが顕在化しやすいため、ウォーターフォールベースが良いでしょう。

事例2：新規事業立ち上げプロジェクト

ITメインの新規事業や、多くのITベンチャー系・スタートアップ系の会社では、やはり早い成果が求められます。近年は、テクノロジーの革新によりそれが可能となったとも言えます。そのため、アジャイルベースがもはや多数派でしょう。トライアル・アンド・エラーを繰り返す意味でも、イテレーションからのフィードバックはよく馴染みます。

事例3：コーポレートサイトのリニューアルプロジェクト

基本的にウェブサイトは、成果物としては早期に出しやすい類です。ただ、どの手法を取るかは、バックエンドやフロントエンドのプログラム的なテクニカル要素がどれだけあるかにも依るでしょう。

とはいえ、担当するプロジェクトマネージャや主要メンバーのバックボーンによる判断や、好みで決めても良いかもしれません。 どちらでも良さそうなプロジェクトのときに、プロジェクトメンバーがウォーターフォール型を実践したことがないのに、いきなりウォーターフォール型にチャレンジするというのもおかしな話です。

プロジェクトマネジメントに関するノウハウや資格

PMO（Project Management Office）

社内にプロジェクトマネジメントオフィスと言われる組織や機構、役割を設置することがあります。プロジェクトマネジメントは、手法が確立されているとはいえ、執行者たるプロジェクトマネージャの力量に結果が大いに左右されます。組織活動としてそれは困るでしょう。

方法論が確立しているだけでプロジェクトの成否が決まるほど、プロジェクトの達成は容易ではありません。 同じ組織内であれば、同じようなプロジェクトが多いはずです。その経験を積み重ねることで、より成功しやすいプロジェクトマネジメント手法や、押さえるべきポイントに対するノウハウを、精度高く磨き上げることができるでしょう。

PMOはそうした目的のため、組織内に同時並行で走る多くのプロジェクトに対し、目標に対して順調に進んでいるかをチェックし、成功を支援する役割を持ちます。

PMBOK（Project Management Body of Knowledge）Ⓡガイド

1996年にプロジェクトマネジメント協会（PMI）により出版された、プロジェクトマネジメントのガイドブックです。初版が出版されて以来、プロジェクトマネジメントの標準化が推進されてきました。

2017年には第6版が出版され、その根底に広がっていたのはウォーターフォール型を前提とした世界観でした。 ですが、上述した通り、ウォーターフォール型にはプロジェクトマネジメントの運営にかかわる、明言されていない重要な要素（つまりアジャイル的な要素）がありました。 アジャイル型の浸透はPMIにとっても無視できないものとなり、2021年第7版の改訂では、かつてない大幅な刷新となったことは記憶に新しいところです。

PMBOKガイド第6版

5つのプロセスと10の知識エリア により、ウォーターフォール型プロジェクトをいかに失敗させないか、そのための極めて詳細な経典でした。

PMBOKガイド第7版

12の原則と8のパフォーマンスドメイン により、アジャイル型プロジェクトマネジメントも、ウォーターフォール型プロジェクトマネジメントと並んで正しいものとして、両者を真とするために、表現がより抽象化され原則化されたのです。

PMPⓇ試験

PMP（Project Management Proffetional）はプロジェクトマネジメントスキル保持を認定する国際資格です。前出したプロジェクトマネジメント協会（PMI）が認定している資格です。このため、（厳密には異なるのですが）PMBOKにかなり準拠したテストと言えるでしょう。 プロジェクトマネジメントに関する実務経験や研修の受講、知識を測る試験で、受験のためにはプロジェクトリーダー以上の役職として、一定年数以上の実務経験が必須とされています。

PMBOK第6版から第7版への変遷により、PMP試験の内容もかなり変わってきたという話です。こうした時代の流れも踏まえているのか、この資格の有効期間は3年間とされており、3年毎の更新申請（トレーニング＆追加費用）が必要です。

プロジェクトマネージャ試験（PM）

プロジェクトマネージャ試験とは、独立行政法人情報処理推進機構（IPA）が主催する、プロジェクトマネジメントに必要なスキルを認定する国家資格です。IPAが主催していることから、情報処理すなわちITプロジェクトが主な内容になります。ソフトウェア開発系のプロジェクトマネージャを目指すエンジニアにはメジャーです。

※PMBOK、PMPはプロジェクトマネジメント協会（Project Management Institute.Inc.）の登録商標です。

おわりに

プロジェクトマネジメントは、一人では到底体験しきれない膨大な経験知の集大成です。 50年前のプロジェクトマネジメント体系より、今のプロジェクトマネジメント体系の方が間違いなく進化しています。10年前の自分のプロジェクトマネジメントスキルより、今の自分のほうが圧倒的に高いプロジェクトマネジメントスキルを有しているべきなのです。

プロジェクトマネージャは、この叡智を借りながら、応用してプロジェクトを成功に導くために尽力します。 どう尽力するかは、別の記事に譲りたいと思います。プロジェクトマネージャとしての力を磨いていきたいと考えている方はぜひそちらも御覧ください。

本記事が、過去のプロジェクトマネジメントにおける経験や叡智の助けを借りながら、自分からコミットし、クライアントや仲間とともにプロジェクトをやり遂げることの助けとなれば幸いです。