不確実性を乗りこなすのがPMBOK
プロジェクトとは独自性と有期性をもった「不確実性」のカタマリであることは以前説明した通りです。ですから今も昔も変わらず「やってみないとわからない」という性質は必ず持ち併せています。
この不確実性に対処するために先人たちは、マネジメントプロセスの経験知を蓄積してきました。PMBOK（プロジェクトマネジメント知識体系）では、このマネジメントプロセスを五つのグループ（プロセス群）として定義しているのは有名ですよね。すなわち「立ち上げ」「計画」「実行」「監視・コントロール」「終結」の５つです。
第７版となってその規定が劇的に変化を遂げたPMBOKですが、資格取得を考えている方以外は本質的な部分を無理に変える必要はありません。この５つの呼称は小難しいので、もう少し端的に言うと
「企む」「段取る」「やる」「視る」「振り返る」
と言い換えることができるでしょう。
VUCAなんて言われる時代ですが、そもそもそんなものとは関係なく「プロジェクト」というのは昔から不確実性の塊であったわけですから、それこそ適切にPMBOKの本質をとらえ使いこなせば、解決できるシチュエーションはいくらでもある…と個人的には思っています。
５つのプロセス群は時間の流れに沿って時系列に表現されていますが、あくまでもそれぞれのプロセスがプロジェクトのどの時期に主に実施されるかでグルーピングしたものです。
実際のプロジェクトでは、それぞれのプロセスが折り重なる形で同時並行的に行なわれたり、繰り返し行なわれたりするのが通常です。
理解していただきたいのは、
それぞれのプロセスには「果たすべき役割」がある
ということです。プロジェクトを成功させるには、それぞれの役割を適切な時期に果たすことが欠かせません。裏を返せば「果たすべき時に果たさない」という選択肢を選ぶと、格段にプロジェクトは失敗する可能性が高くなるということです。
言い換えれば「果たすべき時に果たさない」と言う選択肢を選ぶということは、いかなる理由であれ、
会社に損害を与え、メンバーに不幸を強いるつもりがある
と確信犯的に決断しているということでもあります。マネジメントを正しく運用しないと失敗するのであれば正しく運用するという選択肢以外には存在しないということでもあります。
企む（立ち上げ）
「企む（立ち上げ）」プロセスは、プロジェクトの方向性を定め、プロジェクトを開始することの承認を得るプロセスです。企画を通す…と言い換えてもいいでしょう。
PMBOKでは、プロジェクト憲章を作成し、ステークホルダーに合意してもらうプロセスなのですが、Ｂ２ＢのＩＴプロジェクトであれば「見積書を作成」し、「お客さまから注文してもらう」までがこのプロセスになるでしょう。
このプロセスでのキーワードは「認識の共有」です。
プロジェクトには必ず「目的」が存在します。
プロジ‘ェクトのニーズであり「なぜプロジェクトを立ち上げるのか」という理由です。
この目的が存在しないままプロジェクトが立ち上がることは決してありません。「何のために？」が不明な状態のまま動機付けを行うことなんてできるわけがありませんよね。目的もなく言われたことを言われたとおりにするだけならロボットにだってできます。
だからこそ、目的を理解しないまま進行するプロジェクト、プロジェクトメンバーは危ういのです。
そして、目的には必ず「満たしたいニーズ」や「解決したい問題」があるものです。
お金を支払ってまで実現したい何かがあるから、プロジェクトは生まれるのです。
このニーズや問題を明らかにし、プロジェクトの進め方や方向性について共通認識を得た上で、プロジェクト開始の承認を得る（受注する）ことが「企む」プロセスのゴールであり、役割となります。
段取る（計画）
企む（立ち上げ）プロセスで、プロジェクトに求められるニーズを明らかにしたら次に「どうやって実現するのか」を練るのが「段取る（計画）」プロセスです。
プロジェクトのスコープ（範囲）を定め、必要となる成果物と成果物に含まれる作業と進め方を明らかにします。
計画はここで立てて終わりではなく、プロジェクトを通じて継続的にメンテナンスされるものです。
最初の計画の時点では情報が少なく、分かっていることの方が少ないのが現実です。
したがって、計画も必然的に粗いものにならざるを得ません。プロジェクトが進むにつれ、より詳細な情報が入手できたら計画をさらに詳細化していきます。
このアプローチを「段階的詳細化」と呼びます。
おそらく多くの組織、多くのマネージャーがまだ『計画書のメンテナンス』までできていないと思います。大手企業などでは工程完了ごとに見直したりもしていますが、こういった機微は画一的でいいということはありません。担当するマネージャーの調整スキルの高さに合わせて、低いなら低いなりに、高いなら高いなりにメンテナンスする頻度を見直す必要があります。
ちなみに、私がマネジメントに集中するとほぼ毎日メンテナンスを行います。
これは私自身がスキルの高い低いにかかわらず、リアルタイム性を重要視していることにほかなりません。間隔が短ければ短いほど最新の情報を忘れずに盛り込むことができ、過ちや問題に素早く気づけて、速やかに対応することが可能になります。
なにより、実際に行う作業時間が短くなり、１回あたりの負担が極小で済みます。
やる（実行）
計画を立てたら、実行に移ります。
実行のあいだ、プロジェクトチームメンバー、ステークホルダーはコミュニケーションを的確に、かつ密に行い、常に情報共有が保たれた状態を維持しなければなりません。
新人で学ぶ「報・連・相」をプロジェクトレベルに昇華させる必要があると考えてください。ビジネスコミュニケーションはすべて報連相の延長線上にあります。新人の時に学んだ基礎中の基礎を本当の意味で理解し、きちんと修得できているのであれば、いかなるビジネスコミュニケーションでも失敗することはありません。
逆に言えば、ビジネスコミュニケーションで失敗する人は、新人レベルの基礎を学びきれていないということでもあります。綿密に計画をしてもなかなか計画通りにいかないのがプロジェクトであるとわかっていても、それでも計画から大きく逸脱してトラブルを起こすのは、この新人で学ぶであろう「報・連・相」を疎かにしていることが大きく起因します。
プロジェクトマネジャーは組織／チーム内外のコミュニケーションの架け橋として機能する必要があり、またその点についてこそ最大限の注力をしなければならず、そのための責任が課せられます。
視る（監視・コントロール）
再三再四説明しているように、計画を綿密に立てていても計画通りにプロジェクトが進行することはまずありません。
当初の計画とプロジェクトの現実との「乖離（ギャップ）」を適宜認識し、問題が起これば適切な対応を取ります。そもそもＢ２Ｂのプロジェクト活動なんてそのほぼすべてが
発注者の課題を解決すること
なはずです。
そのことを理解していれば「課題解決」にも精通していることでしょう。
当初の計画とプロジェクトの現実との「乖離（ギャップ）」を知覚し、そのギャップを埋めるために行う「解決（=solution）」活動こそがここでいうコントロールです。
そしてそのコントロールを最も良いタイミングで最も効率的に実施するためには、プロジェクトの現実を常に「見続ける」必要があります。見続けなければ変化に気付くことができないからです。
マネジメントにとって「見続ける」ことを疎かにする人、軽視する人は、どのような能力を持っていたとしてもマネージャー（管理者）には向いていません。素養がないと言い切ってもいいでしょう。
常に視て、状況を「情報」として収集し、整理しないと判断することも、行動することもできません。持ちうる能力を十全に発揮できないということを意味します。
そう言った意味でも、「見続ける」=マネージャーの資質ともいえるのです。
また、仕様変更の管理や、リスクの追跡、管理などの調整も併せて行います。
振り返る（終結）
それぞれのプロジェクトは原則として一度きりの取り組みになります。
二度と全く同じプロジェクトになることはありません。
ですが、その経験は次のプロジェクトに引き継がれることで、役に立てることができます。うまくいったこと、いかなかったこと、どのような問題が起き、どう対処したのかなど『組織の経験知（バックナンバー）』として残すことで、プロジェクトマネジメントの成熟度を向上することができます。
振り返り…いわば過去の歴史を軽視するマネージャーは、組織を成長させる気がないマネージャーです。部下をメンバーを育成しない、したくないということです。
どんなに教育を受けさせ、どんなに新しい技術を学ばせても、自分の…あるいは他人の失敗から学ぶ姿勢がない人は一生失敗し続けます。失敗は技術とは関係のないところで起きるからです。
成功する方法を他人に分け与えない人は、個人的に優れていても、十分な実力を発揮できません。情報を秘匿し続ける限り、同じ経験を積み上げる機会がない限り、チームがついてこれないからです。
これら５つのプロセスは、先に述べた「不確実性」に対処するための方法論の集合ということができます。プロジェクトはそれこそ不確実なものですから、『こうすれば必ず成功する』という方法はありません。
しかし、それぞれのプロセスで「やるべきことをやる」ことで成功の確率を格段に高めることが可能になります。
いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。