戦略を設定したら，その戦略を遂行するための「組織モデル」を決定する。組織モデルには「機能型」，「プロジェクト型」，「ウィーク・マトリックス型」，「バランス・マトリックス型」，「ストロング・マトリックス型」の5つがある（表1[拡大表示]）。
5つの組織モデルの違いは，(1)開発，営業，技術支援といった特定の業務・機能を単位として組織を分けるのか，それともプロジェクトそのものを単位として組織を分けるのか，(2)プロジェクト・マネジャーやメンバーがプロジェクトの専任なのか，それとも兼任なのか，(3)プロジェクト・マネジャーの権限や責任が強いかどうか，といったことにある。
注意すべきは，あらゆる戦略に対応可能な組織モデルは存在しない，ということだ。どの組織モデルにもメリットとデメリットがあり，それらの特徴を理解した上で，戦略に応じた組織モデルを選択する必要がある。
組織モデルを選択するための判断基準については後述するとして，以下ではまず，5つの組織モデルがどのようなもので，どんな特徴を持っているのかを見ていく。最もシンプルな組織モデルである機能型とプロジェクト型を紹介してから，両方の特徴を併せ持つマトリックス型の3つの組織モデルを説明しよう。
対照的な2つの組織モデル
「機能型」は，開発，営業，技術支援といった特定の業務・機能を単位として部門を分ける組織モデルの1つである。専任のプロジェクト・マネジャーが事実上存在せず，リソースの調整は各部門のライン・マネジャーが行う（図4[拡大表示]）。メンバーはプロジェクトごとに各部門から集め，各部門の通常業務とプロジェクトの業務を兼任することが多い。
このような特徴により，機能型組織モデルの適用範囲は非常に狭い。通常は，使用する技術の難易度が低く，期間が短い小規模なプロジェクトに限定される。例えば，比較的単純なパッケージ・ソフトのカスタマイズやハードウエアの導入・設定といった，少数のメンバーが短期間で実施するプロジェクトが考えられる。
対照的なのが「プロジェクト型」だ。特定の業務・機能ではなく，プロジェクトを単位として部門を分ける組織モデルである（図5[拡大表示]）。専任のプロジェクト・マネジャーが，プロジェクト全体を統括する強い権限と責任を持つ。また，メンバーもプロジェクト・マネジャーの管理下で，プロジェクトの業務に専念できる（兼務はしない）。
プロジェクト型の組織モデルは，プロジェクトに対する責任の所在が明確になると同時に，メンバー全員の一体感が生まれやすい，という利点がある。このため，例えば開発担当者と営業担当者の意思疎通に起因するトラブルを回避しやすい。メンバー全員がプロジェクトの目標と戦略を意識しやすいので，モチベーションを高める効果もある。
プロジェクト型では，個々のプロジェクトの独立性が高く，プロジェクト・マネジャーがリソースを一元管理するので，顧客の要求や環境の変化に対応しやすいという利点もある。大規模な基幹系システムの開発や，特定の大手ユーザー向けの継続的なシステム開発など，期間の長いプロジェクトに向く。
その半面，複数のプロジェクト間のコミュニケーションが不足がちになるので，各プロジェクトが似たようなシステム基盤を個別に開発する，といった無駄が生じやすい。開発プロセスやプロジェクトマネジメント手法を，全社レベルで標準化する際に阻害要因になることもあり得る。
マトリックス型は機能型を拡張
一般的なシステム開発プロジェクトは，プロジェクト型の組織モデルを適用するような，大規模で長期間のものばかりではない。Webシステムの開発のように数カ月程度のプロジェクトも多く，一部のメンバーが異なる小規模プロジェクトをかけ持つケースもある。だが，このようなプロジェクトに，責任の所在があいまいでリソースの調整も難しい機能型を適用することはできない。
そこで必要になるのが，マトリックス型だ。機能型と同様，特定の業務・機能を単位とした組織形態を持ちながら，機能型のデメリットを除いたり，プロジェクト型のメリットを取り入れた組織モデルである。プロジェクト・マネジャーの権限や責任の大きさ，あるいは専任のメンバーの割合などによって，マトリックス型はさらに3つのタイプに分けられる。
「ウィーク・マトリックス型」は機能型と同様，プロジェクト・マネジャーが事実上存在しないため，適用分野も限られる。ただし，各部門のライン・マネジャーではなく，実際にプロジェクトに参加するメンバーがリソースの調整役を果たすので，機能型に比べれば，現場で発生する問題や環境の変化に対応しやすい（図6[拡大表示]）。
特定の業務・機能を単位とした組織形態を持ちながら，専任のプロジェクト・マネジャーを置いた組織モデルが「バランス・マトリックス型」である（図7[拡大表示]）。専任のメンバーは比較的多く，プロジェクト全体の半数を超えることもある。このため，機能型やウィーク・マトリックス型では適用が難しかった，Webシステムの開発などに向く。ただし，各部門のライン・マネジャーとプロジェクト・マネジャーという2人の管理者が存在するため，指示系統があいまいになる可能性がある。
この問題を回避するために，バランス・マトリックス型を発展させたのが「ストロング・マトリックス型」だ（図8[拡大表示]）。プロジェクトマネジメントを専門に行う部門を独立させた組織モデルである。プロジェクト・マネジャーはプロジェクトマネジメント部門に属しており，リソース管理などについて他部門のライン・マネジャーよりも強い権限を持つ。各プロジェクトでの指示系統も明確になる。
ストロング・マトリックス型におけるプロジェクトマネジメント部門は，大手ITベンダーが設置している「プロジェクトマネジメント・オフィス（PMO）」に相当し，プロジェクトマネジメントに関するノウハウを蓄積できる利点がある。Webシステムに加え，中規模や大規模の基幹系システムの開発にも適用できる，汎用性の高いモデルだ。
組織モデル選択の4つの基準
では，5つの組織モデルの中からプロジェクトに最適なものを選ぶにはどうすればよいのだろうか。その選択基準として，以下の4つが挙げられる。
第1の基準は「プロジェクト・マネジャーの権限と責任の強さ」である。最初に設定した組織デザインの戦略を遂行する上での難易度や，過去の実績・経験などを十分に考慮し，専任者が必要かどうかも含めて，プロジェクト・マネジャーの権限と責任を決める。
例えば，プロジェクトの内容が，過去に何度も経験したパッケージ・ソフトの単純なカスタマイズであれば，それほど強い権限や責任は必要ない。逆に，過去に経験したことのない新技術を使ったシステム開発プロジェクトでは，強い権限と責任を持つプロジェクト・マネジャーの存在が不可欠だ。
この時，その任務に耐えるプロジェクト・マネジャーが実在するかどうかが重要なポイントになるのは言うまでもない。もしいなければ，ストロング・マトリックス型やプロジェクト型は，選択しようにもできないのである。
第2に「求められるメンバーのスキルと人数」が基準となる。例えば，Javaのスキルを持つ技術者を必要とするプロジェクトの場合，単なるJavaプログラミングの開発経験があればよいのか，J2EE（Java2 platform，Enterprise Edition）やEJB（Enterprise JavaBeans）など高度なスキルが必要なのかを明確化する必要がある。
3つ目の基準は「管理者の統制範囲（スパン・オブ・コントロール）」だ。統制範囲とは，プロジェクト・マネジャーやグループ・リーダーといった管理者の指揮下にある直属のメンバーの人数を指す。統制範囲を狭くすると階層構造が高くなり（階層が増え），組織は中央集権型となる。逆に，統制範囲を広くすると階層構造が低くなり（階層が減り），分散型となる。なお，統制範囲は後述する「コミュニケーション・モデルの決定」と密接にかかわる。
最後の第4の基準は「意思決定のための権限の配分」である。意思決定の権限を，組織の上位層だけが持つのか，あるいは下位層にまで権限を委譲するのかを決める。最近のシステム開発プロジェクトでは，仕様や価格，契約条件などに関する意思決定の主導権がユーザー側に移りつつあるため，ユーザーに近い下位層に意思決定の権限を委譲して，変化に対応できるようにする傾向がある。
これら4つの基準について検討し，前述した特徴を考慮しながら組織モデルを選択したら，組織デザインの3番目のフェーズである「コミュニケーション・モデルの決定」に移る。
|
伊藤 靖（いとう やすし）／ループス・コミュニケーションズ コンサルティンググループ統括責任者 エバンジェリスト |
