本記事は『プロジェクトマネジメントの基本が全部わかる本 交渉・タスクマネジメント・計画立案から見積り・契約・要件定義・設計・テスト・保守改善まで』の「序章 プロジェクトマネジメントのスキルの全体像」と「第1章 プロジェクトとはなにか─基本的な知識と考え方をおさえよう」から一部を抜粋したものです。掲載にあたって編集しています。
プロジェクトマネージャーが直面している課題
課題① 現場で使える知識体系がない
私はプロジェクトマネージャーとして22年間、数千人を超える同業者と仕事をしてきました。そこで出会ってきたプロジェクトマネージャーの力量は玉石混淆です。
名刺に「プロジェクトマネージャー」「プロダクトマネージャー」「スクラムマスター」と書かれていたり、またなにかの資格を所持したりしている人でも、実際の現場で発揮されるスキルは保証されていないという現実に向き合ってきたのです。
プロジェクトマネジメントに関する知識やスキルについてインターネットで検索すると、PMBOKやITSS、PRINCE2といった知識体系を見つけることができます。これらは多くの業界で利用されることを想定しているため、概念としてかなり抽象度が高い特徴があります。そして、研修や講座、書籍も多くが資格取得を想定しており、そのまま自分の現場で活用できるケースは多くはないでしょう。
PMBOKなどの知識体系はプロジェクト関係者が知っていることを前提とできる環境ではとても有効に機能しますが、そうでない環境では現場への適用がとても難しいのです。
課題② 無茶ぶりされる
少なくとも、日本で実施される多くのプロジェクトでは、時間をかけてPMBOKやITSSを基に共通認識を整備するどころではないのが実情でしょう。
たとえば、システムやWebサービスを0から1までつくり上げたことのない担当者が上司からよばれて「限られた予算で1年で発注のシステムを刷新する必要がある」とか、「社長の思いつきでなにも決まっていないけど来期までにDXを始めなければならない」といわれたりするケースが多々あります。唐突に発生する大きなミッションと責任を背負わされるようなことが頻繁に起こるのです。
こうして始まったプロジェクトを時間と予算のプレッシャーの中で、自身のスキルでなんとか取り仕切っていかなければならないのが多くのプロジェクトマネージャーが置かれている状況です。
課題③ スキルの属人化
こうした状況の中で多くのプロジェクトを潜り抜けてきた第一線のシニアクラス（経験5～10年以上）のプロジェクトマネージャーのスキルは非常に属人性が高く、その人でなければ活用できないものとなっています。
つまり、スキルが組織に浸透しづらいだけでなく、その人が組織から抜けることになれば大きな損失につながるため、そうしたシニアクラスのプロジェクトマネージャーをどれだけ確保できるかが企業の成長の可能性を決める大きな要因となっています。すでにスキルのある人材は希少価値があり奪い合いになっているため、どの企業でもまずはジュニアクラス（経験5年未満）のプロジェクトマネージャーを育成することが喫緊の課題になっています。
スキル不足のプロジェクトマネージャー
なぜスキルが不足しているのか
「プロジェクト推進に関する意識調査」という調査（株式会社ネオマーケティング, 2020）によると、プロジェクトマネージャーのスキルについての質問で「スキル不足のPM（プロジェクトマネージャー）が多い」と答えた回答者は19.4%、「どちらかといえばスキル不足のPMが多い」と答えた回答者は48.1%と、約7割がスキル不足のプロジェクトマネージャーがいると認識しています。新規事業やDXなど、より高度なスキルが必要とされる今後、ニーズと人材供給のギャップは社会問題としてより一層浮かび上がってくるでしょう。
なぜ必要なスキルを備えたプロジェクトマネージャーが少ないのでしょうか。その理由として、主に次の2点が挙げられます。
- 世の中で流通しているプロジェクトマネジメントの共通概念が抽象的で利用しづらい
- 「実務で覚えなさい」という方法論であるOJT（オン・ザ・ジョブ・トレーニング）が機能していない
本来、プロジェクトを円滑に遂行していくためには、PMBOKなどの知識体系をベースに組織の体制を整備していく必要がありますが、これには経営層の認識の刷新や組織の改革を伴うため、時間も費用も莫大にかかります。多くの企業ではこれをすべて行うのは現実的に無理があるでしょう。プロジェクトマネジメントの共通概念を実践知として広めるためには、日本の組織の実情にあわせてノウハウを再整備しなければなりません。
機能していないOJT
OJTが有効に機能するためには、プロジェクトマネジメントを体系的に修得していて、それを的確に人に教えられるシニアクラスのプロジェクトマネージャーが社内にいることが前提となります。そのような人材は非常に少ないというのは先ほどの調査で理解できるでしょう。
スポーツの世界では「優れたプレーヤーは優れた指導者になるとは限らない」といわれますが、プロジェクトマネジメントの世界でも同じです。「実際にプロジェクトをこなすスキル」をもつ人の中でも「ノウハウを他人に教えるスキル」までを備えた人材は本当に希少なのです。
また、プロジェクトマネジメントのスキルをもっているシニアクラスのプロジェクトマネージャーは「エース」として組織にとって重要なプロジェクトにアサインされており、きめ細かく若手人材を育成するための時間を割けないことが多いという実情もあります。
OJTが有効に機能しない状況で新人がプロジェクトの現場に投入されると、右も左もわからない状況に陥ってしまい、「目の前の不明点を質問するばかりで不安になる」や「失敗から学ぶ」ことになって、成功体験を積めずに挫折してしまうことになりがちです。
さらに、OJTでは偏った経験や知識しか積めないため、転職した際や経験したことがない種類のプロジェクトを担当する際に大きな失敗をすることにもつながります。
たとえば、to C（一般ユーザー向け）の自社アプリを開発する企業でキャリアを積んだプロジェクトマネージャーがto B（事業者向け）の受託システム開発を担当する企業に転職した場合、必要とされるスキルが大きく異なるために、失敗してしまうことがよくあります。
多様なスキルが必要なプロジェクトマネージャーの育成において、事前教育なしのOJTが有効に機能するケースは非常に少ないのです。
必要なのはスキルの見取り図
全体像をとらえる
それでは結局、現代のプロジェクトマネージャーにはなにが必要なのでしょうか。結論からいうと、現実のプロジェクトに落とし込むのが容易かつ体系化された具体的かつ一般的なノウハウです。
これをプロジェクトマネジメントのスキルの見取り図（図序-1）として、プロジェクトを実施する人が自分が置かれた状況と照らし合わせて判断できるようになれば、プロジェクトの成功率を高め、さらに自身のキャリアの生存率を上げることができるでしょう。
本書はそうしたプロジェクトの見取り図となるよう、プロジェクトマネジメント全体を通して必要になるスキルと、各フェーズで必要となるスキルに分けて解説しています。
各章では事例としてITのプロダクト開発を中心に紹介していますが、プロジェクトの進め方についてはハードウェアの製品開発や組織の業務改善、イベントなどのプログラム運営など多くの他業界のプロジェクトでも参考になるでしょう。
プロジェクト全体を通して必要になるスキル
- 第1章 プロジェクトとはなにか―基本的な知識と考え方をおさえよう
- 第2章 交渉―適切なパートナーシップを築こう
- 第3章 タスクマネジメント―チームでパスワークをしよう
プロジェクトの各フェーズで必要になるスキル
- 第4章 プロジェクト計画―目標や進め方を決めよう
- 第5章 見積り―必要な費用とスケジュールを構想しよう
- 第6章 契約―不利な条件を回避しよう
- 第7章 要件定義―やるべきことを決めよう
- 第8章 デザイン―顧客が本当に必要だったものを目指そう
- 第9章 設計―専門家に渡すバトンをつくろう
- 第10章 テスト―事業リスクを最小限におさえよう
- 第11章 リリース―石橋を叩いて渡ろう
- 第12章 保守改善―事業の成功につなげよう
スキルをセルフチェックしてみよう
現在の力量をつかむ
プロジェクトマネジメントのスキルレベルと担当するプロジェクトがミスマッチの場合、なにが起こるでしょうか。プロジェクトの成功率が大幅に下がり、炎上してプロジェクトマネージャーやメンバーが鬱になったり、離職したり、関係する企業が経済的に損害を受けたり、社会的信用を失ったり、それに伴って事業戦略が遅延したりするなどの大きなダメージを受ける可能性があります。
プロジェクトマネージャーとしての自らのスキルを冷静に分析するには、具体的に自分（相手）が最初から最後までその業務を実施できるか・実施したことがあるかを正確に把握する必要があります。
そのためのセルフチェック表を表序-1に示します。これを基に「できる・できない」や「得意・苦手」などの振り分けをしていくとよいでしょう。
もちろん、プロジェクトマネージャー1人がすべての領域をすべて得意である必要はありません。その分野に詳しい人と協力して進めていければプロジェクトを成功させることは可能です。ただ、全体を俯瞰できる人は最低1人は必要になりますので、各領域でどんなことをやらなければならないかを知っておく必要はあるでしょう。
企業の人事・育成担当の方は、各プロジェクトマネージャーにヒアリングしながらスキルセットを整理していくと、育成や今後のアサイン方針を立てやすくなります。
プロジェクトの特性を理解しよう
プロジェクトの定義
プロジェクトとは、いまある状態からあるべき状態にするために行う、スタートからゴールまで続く複数の業務と本書では定義します。たとえば、新しく顧客や売上を獲得するためにECアプリを開発してリリースしたり、煩雑な事務作業を効率化するために業務システムを開発したりするようなプロジェクトが多くの企業で行われています。
新規事業や業務改善のプロジェクトが成功すると、世の中に新しい価値を提供したり、企業の売上や支出のバランスを改善したりすることができます。これは競争の激しい現代では企業にとって極めて重要な取り組みとなるため、多くの企業でさまざまなプロジェクトが実施されていますが、その成功率は決して高くはありません。
「CHAOS 2020」（Standish Group, 2020）という国際的な調査では、ITプロジェクトの成功率は31%とされています。さらに「失敗プロジェクト徹底調査」（日経SYSTEMS, 2011）という調査では、なんと94.5%のプロジェクトが深刻な失敗を経験したと回答されており、さらにそのうちの9割が同じ失敗を繰り返しているとされています。メディアでは成功したプロジェクトばかりが取り上げられるのでうまくいく気がしますが、実は多くのプロジェクトが世に出る前に失敗しているのです。
では、プロジェクトはなにができれば成功で、どうなると失敗になるのでしょうか。
プロジェクトの成功とはなにか
プロジェクトには「目的」と「目標」があります。この2つの単語は見た目が似ているため、混同して使われることがありますが、プロジェクトの成功を考える際は明確に分けて理解しておきましょう。一言でいうと、プロジェクトの目的はプロジェクトが向かうべき最終的な到達点、プロジェクトの目標はそのプロジェクトで達成すべき基準のことです。
プロジェクトの目的とは
プロジェクトの目的とは、そのプロジェクトを実現することで最終的に達成したいゴールのことです。たとえば、業務システムを開発するプロジェクトであれば、プロジェクトの目的は「業務効率を改善して○億円規模のコストカットを実現し、リモートワークにも対応して働き方改革の基礎になる」といったものになるでしょう。ECアプリを開発するプロジェクトであれば、「自社商品の利用者により利便性の高い環境を提示して、新規顧客を獲得し、既存顧客に対しては顧客1人あたりの売上を上げる」といったものになるでしょう。このように、プロジェクトの目的はより事業に直結したものになりますが、これを1つのプロジェクトで一気に達成することはとても困難です。
新しい業務システムを開発しても、実際の業務と調和させて目的を達成するには、部分的な改善を積み重ねるために複数のプロジェクトを実施することが一般的です。同様にECアプリをつくってアプリストアに並べても、マーケティングや機能改善を継続的に行わなければ目的に達成することは困難でしょう。そこで、この目的に到達するためにより具体的な目標を置くことで、小刻みに目的の達成に向かっているかの判断を行い、適切な事業判断を行うことが可能になるのです。
プロジェクトの目標とは
プロジェクトの目標は一般にQCD（Quality：品質・Cost：コスト・Delivery：納期）によって定義することができます。たとえば、業務システムの開発プロジェクトでは下記のような形でQCDを決めていきます。
- Q：要件定義で必須と合意した機能要件と非機能要件を実装する
- C：初期開発の費用は1.5億円を想定する
- D：リリースは2023年の8月末を想定する
これらをクリアすることがプロジェクトが成功したかどうかの基準となります。ただ、プロジェクトは「ヒト・モノ・カネ」のそれぞれの領域で不確実性が高く、QCDはトレードオフ（いずれか一つの要素を優先すると、ほかの要素の優先度は下がる）の関係にあるため、プロジェクトを進行する際に状況に応じて調整を行う必要があります。その際、どの基準をより優先するのかはプロジェクトの開始時にあらかじめ合意しておく必要があります。QCDをすべて必達としてとらえると、調整の余地がなくなりリスクに対応できず、プロジェクトが危機に陥ることになるからで す。
プロジェクトの目的と目標の合意形成については第4章「プロジェクト計画」でも説明しますが、まずは「プロジェクトの成功」には目的と目標の2つの観点があることを理解しておくとよいでしょう。
プロジェクトマネジメントの役割
プロジェクトマネージャーの不在が引き起こすこと
プロジェクトが抱える本質的な特性から生じるリスクを回避する要となるのがプロジェクトマネジメントです。
気心の知れた間柄でシンプルなアプリなどをつくる場合はプロジェクトマネージャーが不在でもうまくいく場合があります。しかし、事業が進んでメンバーが増えたり、関係する部署や企業が増えていったり、プロダクトの改善が進んだりするとプロジェクトの複雑性が増し、プロジェクトメンバーは全体像をつかめなくなっていきます。
プロジェクトで情報や認識の共有が適切に行われていないと、プロジェクトメンバーの間でも「隣の席にいる人が毎日なにをやっているのか知らない」や「チームメンバーなのにリモートワークで一切会話しない人がいる」といった状況が発生します。
すると、各担当者の間で認識の齟齬が発生して、たとえばシステムの設計や仕様で齟齬が生まれたり、それが元で手戻り（仕事のやり直し）が多発するようになったりします。さらに、こうした状況が重なると、トラブルの対応にも多くの時間がかかります。これはプロジェクト全体の時間と工数、予算の大幅な無駄な消費に直結します。バグも増えて、プロダクトの品質にも影響するでしょう。
また、プロジェクトメンバーは自分の仕事に集中できなくなると、プロジェクトに対するモチベーションを下げてしまったり、責任回避のために社内政治に意識が向くようになったりします。こうなると、プロジェクト全体の効率性や生産性は二の次となり、プロジェクトの成功は一層遠のくでしょう。
プロジェクトの成功を誰よりも考える
こうした事態を避けるため、複雑な状況を取りまとめてプロジェクトメンバーや関係各所に伝え、チームワークが適切に発揮できるよう全体を俯瞰して「優先して対処すべき物事はなにか」を判断する人が必要になります。それがプロジェクトマネージャーなのです。
これはオーケストラで指揮者が必要だったり、サッカーでボランチ（司令塔）が必要だったりするのと同じです。「はじめに」でプロジェクトマネジメントは球拾いであると述べましたが、状況を俯瞰していまなにをすべきかを理解していないと本当に役立つ球拾いはできません。
プロジェクトの目的が新規事業に関するものであれば、ビジネスモデルや技術上の課題を俯瞰して判断できる必要があり、業務改善に関するものであれば各部署の業務に詳しくなる必要があります。
こうした全体的な判断が下されるからこそ、各関係者やチームメンバーが自分の作業に集中し、協力して1つの目的に向かって進むことができるのです。
もちろん、進捗や予算管理も重要な仕事ですが、プロジェクトマネージャーにとってもっとも重要なミッション（使命）はあくまでプロジェクトの成功です。そのことを、肝に銘じておきましょう。
