大規模プロジェクトと官僚制

1. 『規則』
   何をすべきか、どのようにすべきかを公式に定め、全てのメンバーがそれに準拠して行動する。
   ITプロジェクトでは、プロジェクト憲章やプロジェクト規約、各種のガイドラインや標準が定義され、プロジェクトメンバーはそれに準拠して行動することが求められる。
   プロジェクトの場合は、必要とされるスキルセットのメンバーが集められ、目的を達成するまでの一定期間だけ活動するわけだから、一般の組織（永続することを前提とする企業組織）以上に、行動指針や行動基準を示すものが必要になる。
2. 『ヒアラルキー』
   指示をする人、指示を受ける人という役割が分化する。この役割関係は階層構造（ヒエラルキー）を形成する。そして、そのなかでは命令の一元化、すなわちボスは1人という関係を構築しないと組織は混乱をきたす。
   ITプロジェクトにあっても、規模が大きくなるほど階層構造を深くせざるを得なくなる。その結果中間のマネジメント層が増え、プロジェクト・マネージャーは末端の担当者がどのような作業をしているのかが見えなくなる。
3. 『専門家と分業体制』
   それぞれの役割を明確にし、重複のないように定義する。各担当はそれぞれの専門領域に専念する。ITの世界は技術の進歩が速く、さらに専門領域も細分化されてきている。昔のような、インフラ系SE、業務系SE（アプリケーション・エンジニア）、プログラマーといった単純な職務区分では対応できなくなっている。
   インフラ系に限っても、ネットワーク技術者、データーベース技術者、セキュリテ技術者、・・と細分化されてきている。
   さらにデータベース技術者に限ってみても、概念設計や論理設計など業務系に近いところから、物理設計などのインフラ系に近いところまで、技術の深さと幅が要求されるようになった。（従って、担当領域をさらに細分化して、それぞれの担当者を割り当てなくてはならないケースもあるだろう）
4. 『文書による伝達と記録』
   指示やメッセージは、ミスや誤解が生じないよう、正確に伝達されなければならない。どのような経緯でどのような決定がなされたかを保存し、誰もがそれを事実として共有しなければならない。文書主義、文書重視主義とも言われる。
   ITプロジェクトにおいても、議事録や連絡票の類からはじまり、仕様変更やスケジュール変更の事実を、エビデンスとして文書化して保存する。
   一般にアジャイル型の開発ではドキュメントをあまり作成しないと言われているが、債務不履行などで係争に発展する（裁判沙汰になる）プロジェクトもあるわけだから、重要な決定事項はドキュメント化すべきである。

このような特長を持つ官僚制組織は、合理的な管理機構である一方、官僚制の逆機能といわれるマイナス面を生じる場合がある。
マイナス面の主なものは、形式主義的な行動、目的の置換（本来は手段であるはずの規約や手続きが、目的に変質すること）、 そしてセクショナリズムである。
ITプロジェクトにおいても、官僚制組織のマイナス面が生じるリスクがあることは認識しておくべきである。
PMBOKや共通フレームでは、多くのプロセスやアクティビティが定義されている。 また、マネジメント用のドキュメントや規約・ルールが多種になりがちである。 形式主義や目的の置換に陥らないよう、現実的な落としどころを見つけることも時には必要である。

官僚制組織の弊害の1つを指摘したものに、パーキンソンの法則（パーキンソンの第1法則）というのがある。
これは、イギリス海軍省などの事例分析から導き出された法則である。 パーキンソンの第1法則は、「仕事の量は、完成のために与えられた時間をすべて満たすまで膨張する (Work expands so as to fill the time available for its completion)」と言われるものである。
例えば、組織の中で自分の負担（作業負荷）が増えるようだと、同僚と仕事を分けあうよりも、部下を2人任命して負担を軽減しようとする。 そして自らは、その仕事を監督する地位を望むようになる。
このように負担を散らすことで仕事が必要以上に膨らみ、 組織は大きくなるばかりというのである。
この傾向は官僚主義の組織では止め難いとされている。
ITプロジェクトにおいても、特に大規模なプロジェクトほど、組織の階層構造（ヒアラルキー）が深くなり、中間のマネージャーが増える傾向にあるから、この辺りにも注意が必要であろう。

なお、パーキンソンの法則には、IT分野に関するバリエーション（データ量は与えられた記憶装置のスペースを満たすまで膨張する）があるが、この辺りの話題はまた次回に。