第3章：プロジェクトマネジメントフレームワーク(その2)

ここでは、プロジェクトマネジメントフレームワークの以下のキーワードについてまとめます。

どのプロセスで何をするのか?
組織形態
プロジェクト型組織
機能型組織
マトリクス型組織

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

どのプロセスで何をするのか?

立ち上げプロセス

• プロジェクトを選択する
  
• 過去の情報を集める
  
• プロジェクト成果物を決める/見積もる
  
• プロジェクトの前提条件/仮定条件を決める
  
• どんな業務要件があるか調査し、定義づける
  
• どんなプロダクト(製品)になるか、調査する
  
• プロジェクトマネージャの責任を定義する
  
• どれくらいのリソースを使うか見積もる
  
• プロジェクト憲章を仕上げる
  

計画プロセス

• スコープ記述書を書く
  
• プロジェクトチーム/チームメンバーを決める
  
• WBSを書く
  
• WBS辞書(prep.87:WBS内のタスク毎にスケジュール、予算、メンバーを記載したシート)を書く。
  
• ネットワークダイヤグラムを書く
  
• 時間とコストを見積もる
  
• クリティカルパスを見極める
  
• リスクマネジメント計画書を書く
  
• スケジュール表を作成する
  
• 予算を策定する
  
• コミュニケーションが必要なステークホルダーを洗い出す
  
• 品質評価基準を決める
  
• リスク識別、定性的リスク分析、定量的リスク分析、リスク対応計画を、書く
  
• スコープ、スケジュール、コスト、品質、人的資源、コミュニケーション、調達マネジメント計画書を、書く
  
• プロジェクト管理システムを決める
  
• プロジェクト計画書を承認してもらう
  
• キックオフミーティング(prep.51)を開催する
  

実行プロセス

• プロジェクト計画書に沿って、実行する
  
• プロジェクト進捗を測る
  
• ワークパッケージを遂行する
  
• プロジェクト情報をステークホルダーに伝える
  
• 品質保証(prep.171:品質評価基準がちゃんと役に立っているか検査すること)を行う
  
• メンバーの育成を行う
  
• 進捗報告ミーティングを開催する
  
• 「変化」を識別する。つまり、プロジェクト計画とリアルとの「差」がないか見極める。
  
• 作業認可システム(prep.52)を使う。ヘタな訳語だけど意味は「そのタスクがWBS辞書に定義されたとおりの正しいタイミング、正しい順番で行われたかを認可する手続き」です。意訳だと「作業指示書を発行し、その作業結果をOK/NG判定すること」かな。
  
• プロジェクト計画からみて、「例外」が発生していないかチェックする
  

コントロールプロセス

• 変更管理を実行する
  
• プロジェクトが予想したどおり進捗しているか報告する
  
• スコープ変更を管理する
  
• 品質管理を行う
  
• リスク管理を行う
  
• スケジュール管理を行う
  
• コスト管理を行う
  
• スコープを再確認する
  
• 計画を遵守しているか確認する
  
• プロジェクト計画をアップデートする
  
• 是正措置を取る
  

終結プロセス

• 調達監査を行う
  
• プロダクトを検証する
  
• 財務決済を行う
  
• 教訓を取りまとめる
  
• もろもろのプロジェクト情報をアップデートする(記録するため)
  
• 結局、プロジェクトが予想通りに進捗したのか? 予想とズレているのなら、どれぐらいズレているのかを報告する
  
• オフィシャルな承認をもらう
  
• プロジェクト情報のアーカイブを作る
  
• もろもろのリソースを解放する
  

組織形態
押さえるべきポイントは以下の通り(p.18-21)

• どっちに権威があるか? プロジェクトマネージャか機能マネージャか?
  
• その組織形態のメリットは?
  
• その組織形態のデメリットは?
  

プロジェクト型組織
　プロジェクト指向の組織形態。CEOの下にプロジェクトマネージャが、プロジェクト単位にいて、その配下にメンバが割り振られる。メンバはプロジェクトマネージャにだけ報告すればよい。

メリット

• プロジェクト指向の組織のため、案件に対し最も効率のよい組織といえる
  
• 機能型よりもコミュニケーションがやりやすい
  

デメリット

• プロジェクトが終結したら、「ホーム」がなくなる
  
• (財務や人事などの)プロフェッショナルが育ちにくい
  
• プロジェクト毎に同じような仕事が重なることになり非効率的(プロジェクトのそれぞれに経理担当がいると考えてみて)
  
• リソース(ここでは人的)の使い方は、非効率的
  

機能型組織
　最も一般的な組織形態。CEOの下に「開発部門」「営業部門」「経理部門」と機能単位に統括者がいる形。試験ではほとんど出てこないが、「マトリクス型組織は、どこが優れているか?」といった設問の行間に「マトリクス型組織は、機能型組織と比べてどこが優れているか?」という形で埋まっていることが多い。ご注意あれ。

メリット

• (経理や営業など)スペシャリストが育ちやすい。そればっかりやっているからね
  
• メンバはただ一人の上司に報告すればよい
  
• 似たようなリソースが集中しているため、その分野のプロ単位に組織化されている
  
• キャリアパスがハッキリしている
  

デメリット

• プロジェクトの遂行よりも、目先の業務をこなすことに注力しがち
  
• プロジェクトマネジメントのキャリアパスは育たない
  
• プロジェクトマネージャは、何の権威もない
  

マトリクス型組織
　プロジェクト型/組織型それぞれの、いいところ、悪いところを併せ持っている。ポイントは→メンバは上司が二人いる。プロジェクトマネージャと機能マネージャの両方に報告しなければならない。

