私、キットＰＭはプロジェクトマネジメントに関する
あらゆるご相談、ご用命を承ります。
サービス内容のご確認、ご連絡はこちらからどうぞ。
～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～
～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～
■本日は朝一で内科の定期検査に行ってきました。そのため、更新時間が遅れています。ご迷惑をおかけします。
キットＰＭは結構な年ですので、やはり体のあちこちガタが来ています。でも、まだまだやりたい事、やらないといけないことが山積みなので、できるだけマメにメンテナンスをするように心がけている次第です。ジムにも定期的に通って適正な状態になるよう務めています。時間も気持ちも結構シンドイのですが、それも自分の責任だと思っています。
■さて、前回はちょっと横道に逸れました。結局コーチングには否定的な色が出ていたと思いますが別にコーチングそのものを否定しているのではなく、どうやればうまく日本の社会や会社に持ち込むかの道筋が見えなかったのが一つ。それから、どうしても心理学のテクニックに走って、その大元となる思想というかどんな問題を解決できて、それでどんな世界が実現できるかをキットＰＭが見いだせなかったためだと思います。
■言い訳はこのくらいにして、本日は予告通りキットＰＭが唱える「プレプロジェクト」とは何なのか？また、それが「プロジェクト憲章」とどう関わるかについて、考えていきたいと思います。
■すでに申し上げたように、”ＰＭＢＯＫ”で定義されている「プロジェクト・プロセス」は５つあります。すなはち ①立上げ ②計画 ③実施 ④監視 ⑤終結 です。
キットＰＭが言う「プレプロジェクト」は「立上げプロセス」の前にあり、立上げに繋げるための、一連の必要かつ不可欠な活動となります。んー、この説明だとピントきませんね。
ちょっと、ＰＭＢＯＫの考え方をトレースしてみます。つまり、アメリカ的な合理性に基づく考え方です。プロジェクトを開始するためには、当然何を目的として、プロジェクト結果から何を得るのかが明確になっていることが前提になります。当たり前ですね。それで、そのインプットを元にプロジェクトをどうコーディネイトして、マネジメントするかが「プロジェクトマネジメント」の役割というわけです。ここまではOKですね？
■でも、このブログで何回か書いてきたように、そもそもプロジェクトに対するインプット自体が、まったく得体のしれないものであることが沢山あるわけです。これはもう、キットＰＭの経験から山のように引っ張り出すことができる”事実”なわけです。
この原因には色々なことが考えられると思いますが、問題は企業がプロジェクトへ正しい情報をインプットする必要性をあまり感じていないことだと思うのです。えっ？でもなんとかプロジェクトは回っている？ そうですね。多分それでもプロジェクトを回すことができるのは、日本企業の”現場力”の高さだと思います。つまり、抜けている情報をうまく補って（ときには推測して）現場レベルで目標設定を行ない、プロジェクトを進めることができているからだと考えています。それだけ、日本企業の”無茶は承知でもなんとかしてしまう”という現場力があるからでしょう。
しかし、やはり時間的にもコスト的にも無駄が多くなり、万一現場の解釈が間違っていたら、本来ナすべきことが出来なくなる可能性もあるわけです。ここが問題なわけですね。
■であれば、誰かがやるべきだというのではなく、いっそプロジェクト活動の一環として取り込んでしまえっ。というのがキットＰＭの考えです。ただ、これをやろうとすると「プロジェクト・ポートフォリオ」や「プログラムマネジメント」など、ＰＭにかかる責任が増大しますし、知識レベルも高くなることを要求されます。シンドイ話ではあります。でもやり甲斐はあるのだと思います。
■では具体的にどのようなことをするのかです。まず、対象のプロジェクトが企業戦略のどのような”文脈”から出てきているのかをはっきりさせます。それで、その文脈に繋がる他のプロジェクト（兄弟プロジェクトですね）の存在と目的を確認します。この作業が「プログラム」という戦略をを意識した上でプロジェクトを捉えることになります。
これで、プロジェクト目的を大きな枠組で明確にできますし、対象プロジェクトの重要性や優先順位、他のプロジェクトとの関連もハッキリすることになります。
そう、もうお解りですね。ここに上げた内容はプロジェクト憲章の項目に上げた次の項目に該当します。
１．プロジェクトの目的（プロジェクト単体の目的）
２．プロジェクトの背景（プロジェクトの必要性を説明）
■さて、次に考えないといけないのはプロジェクトの目的を達成するために必要な”資源”のあり方ですが、その前にどのようなアプローチで目的にたどり着く方が効率的で有意義かという検討です。
同じ山の頂上を目指すのであっても登山ルートは沢山あり、選択するルートで必要な装備もスキルも変わるというお話を以前しました。
でっ、この複数存在するルート（方針）を一つ一つ検討しどれを選択するかを考えるわけです。考える方法はいろいろあるでしょうし、いくつかのステップを踏む必要もあるでしょう。規模が大きいとこのプロセスだけで一つのプロジェクトとすることもあるかもしれません。
例えば、複数の業務パッケージソフトウェアを評価、検討するとか。協力先のベンダーを選択するとかの作業や、クラウドのプラットフォームのどれを選択するのかなどプロジェクトによって様々だと思います。
■あっと、またまた長くなりすぎたようです。続きは次回ということで、今回はこのへんで。