第12回：文書は、アーキテクトの”製品”であると知れ｜本気で読み解く”人月の神話”（第6章「命令を伝える」）

正しい文書をつくることが、コンセプトの完全性担保の鍵

人月の神話【20周年増訂 新装版】

今回は、前回ご紹介した「鍛錬と自制心」によって、アーキテクトが過不足のないデザインをしたとしても、その決定内容をどのように開発陣に「理解させ、実現させるのか」というお話です。

連載記事一覧は、コチラの最下段から

文書は製品だ

この章のメインメッセージは「文書とはアーキテクトが作成する主要な製品である」ということです。文書が製品であるならば、他者の使用に足るだけの品質を担保せねばなりません。幾つかの鍵となる部分を引用します。

高品質なマニュアル作成のポイント

マニュアルには、利用者が見ること全て、インターフェースも含め、記述しなければならないだけでなく、利用者の目に触れないことは記述しないようにもしなければならない。

これは、前章でも述べられた「アーキテクチャとインプリメンテーションの境界線」の話です。利用者の目に触れないということは、すなわち、インプリメンテーションの話であり、そこに踏み込むことはアーキテクトの仕事の範疇を超えているわけですね。ただ、その境界線を超えない部分、すなわち、アーキテクチャの守備範囲については、全てを網羅的に記述する必要があります。

文体は的確で過不足なく、正確に詳述されていなければならない。利用者は1つの説明だけを参照することが良くあるので、必要事項はそれぞれに繰り返されていて、それらすべてが一致している必要がある。

つまり、重複していてもいいから、誤解の内容に記載する、ということですね。そして、それは「すべて正しい」必要があります。

規定されていないものも規定されていることと同じように慎重に定義しなくてはならない

つまり「何を規定しているのか」だけでなく「何を規定していないのか」も大切ということですね。”わざと記述していない”とか”別のモデルでは結果が異なる可能性がある”とか、そういうものが例示されています。

品質担保のための打ち手

上述のポイントをしっかりと押さえたマニュアルをつくるために、ブルックス氏は「1人か2人でマニュアルをつくりあげる」ことを推奨します。

アイデアが10人ほどから出されたものであっても、文章と製品の一貫性を保つためには、文章として仕様書にまとめる作業は1人かせいぜい2人で行わなければならない。

慧眼ですね。その通りだと思います。後述しますが、コンサルティングの現場でも、同じようなことが言えます。

会議をうまく活用する。

続いて、文書だけではなく、会議の活用も有効だと説かれます。会議には、週次ミーティングと全体会議があります。概略を下図にまとめました。

（ちなみに、ブルックス氏がシステム/360の開発時に行った「全体ミーティング」は1年に1度だったようですが、「今もし同じ立場にいるなら、半年ごとにこの会合を開きたい」とのことです。）

そのほかにも、インプリテーションを複数同時並行で走らせることにより”仕様書”の絶対性が高まる、であるとか、独立したテスト機関を設けることで悪魔の代弁者としての機能を持たせる、などのテクニックがありますが、ここでは割愛します。

戦略コンサルティングでも同じ

この「正しい文書によって、情報を伝える」ということの重要性は、戦略コンサルティングの現場にも相通ずるものがあります。（戦略コンサルティングの位置づけについては、コチラをご参照ください）

まず、戦略コンサルティングにおける成果物は「紙（パワポ）」です。アーキテクトはインプリ担当に情報を伝えるためにドキュメントをつくり、戦コンはクライアントに情報を伝えるためにドキュメントを作ります。そのため、成果物における表現は、非常に重要です。（”何が書いてあるか”と同じくらい、”どう表現してあるか”が大事なのです）

さらに、その資料には、「パッケージ全体ではなく、たった1枚のスライドだけがクライアント社内で回覧されてしまう」というリスクがあります。これも、アーキテクトの作成したドキュメントが、利用者に一部のみを読まれてしまう、というリスクに通じます。また、戦略コンサルティングの場合、カラー印刷で提供した資料が、白黒コピーで回覧されたりもしますので「色鮮やかに作ったが、色が消えると却って伝わらない」というリスクも考えておく必要があります。そこまで考えきって初めて”プロの資料”です。

また、マニュアル作成が「1人かせいぜい2人」で担当されるべき、ということと同様に、戦コンの作成する資料（パッケージ全体）の責任は、誰か一人（プロジェクト責任者）が負うことが通例です。彼が、自分の言葉でしっかりと説明できるように全ての記述を”整合性を取って”まとめあげることが重要です。人に依るのでしょうが、僕の場合、一字一句に至るまで書き直すことが多いです。（説明には使わない参考資料でも、書き直しちゃう勢いです）

最後に、アーキテクチャが、インプリを規定しすぎてはいけないという話も、コンサルティング領域に当てはまります。上位コンサルタントがチーム内で「こういうことを考えてほしい」という際に、「例えば、ｘｘｘとか〇〇〇のようなことを明確化したい」と言ったとしましょう。そうすると、チームメンバーの多くは「ｘｘｘと〇〇〇を明確化する」という部分にリソースの大半を投下します。そういうこと言ってんのとちゃうっちゅうねん、それは”例”であって、考え方を踏襲して他のことを考えてほしいって言うてんねや！って感じですよね。ただ、本書を読むことで、これは、もちろん受け取り手の問題もあるものの、伝える側にも問題があるのだなと深く反省した次第です。

以上、本初の普遍性の高さを痛感したところで、第6章の読み解きは終了です。次回は、第7章：バベルの塔は、なぜ失敗に終わったか？です。（ちなみに、神の逆鱗に触れたから、ではありません。）

連載記事一覧は、コチラの最下段から