■PMBOK ドリルダウン！_No.13
　　プロジェクトマネジメント力評価 (９)

前回から、プロジェクトマネジャーに求められるスキルについて説明してきました。
それでは、今日は、プロジェクトマネジャーに求められるスキルの中から最も重要なコンピテンシーについて学びましょう。
では教室の戸を開けましょう。
コンピテンシーの重要性は９０年代初めから言われてきました。多くの企業の人事制度・人材育成の場面で活用が始まっていると思います。
ＰＭの世界でも、最近特に話題となっています。米国のＰＭＩがＰＭＣＤに取組み始めたことも影響していることでしょう。

変化の激しい外部／内部環境、及び、不確実性の環境下において、現在最も求められるＰＭとはどのような人材でしょうか。
一言で表現するならば「変革型のプロジェクトマネジャー（PM）」ということでしょう。このような、会社に貢献できる「変革型のＰＭ」の特徴は、以下の通りです。

• 明確なビジョンが示せる
• 差別化優位戦略が立案できる
• 価値創造のためのＷＨＡＴを構築できる
• 組織のパフォーマンスを最大限に活用できる

この「変革型のＰＭ」は、 これまでのような所謂“就社”意識から脱却し、精神的に会社離れをし、自らのキャリアを会社に依存せず自分自身で考えるような人材です。そうすることが、現在の本格的な実力主義のＰＭの世界では必須であることもまた事実です。
では、これらの「変革型のＰＭ」が持つスキルは、どのようなスキルとして捉えることができるのでしょうか。

ＩＴＳＳの対象領域となっている、ＰＭ知識（ＰＭＢＯＫなど）や特定職務におけるテクニカルなＰＭ専門分野固有スキル項目だけではないことは明らかでしょう。このＰＭ知識やテクニカルなスキル以外の部分については、これまでは、ＰＭの資質や性格として完全に先天的なものとして捉えられてきました。しかし、９０年代中頃になって米国において「コンピテンシ-」という考え方が登場し、９０年代後半から、日本企業大手の間で急速に普及してきました。また、あの米国のＰＭＩが、ＰＭＣＤフレームワーク（プロジェクト・マネジャ・コンピテンシー・ディベロップメント）を発表し提供したことも大変意味があることだと思います。
コンピテンシーは、一般的に「ある特定の職務にあって、定常的に優れた業績を上げる現職者のもつ特性」と定義され、実在の高業績 者をベンチマークして抽出されるものです。そして、その際に着目する点は、知識やテ クニカルなスキルではなく、仕事に対する「考え方やこだわり、価値観、行動のスタイル、 習慣」といった“ソフトスキル”です。
　　 それでは、先程の「変革型のＰＭ」に求められるコンピテンシーはどんな要素でしょうか？　筆者は、以下のコンピテンシーが要求されると思っています。

• 組織的リーダーシップの発揮
• 新しい成果へのチャレンジ
• 戦略・戦術立案推進
• 新コンセプトの創出

以下に、「変革型ＰＭ」のイメージ図を示します。

さて、抽出したコンピテンシーにＩＴＳＳで要求されるスキル（知識・技術力）を加えて、モデル化したものをＰＭコンピテンシーモデルと呼んでいます。
ＰＭコンピテンシーモデルは、基本的にはPMの職種ごとに特徴が出るものですが、 特定の企業ごとに共通部分を抽出することも可能です。つまり、特定の職種においてだけではなく、ある企業において広く求められる能力もＰＭコンピテンシーに置き換えて具体的に捉えることが可能です。
　　 次回からは、プロジェクトマネジャーに求められるスキルをもう少し具体化していきましょう。

　　 リスクマネジメント (13)

前回は、リスク識別の訓練を継続しました。
今回は、前回宿題の答え合わせをしましょう。
では教室の戸を開けましょう。

前回、以下の宿題を提示しました。空欄は埋まりましたか？　講師の方から、解答の一例を示します。

分類	根本原因	リスク事象	結果	合併症	予防法
コスト	・ プロジェクト管理者が、見積技法、見積支援ツールを適切に用いない。 ・ プロジェクトの規模、技術要因、技術者のスキル、その他の影響要因の考慮が見積時に不十分である。 ・ プロジェクトの担当範囲や要求仕様の増大が、見積の実施後に起こる。	十分に計測し管理されたプロジェクトに比較し、３０％以上の誤差がある	コスト見積りが不正確である	・ コストの超過、スケジュールの遅れ、ビジネス機会の喪失、プロジェクトの中止、不正確な信頼性評価	・ 正確な計測 ・ 機能的尺度（FP法など）を用いれば規模算定の誤りを効果的に防止できる
タイム	・ 訓練、スキル、自動化などが不足しているため、大抵のソフトウェア製品の開発責任者が競争力のある計画の作成とその計画自身の評価をしていない。 ・ 開発中のプロジェクトに対するユーザ要求が除除に増大したり変化したりすること。 ・ 社内教育において、スケジュールの作成や見積に関する訓練が著しく不足していること。	システムが要件定義から出荷するまでに、３年以上の期間がかかる	リリース時期が遅れる	・ ビジネス機会の喪失、顧客との軋轢、経営者との軋轢	・ スケジュールを正確に予測する ・ 管理者が、見積・計画作成支援ツールを使用する。
スコープ	・ この問題がきわめて複雑な問題であり誰もが理解できるわけではなく、解決できる人もほとんどいないこと。 ・ 構成管理の必要性が認識されるのは、一般に多大の損害が発生してしまった後である。 ・ 構成管理は、多くのフェーズにまたがる作業であり、一度には非常に少数の人が、それも継続的にかかわるものである。	ソフトウェアの計画文書、契約書や設計書、仕様書、図形、ソースプログラム、テストケースなどを同期させ、相互参照し、統合し、修正するための自動化された正規の仕組みがない	ソフトウェア構成管理が不適切である	・ 高い保守コスト、低品質、低生産性の主因である ・ リリース時期の遅れ、コスト超過の要因	・ 構成管理は、できるだけ早く、理想的には要件定義時点から始めるべき ・ 設計の完了後に部分的な構成管理を行うような、遅い段階から始めても十分な成果は得られない。

いかがでしたでしょうか？　ここまでくると、前回お話しした、

• リスク識別の作業は、その「感じ方」によって、解答が異なること
• 「感じ方」が人によって異なるのは、人それぞれの経験、見識、ｅｔｃ、様々な理由からである

ことが改めて、ご理解頂けたのではないでしょうか。
また、宿題の空欄を埋める作業においても、すべてのリスクを特定し、根本原因を突き止め、予防をすることはできないことも心に留めておく必要があるでしょう。知ることができないリスクもあり、見逃してしまうリスクもあるのです。プロジェクトの途中でもリスクを特定する機会はあります。手短に言えば、リスクを特定する可能性を高めることが目的であり、すべてのリスクを取り除くことはできないのです。

次回は、リスク識別で使用する「ツールと技法」について整理してみましょう。
ご苦労さまでした。


参考資料：ソフトウェア病理学、Capers Jones著、構造計画研究所発行