私が経験したり見てきたこれまでのプロジェクトから、プロジェクトを成功させるポイントは、「JIS Q21500：2018 (ISO 21500：2012) プロジェクトマネジメントの手引」でいうところの、
- 統合の立ち上げのプロジェクト憲章
- 資源のプロジェクト・チームの編成
の部分です。
もう少し具体的にいうと、次の３つがプロジェクト成功の鍵（ポイント）になると考えています。
- プロジェクト立ち上げ
- プロジェクト・チームの編成
- リスク管理
どれも人（ヒト）に関わることなのは、プロジェクトに共通する特性なのかもしれません。
以下、「JIS Q 21500：2018 (ISO 21500：2012) プロジェクトマネジメントの手引」から、私がプロジェクト成功のために重要と考える内容について説明します。
JIS規格「JIS Q 21500：2018 (ISO 21500：2012) プロジェクトマネジメントの手引」はネットで見ることができます。
JISについては、以下のページをご参照ください。
プロジェクトの対象とプロセス
下表は、「JIS Q 21500：2018 (ISO 21500：2012) プロジェクトマネジメントの手引」より引用した、「プロセス群及び対象群に関連するプロジェクトマネジメントのプロセス」です。
表の縦軸はプロジェクトの対象、横軸はプロジェクトのプロセスとなっています。
例えば、一番上の行の統合は、プロジェクトの立ち上げ、計画、実行、管理、終結とプロジェクト全体に関連しており、プロジェクト全体の大きなPDCAを表しています。
表１ プロセス群及び対象群に関連するプロジェクトマネジメントのプロセス
表１は、「JIS Q 21500：2018 (ISO 21500：2012) プロジェクトマネジメントの手引」から引用
※行列のラベル部分を一部修正しています
| 立ち上げ | 計画 | 実行 | 管理 | 終結 | |
|---|---|---|---|---|---|
| 統合 | 4.3.2 プロジェクト憲章の作成 | 4.3.3 プロジェクト全体計画の作成 | 4.3.4 プロジェクト作業の指揮 | 4.3.5 プロジェクト作業の管理 4.3.6 変更の管理 |
4.3.7 プロジェクトフェーズ又はプロジェクトの終結 4.3.8 得た教訓の収集 |
| ステークホルダ | 4.3.9 ステークホルダの特定 | 4.3.10 ステークホルダのマネジメント | |||
| スコープ | 4.3.11 スコープの定義 4.3.12 WBSの作成 4.3.13 活動の定義 |
4.3.14 スコープの管理 | |||
| 資源 | 4.3.15 プロジェクトチームの編成 | 4.3.16 資源の見積 4.3.17 プロジェクト組織の定義 |
4.3.18 プロジェクトチームの開発 | 4.3.19 資源の管理 4.3.20 プロジェクトチームのマネジメント |
|
| 時間 | 4.3.21 活動の順序付け 4.3.22 活動期間の見積り 4.3.23 スケジュールの作成 |
4.3.24 スケジュールの管理 | |||
| コスト | 4.3.25 コストの見積り 4.3.26 予算の作成 |
4.3.27 コストの管理 | |||
| リスク | 4.3.28 リスクの特定 4.3.29 リスクの評価 |
4.3.30 リスクへの対応 | 4.3.31 リスクの管理 | ||
| 品質 | 4.3.32 品質の計画 | 4.3.33 品質保証の遂行 | 4.3.34 品質管理の遂行 | ||
| 調達 | 4.3.35 調達の計画 | 4.3.36 供給者の選定 | 4.3.37 調達の運営管理 | ||
|
コミュニケーション
|
4.3.38 コミュニケーションの計画 | 4.3.39 情報の配布 | 4.3.40 コミュニケーションのマネジメント |
プロジェクトマネジメントの手引きにおけるプロセス
下図に示す５つのプロセス、立ち上げ、計画、実行、管理、終結（完了や中止）の関係について説明します。
プロジェクトマネジメントの5つのプロセスの相互関係
図１ プロジェクトマネジメントの5つのプロセスの相互関係
図１は、「JIS Q 21500：2018 (ISO 21500：2012) プロジェクトマネジメントの手引」から引用
例えば、あるプロセスを立ち上げると、計画し、プロセスを開始（実行）し、プロセスの進捗を管理し、最終的にそのプロセスを終結します。
表１の５つのプロセスは、対象により全てのプロセスに関係するわけではなく、対象により、必要なプロセスは異なります。
例えば、ステークホルダー（利害関係者）は、立ち上げと実行のプロセスに関係しています。
実際のプロジェクトでは、表１の対象ごとに複数のプロセスが実行され、大なり小なり相互に影響を受けます。
表１の対象を以下に列挙します。特別な何かがあるわけではありません。
- 統合
- ステークホルダ（利害関係者）
- スコープ（適用範囲）
- 資源
- 時間
- コスト
- リスク
- 品質
- 調達
- コミュニケーション
プロジェクトと基本プロセスの相互関係
下図は、図１に形のある成果物（プロジェクトのキー情報）を加えて各プロセスの相互作用を説明したものです。
プロジェクトにおける成果物とプロセスの相互作用
図２ プロジェクトにおける成果物とプロセスの相互作用
図２は、「JIS Q 21500：2018 (ISO 21500：2012) プロジェクトマネジメントの手引」から引用
プロジェクトは、１つのプロセスの中にある相互作用だけでなく、各プロセス間にも相互作用があります。
また、私が見てきた実際のプロジェクトでは、ステークホルダー個人の思惑が見え隠れしていました。
だからこそ、以下の３つを重視してプロジェクトを立ち上げ、
- プロジェクト憲章（プロジェクトの目的、目標、期限）
- ステークホルダのプロジェクト憲章への合意
- プロジェクトチームの編成（人選）
実行にあたり、以下の２点を重点にしてリスクを管理します。
- プロジェクト内の各タスクの進捗
- プロジェクトのキーとなるプロセスのキーマンの進捗
プロジェクトを成功させる３つの鍵
私が経験したり見てきたこれまでのプロジェクトを振り返り、プロジェクトを成功させる３つの鍵（ポイント）について説明します。
プロジェクトを成功させる鍵となるのは、
「JIS Q21500：2018 (ISO 21500：2012) プロジェクトマネジメントの手引」でいうならば、
- 統合の立ち上げの部分（プロジェクト憲章）
- 資源のプロジェクトチームの編成
にあると私は考えています。
失敗したプロジェクトからは貴重な教訓が得られるのですが、なぜか聞く人は少ないです。
成功したプロジェクトの表面だけを真似したプロジェクトが厄介な問題になっていくのは、無力感というよりは残念な思いで見ていました。
プロジェクトの立ち上げ
プロジェクトの立ち上げでは、「プロジェクト憲章」により、プロジェクトの目的や目標が、プロジェクトのステークホルダ（利害関係者）に共有され、文書で明確にします。
プロジェクトの目的と目標「何のために何をするのか」が、明確かつ具体的であり、ステークホルダ間で合意されることがポイントです。
オーナー系の企業に限らず、プロジェクトが始まってからひっくり返すステークホルダがいたりします。
そのため、プロジェクトを実際にマネジメントしているキーマンを支えるステークホルダを味方につけておくことが必須です。
これは、合意事項についても同様で、ひっくり返されるところまではいかなくても、理不尽な意見を取り入れたりするだけで、プロジェクト実行メンバーに悪影響が出るためリスクとしての管理することが重要です。
「プロジェクト憲章」についての詳細は、以下の記事をご参照ください。
プロジェクト・チームの編成
プロジェクトチームの編成つまり、人選です。
現実問題として、プロジェクトに必要とされる、プロジェクトに呼びたい人は、その人の部署にとってはできれば出したくない人です。その部署の日々の業務の継続に重要な影響を与える人である場合が多いからです。
このため、プロジェクトのメンバー自身が、プロジェクトに興味を持ちやりたい、協力したいと思うことが最低限必要です。
また、その人の部署についてもプロジェクトが全社的に見た場合、今必要なものであり、プロジェクトメンバーに呼ばれている人財は、適任であることに同意できる（代わりがいないことが分かっている）ことが必要です。
さらに、プロジェクトに割く時間と期限も明確にします。
この人選により、プロジェクトが達成できるかどうかは、ほぼ決まります。
また、プロジェクト開始後、それなりに影響力のある人からの横槍に対し、プロジェクトのリーダー（マネージャー）と主要メンバーを守るステークホルダーの協力（後ろ盾）を確保することが必須です。
私も商品企画時代、営業側からネガティブなダメ出しをずいぶんと受けていたようですが、後ろ盾と後ろ盾を動かしてくれる上司のおかげで、プロジェクトを進めることができました。
成功するプロジェクト（売れる製品の開発）であることを商品企画担当者としての私は確信していましたが、実際に様々な方々から表からも裏からも協力を頂き製品を計画通り完成させることができました。
何も言わずに発売開始後即受注してくれた営業のおかげでホッとしたのは事実です。
「売れる商品ならば営業は文句は言わない」を実感した瞬間でもありました。おかげさまでその後の商品企画は進めやすくなったように思います。
商品企画については、以下のカテゴリページに参考記事をまとめていますのでご参照ください。
リスク管理
ここでいうリスク管理は、情報セキュリティなどのリスクアセスメントの様に、リスクをランク付けして管理することではありません。
プロジェクトを成功させるリスク管理のポイントは、次の２つと考えています。
１つは進捗管理です。ここで言う進捗管理は、プロジェクトの各タスクが計画通りに進んでいるか遅れているかということではありません。
プロジェクトでは、予定した計画との差異が発生して当たり前なので、その差異が各タスクの期限やプロジェクト全体にどのような影響があるかを把握するということです。
また、製品開発だからといって、プロジェクト管理に技術的な知識は必須ではないと考えています。場合によっては、思い込みによる見落としを避けるためには、知識がない方が客観的に状況分析と判断ができることさえあります。
技術的な知識を持っているならば、知っていても知らないフリをしていてちょうどよいと思います。今の時代、調べれば大抵のことは分かりますし、担当者がネガティブなことを言い出すときには、何か他の根本的な原因があることが多いからです。
プロジェクトの進捗が遅れる場合、人に問題がある場合が少なくありません。これがなかなか厄介なのです。
もう１つは、プロジェクトのタスクの中でもその人の担当業務が遅れたり、抜けたりすると困るプロセスを明確にし、常に進捗や状況を把握しておくことです。
ここにも、技術的知識よりも、そのキーとなる人とのコミュニケーションを図り実際の状況を知ることが大切なポイントとなります。
場合によっては、直接進捗を確認しないといけないこともありますが、うまくいっているかどうかは、その人と話をしたり、よく見ていれば分かるものです。
隠すようならうまく行っていないし、遅れているのに何も聞かない場合には、キーとなっている人からどのような状況なのかボヤーっと伝わってくるものです。
私はこれを察知力と言っていますが、なかなかその意味が伝わらず、歯がゆい思いをすることが多いです。
進捗について聞く際の注意点をあえて上げるならば、
「計画通り進んでいないことを責めない」
ということに尽きると考えています。
プロジェクトを成功させるために
プロジェクトを成功させるための視点について、商品開発を例に説明します。
商品開発プロジェクトにおいては、新製品を形にするためにはどうするのがよいかを、様々な視点から具体的に考えることが必要です。
この視点については、表１の対象とプロセスを組み合わせることで、現状を分析し、最も重要なプロセスを探してみるヒントになると思います。
厳しいようですが、プロジェクトを必ず成功させる手法はありません。
仮に、「プロジェクトマネジメントの手引」通りにやれば、プロジェクトが成功するのであれば、航空機開発が遅れることもなく、自動車のリコールもなくなっているのではないでしょうか。
プロジェクトに係ることになったら、「プロジェクトを完成させるのは人であるということ」、しかも、それは１人ではなくプロジェクトに直接的、間接的に関わる人全てであることを頭の片隅においておくと、困った時の糸口になると考えています。
プロジェクト管理のその他のポイント
ここでは、「JIS Q 21500：2018 (ISO 21500：2012) プロジェクトマネジメントの手引」の中で、プロジェクトを進めるにあたり必要な項目の内、私が重要だと考えていることについて説明します。
なお、以下の各項目の説明内容は手引の解釈ではありません。私が理解している内容なので、手引について正確に知りたい場合には、「JIS Q 21500：2018 (ISO 21500：2012) プロジェクトマネジメントの手引」を参照してください。
プロジェクトと戦略
組織の戦略について、中小企業をイメージしてみると、戦略は、社長が思う使命（ミッション）とビジョンを実現するため、方針及び外的要因を考慮して確定するものであり、プロジェクトは、この目的達成の手段ということになります。
手引によれば、プロジェクトとは次の様なものです。
- プロジェクトの目標を達成するために遂行（実行）する、開始日と終了日とをもち、関係者との調整、進捗管理をするプロセスの集まり。
- プロジェクトの目標達成には、定められた（規定の）要求事項に適合する成果物の必要とする。
プロジェクトの進捗報告を例にするならば、
「設計がうまくいってます」
の類ではプロジェクトの進捗報告にはなっていないいうことです。
「ステークホルダーで共有、承認できるもの」
でなければならないということです。
プロジェクトのステークホルダ
プロジェクトのステークホルダの中で、ポイントになってくるのは、
- プロジェクトスポンサ（会社としての決定権を持つ）
- 顧客（代理人）
- その顧客向けの製品開発においても本当に必要かどうかについては疑問が残ります。そうでない場合もあるようです。
- 供給者は、プロジェクトに様々な資源を供給し、プロジェクトに寄与します。
プロジェクトマネジメントについて学ぶと、プロジェクトマネジメントオフィス（PMO）が、すべてを行うようなイメージがありますが、重要なのはそういった組織を作ることではありません。
形から入ったプロジェクトは、コンサルにもらった品質マニュアルの様なものです。
プロジェクト・マネジメントも品質マネジメントシステム同様、実際の状況や現場を考慮して作り上げていくものです。
プロジェクト環境
手引のプロジェクトの環境には、次のような項目が列挙されています。
- 組織の外側の要因
- 社会経済、地理、政治、規制、技術、環境など
- 戦略、技術、プロジェクトマネジメントの成熟度、資源の利用可能性、組織の文化、組織構造など
新製品開発を例にすれば、
- お客様としては、新製品を使うユーザー、購入を決定する人
- 販売面からは、代理店や商社、直販、ネット販売（EC）
- 製造面からは、自社、協力会社（外注先）、同業のメーカー、全くの異業種、ベンチャー、海外製品（輸入品）
- 顧客要求を製品という形あるものにまとめる、商品企画力（人、コンサル）
- 開発リソースとしては、時期（今か、１年後か等）、社内開発者の存在、使える工数、協力会社であれば、何をどこまで委託できるのかなど。
などがあります。
社内と社外に分けて整理してもよいと思います。
商品企画を進める際には、商品イメージの思考範囲を、
- 最も狭い範囲と最も広い範囲で考えてみて、
- 現実的な範囲に絞り込み、
これを繰り返し、時にはリセットして商品イメージを具体化、詳細化していくことになります。
プロジェクトをマネジメントする立場としては、自分で管理できる範囲内のみ対象としたいところですが、自分で管理できない範囲であっても考慮しておくことが望ましいです。
私は察知力と呼んでいますが、「なんとなく危ないな」とか「なんとなく気になる」ことが、プロジェクトを立ち上げる前からあるかと思います。これを忘れずにメモ（記録）しておき、時々振り返ることがプロジェクト成功の要因の１つにあると思います。
私が言う察知力、第六感と呼ばれるものと同じ様なものかもしれません。
「何が危ないか」は、「なぜ売れる商品だと分かって企画しているのか」を説明するのと同じように、他人に伝えることが難しいです。
新商品が使われているイメージを具体化できることとは、
- 簡単なイメージ（落書き）が、
- 詳細なイラストになり、色が付き、
- 映画のように動き出し、
- さらにカラーの動画となって見える。
こうなれば少なくともカラーの動画になった範囲で売れるのは間違いないでしょう。
この際、私情はもちろんのこと自社の都合も含めないのが大前提です。欲を出すと見えていたもさえ、あっという間に見えなくなってしまいます。
ガバナンス
手引では、
「ガバナンスとは、組織を指揮し、管理する枠組み」
とあります。
プロジェクト・ガバナンスとは、プロジェクトに関する組織のガバナンスを含みますが、次のような内容も含まれます。特に影響が大きいと考えている項目を列挙します。
- 意思決定の権限の範囲
- これは重要です。過去の功績があったからというのは、権限とは違います。あまり意識されていないように感じることが多いのですが、プロジェクト内でこじれると表面化します。
- ステークホルダの責任及び説明義務
- プロジェクト内の合意事項をひっくり返されるときは、大抵これが守られず、決定したということだけが指示となって落ちてくるのではないでしょうか。
- 報告、課題及びリスクの上層管理者への嘆願などの相互作用
- 顔を立てるとか言って、実質問題が先送りになり、より大きな問題となって、最後に現場で何とかしろということもありがちです。
ガバナンスに問題がある場合、小さい成功を積み上げていくしかないように思います。
プロジェクトの制約
プロジェクトに制約はつきものであり、前提だと考えています。
「制約のないプロジェクトはない」という意味です。
手引（手引3.11）では、プロジェクトの制約として、以下の項目があります。
- プロジェクトの期間又は目標期日（新製品開発なら出荷日とか）
- 予算、人員、ツールなどの資源
- 受け入れ可能なリスク、潜在的な社会又は環境への影響
- 法的要求事項
どれが大きな制約になるかは、プロジェクトの内容は規模によっても違ってきます。
また、プロジェクト開始後の社内外の環境の変化などにより影響を受け変わっていくものでもあります。
プロジェクト憲章
「プロジェクト宣言書」と呼ばれることもある、プロジェクトの成否を左右する重要な要素の１つです。
「プロジェクト憲章」を作成する目的は、次の通りです。
- プロジェクトを正式に許可する（非公式ではなく公式）
- プロジェクトマネージャを明確にし、適切な責任と権限を明確にする（形式的でなく実効力が必要）
- ビジネスニーズ、プロジェクト目標、成果物、予算等を文書化する（口約束、口頭指示ではないことが重要）
プロジェクト全体計画
手引では、プロジェクト計画とプロジェクトマネジメントを合わせたものを、プロジェクト全体計画としています。
プロジェクト全体計画作成の目的は、次の事項を文書化することとしています。
- なぜプロジェクトを実施するのか
- 誰が何を提供するのか
- どのように提供するのか
- コストはどれほどか
- どのようにしてプロジェクトを実行し、管理し、集結するか
どれもプロジェクトを進めるためには必要なことで、プロジェクト開始後に変更されると、それまでの成果がゼロになることさえあります。
これらが不明確、具体的でないプロジェクトは、そもそも成立しないということです。
大きな失敗を避けるポイントは、終結の条件（プロジェクト中止の条件）を決めるということです。
新製品開発に限らず、リスクの全くないプロジェクトはありませんし、プロジェクトを取り巻く社内外の環境は変わって当たり前です。
ずるずると成功の見込みがないのに続けるプロジェクト、期限のないプロジェクトは社内的にもよい結果を産みません。
プロジェクトを組んで挑戦するのですから、リスクがあるのは分かっている、それでも想定していた成果物を得られないのであれば、プロジェクトそのものを見直す必要があります。
プロジェクトは、ビジネスのために計画し実効しているからです。
まとめ
プロジェクト成功のためのポイントは、プロジェクトの立ち上げ、チーム編成（人選）、リスク管理です。
ここでは、「プロジェクトマネジメントの手引き」を参照しながら、プロジェクト成功のポイントについて以下の項目で説明しました。
- プロジェクトの対象とプロセス
- プロジェクトマネジメントの手引きにおけるプロセス
- プロジェクトと基本プロセスの相互関係
- プロジェクトを成功させる３つの鍵
- プロジェクトの立ち上げ
- プロジェクト・チームの編成
- リスク管理
- プロジェクトを成功させるために
- プロジェクト管理のその他のポイント
- プロジェクトと戦略
- プロジェクトのステークホルダ
- プロジェクト環境
- ガバナンス
- プロジェクトの制約
- プロジェクト憲章
- プロジェクト全体計画