　強いマトリクス型組織では、プロジェクトマネージャがより強い権威をもつ。一方、弱いマトリクス型組織では、機能マネージャがより強い権威をもつ。バランスマトリクス型組織では、権威は二人のマネージャで共有される。

　タイトマトリクス(tight matrix)は、組織形態と何の関係もなし。これは、メンバがオフィスの同じ部屋に「縛り付けられているか」という意味。ダミー選択肢としてたまにでる。

　仕事を進めたり、モニタリングしたり、コントロールしたりするのが複雑化するけれど、そこそこ効率的で、そこそこ安全で、そこそこプロジェクト向けな組織形態といえる。リアルではこれが一番多いのではなかろうか… 形だけでもな。

　「チミ、明日からプロジェクト-Xへ逝ってくれ」
　『え? 今の案件はどうするのですか?』
　「それもやるんだ、当然だろ」
　『 ＿/￣|○ 』

かくして、今の上司とプロジェクト-Xの上司の板ばさみになる毎日であった… って、よくある話でしょ。PMBOKでは「プロジェクトマネージャ」vs「機能マネージャ」で権威やリソースの綱引きが書いてあるんだけど、ありゃ現実を知らない連中が書いてるよな。リアルでは、その確執がメンバに押し付けられるんだヨ。じゃなきゃ、メンバにシワヨセがくるんだヨォォー。無給残業という形でな(w
（つД｀）

メリット

• プロジェクトの目標が見えやすい
  
• プロジェクトマネージャがリソース管理する能力を育むことができる。つまり、プロジェクト型だとムダ使いするかもしれないし、機能型だとリソース管理すらさせてもらえないだろうし… ってこと
  
• 機能組織からのサポートが受けやすい
  
• 限られたリソースを最大限に活用することができる
  
• より調和の取れた組織形態
  
• 機能型よりも、水平・垂直の両方向にコミュニケーションが取れる。水平は、プロジェクトメンバー同士。垂直は、プロジェクトマネージャ同士
  
• プロジェクトが終結しても、メンバは「ホーム」がある
  

デメリット

• プロジェクトマネージャと機能マネージャの調整役を必要とするため、コスト的に見て非効率的
  
• メンバにとって二人以上の上司がいる
  
• モニタリングやコントロールが複雑(アタリマエだけど、出るところです)
  
• リソースの割り当てが難しい。奪い合いになることもある。ここでいうリソースは「人的」だろうなぁ
  
• 仕事を進める上での方針や手続きが、プロジェクト部門と機能部門の両方にまたがる
  
• 優先順位が機能マネージャとプロジェクトマネージャで異なることがある←っつーか、真っ向対立することがよくある、リアルではな。最初は機能マネージャがﾄﾞｷｭｿだからだと思っていたが、両方の仕事を経験すると、どちらも正しいことがよくわかる。機能マネージャは機能マネージャの、プロマネはプロマネの「やるべきこと」があり、どちらも銭を引いてくるのに必要ナリ。PMBOKではハッキリと書いてないが、「プロジェクトマネージャﾏﾝｾｰ! プロマネ最高でーす」てな選択肢があれば迷わずソレを選びなされ。
  

プロジェクト推進担当

　スタッフの手助けをしたり、異なる機能部門の間に立って、コミュニケーションの調整役をする人のこと。立場はマネージャより下。異なる部門のメンバ間の緩衝材といったところかな。原語は"project expeditor"

　あなたの会社にもいるでしょ? そーいう人。リアルでは、次の両極端になると思う。どうしようもないﾄﾞｷｭｿで子どもの使いレベルか、立場的にはバックアップなんだけれどﾒﾁｬｸﾁｬ仕事ができて、前面にまで出てくるほど有能な人か。

expeditor
　　・推進
　　・原料供給係
　　・(生産・製造工程での)督促係、促進係

プロジェクトコーディネーター

　部門間の調整役なところは上と同じ。違うのは、立場がマネージャより格上ってところ。プロジェクトコーディネーターからの指示はマネージャを通して通達される。リアルではこっちのほうがﾄﾞｷｭｿ率高し。現場を知らないまま動くからな。

　訳語がPMBOK日本語版と違う(p.19)が、私はprep本を信じる。PMBOKは訳がアレだしな。

coordinator
　　・同格対等にする人
　　・整合調整する人

プロジェクトオフィス(p.21)
そのプロジェクトが遂行されるオフィスのこと。手取り足取り腰取りから、フォーマットだけ与えてあとは放ったらかしまで、イロイロ。

• プロジェクトを遂行する上での方針や方法、テンプレートだけを提供する。ここでいうテンプレートは、その組織で使う報告書や指示書の様式のこと
  
• 仕事を進めるうえでのお手本を示してくれる。プロジェクトマネジメントをどうやって進めるのかを教えてくれる。プロジェクトマネジメントソフトウェア(M$社のが有名だね)の使い方や、他のプロマネツールを適用する方法を指導してくれる
  
• 複数の異なるプロジェクトを与え、それらのプロジェクトの結果への責任を持たせる
  

プロジェクトオフィスのキーとなる考えは以下の3つ

• プロジェクトオフィスの役割が明確に定義されていること
  
• シニアマネジメント(プロマネの上司)の承認が得られていること
  
• プロジェクトマネジメントの手法を実際に使わない限り、どんなにトレーニングをしてもらってもプロマネ能力は上達しない
  

あうう、最後が耳に痛い… が、私の場合は「現場のデスマーチをなんとかしたい」ために始めたこの勉強。なんとか役に立てていますぞ。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
PMP試験対策の目次に戻る
--