以下は、ピー・ジェイ・ワイの「プロマネ入門講座」において、研究課題として提示しているテーマとその解説に関する内容です。　講座の概要を類推する参考として掲示するものです。

(解説）

 第Ⅰ部入門編は、プロジェクトマネジメントというスキルの体系と、我々が属する情報処理業界、これを取り巻く環境について述べ、業界の中であなたが今存在しているドメインを再確認することを内容としています。

　世の中にはPMBOKもあればCMMIも有ります。　PMBOKはプロジェクトマネジメントの研修・教育関係で多く使われ、またCMMIはＩＴ組織の能力の成熟度レベル診断に使われています。　プロジェクトマネジメントの実際は、この２つの考え方がかみあって運営されますが、一般的には全くの別物として扱われることが多いのではないでしょうか。　今回はこの2つの接点はどこなのかを問う問題です。

　PMBOKはプロジェクトマネジメントの知識体系として「どんな知識が必要とされるか」を説明しますが、CMMIはプロジェクトマネジメントの実務活動（成果物指向プロセスに近い）として「やるべき作業のベストプラクティス（最も良いやり方）」を説明します。

　PMBOKで知識体系を理解した上で、CMMIのベストプラクティスを活用出来れば、プロジェクトマネジャーとしての実践力の厚みは増します。　逆にこういうアプローチをすることが、一昔前まで徒弟制度しか考えられなかったプロジェクトマネジメントの体得への近道であると言ってるわけです。つまりプロジェクト毎に異なるプロジェクト環境の中でのマネジメントについて、これまで共通化・汎用化出来なかった状況から脱皮する道が開けてきているのではないか、と言う事です。

　ともすれば影に隠れてしまっているCMMIは、本当はプロジェクトマネジャーの「虎の巻」となる、価値ある手本を示している事にも気づいて欲しいと言ってるわけです。

（解説）

　プロジェクトマネジメントについて教えている人（講師）はプロマネの実務は出来ない。　プロマネを実務としてこなしている人は、人にプロジェクトマネジメントについて教えるのが苦手な人が多い。　これは現実に良くある事です。

　そして一昔前まではプロジェクトマネジメントは徒弟制度でしか教えられないスキル体系の分野である、となっていました。　何故こんなことになってしまうのでしょうか。

 PMIのPMBOKを読んだ事が有りますか。　　実際に読んで見ると、PMBOKを読んだだけではプロジェクトマネジャーは出来ないことに気づくでしょう。　したがってスキルを求める人たちは、PMBOKにもとづく実践本をテキストとして求めます。　それでようやく現実の実務工程（成果物指向プロセス）とかみ合うのです。

　プロジェクトマネジメント・プロセスとは、プロジェクトに関わるマネジメントサイクルとして実施すべきプロセスを示しており、成果物指向プロセスとは、システム開発の成果としてのモノをアウトプットするための実務に必要な工程プロセスを示します。　この成果物指向プロセスの工程単位にプロジェクトマネジメント・プロセスは存在し、成果物指向プロセス全体の流れの管理にもプロジェクトマネジメント・プロセスは存在します。

　プロジェクトマネジメント・プロセスを実際の成果物指向プロセスとしての開発工程の作業段取りに当てはめてみて始めて、開発をマネジメントするプロジェクト計画を作ることができます。　成果物指向プロセスとして、開発技術力を強調したモノづくりの作業の段取りだけが決まっていても、開発が失敗する事はあります。　作業段取りとその失敗リスクを想定しながら、そのリスクを最小化していくためのマネジメントが無ければならない訳です。

　実際のシステム開発におけるマネジメントとは、この2つのプロセスを組合せて始めて成り立っている事を理解する必要があります。　まさにテキストにあるように、モノづくりの基本的理解と技術力が無ければ開発のスコープが作れない(見積れない）と同じように、マネジメントの知識が無ければモノづくりの失敗のリスクは高まるばかりということなのです。

（解説）

　最も大事な課題は、まずプロジェクトの性格によって異なります。

　新規のプロジェクトでは、「要求から要件へ、要件にもとづいて設計、開発し実装、さらにテストなどの検証を経てリリース」　されます。　そしてそのシステムは、ビジネス環境の変化、社内組織の変更などにより新たな要求が生まれてきます。　　この新たな要求をシステムで実現するのが改良開発プロジェクトです。　新規の場合との違いは、母体として既存のシステムが存在することです。

　新規開発プロジェクトの最大の課題は、「見積り」です。　　「見積り」は開発スキルと技術力が無ければできません。　そして要求・要件があいまいな段階で行われる見積もりが、特に問題です。　

　対して、改良開発プロジェクトの最大の課題は、母体となる既存システムを調査理解し、新たな要求を機能として実現するための影響分析が必要となります。　この現行理解のための調査分析に必要な期間・工数が確保できないまま、プロジェクトが進む環境が、特に問題です。　改良開発プロジェクトにおいて良く言われる既存システムの「現行踏襲」については、必要に応じて現行理解のための調査分析工程の確保を要することが忘れられがちです。

　まず上記を押さえた上でですが、最も大事な工程という観点でとらえたとき、大事でないプロセスなど無い訳で、またこれといって手を抜いて良い工程なども無い訳で、ただ言えることは始めが肝心であると言うことです。　出来る限り多くの知恵と時間を設計の工程に投入する事です。　諸般の事情から設計工程のショートカットを余儀なくされたプロジェクトは大体失敗します。　　先に進んでから前の工程に逆戻りするのは、最初の工程の数倍の困難を伴う事になります。　　そういう意味では、はじめの工程から慎重にクリヤして行く事が必要となる訳ですが、システム開発ではモノ（コンピュータに実装する中身）を作る工程よりも、その設計の段階が大事なことは言うまでもありません。　

　この設計工程に対するプロマネのマネジメントの仕方がプロジェクトの成否を左右します。　

　設計工程では、有識者および経験者を入れ、関係者の英知を入れて行けばいくほど、より精度の高い計画また設計書を作る事が出来ます。　また、品質のＶ字ラインとは、設計・デザインとそのモノ（アウトプット）が一致しなくてはならないことを表していますが、期間の大小まで表している訳ではありません。　　設計（要件定義・機能設計）と開発（プログラム設計・プログラミング・テスト）の工程期間の割合を問われたら、事情が許す限り設計の期間割合を大きくした方が効率的に、より確実に計画を作成し、そしてモノ作りが出来る、と言えます。

（解説）

　この１７ケ条を読むと、プロマネ経験者は大体が身につまされることと思います。　裁判の判例を基にしたと言われてますが、本当に良く出来ています。

　ＩＰＡ－ＳＥＣの１７ケ条は、過去のＩＴトラブルの法廷闘争などの事例をもとに作られたものです。

　ＩＰＡ（情報処理推進機構）のＳＥＣで識者を集め、「超上流」フェーズで発注者側、受注者側の双方が上手く進めるために重要と考えられるポイントをまとめたものです。

　現在では製本され、ＩＰＡで販売されています。

第1章  超上流から攻めるIT化の原理原則17ヶ条

第2章  原理原則17ヶ条の理解を深める事例集

第3章  失敗から学ぶ原理原則17ヶ条

第4章  成功を支える原理原則17ヶ条

第5章  実務に活かす原理原則17ヶ条

参考資料  上流工程での品質確保における発注者責任の実現

付録  原理原則17ヶ条と共通フレーム2007

（解説）

   オーナが中止宣告したのは、プロジェクト始動の際のスコープ(目標・作業範囲）の定義が明確でなかったということにつきるだろうと言えます。      つまり、PMOが目指した目標とオーナが期待した短期での利益拡大の思惑が一致していなかったという事です。　また、業務改善の目標をもって進んでいたはずなのに、改善のＫＰＩ（Key　performance Indicator）、ＫＧＩ（Key Goal  Indicator)などのディジタルな指標、目標が設定されていた形跡はありません。

　そしてPMOが作成したPMOのプロジェクト計画書が思うように進展しなかった理由としては、以下の事を上げる事が出来るでしょう。

　①.　全社PMOの共通化の計画と現場の実態が合っていなかった

　②.　時期的な状況も含め個別プロジェクトのプロマネのやる気を引き出すまでにいたらなかった

　③.　実態と合わない部分が検出されにもかかわらず、計画を修正する間もなかった

　ということは、プロジェクト計画は実態に適合して、そして実現可能な内容でなければならないということです。　　プロジェクトの現場の実態に適合したプロジェクト計画であるという検証が必要であるということになるでしょう。

　上記のような事が正論として言えるとしても、現実として経営が置かれているビジネス環境、組織体制面、そして事態の緊急性などなどの理由により、本来あるべき王道とするプロセスが進めない事が起きることはあります。

　かといって、巷の教科書が教えるプロマネのセオリー通りに、「さあプロジェクト憲章を作りましょう、この合意が無い限り私は進みませんヨ」みたいな、プロマネの拒否宣言が解決策になる訳でもありません。　　むしろ、現実にはこのような状況に似たケースは結構多いのではないでしょうか。　セオリー通りにいかなかったとして、一旦プロジェクトが進んでしまってから、やはり成果が出なければ、それはそれで、そのプロマネの責任になるのは当然のことです。

　とはいえ、オーナと上手くコミュニケーションがとれないままのこの物語のような環境下で、もし自分がこのようなPMOの責任者だった場合にはどう対応すれば良かったのか、究極の選択とはどういう対応のことを言うのでしょうか。　この課題に特に正解といったものがある訳でもありませんが、以下にPMOに限らずプロマネの極意につながる参考事項を示してみます。

　その対策の一つは、まずは「文書を残すこと」でしょう。　プロジェクトの進行に応じて適宜文書を残しておけば、何故こういう事態となったかについて反論出来る根拠となります。　　何もなければ単にバカと言われて終わるだけでなく、ともすると損害賠償にもつながるかもしれません。

　そして二つ目は、折に触れてプロジェクトオーナへの「報告」を怠らない事でしょう。　　特に事態がまずくなる予兆があれば、なおさら、その時点での状況をインプットしておくことです。

　さらにプロマネ自身は、明確にプロジェクトの「スコープ」を定義しておくとともに、常にその「スコープ」の観点からプロジェクトを評価する「モノサシ」（リスクマネジメント）を持って、全体を俯瞰していなければなりません。　そして一朝事起きれば素早く対処することである、と思う訳です。

（解説）

　まずPMOというものを再度整理してみると、PMOというのは複数のプロジェクトおよびプロマネを対象として、標準化ツールを適用しつつ、無事ゴールに誘導するものです。　言ってみれば、単一のプロマネの一段上のマネジメント力が求められるものであると言えます。　つまり単一プロジェクトのプロマネが、次に目指す能力はPMOオフィサーの能力であると言っても間違いではないでしょう。

　また往々にして、PMOの責任を拡大解釈されて、複数のサブプロジェクトを同時に実質的にマネジメントする状況に対応するようを求められたり、雑誌で読むような例えば銀行３次オン（10万人月超）のPMO組織におけるプロマネの機能を求められたりしがちです。　これはPMOに対する過剰要請であり、しっかりとPMOの責任範囲、スコープを定義して臨む必要があります。

　プロジェクトマネジャーには３つの大きな役割があります。　一つ目はプロジェクトの目標とスコープを詳細化しそれを見積りすること、二つ目はプロジェクト計画を取りまとめること、三つめは計画から逸脱しないようにマネジメントすることです。　これらを標準化して第３者的立場で支援する視点がPMOオフィサーの視点です。　

　このような観点からは、あえて差を強調するならば、単一プロジェクトで開発技術者をマネジメントするプロマネを「テクニカル面重視型」・「行政府的」（実際に共に活動する）であるとすれば、PMOオフィサーは開発マネジャーをマネジメントする「マネジメント面重視型」・「立法府的」（ルールを定め監視する）である、と言う資質が求められるか、と思います。

　また、別の視点からPMOを考えてみますと、PMOにはをPMOとしての支援活動のスコープと、掌握すべきプロジェクトの数の幅があります。　このスコープと掌握すべきプロジェクトの幅を絞り込むと、究極的には１プロジェクトとなるわけであり、とすると単一のプロジェクトの中にPMO機能をおくこともできることになる、と気づくでしょう。　つまり自分のプロジェクトの運営にあたって、自分だけのPMOを適用することもできる、という言い方もできるという事です。　このスコープと掌握すべきプロジェクトの幅を広げたものが組織レベルのPMOであると捉えても良い訳です。

　PMOの目標とするところは、決して統制/コントロールのために統制/コントロールの行動を起こす事ではなく、プロマネが成果を生み出すための手助けをする事に有ります。　　そのためには、全てのプロジェクトに共通なツールやテクニックを使用してプロジェクトマネジメント機能を標準化し、全てのプロジェクトに適用できる状況を作っておかなければなりません。　

　いわゆるPMOの存在というのは、プロジェクトマネジャーの支援とマネジメントがプロジェクト成功のために大変重要な要因であることを認識することが必要です。　また、プロジェクトマネジメント支援は、個人レベルで標準化しコントロールを規定するのではなく、組織レベルでこれを行うものでなくてはならないということ、も肝要です。