目次
コミュニケーションを”減らして”から、”円滑化する”
本日は、「第7章：バベルの塔は、なぜ失敗に終わったか？」を読み解きます。
連載記事一覧は、コチラの最下段から
バベルの塔は「コミュニケーションの壁」によって崩壊した
バベルの塔の失敗の理由はなんだったのでしょうか？
一般的には「神の逆鱗に触れたから」ということになるわけですが、プロジェクト管理の観点で答えるならば、「その結果引き起こされた、言葉の分裂によって、コミュニケーションが阻害されたから」と考えるべきでしょう。
もちろん、コミュニケーションの他にも、プロジェクト成功のために欠かせない要素はいくつかあります。ただ、ブルックス氏によれば、バベルの塔プロジェクトにおいて、それらは全て満たされていました。
- 明白な使命あるいは目的は何か？ イエス。無邪気にも不可能を可能と考えていた。プロジェクトはこの根本的な限界に突き当たるずっと前の段階で失敗だった。
- 要員はあるか？ これは十分にあった。
- 材料はあるか？ 粘土（れんが）とアスファルト（瀝青）は、メソポタミアにふんだんにある。
- 十分な時間はあるか？ イエス。あったはずだ。時間的制約をうかがわせる記述はないのだから。
- 十分な技術はあるか？ イエス。これもあった。ピラミッドもしくは円錐形の構造は本来安定していて、重圧による負荷をうまく分散できる。石工術は明らかによく理解されていたはずだ。このプロジェクトは、技術的限界に突き当たる以前に失敗してしまったのである。
では、なにが問題だったのか。前述したとおり「コミュニケーションが阻害されたこと」です。
彼らに欠けていたのは、コミュニケーションとそれから生まれる組織の2点であった。互いに話をすることができなかったため、まとめることが不可能だった。共同作業ができないとなれば、作業はとん挫せざるを得ない。
前回の「命令を伝える」でも解説した通り、コミュニケーションは非常に大切です。上意下達に限らず、ボトムアップ型の情報吸い上げや、水平方向のチーム間情報共有がなければ、プロジェクトの成功はありえません。そして、その際に「組織」という概念も非常に重要な役割を果たします。
手引書は、非常に大切なツール
まず、コミュニケーションを円滑化するための効果的な方法として、ブルックス氏は3つの手段を上げます。
- 非公式な方法（電話）
- ミーティング
- 手引書
このうち、電話は「会話」とほぼ同義と捉えるべきですし、ミーティングは前章＝前回触れましたので、今回は「手引書」について見ていきましょう。（実際に、原書内でも「手引書」について多くのページが割かれます）
手引書＝構造化された文書アウトプット
本章では、手引書について、「それは何か」「なぜ必要か」「その仕組み」「現在はどうなっているのか」という、4つの切り口で解説されます。簡単にサマっておきます。
- それは何か：プロジェクトの生産したものを、すべて文書として構造化したもの
- なぜ必要か：まず、プロジェクト初期にしっかりと構造を決めておくことで、プロジェクトが進んでも全体の構造が守られる。さらに、この情報をしっかりと全員に受け渡すことで、情報格差がなくなり、認識齟齬を排除できる
- その仕組み：プロジェクトの規模の増大につれ、文書量は圧倒的に多くなるため、構造化がより重要になる。伝達に際しては「何が変わったのか」と「最新版はどういう内容化」の2つが明確になるように気を付ける必要がある。これは「毎日情報を最新化する＋変更箇所の強調」で解決される。（ただし、尋常ならざる工数がかかる）
- 現在はどうなっているのか：当時は、印刷資料からマイクロフィッシュへと移行することで差し替え工数を削減した。現在（といっても、1975年頃ですが）になると、コンピュータが普及し、情報連携は容易になってきている。
尚、本章で主張される「すべての情報は、常に最新の状態で全員に開示され・共有されるべき」というブルックス氏の持論は19章において撤回されていますので、ご注意ください。
組織は「作業の分割」と「機能の専門化」でうまくいく
コミュニケーションが増えると、生産性に影響が出るということについては第2章で述べられました。ここでも、その課題について触れられます。
プロジェクトにn人の要員がいる場合、各2人のコミュニケーションについては、（n2-n)/2通りのインターフェースがあり、潜在的には、調整を必要とするグループの総数は約2n通りとなる。
つまり、10人いれば、210通り＝1024通りということですね。100人なら・・・？ そのための打ち手も挙げられます。
組織の目的は、必要になるコミュニケーションと調整作業の量を減らすことだ（中略）。
コミュニケーションを不要にする手段は、作業の分割と機能の専門化である。
要するに、作業をしっかり分割し、また、各人が保有する機能が専門的になれば、自分（および、自分のチーム内）の範疇で処理できる物事が定義されるため、不要なコミュニケーションを抑制できるということですね。
ツリー構造をうまく活用する
さて、コミュニケーションを減らすために「組織」が活用されるわけですが、”ツリー構造＝木構造”の組織がベースとなりつつも、コミュニケーションがより複雑な”ネットワーク構造”になっていることから、スタッフグループ、特別チーム、委員会、マトリックス型組織などが生まれていきました。しかし、やはり基本は大切です。ブルックス氏は、ツリー構造のなかで、どういう「要素」があれば、円滑なコミュニケーションが実現されるかを考察します。
- 使命
- 製作主任（マネージャー）
- 技術主任（アーキテクト）
- スケジュール
- 作業分担
- 各部分間のインターフェース定義
上記の要素のうち、マネージャーとアーキテクトの区分がある以外は、これまでと変わりません。
一言でいえば「マネージャーは、外向きのコミュニケーション」を担当します。もちろん、そのために必要なチーム内部のコミュニケーションの設計も行うのですが、対外的な（つまり、上層部や別チームとの）折衝が主要な活動となります。一方、「アーキテクトは、技術領域に関して、チーム内を統括する」ということになります。この2つの役割の関係性には、（当たり前ですが）3つのパターンが存在します。
すなわち（A）マネージャー＝アーキテクト（同一人物）の場合、（B）マネージャー＞アーキテクトの上下関係の場合、（C）マネージャー＜アーキテクトの上下関係の場合、の3パターンです。
(A)の場合：一人で管理できるのは、せいぜい6人まで
少人数のチームならばなんとかなるものの、大人数になると「マネージャー兼アーキテクト」の体制には無理がある、とブルックス氏は2つの理由を挙げて述べます。ひとつめは、管理能力と技術能力が料理すつする優秀な人間は殆どいないこと。ふたつめは、大規模プロジェクトにおいては、どちらの役割も工数がひとり分のフルタイム工数を超える作業量になってしまうのです。
(B)の場合：マネージャーが上司の場合は、うまくやれる可能性が高い
マネージャーが上司でアーキテクトが部下の場合については、マネージャーがアーキテクトに対して敬意を払っていることを内外に示す必要があると述べられます。そして、技術的な見解を、マネージャーとアーキテクトがしっかりと議論しつくして共有し、その上で、アーキテクトに（技術的な領域においては）全権を委譲することができれば、プロジェクトがうまく回る可能性が高くなります。
(C)の場合：アーキテクトが上司の場合は、「外科手術チーム」を真似よ
最後のパターン、つまり、アーキテクトが上司の場合は第3章で紹介された「外科手術チーム」を踏襲するのが良さそうです。つまり、アーキテクトを「執刀医」として、マネージャーを「管理者」と「秘書」にするわけですね。システム開発のような技術オリエンテッドのプロジェクトにおいては、この体制は非常にしっくりきます。（個人的には、戦略コンサルティングのチームも、この体制が望ましいと思いますね）
コミュニケーションは本当に大変で大切
チームで仕事を成し遂げる、という場合に、本章で述べられていた「組織」と「コミュニケーション」の設計は非常に重要です。
そして、そのためには、まず「言語化」することが重要です。ただ、言語化するだけでは忘れられたり伝わりそこなったりしますので「文書化」することが求められます。（文書化については、前回述べましたね）
そうして文書化したものを、組織内のコミュニケーションや、組織間のコミュニケーションに使っていきます。
しかし、残念ながら「文書化」が不得意な人も多いです。これは性格的な問題です。また、そもそもの「言語化」が不得意な人もいます。これは才能の問題でもあり、努力不足の問題でもあります。そのため、各メンバーのこれらのスキルをしっかりと見極めて要員配置をしなければ、思わぬ失敗を招きます。
若手のうちは、できるだけ多様な経験を積んだ方が良いと思いますが、ある程度年齢が進み、キャリアを積んだ後は特異な領域にドップリ浸かって戦う方が幸せだし、価値も出しやすいと思う今日この頃です。
連載記事一覧は、コチラの最下段から
