460 ネット上に「人月の神話」読了メモがあった・・・。
転載。天才。
読まれない名著「人月の神話」を本気で読み込んでみた（まとめ）
まじめに読まれない”40年前に書かれた古文書”
人月の神話【20周年増訂 新装版】
本日は、田山花袋の蒲団と同じくらい、知られているけど読まれていない名著「人月の神話」についてご紹介します。
人月の神話とは？
人月の神話というのは、ソフトウェア開発の”単位”である「人月」という概念が、神話に過ぎない（つまり、意味をなさない）という悲しい真実を軸に、ソフトウェア開発が如何に困難を伴うものであるかを説いた名著です。一言でいえば、10人月の仕事＝1人で10か月かかる仕事は、「人月という単位が絶対であれば”10人で1ヶ月”でできるハズ」だが、そんなことは起こりえない、というお話です。そして、この状況を打破し、遅延したプロジェクトに100人投入して一瞬でシステムを完成させるような「魔法の道具（＝狼男に決定打を与える”銀の弾”）」は存在しない*と結論付けられます。
本書は、1975年（40年前！）に初版が発行されました。それが本書の1~15章です。その後、補稿とも言うべき「銀の弾などない（16章）」「銀の弾などない 再発射（17章）」が発表された後、初版から20年が経過した1995年に「人月の神話から20年を経て（19章）」が発表されました。
そして、その1995年から現在までには、さらに20年が経過しています。もはや「古典」を飛び越えて「古文書」と称されても仕方ないくらいの一冊です。
非常に今日的で、普遍的。
この書籍では、40年が立った今日でも全く色褪せることのない真理が沢山語られています。そして、その内容の大半は、ソフトウェア開発に限らず、非常に普遍的なものです。本書をしっかりと読むことは、様々な職種の人にとって、得るものが多いと僕は思います。
本気で読み込みすぎたという反省
というわけで、本当に気合を入れて読み込んでみました。
ただ、気合を入れすぎて、第0回~第21回の「22回連載」となりました。総文字数が（引用文も含んで）7万4,000字になってしまったので、もう、それ、直接書籍を読んだらいいんじゃないの？と我ながら思ったりもしつつ、とはいえ、書籍は30万字くらいあるのでそれよりは幾分マシなんじゃないかと思う次第です。まぁ、折角書いたので、お時間のある時に興味のある項目だけでもピックアップしてお読みいただければと思います。（とりあえず第0回を読んでいただいて、その後、興味のある回を選んでいただくのがオススメです）
「読み込み」の目的と狙い
本書を読み込んでいくにあたり、幾つか気を付けたことがあります。
明らかにシステムに特化した部分には、踏み込まない
時代遅れになってしまっている概念には、極力触れない
翻訳が回りくどかったりする部分は、思い切って「僕の解釈」でシンプルに書き直す
システムに明るくない人＝ビジネス領域の人が読んでも分かるような具体例を可能な限り付加する
僕は、SE → 戦略コンサル → 起業 というキャリアを経てきました。そのキャリアを歩む中で、世の中における「ビジネス世界の住人の、システム領域に関する無理解」が、著しい非効率を生んでいるように感じています。システムは、ビジネス課題を解決するためのツールに過ぎません。どんなシステムを作るのか？は、どんなビジネス課題の解決を目指すのか？と同義です。にもかかわらず、多くのビジネスマンは、システムのことをあまり理解しようとせず、ベンダーにもやっとしたボールを丸投げして終わります。（関連記事：上流（ビジネス）と下流（システム）の切り分け）
この状況を打破するには、ビジネス世界の住人が「システム開発とはどういうものであるか」を”もう少しだけ”理解することが必要だと思うのです。現在は、その仕事をシステム世界の住人に押し付けている状態だと思います。「ビジネスがどういうものであるか、システムサイドが理解しろ」という要求をしているわけですね。これは（ある意味ではシステムサイドの方に失礼かもしれませんが）実現不可能な無理難題です。そんな無理難題をシステムサイドに押し付けるから、その間に入るコンサルティングファームが高い報酬を得て、”要件の翻訳作業”をすることになるわけです。（それはそれでもちろん価値があるんですけれど、コンサルはもっと有益に使うべきだと思うんですよね・・・高いんだし。）
それらを踏まえ、今回の一連の読み解きにおいては、ビジネス領域にも適用できる普遍的な部分を括りだしていくことに留意しました。それによって、本連載を読んだビジネス世界の住人が「自分事」としてイメージしやすくなることに加えて、システム開発における勘所も何となく理解できるようになることを目指してみました。その試みが上手くいっているかどうかは分かりませんが、騙されたと思って、ちょっと読んでみてくださいませ。
脚注） *：正確さを期するなら「ソフトウェア開発には固有の困難性（むずかしさ）があるので、人月の神話が成立しない。その困難性を魔法のように解決しうる銀の弾はない」という表現の方が適切だと思いますが、そのあたりは個別解説記事でご確認ください
連載目次：
第3回：反論に対する反論（17章：前編）
第10回：コンセプトの完全性を優先せよ（4章）
第14回：”見積り”にも銀の弾は無いのだ（8章）
第18回：「考える」と「作る」は別物（12章）
第20回：今日の遅れを見過ごすな（14章）
おまけ：読まれない名著「人月の神話」を本気で読み込んでみた（まとめ） ※本稿
第0回：人月の神話とはなんなのか？（解説編）｜本気で読み解く”人月の神話”
TAG : Strategy & Art | ギックスの本棚 | 人月の神話
目次
ソフトウェア開発者のバイブルだが・・・誰にも読まれていない
人月の神話【20周年増訂 新装版】
こんにちは、元SE（システムエンジニア）の田中です。新卒でSEになった2000年当時に「バイブル（聖書）」として読むことを勧められた一冊が、この「人月の神話」です。
だれにも読まれないバイブル
本書は、素晴らしい名著です。1975年に発刊され、すでに40年が経過しています。そんなにも長い期間「バイブル」として増刷され続けている本書について、著者であるフレデリック・P・ブルックス氏はこんな言葉を残しています。
この本は「ソフトウェア工学のバイブル」と呼ばれている。なぜなら、誰もがこの本を読んでいるが、誰もこの本で述べていることを実践しないからである。
はっはっは、と声をあげて笑うべきところでしょうが、残念ながら、現実はもっと残酷です。正確には、「誰もがこの本を買っているが、誰もこの本を読んでいないからである」と言うべきです。
ちゃんと読むと、とても良いことが書いてある
然しながら、この本は、本棚に飾っておくだけでは、あまりにもったいない良書です。
そもそも、タイトルの「人月の神話」とは、「人（労働人数）と月（投下時間）が交換可能である」という、ソフトウェア開発の世界では「常識」とも言うべき考え方が、「単なる神話に過ぎない」と述べているわけです。これは、凄いことです。しかし、それから40年が経過した今も、人と月は交換可能であるかのように扱われ続けており、そして、非常に悲しいことに「デスマーチ」なプロジェクトが量産されています。
それは、いったいなぜなのか。本書をしっかり読むことで、ソフトウェア開発の本質が見えてくるわけです。
少しだけ頭出しをしておくと、本書はIBMの「OS/360」の開発における”失敗”に基づいて書かれています。一説によると、5,000人年！もの工数が投下されたと言われる、この伝説的なソフトウェア開発プロジェクトでの失敗から学ぶべきものは非常に多いハズです。
ただ、めちゃめちゃ長くて「読みにくい」
しかしながら、非常に残念なことに、本書は非常に長いです。19章で約300ページあります。（初版時の内容である15章までで、168ページとかですね）
そして、非常に読みにくいのです。訳者の方の並々ならぬ努力の跡が随所に感じられますが、いかんせん読みにくい。イメージでいうと「指輪物語」の和訳が非常に読みにくかったのと似てます。スッと頭に入ってこないんですよね。指輪物語を村上春樹が翻訳したら、相当読みやすくなるだろうなと思うんですよね、って、まぁそんなことしたら、フロドの一人称が「ぼく」になって、妙に達観して何かというと「やれやれ」とかつぶやきだすわ、エルフの声を「梅雨時の竹林を吹き抜けた風のよう」とかって表現しだして別の意味で頭に入ってこないような気もしますが。
さて、話がそれましたが、そんなわけで、これを頑張って読み通すには相当な労力が必要です。なので、大抵の人は、途中で心が折れてしまうわけですね。
こころが折れる前に「18章」を読もう
そんな大作を読む気力も根性もない、という人は、全てをあきらめる前に、ひとまず「18章」を読んでみることをお勧めします。
18章は『人月の神話』の命題 -真か偽か と題されています。なんと、1~15章の内容をたった24ページにサマライズしてくれているのです。
尚、18章の最初に、著者はこんなことを書いています。
「概略だけで済む内容なら、どうして165ページもの長さになったのか」などとは言わないでもらいたい
まぁ、そういいたくなるよねって感じですが、さすがに著者本人がまとめただけあって、非常に良くまとまっています。ですので、とりあえずこの章を読む、という選択は正解です。（読書感想文を書くときに、あとがきとか解説とかを先に読む、的な感じですね）
田中の「オススメ順序」
いやいや、もうちょっと頑張って理解したいんだ！という方にオススメの読み方もあります。
それがコチラ。
18章で全体を把握し、16→17→19で、情報の鮮度を上げる。というものです。（まぁ、18章＋19章だけでもいいですけどね。）この読み方にすることで、18章(24p)＋16章(26p)＋17章(21p)＋19章(38p)の、100ページ分くらいで済みます。
その上で、18章の中で特に気になったところを、原文＝1~15章にあたる、というのが良いと思うのです。
この連載は「田中のオススメ順序」に沿って進めます。
というわけで、本連載では、この「田中のオススメ順序」に沿って、読み解きを進めていくこととします。
ただ、最初に読み解く18章は「サマリー」ですので、原著を読んでもらうことを強くお勧めしたいと思いますので、「各章のタイトルの意味するところを説明する」に留めます。その後、16章・17章・19章の順で読み解きを進めていき、さらに（18章と重なる部分は非常に多いでしょうが）1章～15章を、それぞれ深堀していく、という流れとなります。
では、次回＝読み解き初回は、「18章を読み解く：各章のタイトルの意味するところ」です。長期連載：火の鳥を読み解く並の超大作になってしまいそうですが、何卒お付き合いいただければと思います。
ぜひ、「ソフトウェア開発のバイブル」を一緒に読み解いていきましょう。
第1回：各章のタイトルの意味するところは？：あらすじを把握しよう｜本気で読み解く”人月の神話”（第18章）
TAG : Strategy & Art | ギックスの本棚 | 人月の神話
目次
名著の「全体」を押さえる。
人月の神話【20周年増訂 新装版】
さて、本気で読み解く人月の神話シリーズ。いよいよ本論です。初回となる今回は、まずは「1～15章の、各章のタイトルをしっかりと理解する」ということですすめます。
今回取り上げる18章がサマリーとなっていますので、これをもって「18章の読み解き」と代えさせていただきます。（なんで、18章からやねん、という方はご面倒でしょうがコチラをご一読ください。）
各章の名前は「結構、意味深」
前回もご紹介しましたが、各章のタイトルはなかなか意味深です。
「タールの沼」「外科手術チーム」「5ポンド袋に詰め込んだ10ポンド」「切れ味のいい道具」など、興味深い言葉が並びます。まずは、これらをしっかりと理解しておきましょう。
第1章：タールの沼
タールの沼。分かりやすいですね。ドロドロの沼です。そこに囚われれば、命はありません。つまり、大規模システム開発＝タールの沼だ、と言っているわけです。
第2章：人月の神話
なぜ、システム開発は「遅れる」のか。それは「どれくらいの人月を投下すれば、システム開発が終わるのか」という見積もりが間違っているからです。それは”見積ったひとの見積もり能力”の問題もあるのかもしれませんが、多くの場合「人（人数）と月（時間）が交換可能だ」という前提そのものが間違ってしまっていることが原因です。
ここでいう「人月の神話」は、「人と月が交換可能だという”幻想”は捨てなさい」という意味で使われています。
第3章：外科手術チーム
この「外科手術チーム」は、開発におけるチーム構成について語っています。チーフプログラマを「執刀医」とし、その下に「副執刀医」「管理者」「秘書」などの役割を設定して、チームとして生産性の高い「オペ（手術）」すなわちプログラム開発を行う、という思想です。
尚、この1チームだけでは「超大規模プロジェクト」は遂行できない（というか、時間がかかりすぎる）ので、システムの規模が大きくなると、この「外科手術チーム」を複数管理していくことになります。
第4章：貴族政治、民主政治、そしてシステムデザイン
この章の最大のキーワードは”コンセプトの完全性”です。システムデザインにおいて最も重要な、この”コンセプトの完全性”を担保しようとすると、例え「貴族政治」と誹りをうけようとも、アーキテクト（最高設計責任者、とでも訳しておきますか）だけが”コンセプトを決めきるべき”ということになる、ということが述べられます。
もちろん、「民主主義なんてくそくらえだ」とかいうことを言っているわけではないので、詳細は、第4章の解説において深く掘り下げたいと思います。
第5章：セカンドシステム症候群
一番危険なのは「二度目のシステム開発」である、ということの警句として「セカンドシステム症候群」という言葉を用いています。要するに「はじめての時には”次回に取っておこう”と我慢したアイデアたち」を、一回、システムリリースに漕ぎつけた安心感と自信から、二回目には全部取り入れようとしてしまって破綻する、というリスクがある、というわけです。
これは、システムデザインに関わる全員が、頭の中に叩き込んでおくべき至言です。慣れたころが危ないんですよ。
第6章：命令を伝える
”やりたいこと”をアーキテクトが決めたとして、それを、マネージャーがチームメンバーにどのように伝えるべきか、ということを「命令を伝える」と表現しています。この際に大事になるのが「仕様書」であり、その「定義」なのだ、というお話です。
第7章：バベルの塔は、なぜ失敗に終わったか？
「バベルの塔」を知らない人はいないでしょう。神への冒涜として、建築中に破壊されてしまうアレです。失敗した理由は「神の逆鱗に触れたから」なのですが、敢えて、プロジェクト管理の視点で見ると、何が間違っていたのか？と本章では論じられます。ちなみに、答えを述べておくと「コミュニケーション」と「組織」です。詳細は、第7章の解説にて詳しく述べます。
第8章：予告宣言する
「予告宣言する」の扉絵は、ベーブ・ルースの「予告ホームラン」の写真です。が、本章の中身は「ホームランを打つと予告しよう」ではなく「失点しません、というためには、どうしたらよいか？」という観点で述べられていると思います。
つまり、「必要な作業量（＝労力）をどのように見積もるべきか」ということを論じています。そして、世の中の（悲痛なまでの）失敗例から考えられる見積もり方法への示唆が述べられます。現実は常に過酷なのです。
第9章：5ポンド袋に詰め込んだ10ポンド
5ポンドしか入らないところに、10ポンド詰め込む、ってどういうこと？って話ですが、要は「メモリスペース」のうち、どの程度を「システム本体」が占有すべきか、という議論です。5ポンド分しか割り当てられないところに、10ポンド分を”工夫して”放り込むにはどうすれば良いか？を「表現方法」として考えることの重要性が説かれるわけです。
尚、この話は、（一部の領域を除いては）昨今では論じる必要が無くなってきている課題かもしれません。そのあたりについては、16,17,19章において情報鮮度を上げる中で論じていきましょう。それでも足りなければ、第9章の解説において掘り下げます。
第10章：文書の前提
システム開発において、比較的”おそろか”にされがちなものの一つが「文書」です。書類の項目が規定され、それを適切に埋めるように指示されます。作業をさせられる方からすると、これは「本質的でない管理作業」に見えます。そして、形骸化していき、ないがしろにされていくわけですが、それはデスマーチの入り口です。こんにちは！死への行進へようこそ！
文書化の重要性とは、客観性の獲得であり整合性の確保です。（関連記事：プレゼンのコツを参照。）そういう「作成する文書の”前提”」をしっかりと明確化し、チーム内で共有することがいかに重要であるかを述べているのが、この第10章です。
第11章：1つは捨て石にするつもりで
これは、「パイロットシステムをつくって、1回捨てろ」ということを述べています。要は、いきなりうまくいくことは無いからあきらめろ。ちゃんと手順を踏めということですね。
この思想については、19章「人月の神話 から20年を経て」において修正概念が唱えられますが、そのあたりの詳細は19章の解説で。
第12章：切れ味のいい道具
この用語は、どちらかというとアンチテーゼとして使われています。つまり「熟練の機械工と同じように、独自の七つ道具（切れ味のいい道具）を持っているプログラマってどうなのよ？」という命題です。
特に、本書全体のテーマである「コミュニケーションこそがプロジェクト推進の鍵であり、癌である」という視点から見ると、個人が勝手な判断で道具を持っていることは好ましくありません。（もちろん、チームとして生産性向上のために必要な道具があることも前提としつつ、です）
第13章：全体と部分
これは、テストフェーズ、デバッグフェーズにおける「統合されたシステム（全体）」と「個別のコンポーネント（部分）」を指しています。
いかにして、バグの少ないシステム開発ができるかについては、「トップダウンデザイン」が有効であると説かれます。要するに、「全体整合性」をまず確保し、それを「（独立性のある）モジュール」に分解した上で、それぞれを洗練させていくべきだと述べているわけですね。
第14章：破局を生み出す事
「破局」。この強い言葉は「プロジェクトの破滅的状況」すなわち「信じられないくらいの遅延状況」を指します。
ひらたくいうと「なんでプロジェクトは遅れるちゃうのさ」ってことですね。その理由を端的に表現すると”遅れて当たり前という感覚が問題”ということになります。詳細は、14章の解説記事で述べますね。
第15章：もう一つの顔
前章すなわち1～14章では「開発」サイドから、プログラムあるいはシステムを語ってきました。この章ではその「もう一つの顔」すなわち「ユーザー」サイドからみたシステムについて述べていこうとしているわけです。
ちなみに、言っていることはシンプルで、ユーザーは開発者と別人なんだから、普通に考えて「ドキュメント」がないと伝わんないでしょ？ってことです。
（おまけ）第16章：銀の弾などない
本稿は、本書を要約した第18章の読み解き、と謳っていますので、18章の要約対象として含まれない「16章：銀の弾などない」は読み解き対象ではないのですが、ついでに理解しておきましょう。ちなみに、僕が本書を初めて入手したとき、その副題は「狼人間を撃つ銀の弾はない」というものでした。当時大学生だった僕は、この副題にワクワクしたものです。（まぁ、読んでみて、ワクワクがガッカリに変わったのは言うまでもないのですが）
ここでいう「狼人間」とは、システム開発を破滅へと追い込む恐るべき”なにか”、です。そして、その狼人間（いわゆる狼男）の弱点である「銀の弾」は、システム開発を滞りなく進めるための決定的な何か、のことです。つまり、この章では「そんな特効薬なんてない」と言うことを語っているわけですね。
しかし僕は、この言葉には、実はもう一つの意味があるのではないかと思うのです。
たしか、アランの「幸福論」の一節だったと思うのですが、こんな逸話が掲載されています。（手元に原典が無いのでウロ覚えですが・・・）
ある村に、夜な夜な正体不明の怪物が現れ、子供を食べるなどの被害が出ていた。村人たちは、とても忌み恐れていたが、ある時、その怪物を「ライオン」と呼んだ途端に、その正体不明の怪物は、ただのライオンになってしまった。
この逸話の示唆するところは、”正体不明の怪物”と恐れている間は対処法もなく震えて過ごすしかないものを、ひとたび名前を付けて定義してしまえば対策を考える余裕が生まれる、ということだろうと僕は解釈しています。つまり、「狼人間を撃つ銀の弾はない」という言葉は、「銀の弾が無いから地道に頑張れ」ということと同時に、「とはいえ、狼人間だと分かっちゃえば（恐ろしい怪物には違いないものの）対策も考えられるよね」ということなんじゃないかなと思うのです。
それでは、次回は、その「第16章：銀の弾などない」を読み解いていきたいと思います。
連載記事一覧は、コチラの最下段から
第2回：銀の弾は無いけど、”銃”はあるよね｜本気で読み解く”人月の神話”（第16章）
TAG : Strategy & Art | ギックスの本棚 | 人月の神話
目次
すっごい武器はないが、まぁまぁ効く武器は結構ありそう。
人月の神話【20周年増訂 新装版】
だれにも読まれていない（あるいは、読んでも実践されていない）ソフトウェア開発者のバイブル「人月の神話」を読み解くこのシリーズですが、僕が最も思い入れのある章から、ガチ読み解きを始めていきたいと思います。「第16章：銀の弾などない －ソフトウェアエンジニアリングの本質と偶有的事項」です。
連載記事一覧は、コチラの最下段から
銀の弾とは何か
「銀の弾などない」という章タイトルの意図するところは、この一文を読んでいただけると良くわかると思います。引用します。
民話の中の悪夢に登場する怪物のうちでも狼人間ほど恐ろしいものはない。というのも、狼人間は慣れ親しんでいるものを不意に恐怖に変えてしまうからだ。だから、私たちはこの狼人間を魔法のように鎮めることができる銀の弾を探し求める。
この一説は、本書のメインテーマである「システム開発」の話として、以下のように続けられます。
慣れ親しんだソフトウェアプロジェクトにもこうした性質が若干あり（中略）ふだんは無害でまともなのだが、スケジュールの遅延、膨れ上がった予算、そして欠陥製品と知った怪物にもなりえる。そして私たちは銀の弾、すなわちコンピュータハードウェアのコストと同じようにソフトウェアのコストも急激に小さくしてくれる特効薬を求める必死の叫び声を聞くのである。
では、どうするべきなのか？＝まずは「むずかしさ」を理解しよう
それでは、いったい、どうしたら良いのでしょうか？そのために、著者は「むずかしさ」を理解することから始めるべきだと提言します。
ソフトウェア開発のむずかしさ
ソフトウェア開発における「むずかしさ」は、本質的なものと偶有的なものに分けられる、とブルックス氏は述べます。
本質的なむずかしさとは、ソフトウェア開発に固有のものです。具体的には「複雑性（ややこしい）」「同調性（他と合わせる必要がある）」「可変性（常に変化することが求められる）」「不可視性（リアルなものとして捉えられない）」の４つが挙げられます。
一方、偶有的なむずかしさとは、事象としては実際に難しいものの、別にソフトウェア開発だから難しいってわけではない、というような事象です。これは、ソフトウェア開発の歴史の中で、少しずつ解決されてきました。（もちろん、この”偶有的むずかしさ”さえも、まだ完全に解決していないが故に「銀の弾がない」という結論に至っているわけですが）
その解決の歴史として「高水準言語（機械語からの脱却による”概念”の世界でのプログラミングの実現）」「タイムシェアリング（リアルタイム処理による”思考を妨げない”）」「統一されたプログラミング環境（統合ライブラリ等によって”概念構造体”としてプログラムを捉えることができるようになった）」という3つについて述べられます。
しかし、高水準言語は”言語に対する習熟”が必要になることがボトルネックであり、また、タイムシェアリングも”応答速度が人の知覚可能な領域を超えた”後には更なる改善機会としては存在し得なくなったと指摘されます。
最後の砦「統一されたプログラミング環境」が銀の弾の可能性を秘めている（かもしれない）わけです。というわけで、後半は、統合プログラミング環境についてのお話となります・・・となるのが筋が良いストーリーだと思うのですが、実際には、この後「上記全部をひっくるめた、現在（といっても、1980年代半ば）時点で研究が進んでいる『銀の弾の”種”』」についての議論になります。（なんでやねん。）
プログラミング環境の変化に伴う「改善」
（当時の）技術動向については、9つのトピックが取り上げられます。
最初に取り上げられるのは、Adaを含む高水準言語についてです。Adaは「エイダ」と読みます。僕は使ったことが無いのですが、少なくとも1980年代には重要な役割を持っていたプログラミング言語です。しかし、これも先述した「偶有的困難」の一部を解決することしかできませんので、銀の弾とは言えません。
続いては、オブジェクト指向プログラミングです。モジュール化によって再利用性が高まるなどの強みはありますが、これも「偶有的困難」の排除に留まると断じられます。
3つ目は人工知能です。人工知能は「人間の知能によってのみ解決できる問題を解決する」ものと「推論エンジン・ルールベース」を持つものに分けられる、と定義した上で、まずは、その前者の話をしています。これには非常に大きな可能性はあるものの「個別の問題特有の機能」になってしまうので、普遍的に活用することが困難だと結論づけられます。
4つ目は、先ほどの人工知能の区分のうち、後者すなわち推論エンジン・ルールベースのもの＝エキスパートシステムです。これは、非常に有効だとしつつも、その設計・構築に際して「推論」「ルール」をしっかりと定義できる人材（その業務領域の専門家）が必要になることが課題とされます。（要は、誰にでも作れるものではない）
5つ目は、自動プログラミングです。プログラムの自動生成によって、いろんな困難は回避できるが、「シンプルな機能群」ならば実現できても、「複雑な機能群」は自動では作れないだろうと著者は述べます。
6つ目は、ビジュアルプログラミングです。これについては、「そもそも見えない（不可視）プログラムを、ビジュアルで表現するのには無理がある」ということで、割りとあっさりと可能性を否定します。
7つ目は、プログラム検証ということで「システムデザインの段階で、バグをつぶしこむ」という技法について語られます。ただ、この技法の最大の弱点は「プログラムと仕様書が整合している」ということしか検証できないために、「仕様書そのものが間違っている」というリスクを潰しこめないことです。
8つ目は、環境とツールです。これについては、「生産性と信頼性の両方においてきっと成果をもたらすだろう。しかし本来の性質から言って、今後の見返りはあまり期待できないはずだ」とバッサリ切り捨てます。（僕の理解としては、「情報の”最新状態”が常に共有されるということは”画期的”ではあるが、”本質的な解決”にはなりえない」ということだと思います。）
最後＝9つ目は、ワークステーションです。ワークステーションのスペックは飛躍的に向上し続けています。これによって生産性は間違いなく上がります。しかし、1980年代当時でさえも、既に「人間の思考」を妨げないレベルに到達してしまっていましたので、そこから先に「スペックが高くなったから、プログラミングの生産性が上がった」ということにはならないだろうというのが、著者の見解です。
つまり、現在進行形（我々からすると、過去進行形ですが・・・）の技術を見ても、改善にはつながるだろうが、銀の弾として魔法のような効果はもたらし得ない、ということです。
では、どうしろっていうのよ！？
じゃぁ、どうすれば良いのさ？というお話になりますよね。著者の答えはシンプルです。
「本質的な課題に向き合おうぜ。以上。」
・・・お、おぅよ。って感じですね。（笑）ちょっと分かりにくい日本語なのですが、引用します。
仮に作業の中でコンセプト部分そのものに現在一番時間がかかっているのならば、単にコンセプトを表現するだけの部分にいくら労力を割いても生産性を大きく向上させることはできない。
直訳感がありますよね。（笑）これは、「私は、作業工程の中で”コンセプト策定”に一番時間がかかっていると思っている。そうだとすると、既に策定されたコンセプトを”表現する＝プログラムという成果物にする”ところをどうこうしても、全体としての生産性は上がらないよね」ということだと僕は理解しています。
もっと平たく言えば「コンセプトを策定するところ（正確には、概念構造体を定式的に定義するところ）を改善しようぜ」ということです。
”コンセプトの本質”への攻略
それを、「コンセプトの本質への攻略」と呼んで、4つのアプローチを提唱します。
それは、
自分で作らないで、できてるものを買えばいいんじゃないか？
要件を定義するのがメチャメチャ難しい上に、メチャメチャ重要なんだから、仕様を決めきって作るんじゃなくて、プロトタイプ作成と仕様作成を往復しながら進めるべきなんじゃないの？
システムを「構築する」のをやめて「育成する」ことにしたらどう？とりあえず動くものを作ってから、ちょっとずつ機能拡張していこうよ。
デザイナーを育てませんか？結局、画期的なソフトウェアって、少人数の天才がつくるもんだから、そういう”天才的な人”を育てるしかないよ。
という4つです。（下図に、もう少し詳しく本書の記述内容をまとめておきました。）
ちょっと余談ですが・・・
本筋からは少し外れますが、少し余談を。下記の一説をご一読ください。
ソフトウェア制作者が顧客のために行う最も重要な仕事は、製品の要件を繰り返し抽出し、洗練していくことだ。実際のところ、顧客自身何を希望しているのか分かっていないものだ。彼らは通常、どんな質問に答えなくてはならないかを理解しておらず、指定しなければならない問題の詳細さについて考えたことなどほとんどない。「これまでの人がやっていた情報処理作業と同じように動く新しいソフトウェアシステムを作ってくれ」という単純な答えでは、実際まさしく単純すぎる。顧客は、正確にそれを望んでいるのではない。
この一文は、多くのソフトウェア制作者が感じていることでしょう。しかし、結局のところ、皆、文句を言うばかりで、それを自ら解決しようとはしないわけです。つまり「要件を決めるのは誰か」というところに関して、大きな誤解があるのです。「要件を出す」のは顧客、「要件を出し切らせて整理する」のは製作者、「整理された要件を承認する」のは顧客、であるべきです。
このあたりに、そもそもの「ソフトウェア開発に潜む深遠なる闇」の一端が見え隠れすると思うんですよね。いや、ほんとに。
そして、提言へ
さて、ここまでの一連の流れを踏まえたうえで、本章の冒頭に述べられる「提言」（すなわち、上述した「”本質へのアプローチ”の要約に相当するわけですが）を読むと、非常に含蓄深く感じられるはずです。
購入できるものを敢えて構築しないようにするためのマスマーケット（市販製品）の利用ソフトウェア要件の確率に際し、開発反復計画の一部として、ラピッド（迅速な）プロトタイピングを使用すること実行と使用とテストが行われるにつれて、より多くの機能をシステムに追加しながら、ソフトウェアを有機的（系統的）に成長させること若い世代の素晴らしいコンセプトデザイナーを発掘し、育てること
深いなぁ、、、。ただ、冒頭に、これだけを読んでも、ピンとこないと思うんですよ。一方、この流れの中で理解を進めると、なるほどなと肚落ちしませんかね？というわけで、非常にしっくりきたところ（え、僕だけ？）で、第16章の読み込みは終了です。
次回は、【第17章「銀の弾などない」再発射】を読み解きます。
第4回：再利用って口で言うほど簡単じゃないんだよね｜本気で読み解く”人月の神話”（第17章：後半）
TAG : Strategy & Art | ギックスの本棚 | 人月の神話
目次
見解は変わらない（だって、正しいこと言ってたもーん）
前回に引き続き、第17章「『銀の弾などない』再発射」を読み解きます。17章の前半では、色んな人からの”突込み”に対して全力で”突っ込み返し”ていたブルックス氏ですが、今回ご紹介する後半部分では、オブジェクト指向および、それに関連するモジュールの再利用性について語ります。
連載記事一覧は、コチラの最下段から
オブジェクト指向も、銀の弾ではなかった
オブジェクト指向を捉える際に、4つの見方がある、とブルックス氏は説きます。それは、
モジュール性（きれいなインターフェース）
カプセル化（内部構造を隠す）
継承（クラスの階層構造と、仮想関数）
強い抽象データ型
です。ただ、これらの特徴は、オブジェクト指向の登場以前から存在していたものであると指摘した上で、「それらすべて」を同時に享受できることが特徴なのだと述べます。
高まる期待と、それに反する緩やかな発展・浸透
そういう意味で、オブジェクト指向は、高い期待をもって迎えられたわけです。しかし、その期待に応えることはできませんでした。なぜか？
期待されていたのは「デザインの原則を与えること」だった
オブジェクト指向について本書で語られる期待は、一言でいうと「大きなレベルで”モジュール化”（あるいはカプセル化）すること」だと僕は理解しています。
これは、”高度な抽象化”という表現がされます。そして、その高度な抽象化の目指すところは、オブジェクト指向をデザインの一つの種類だと定義して、プログラマにデザインの原則を与えるべきだったと述べられます。
オブジェクト指向の目指すところに関する解説は別の機会に譲りますが、この”高度な抽象化”によって、ソフトウェア開発の”本質的なむずかしさ”から開発者を解放することを狙っていたわけです。
実際には、「特定ツールの使用」の励行にとどまった
しかしながら、その期待は達成されませんでした。その原因として、本書ではデービット・パルナスの言葉を引用しています
答えは簡単だ。それは［オブジェクト指向が］、いろいろな複雑な言語に結び付けられてきたからだ。（中略）オブジェクト指向が特定のツールを使用することであると教育してしまった。どんなツールを使っても、優れたプログラムも書ければ、まずいプログラムも書ける。
デザインするための思考法・考え方として理解されるべきオブジェクト指向が、特定の言語・ツールを使ってプログラミングすることだと誤って理解されてしまったのでは、ソフトウェア開発者を「本質的なむずかしさ」から解放することができないのも自明です。
「先行投資」をするという意思決定は難しい
また、仮に「デザインのための思考法だ」と理解したとしても、オブジェクト指向が、開発プロセスにおける真の価値貢献をするためには、大きな壁があるとブルックス氏は述べます。
投資家なら、予想はされるが後の不確かな利益のため事前にお金をかけることは日ごろからやっている。しかし、多くのプログラミング会社・団体の経営者・管理者にとって、これは真の勇気を必要とする。（中略）コストの事前投資と据え置かれる利益の両極端さこそ、オブジェクト指向テクニックの採用を遅らせている唯一最大の要因であると私は思う。
オブジェクト指向は、再利用されることによってこそ、その価値が出ます。（この再利用には、カスタマイズも含まれます。）しかし、それが発揮されるのは「最初の開発時」ということはありえません。「後継ソフトウェアの開発」（あるいは、「開発済みソフトウェアのメンテナンス」）のタイミングにならないと、再利用のメリットはでにくいのです。
つまり、「いま、目の前では収穫できない果実を、いま、目の前の手持ち資金で植えることができるか？」という判断になりますので、上の引用文のとおり、投資の概念と近くなります。さらに、事態をさらに複雑にしているのは、（特にシステム開発の場合）メンテナンスや後継システムの開発をしたりするのが”自社じゃないかもしれない”ということです。果実はきっと実るのでしょうが、誰が刈り取ることになるのかわからない、ということになるわけです。（まぁ、”業界全体で、順繰りに果実を刈り取っているのだ”と割り切れればいいんでしょうけどね・・・）
結局、再利用されないんだよね・・・
そんなわけで、「再利用性」が最大限に活用されることは少ないのですが、プログラマ「個人」の世界では、再利用が盛んに行われます。
経験豊かなプログラマのほとんどは、私的プログラムライブラリを持っていて、開発しているソフトウェア全体の約30パーセントにその際利用コードを使っている。
しかし、それは、あくまでも「個人」の世界に留まります。
私たちは、再利用を妨げているものは、生産者側の問題ではなく、消費者側にあると推測している。ソフトウェアエンジニア、つまり標準化されたソフトウェアコンポーネントの潜在的消費者が、自分のニーズに合ったコンポーネントを見つけ、それを検証するコストが、新たにコンポーネントを書くよりも高くつきそうだと認める場合、そっくり同じ新しいコンポーネントが書かれることになるだろう。注意してもらいたいのは上で私が「認める」と言ったことである。再構築に実際かかるコストがどれくらいかは、問題ではないのだ。
要は、「探すのが面倒だ」と思ったら、「自分で書く」ということです。（プログラマという人種を一人でもしっていたら「奴ならありえるな」と思いませんか？）ということは、普通にやっていては”企業レベルの再利用性は、なかなか高まりにくい”ということになります。
どうすれば、再利用されるのか
では、いったいどうすれば”企業レベルの再利用性”を高められるのでしょう。
本書内に「企業レベルでは、全体の75パーセントの再利用を目指しており、特殊なライブラリと管理サポートを必要としている」という記述があります。75%って、相当な割合ですよね。そのためには何をしたらよいのか。本書では「優れたデザイン」と「非常に優秀な文書」が鍵だと述べられます。
しかしながら、その要件を満たし、再利用性が十分に高いものを作ろうとすると、「1回限りのコンポーネントの2~3倍の労力がかかる」とも言われます。それは、本書の第1章でかたられる「プログラムをプログラミング製品にするための労力＝3倍」と同じです。そのむずかしさの一端を示す一文を引用します。
一般性のため必要なものがなんであるかを事前に予測するのは難しい（中略）ユーザーインターフェースに関する自分自身のライブラリを使用するのが五度目にもなったというのに、修正が必要な状況が続くのだ
いやはや、何とも難しい。
「高水準言語」ゆえの、再利用のむずかしさ
さらに、高水準言語であるがゆえの、プログラム再利用に関する困難性がある、とブルックス氏は述べます。そもそも、高水準言語の特徴として
高水準言語になるほど、その語彙は多く、構文（シンタックス）は複雑に、また語義（セマンティクス）は豊富になる
再利用性を高めようとすると、「再利用できるもの（ことば）」を沢山つくる、すなわち”語彙が増える”ことになります。そして、再利用性が高いということは「再利用するシーンの幅が広い」ということですので”語義が豊富になる”ということを意味します。さらに、そのような複雑な情報を記述するためには”構文が複雑になる”わけです。
そうすると、問題はソフトウェア開発の域を超え、言語習得の領域に踏み込んでいくことになります。それに関して、3つの教訓を例示してくれていますが、まだまだたくさんの課題が潜んでいるのは言うまでもありません。そりゃぁ、再利用するの難しいですよね。
人々は文脈の中で学んでいくので、部品ライブラリだけではなく、構成した製品の実例をたくさん公表する必要がある。人々は綴り以外暗記しない。構文と語義は、文脈の中で使用しながら少しずつ学んでいく。人々は構文クラスによって語構成規則をグループ化するのであって、互換性のあるオブジェクトのサブセットによるのではない。
「見解は変わらない」
そして、本章（すなわち、本論文）の締めは、「解決策についての要点 －見解は変わらない」という見出しで締めくくられます。
R・L・グラスは（中略）私の1995年時点の見解を正確に要約してくれている。
ということで、前回述べたような「いろんな反論」は、解決策が身近にあると考えていた人たちによるものに過ぎず、現実的な観点に立てば、これは非常に妥当なのだ、ということで締めくくるわけですね。非常なる自信に満ち溢れていますね。（笑
以上、第17章は「反論への反論」という体で進められましたが、読み手としては「第16章の補足」だという位置付けで読むべきでしょう。
色んな人の批判は的外れであり、折角のオブジェクト指向によるモジュール化・カプセル化も”再利用性”という意味では殆ど活用されない状況であることを踏まえれば、銀の弾は相変わらず存在しないと言わざるを得ない。結局のところ、行うべき”本質へのアプローチ”は、9年前に述べた通り「マスプロダクトの活用」「ラピッドプロトタイピングの実施」「インクリメンタルな開発」「デザイナーの育成」しかない、という「見解は変わらない」というわけですね。
さて、ここまでの4回（＋1回）の連載で、「”人月の神話”の全体像」と「”銀の弾などない”の概略」をご理解いただけたことと思います。この次は「19章：『人月の神話』から20年を経て」で、（”銀の弾などない”ではなく）”人間の神話”を、（他人からの批判ではなく）自己批判の精神で著者自身が振り返ってくれますので、そちらをしっかりと読み解いて”人月の神話”に対する理解を深めていきましょう。
連載記事一覧は、コチラの最下段から
第5回：やっぱり、人と月とは交換できないのだ｜本気で読み解く”人月の神話”（第19章）
TAG : Strategy & Art | ギックスの本棚 | 人月の神話
目次
20年たっても結論は変わらない
人月の神話【20周年増訂 新装版】
前回までに、18章（1-15章の総まとめ）→16章（銀の弾などないのだ！という主張）→17章（銀の弾はやっぱりないのだ！という主張）を読み解いてきました。今回は、19章「『人月の神話』から20年を経て」です。
連載記事一覧は、コチラの最下段から
ブルックス氏、自己反省をする の巻
前回（第4回）の末尾でも述べた通り、この章は「人月の神話」を書いてから20年を経て、「人月の神話の、何が正しくて何が正しくなかったのかを明確にしよう」という、ブルックス氏の自己反省です。
すさまじくザックリと要旨をまとめると、下図のようになります。
正しかったのは、
コンセプトの完全性が成功の鍵であること
その、コンセプトをしっかりと構築するために、アーキテクトを任命し、アーキテクチャとインプリメンテーションを分離すること
セカンドシステム症候群、すなわち、「後継システムの開発」には、大きなリスクがあること
そして、もっとも重要な命題である「人月の神話」は、やはり神話であったこと
が挙げられます。
一方、自己反省として、正しくなかったこととして挙げられるのは
一つは捨石にする、という発想（前提としていたウォーターフォール型開発そのものに限界があったため）
情報公開・共有こそ是である、という考え方（カプセル化は非常に有効だと分かったため）
です。
また、20年間で大きく状況を変化させたのは、以下の2つの出来事だと述べられます。
マイクロコンピュータ（いわゆる、パソコン）が普及して、”偶有的困難”を大幅に減らした
パッケージソフトが普及して、極力「自分で作らない」ことが可能となった
そりゃそうですよね。って感じです。
人月の神話は、やはり”神話”だった
このうち、コンセプトの完全性等については、1章~15章の解説の中で触れていきますが、本書まるまる一冊の大命題であり、大前提である「人月の神話」については、ここで詳細にみておきましょう。
バリー・ベームの研究
ブルックス氏は、バリー・ベームの研究を引用し、以下のような発見を取り上げます。
ベームの結果は、要員と月数の間のトレードオフは線形どころではなく、人月は生産性の尺度としては実に神話的だとする『人月の神話』の主張を、強固に立証している。中でも、彼が発見した次のことは注目に値する。
さらに、新たな要員を追加すると、キャッチアップに数週間の時間を要することから、「要員を追加しても、納期短縮にはつながらない」と述べます。もちろん、「遅延しているプロジェクトにさらに要員を追加することは、つねにコストがより高くつくことにはなるが、完了をつねに遅らせるわけではない」という話は持ち出すものの、そのためには「プロジェクトの初期段階で要員を追加するべき」と述べています。
結局のところ、人と月は交換可能ではない、というブルックスの説は、20年たっても何ら色あせることがない真理だということです。
カプセル化は、正解だ
ブルックス氏の自己反省における、「漸増的（インクリメンタル）な開発が理想だ」という話は、16章「銀の弾などない」や、17章「銀の弾などない 再発射」で熱く語られていますので一旦良しとして、ここでは、「情報隠匿は罪だ」と考えていたことへの反省の話をしたいと思います。
まずは、その「間違っていた、と自己反省した箇所」を第7章より引用します。
カーネギー・メロン大学のD・L・パルナス（中略）の主張では、プログラマは自分の担当以外のシステム部分の開発に関する詳細にさらされるより遮断されている方が効率的だと言う。ここでは、すべてのインターフェースが完全かつ正確に定義されていることを前提にしている。そういうデザインはまさしく理論的だが、完璧な完成品に依存する点で、失敗のレシピだと言える。優れた情報システムは、インターフェースエラーをさらけ出して、その修正を促すものなのだ。
これですね。「失敗のレシピだと言える」と言い切ってしまったのだけど、ごめんなさい・・・というわけです。素直ですね、ブルックスさん。その上で「モジュールに関する情報隠匿の定義＝オブジェクト指向の考え方」は、以下の3段階を経て発展してきたと解説します。
モジュールを、独自のデータモデルおよび演算一式を備えたソフトウェア実体（エンティティ）と定義し、データは適切な操作を介してのみアクセスできる＝パルナスの提唱した”情報の隠匿”
当該モジュールを「抽象データ型」に格上げし、この抽象データ型からたくさんのオブジェクトを派生させた
「継承」による、クラスの階層化を実現
このうち、オブジェクト指向は「第一段階」すなわち、パルナスが提唱したことである、として、自らの過ちを認めています。
要は、16章・17章での主題が「オブジェクト指向」だったことを踏まえて、オブジェクト指向の”知的先祖”とも言うべきパルナスの思想は素晴らしい、と評価したのでしょうね。
2つの大きな変化
20年間で起こった大きな変化としてあげられた「PCの普及」「パッケージソフトの普及」ですが、前者については、既に人間の知覚を超えるレベルまで進化した事を踏まえると、今後の影響は（まぁ、小さくはないでしょうが、相対的に）大きくないと理解し、割愛します。一方、後者は、まさに「本質的困難」を打破する非常に意味のある一手であり、また、ひとつの”思想”として強く認識すべきものですので、少し読み解きをしていきたいと思います。
パッケージソフトの意義
パッケージソフトは、すでにテストされており、詳細なドキュメントが添付された上に、完全に「情報隠匿」もなされています。再利用性という意味で「完璧」です。「つくらなくていいものは、つくらない」「すでにあるものは、そのままつかう」という基本思想に基づけば、パッケージソフトこそ、生産性向上の鍵です。
もちろん、パッケージソフトを買ってきて、それですべて解決、ということにはなりません。その場合・・・
特に見込みのある方向は、マスマーケットパッケージをプラットフォームとして使用して、もっと機能豊富でよりカスタム化された製品を構築することだ。
ということになります。これは、実際に、弊社（株式会社ギックス）が提供する、データビジュアライズサービス”graffe/グラーフ”の構築に際して用いた考え方です。既存のプラットフォームを環境として使い、それを活用して「自社のサービス（あるいは、ソリューションと言うべきかもしれませんが）」を組み立てるわけです。
この「パッケージを使って構築する」ということは、非常に有効です。引用します。
現在、パッケージを使って構築するという現象が平均的な情報システム管理制御プログラマに大きな影響を及ぼしていないため、ソフトウェアエンジニアリング分野ではまだあまり目立っていない。そうはいっても、これは概念構造体を作り上げることの本質を攻略するものだから、急速に成長していくことだろう。パッケージソフトは緻密だが厳密なインターフェースを持った関数の大きなモジュールを提供するので、その内部の概念構造体をデザインする必要が無い。（中略）よって次のレベルのアプリケーションを構築する人は、豊富な機能やテスト済みコンポーネント、優れた文書が手に入り、短い期間で開発ができ、コストは極端に抑えられる。
当時（1995年）の時点では、まだパッケージ活用が十分ではなかったのかもしれませんが、現在は、かなりのパッケージソフト、および、パッケージ化されたプラットフォームが提供されています。さらに、それらの多くは、クラウド環境で提供されており、容易に活用できます。（例えば、最近、テレビCMとかでやっているIBM Blueｍixなんかは、バッチリそんな感じですよね。） →関連記事：IBM Bluemix 経由で Watsonを使ってみる
尚、このパッケージソフトウェアの利用者は、４つのレベルに分けられるとブルックス氏は主張します。要約します。
そのままの利用者：アプリケーションの提供する機能・インターフェースをそのまま使う人
メタプログラマ：提供されたインターフェースを利用しつつ、エンドユーザーの利便性向上のために関数などを作る人
外部機能作成者：アプリケーションに、手作りで機能を追加する高度な技術を持つ人
メタプログラマその２：複数のアプリをシステムコンポーネントとして活用する人
上の3つは分かりやすいですが、最後の1つはなかなか複雑です。ブルックス氏は、この最後の利用者のニーズは殆ど満たされていないとした上で、以下のように述べます。
最後に挙げた利用者にとって、パッケージアプリケーションには補足的な文書作成が為されているインターフェース、すなわちメタプログラミングインターフェース（MPI）が必要である。このインターフェースにはいくつかの能力を必要とする。まず、メタプログラムはアプリケーション群全体をコントロールする必要があるのに対し、通常のアプリケーションではそれぞれが自分でコントロールするものと想定されている。
このあたりに解決策が提示されてくると、より一層「パッケージソフトの活用」が進み、生産性が向上していくというわけですね。僕は、最近の動向に詳しくないので、この辺りは弊社の別メンバーに解説記事を書いてもらいたいと思います。
ソフトウェアエンジニアリングの将来
20年を経てもなお、ソフトウェアエンジニアリングの置かれた状況は（ほとんど）変わらないとブルックス氏は締めくくります。
結局のところ、ソフトウェアエンジニアリングは、化学工学と同様に、産業規模の工程に規模拡大させるという非線形問題に関心があり、また、経営工学同様に、人間の行動の複雑性によって永久的に混乱させられるものなのである。
ソフトウェアエンジニアリングに特有な問題は、現在でもまさしく（田中注：20年前に）第1章（田中注：「タールの沼」のこと）で述べたことである。再び述べておこう。
この結びの一文を読むと、ソフトウェア開発とは決して、スキルだけで解決するものではなく、”正しい思想”によってのみ解決されるのかもしれないなと感じます。
もはや、完全に「哲学」の領域に突入しているなぁとは思いつつ、これこそが「ソフトウェア開発のむずかしさの”真理”」を言い表していることにも気づかされます。まぁ、20年も一つの事象（ソフトウェア開発）を研究し続けていれば、そりゃぁ哲学的にもなりますよね。本書を理解するということは、ブルックス氏の”精神世界”を理解することなのかもしれません。
これまでの連載（第0回から第5回）は「人月の神話」の概略および、その後の情報更新に関しての読み解きでした。ここまで読んでいただけば、本書の7割は理解したと言っていただいて大丈夫だと思います。さらに、書籍を購入して18章をしっかりと読んでいただけば「本書の90%を理解した」と胸を張って言って良いと思います。
当初は、この後、第1章に立ち戻って、第15章まで順に読み解きを進めていこうと思っていたのですが、先ほど述べた”精神世界”をより理解するために、すこし回り道をしたいと思います。それは「エピローグ：50年間の不思議、興奮、それに喜び（2ページ）」および「訳語について（2ページ）」「訳者あとがき（7ページ）」の読み解きです。特に、訳語および訳者あとがきは、正直言って、読みやすいとは言い難い本書の翻訳にあたり、どういう苦労があったのかを窺い知ることができますので、そこにスポットライトを当てたうえで、本編（1章~15章）の解説へと進みたいと思っています。お付き合いのほど、よろしくお願いします。
→第6回：エピローグ／訳者あとがき
連載記事一覧は、コチラの最下段から
第6回：”翻訳する”ということにも、本質的なむずかしさがある｜本気で読み解く”人月の神話”（エピローグ／訳語について／訳者あとがき）
TAG : Strategy & Art | ギックスの本棚 | 人月の神話
目次
”翻訳”とは、”創作活動”である
人月の神話【20周年増訂 新装版】
本日は、普通ならあまり解説されないであろう「エピローグ」「訳者あとがき」を読み解いていきたいと思います。ただでさえ田山花袋の「蒲団」並に読まれていない「人月の神話」の、「エピローグ」や「訳者あとがき」まで真面目に読んでいる人は、指輪物語（およびホビットの冒険）の世界の神話の時代を描いた「シルマリルの物語*」を読んでいる人ぐらいレアな存在だろうと思います。
*日本の歴史でいえば「日本書紀」だと思ってください。
連載記事一覧は、コチラの最下段から
エピローグはたった1.5ページ
この300ページにわたる（読みにくい）長編のエピローグは、たったの1.5ページ（正確には、1.3ページくらい）です。行数にして39行。約1,300文字くらいです。もはや全文引用してもいいくらいですが、それではさすがに芸が無いので、とりあえず要点を括りだしておきます。
13歳の時（1944年）に Harvard Mark I というコンピュータに対する記事を読んで、非常な驚きを得た
その後、10代のIBMでのアルバイト経験（プログラミング講習）を経て、ハーバード大学に学び、ソフトウェア開発の研究に没頭した
テクノロジーの進歩を目の当たりにしながら、自分自身が、スーパーコンピュータの開発に関与した
時代は流れ、当時開発したスーパーコンピュータよりも何倍も高性能で、1000分の1の価格の”パソコン”が簡単に入手できるようになった
その技術革新と同様に、コンピュータ関連の知的分野も、爆発的進化を遂げた
情報量は非常に増え、すべてを網羅して知ることは不可能になってきた
それは、悲しむべきことではなく、未来に向けて進歩する可能性が無限にあることを意味する。喜ばしいことだ
という感じですね。
ソフトウェア開発、ソフトウェアエンジニアリングの本質的困難を奇跡のように解決する「銀の弾」は無いにせよ、今後の進歩に「可能性」を託しているわけですね。
訳語に関する解説
ここからは、訳者の努力の痕跡を追っていきたいと思います。まずは「訳語」に関する解説です。すさまじくザックリ解説しておきます。
アーキテクチャ：ソフトウェアの基本設計。外部設計局面＝業務要件と理解すればよいと思われる
インプリメンテーション：内部設計局面。すなわち”仕様”決定≒システム要件の決定
実現（リアライゼーション）：プログラミング局面。
アーキテクト：アーキテクチャを設計する人。ソフトウェアの基本設計を”デザイン”する人
実現者・制作者：インプリメンテーションを担当する人、プログラミングを担当する人。（明確な切れ目が無い？）
というあたりですね。
最後にあげた、実現者・制作者については、この章の説明文を読んでも、正確な定義がわかりません。このあたり、「翻訳時には、めちゃめちゃ苦労したんだろうな」と思いますが、読者が混乱するのも仕方ないなと思ってしまいます。（引用しておきます）
ブルックスは、文脈によってはアーキテクト以外という意味でインプリメンテンターやビルダーという言葉を使っている。インプリメンテーション担当者、プログラミング担当者、あるいは製品組み立て担当者のことで、本訳書では文脈に応じて実現者あるいは製作者などという訳語をあてた。
ということなのですが、「実現＝リアライゼーション」と定義しておいて、「インプリメンテーション担当者」を「実現者」と訳したら混乱するよな、という感じです。まぁ、そもそも、ブルックス氏が、「アーキテクト以外」をひとくくりにしているので仕方ない、というのも分からなくはないのですが・・・
訳者あとがき
と、エピローグ、訳語解説と来たわけですが、いよいよ今回のメインディッシュ「訳者あとがき」です。まぁ、お定まりの”謝辞”は飛ばしまして、”編集後記”を読み解いていきたいと思います。僕は「この本は読みにくい」と連呼してますが、訳者の皆さんが、相当苦労されたであろうことは、想像に難くないのです。
”普遍性”の3つの理由
訳者（の、富澤氏）は、「人月の神話」が20年経過した今も、まったく色あせることなく「そのまま実情に当てはまる」ことについて、3つの理由を挙げています。
優れた組織論であるために、色あせない。例え、組織の在り方が変わったとしても、組織運営をしていく上でのむずかしさは、本書が述べているものと同じである。
ソフトウェア構築が、非常に”人間的な創作活動”であるためにいつの時代の、どんな物事にも適用できる。プログラミングは、創作活動の中でも”常に変化する”ことを前提とする必要があり、柔軟性が求められるものなので、さらにむずかしくなっている。
パーソナルコンピュータの普及により、コンピュータの”利用者”が圧倒的に増えたことで、本書を必要とする人が増大した。利用者は専門家ではなく、一般ユーザーのため、迷わないための指針が必要であり、その役目を果たすことができるのは本書だけだ。
この3つは、非常にリーズナブルに思えます。特に二つ目の「人間的な創作活動に対する”銀の弾”の模索だから普遍的なのだ」という観点は、非常にしっくりきます。僕はこの連載を書くために、人月の神話を再読し、微細な部分まで読み込んでいるわけですが、読めば読むほど「普遍性」に気づきます。富澤氏がひとつめにあげた組織運営に関して適用できるのは勿論のこと、戦略コンサルティング（あるいは、経営そのもの）の領域にも適用できます。（このあたりは、次回以降（1章~15章）の読み解きの中で、触れていきます。）
「訳者の思想」が翻訳を難しくしたのではないか
続いては、「本書の読みにくさ」の理由と思しき一節を引用します。
もともとブルックスの関心はトータルとしてのシステムの構築にあった。その本質を攻略する「銀の弾」はないが、それを攻略するための有望な方法を挙げている。例えば、パッケージソフトの利用であり、プロトタイプであり、漸増的なプログラム構築法である。（中略）
この「訳者の1人」というのは、滝沢徹氏のことだと思われます。（というのも、巻末の訳者略歴に3名のお名前が記載されていますが、男性は、滝沢氏と富澤氏だけなのです）
もちろん、できるだけ公正に・公平に翻訳するように取り組まれたのだと思うのですが、本書は最早”哲学書”の領域にたどり着いてしまっています。それを翻訳するにあたっては「原著の著者と、同じ哲学・同じ思想を持った訳者」でないと、うまく翻訳できないのではないか、と感じてしまいます。
レベルの全く違う話で恐縮ですが、僕も、IBM在籍中に、あるホワイトペーパーの日本語版の監修を任されたことがあります。その際、一旦、翻訳業者に「日本語」にしてもらった資料を読み込んで、意味が通るように一字一句残らず書き直す、という作業を行いました。そして、ほぼ原形をとどめないレベルまで書き直した結果を、英語が堪能な方に”原文と齟齬が無いか”という観点で確認してもらいました。何を言っているのかというと「創作活動に近い領域に踏み込まないと、本当の意味での”翻訳”なんてできない」ということです。それはつまり「日本語版のホワイトペーパーは、監訳者である僕個人の考え方・思想を反映したものになる」ということを意味します。
そうすると、著者と訳者に、なんらかの”思想の差”がある場合には、「訳者の意向に沿う内容に寄せていく」か、「正確性を重視して、もってまわった表現にする」ことになります。本書の場合、さすがに前者という選択肢はなかったでしょうから、後者を選択した結果「回りくどい表現が多い本」になったのだろうと考えられます。
その後、訳者あとがきは「錬金術」の話から、「貨幣価値に換算される成長」の話となり、それを支える金融システムは果たして”実体”をもつのか否かという命題に辿り着き、電子マネーという”実体のない貨幣”の登場が、貨幣に対する認識を変えるのかもしれない・・・というお話に展開されていきます。非常に面白い視点ではありますが、これもまた、「別の思想・哲学」の話ですね。
非常に賢い方が別の言語で書いた本を、別の非常に賢い方が違う言語に訳す、ということには、非常なる「むずかしさ」があるのだということをしみじみ感じます。そもそも、英語で書いてある本を英語で解説することも難しいでしょうし、日本語の本を日本語で解説することだって難しいのです。この部分は、まさに”偶有的ではない、本質的なむずかしさ”だと言えるでしょうね。（笑）
ということで、今回は、やや「おまけ」っぽい雰囲気が漂ってしまったように思いますが、次回からは、いよいよ、本編＝第1章~第15章の読み解きに入っていこうと思います。もう既に「第6回」ということで、いったい何回連載になるのか良くわかりませんが、懲りずにお付き合いいただけましたら幸いです。
第7回：「プログラムを書く」と「システムを作る」は別物だ｜本気で読み解く”人月の神話”（第1章「タールの沼」）
TAG : Strategy & Art | ギックスの本棚 | 人月の神話
目次
「システム製品」として納品するのは、死ぬほど大変
人月の神話【20周年増訂 新装版】
前回までは、16章以降の「全体概要」および「情報UPDATE」を読み解いてきましたが、今回からは、しっかりと「本編」に踏み込んでいきたいと思います。宜しくお願いします。
連載記事一覧は、コチラの最下段から
プログラムを「システム」「製品」にするのは大変なこと
プログラムをつくる、というと、ハリウッド映画などにでてくるような”天才プログラマー”がちゃちゃちゃっと作ってしまえば早そうに感じますよね。本書でも、それは一つの真実である、と述べます。
しかし、たいへん残念なことに、「プログラム」をつくることと「システム」をつくること、あるいは、「製品」をつくることは、絶望的なまでに別物です。
上図は、本書の内容を、ほぼそのまま転記しました。言葉でも解説しておきます。
プログラムを作る（左上）ことに比べて、プラグラム製品を作る（左下）ために投下すべきコストは3倍になる。【縦移動】
プログラムを作る（左上）ことに比べて、プログラミングシステムを作る（右上）ために投下すべきコストも、3倍になる。【横移動】
よって、プログラムを作る（左上）ことに比べて、プログラミングシステム製品を作る(右下）ために投下すべきコストは、3×3＝9倍となる。【縦＋横移動】
このうち【縦移動】は、「だれでもテスト・修正・拡張が可能なプログラム」を作ることを意味し、「多くの稼働環境で、多くのデータの組み合わせに対して使用することができる」ということが求められます。そのために、プログラムそのものが”一般的な作り方”で書かれていることが求められたり、プログラムのテストが”高い信頼性”を担保できるレベルまで実行されていなければならなかったり、さらには、十分な”文書”が添付されている必要があったりしますので、「3倍のコストがかかる」わけです。
一方、【横移動】は、そのプログラムが”単体”としての役割から、”コンポーネント”としての役割に脱皮することを意味します。そうすると、他のコンポーネントとの関係性の中で機能する必要があります。これは、「すべての入出力が的確に定義されたインターフェースを持つ構文（シンタックス）およびコマンドの語義（背マンティクス）に準拠するように書かれていなければならない」ということであり、また「メモリスペースや入出力装置、コンピュータ時間といったリソース（資源）を定められた量だけ使用するようにデザインされていなければならない」ということです。そうすると、他のコンポーネントとの結合テスト・統合テストが求められますので、これもまた「3倍のコストがかかる」こととなります。
右下の「プログラミングシステム製品」は、その両方を行わなければならないわけですので、まぁ、9倍のコストが必要というのも納得できます。
この、残酷なほどにコストがかかる「プログラミングシステム製品」の開発こそが、踏み出す方向を一歩間違っただけで、二度と身動きの取れない”タールの沼”です。決して、普通の「プログラムを作る」ということがタールの沼なわけじゃありませんので、そこのところは、ぜひ誤解なきよう！
プログラミングって楽しいの？苦しいの？
続く後半では、プログラミングという行為そのものの、楽しさと苦しさについて解説されます。まずは、ザックリ纏めたものをご覧いただきましょう。
「喜び」については、まぁ、上図の内容をご一読いただければ良いかなと思います。ここでは「苦しみ」の方に着目しておきましょう。
システムは、完璧につくらないと動きません。「一字一句間違ってはいけない」ということは、創作活動には適さない特性です。
目的やリソースは、多くの場合、”誰か”に勝手に決められています。これもまた、創作するという楽しみとは相反する制約です。
バグを潰しこむという作業も「単純労働」で、しかも、「永遠に終わらない作業」です。これは、ひとつめの「間違ってはいけない」というのと根源的には同じ問題ですが、「一見動いていてもダメ」というものを検知して潰しこむのは、なかなか精神的につかれる仕事です。
最後に、そこまでして作りこんでも、完成したときには「時代遅れになっている（と感じる）」というのは、非常に悲しい現実です。（システム開発のご経験が無い方は、車やパソコンを買った時にも「買った直後から、時代遅れ感」がでてくることを想像していただくと、イメージしやすいかなと思います。）
尚、この「作る苦しみ」は、自分が使うプログラムを書くときには、さして問題になりません。本稿の前半で述べた「システム」「製品」あるいは「システム製品」を作る際に、顕著に表れてきます。そして、それこそが、システム開発を「タールの沼」に変えてしまう最大の元凶なのかもしれませんね。
さて、次回は、不朽の名作である本書のタイトルと同じことばを章題に持つ「第二章：人月の神話」を解説します。どうぞお楽しみに。
第8回：人と月は交換可能ではない、という言葉も魔法の言葉じゃないよ｜本気で読み解く”人月の神話”（第2章「人月の神話」）
TAG : Strategy & Art | ギックスの本棚 | 人月の神話
目次
人と月の交換法則を語る前に、まずは「前提」を揃えよう
人月の神話【20周年増訂 新装版】
本日は、名著「人月の神話」の 第2章「人月の神話」を読み解きます。本のタイトルと同じ章題がつけられたこの章は、非常に重要な意味を持ちます。
連載記事一覧は、コチラの最下段から
人と月は交換可能なのか？と論じる前に・・・
ソフトウェア業界に限らず、今日でも、ありとあらゆる状況で使われる「人月」という単位。これは、人（人数）と月（時間）が交換可能であるという前提で用いられます。
要するに「20人月かかる仕事」というと、1人でやると20ヶ月、2人でやると10ヶ月、5人でやると4ヶ月、10人でやると2ヶ月、20人でやると1ヶ月かかる。ということを意味しています。
勘の良い方はお気づきだと思いますが、上記はつまり（1ヶ月の稼働が20日だとすると）「400人でやれば1日」と言っています。これって、現実的じゃないよね？と思うのが最初の一歩です。
大工さんを100人集めても、家は1日ではつくれない
もっと身近な具体例で考えてみましょう。「家を建てる」という場合に、100人日（5人月）かかるとしましょう。それを3人の大工さんで2ヶ月弱で作る、というのが一般的だとした場合に、100人連れていたら1日でできる、、、ハズがないですね。当たり前です。
ただ、勘違いしてはいけないのは、「人月の神話」の主題はそこにはない、ということです。
まずは、プロセスにわけて考えてから
ボトルネック、とか、クリティカルパスとか、そういう話が大前提としてあります。例えば「土台ができてからじゃないと、上に柱が立てられない」とかいうのはクリティカルパスの話です。「仕様が決まってから、資材が納品されるまでのリードタイムは一定以上に短縮できない」というのはボトルネックでしょうね。そもそも、「資材が全部いっぺんに届いても、作業スペースが無いから一度には作れない」みたいなのも”現実的な制約事項”として存在しますね。
これらを解決するのは「人と月が交換可能かどうか」とは別の話です。仕事（この場合は「家を建てる」）を”プロセス”に分解し、その順序・必要リードタイムを明確にしたうえで、それぞれのプロセス内で「人月」を算出することが最初の一歩です。
※プロセス分解については、関連記事もご参照ください
プロセスに砕いたとしても「人と月とは交換不可能」という話
上記のように、プロセスに分解したとしても「人月は交換可能ではない」というのが人月の神話のメインテーマです。こういう前提を揃えずに、金科玉条の如く「人と月は交換できないのだ！」とか言うのは、頭悪い感じがするので気を付けましょう。ほんとに。
ということで、ようやく本題です。お待たせしました！
目盛りに”数字”がないから分かりにくい
本章は、非常に良いことを言っているのですが、大変残念なことに「読者に優しくない」ので伝わらない、典型例だと思っています。
というのも、「図表の目盛りに数字（メジャー）が記入されていない」ことに加えて、「対比すべき複数のグラフが同一見開き内に無い（同じ紙の裏表に印刷されている）」という致命的な問題があります。アホかと。
こちらで、目盛り（メジャー）を追加して、横に並べてみました。これでメッセージがクリアに伝わると思います。
仕事の種類によって「交換できる度合い」が変わる
まず、明確に理解すべきは、仕事が「完全に分割可能」か「コミュニケーションをしながら、という前提で分割可能」か、が大きな分岐点であるということです。
完全に分割可能な仕事は、1人でやって10時間なら、10人でやって1時間です。例えば、封筒の宛名書きとかってそんな感じでしょうかね。あるいは、物流倉庫の仕分けとか。これは「完全に交換できる」と言えます。ここに分類される仕事には、いわゆる「単純作業」が多いです。（下図 左側）
一方、コミュニケーションが必要な場合は、1人でやって10時間を、10人でやっても2時間かかる、と考えてください。例えば、書店の新店オープン準備で売り物の本を並べる、とかはこの類かもしれません。もちろん、ある程度手順にはなっているでしょうが、「これは、このカテゴリで良いのか？」とか「新刊エリアと旧書エリアに重複配置すべきか」とかは、その場その場で考えないといけないでしょう。この時に、1人で10時間かかるものを、10人で1時間、ということにはなりません。相互に、どこまで進んだかを確認しながら、それは全体方針に沿っているのか、などをキチンと理解しながら進める必要があります。そうすると「ある程度は交換できるが、完全な交換はできない」ということになります。（下図 右側）
交換しようとすると、破綻するものもある
次に理解すべきは「交換しようとすると、とんでもないことになるタイプの仕事」があるということです。
言葉で説明するよりも、下図の右側をご覧いただいたほうが早いでしょう。
複雑な相互関連を持つ仕事の場合、一定人数を超えると「コミュニケーションにかかるコストが、人を追加したことによる分割効果を上回る（＝非効率になる）」ということです。本文より引用します。
ソフトウェア構築は、本来システム的な作業ー複雑な相互関係における作業の遂行ーであり、コミュニケーションを図るための労力は大きく、分担によってもたらされた各個人の作業時間短縮をすぐに上回ってしまう。だから、要員を追加することが、スケジュールを長引かすことはあっても、短くすることは無いのである。
「要員を追加することが、スケジュールを長引かすことはあっても、短くすることは無いのである」。なんか、もう、ごめんなさいしか出てきません。ごめんない。
さらに、システムテストでコケるという罠
個人的には、この章で覚えるべきは、上記まででOKだと思いますが、後半も少しだけ解説しておきます。
システム開発の後半に「システムテスト」というものがあります。要は「それ、ちゃんと（仕様通りに）動くの？」って確認するわけですね。しかし、バグというのは楽観的に考えれば”存在しないもの”なわけですので、基本的に、ここは、実態よりも圧倒的に短く見積もられる、ということになります。
そのための打開策として、以下の比率で見積もるべしとブルックス氏は述べます。
1/3 計画1/6 コーディング1/4 単体テストおよび初期システムテスト1/4 すべてのコンポーネントを統合して行うシステムテスト
要は、半分（1/4+1/4）は、テストに充てろ、ということです。また、計画もコーディングの2倍を費やせと言っています。え、まぢで？やりすぎじゃね？と思ったあなたは、タールの沼の入り口にいますので、1章から読み直しましょう。
そして、この見積もりができない最大の原因を、ブルックス氏は以下のように看破します。
得意先の希望する納期に合わせた間違ったスケジューリングは、他のどのエンジニアリング分野よりも、ソフトウェアエンジニアリングで頻繁に行われている。
そして、この「希望納期に合わせた間違ったスケジューリング」は、プロジェクト後半での「大幅な納期遅れ」を招き、その結果「大量の要員追加」というデスマーチへまっしぐら・・・ということになります。
顧客が何を言ったかということに依らず、常に「正しい見積もり」を行うことが、破綻しないシステム開発を行うための鍵だ、ということですね。
以上、本書のメインテーマである「人月の神話」について解説しました。次回は、開発体制のお話である「第3章：外科手術チーム」の解説です。
連載記事一覧は、コチラの最下段から
第9回：少数精鋭×複数チーム＝生産性の高い大規模システム開発｜本気で読み解く”人月の神話”（第3章「外科手術チーム」）
TAG : Strategy & Art | ギックスの本棚 | 人月の神話
目次
生産性の高い「精鋭チーム」で大規模システムをつくろう
本日は、「第3章：外科手術チーム」について解説します。本章の前提として「コンセプトの完全性こそが、システム開発における成功の鍵である」というものが置かれています。これについては、次回の「第4章：貴族政治、民主政治、そしてシステムデザイン」で詳しく触れますので、一旦は”所与”として肚にお納めください。
連載記事一覧は、コチラの最下段から
少数精鋭の方が生産性が高いのは「当たり前」
本章では、外科手術チームのような専門集団で開発にあたるべきだと述べられます。その大前提となるのが「少数精鋭の方が、大量のメンバーで臨むよりも生産性が高い」ということです。
ただし、これは規模が小さい時の話です。本書内の試算では、5,000人年の仕事に、10人の精鋭チームで取り組んだ場合、10年で完成すると計算しています。それでは「時間がかかりすぎている」と言わざるを得ません。つまり「少数精鋭で取り組めば、（生産性が高いので）トータルコストは押さえられるけれど、開発期間が長くなりすぎる」と言っているわけですね。
少数精鋭で大規模システムに取り組むために
そこで、ハーラン・ミルズが提唱した考え方が取り上げられます。一言でいえば「いくつかのカタマリ（セグメント）に分解して、それぞれを少数精鋭で取り組もう」ということです。
その際に、各セグメントに割り当てるチームが「外科手術チーム」のような、専門性を持ったメンバーで構成された”一心同体型チーム”であるべきだ、と言うのが、本章の主題です。
外科手術チームは、執刀医と副執刀医の関係が”肝”
この外科手術チームの構成要素については、いろいろと詳しく述べられるのですが、ここでは、簡単に触れるに留めます。なぜなら、これらって、僕にしてみれば、あまり本質じゃないんですよねー。
外科手術チームの構成
執刀医：チーフプログラマ。自分でコードも書くし、文書も作る。責任者。
副執刀医：経験は浅いが、執刀医のスキルセットを持っていて、対等に議論したり意見交換ができる。スキルはあるので、仕事を分担されたらそれを担当してこなす。
管理者：プロジェクト管理上のバックオフィス機能を担当。人事とか昇給とか設備の手配とか。
編集者：執刀医の文書作成を支援。
2人の秘書：管理者と編集者、それぞれに秘書をつける。
プログラム事務係：技術記録全般のメンテナンスを担当。各プログラムの更新記録をすべて記録し、メンバー全員に共有化する。
ツール製作者：執刀医が求める”生産性向上のためのツール”をつくったり、メンテナンスする。
テスト担当者：テストケースをつくったり、デバッグ用テストデータをつくったりする。テストの計画や環境準備も行う。
言語エキスパート：執刀医の”デザイン能力”とは別のスキルである”言語の特性を活用して、問題をうまく解決する能力”で執刀医をサポートする。
まぁ、非常にいいことが書かれてはいるので、是非、原典にあたっていただきたいとは思うのですが、なぜ本質じゃないと思っているのかというと、このチームの概念においてもっとも重要なのは「執刀医と副執刀医の関係性」だと理解しているからです。その他は、些末なんですよね。（いや、もちろん重要なんですよ。相対的に些末なだけで）
執刀医と副執刀医は、討議においては対等で、意思決定においては主従であるべき
執刀医と副執刀医は、保有するスキルセットは同じです。従って、（もちろん、経験の差による違いはあれど）同じような判断ができ、同じような作業ができます。
この2人が、同じ情報を保有することによって、全デザイン及び全コードについて「同じ理解」をすることが可能です。これは「コンセプトの完全性を保つ」ということにおいて、非常に重要です。なぜなら、コード記述は執刀医と副執刀医が役割分担をして実施しますので、この2人の「理解が異なっている」という状態は、コンセプトの完全性が保たれないリスクをはらんでいるのです。
さらに、執刀医と副執刀医が主従関係にあることが重要です。議論においては対等で良いのですが、意思決定段階では「どちらかの決定」が尊重されなければなりません。ある時は執刀医の判断基準に従い、別のある時は副執刀医の判断基準に従うということになると、コンセプトの完全性が損なわれるリスクが高まります。（当然ながら、どちらか一方の意見ではなく、バランスをとる、ということでも”完全性”から乖離していくのは避けられません）
チームを横断した「コンセプトの完全性」を維持する
上記のように、執刀医と副執刀医の関係性をクリアにすることによって「セグメント」を担当するチーム内での「コンセプトの完全性」は担保されます。
その次に考えなければいけないのは、チームを横断したシステム全体での「コンセプトの完全性」です。先述したとおり、5,000人年の大規模システム開発に10人で取り組むと10年かかるわけですから、複数チーム（たとえば20チーム＝200人）で開発に臨むことが求められます。
そこで求められるのは「執刀医」同士のコミュニケーションであり、コンセプトに対する共通的な理解です。
本章では、「執刀医間での調整を図ることが重要だ」というところで筆を置かれてしまいます。ただ、このチーム間でのコンセプトの完全性担保のために「インターフェースの統一」などの打ち手が求められてくるわけですね。そのあたりについては、「第7章：バベルの塔は、なぜ失敗に終わったか？」で触れていくことにしましょう。
（次回、第4章の読み解きはコチラから）
連載記事一覧は、コチラの最下段から
第10回：コンセプトの完全性を優先せよ｜本気で読み解く”人月の神話”（第4章「貴族政治、民主政治、そしてシステムデザイン」）
TAG : Strategy & Art | ギックスの本棚 | 人月の神話
目次
誰かが決めなければ、みんなが不幸になる
人月の神話【20周年増訂 新装版】
前回ご紹介した「第3章：外科手術チーム」の前提として語られていた”コンセプトの完全性こそが重要である”という内容についてしっかりと論じられるのが、今回ご紹介する「第4章：貴族政治、民主政治、そしてシステムデザイン」です。
連載記事一覧は、コチラの最下段から
コンセプトは「完全」でなければならない
本章では、コンセプトが完全であることが重要であると述べられます。この部分は19章でも触れられていたものの、解説記事では説明をすっ飛ばしましたが、”20年たっても相変わらず正しかった”としてブルックス氏がわざわざ取り上げているトピックの一つですので、今回の解説でしっかりと理解していただければと思います。
まず、「コンセプトの完全性」を理解するために、ヨーロッパの大聖堂を例にとって説明されます。少し長いのですが引用します。
ほとんどのヨーロッパの大聖堂は、いろいろな時代にわたってさまざまな建築家によって立てつづけられてきている。各建築家が建てた部分間で、構想や建築様式の相違がみられる。後代の検知羽化は、様式の変更や好みの違いを反映させるため、それ以前の設計を「改良」したいと思うものだ。（中略）その結果、神への賛美と同じくらいに建築家の奢りを物語ることになる。
自我の発露は全体最適を損なう、ということですね。皆がコンセプトを尊重すれば全体が調和します。建物は仮に美しさが損なわれても”簡単には壊れない・崩れない”などの最低要件を満たせばあまり困りませんが、システム開発におけるコンセプトの崩壊が即ち「最低要件を満たさない」ということを意味しますので、注意が必要です。
コンセプトの完全性が損なわれると、何が起こるのか？
コンセプトの完全性を損なうことの怖さについて、ブルックス氏は、OS/360の外部仕様書の作成に関する、自らの経験を語ります。（以下は、田中による要約です。）
アーキテクチャのマネージャーの主張
さて、このやり取りを見て、あなたなら、どちらを信じますか？
ブルックス氏の判断は「制御プログラムチームに任せる」だった、が・・・
ブルックス氏は、制御プログラムチームに任せることに決めました。が、その結果は、惨憺たるものでした。
アーキテクチャのマネージャーはいずれの点でも正しかった。そればかりか、コンセプトの完全性がとれなかったために、システムは開発にも変更にもはるかにコストのかさむものとなり、私はデバッグの時間にさらに1年かかると見積もらざるを得なかった。
この判断ミスの、決定的な理由は「スケジュールに間に合うという魅惑的な言葉」と「150人に仕事を与えるべきだという切実な訴え」だとブルックス氏は自戒します。
コンセプトの完全性は、どうすれば守れるのか
上記の事例を反面教師とするならば、採択すべき選択肢は「10人のアーキテクチャ・チームに仕様書を書かせる」ということになります。これは「エリートに集権する貴族政治」と言えます。
貴族政治は、昨今の「みんな平等がいいよね主義」に基づけば、忌避される思想です。ただ、忘れてはいけないのは、民主政治はすなわち衆愚政治となる可能性をはらむということです・・・という政治論は横に置いておいたとしても、少なくとも、ソフトウェア開発においては「民主政治はコンセプトが散らばる」ことを意味します。
もちろん、ブルックス氏も、民主的なやり方が悪いと言っているわけではありません。例えば、アイデアの数・種類に関して言えば、限られたメンバー（貴族）だけで考えるよりも、民主的に全員から集めていった方が色々なものがでてくるでしょう。これは民主的アプローチの良い側面です。しかしながら、それは往々にして「コンセプトの崩壊」を招きます。
前回（第3章の解説＝連載第9回）の何用にもあったように、討議は”執刀医と副執刀医で対等に行う”べきですが、意思決定は”執刀医が単独で決める”べきなのです。
「船頭多くして船山に上る」という諺がありますが、まさにそれですね。また、これは（システム開発に限らず）世の中の事業企画や事業立ち上げにおいても同じことです。3人程度で討議してコンセプトを固めないと、いつまでたっても”何をやるのか”が決まりません。さらに言えば、大勢の声を集めてコンセプトを作るというのもオススメできません。民主主義は無責任を生じさせます。何かを”決める”という行為は、ごく限られたメンバーが強い意志と責任を持って行うべき作業です。（好き嫌いの問題ではなく、物事を効率的に進めるためにはその方が良い、ということです）
貴族政治に対する不信感
とはいえ、「貴族政治」とか「エリート主義」というものに対する世の中の反発は激しいです。僕も30代の半ばを過ぎてから「まぁ、人には得意分野というものがあるので、特定領域に優れている人が、その領域を担当した方がいいよね」と思えるようになりましたが、20代の頃は「俺の方ができるのに！」とか「もっと、こんなアイデアを取り入れた方がいい！」という自己主張のカタマリでした。若いって、そういうことですよね。てへ。
それを踏まえて、ブルックス氏は、貴族政治に治する批判に関する「3つの異議」を取り上げて、どう考えるべきかを解説します。
上図内にサマりましたが、3つの異議と、それに対する回答です。
エリートだけが作ると、実現性を無視した”理想の機能”が盛り込まれて困る → 起こり得る！だから次章で解説します
アーキテクトが創造的楽しみを独占するのか。実現者は創意工夫できないぞ → 妄想です。インプリメンテーションも十分”創意工夫”の余地があります
仕様書ができるまで、実現者は指をくわえて待ってるなんて無駄だ → 妄想です。ただ待ってるだけじゃなくて、やるべきことは沢山あります
ひとつめはその通りだ、としたうえで、2つめ・3つめは「妄想だ」と切り捨てます。
2つめは「平等主義」という悪癖と、「下流工程」という言葉のもつ悪いイメージが影響しているのだと思います。上流工程だけがクリエイティブなわけじゃありません。下流だってとってもクリエイティブです。上流が得意な奴に蒸留を任せて、下流が得意な人は下流を”エレガント”にこなすことが全体最適のためには最良の選択です。（関連記事：上流（ビジネス）と下流（システム）の切り分け）
3つめは、本来的には、待ってるのが嫌ならそれまで雇わない、ということが最良の選択だと言えるでしょう。ただし、現実世界の建築とは異なり、ソフトウェア開発においては、納期圧縮が至上命題として常に存在するため、”仕様策定（上流）”と”製作（下流）”をオーバーラップさせようという方向に強いインセンティブが働きます。そのため、早い段階から、可能な範囲の製作に取り掛かることになります。要するに、上流工程をみんなで終わらせるのではなく、下流工程（の先行開発可能な部分）に早期に着手するべきなのです。
「垂直分割」が短納期開発の鍵
この「プロジェクトの前半で、インプリメンテーションに着手する」ということは、反対に「プロジェクトの後半に至ってもアーキテクチャも仕事がある」ということを意味します。
この考え方を、ブルックス氏は「垂直分割」と表現しています。
コンセプトの完全性には、システムが1つの原理を反映していること、および、利用者から見た仕様書が少人数で考えられたものであることが必要である。しかし、作業が、アーキテクチャとインプリメンテーションと実現とに実際には分けられるからと言って、そうしたデザインのシステム開発に余計に時間がかかることは無い。（中略）要するに、広範囲にわたって水平分割された作業が垂直分割によって顕著に縮められ、結果としてコミュニケーションが非常に単純化され、コンセプトの完全性が促進されることになる。
バリューチェーンの考え方において、水平統合、垂直統合という言葉があります。ご存知の通り、上流から下流を一気通貫でつなぐのが「垂直統合」で、流れの中の”ある一部分”を幅広く抑えるのが「水平統合」ですね。一方、今回は「水平分割」「垂直分割」と表現されています。ややこしいのですが、「水平分割＝水平統合」「垂直分割＝垂直統合」と考えるのが良さそうです。（うおー、ややこしいー！！！）
つまり、システム開発の「上流（アーキテクチャ）」「下流（インプリメンテ―ション）」と”水平方向に分割”されている作業を、上流から下流までの”垂直方向に分割”するべきだと言っているわけです。
具体的な”垂直分割”の例としては
システム機能の概要（アーキテクチャ） → モジュール境界やテーブル構造の設計（インプリメンテーション）
完璧なシステム機能を含んだ「外部仕様書」（アーキテクチャ） → サブルーチンの慣習や管理技法、個別のアルゴリズムの設計（インプリメンテーション）
などが、本章のなかで挙げられています。尚、正直なところ、この部分は引用するをためらわれるくらいに読みやすくもなければ理解しやすくもないので苦労することと思いますが、頑張って原典にあたっていただければと思います。
以上が、「第4章：貴族政治、民主政治、そしてシステムデザイン」の読み解きとなります。次回は、今回の”コンセプトの完全性”と同様、19章でブルックス自身が「20年経っても間違っていなかったと自信をもって言える」と述べている「セカンドシステム症候群」について解説します。（なお、本章において貴族政治のリスクとして挙げられた、アーキテクチャが機能を盛り込みすぎる、という懸念についての回答にもなります。）
連載記事一覧は、コチラの最下段から
第11回：慣れてくると、やりすぎるのが人の常｜本気で読み解く”人月の神話”（第5章「セカンドシステム症候群」）
TAG : Strategy & Art | ギックスの本棚 | 人月の神話
目次
やりすぎない、という強い心が大切
人月の神話【20周年増訂 新装版】
本日は「第2章：セカンドシステム症候群」について解説していきます。
連載記事一覧は、コチラの最下段から
「鍛錬」と「自制心」が鍵
本章では、アーキテクトが積むべき「鍛錬」と、持つべき「自制心」について語られます。このうち、特に、前回ご紹介した第4章における「コンセプトの完全性」の話でも書いた通り、自我の発露は全体最適を妨げますので「自制心」に関する記述が多くなっています。まずは「鍛錬」についてザックリとサマっておきます。
鍛錬について：
鍛錬とは、コミュニケーション（対話）の方法である
インプリメンテーションにも”創意工夫”があるが、それは、実現者の責任範囲であることを理解し、実現者には「指示」ではなく「提案」するに留める
但し、「提案」できる実現方法案を、つねに用意しておく
出てきた改善案は、積極的に受け入れる
これは、アーキテクトに限らず、ありとあらゆる「創造的な現場」でリーダーが気を付けるべきことだと言えそうです。「訳者あとがき」の解説でも述べたとおり、非常に普遍的ですね。
鍛錬については以上です。続いては、本章の大半を割かれる「自制心」に関して読み解いていきましょう。
セカンドシステム＝2回目に開発するシステム
自制心については「セカンドシステム症候群を克服する」という見出しが用意されています。章題でもある、この「セカンドシステム症候群」という言葉をまずは理解しておきましょう。
まず、セカンドシステムとは、その名の通り「２つめのシステム」です。つまり、「1回作ったものと、同じようなものを作る」というシチュエーションを指しています。ブルックス氏は、この2回目に作るときに失敗するリスクが高まる、として「セカンドシステム症候群」と名付けて警鐘を鳴らしているわけですね。
最初のシステムは、慎重に作る
人は、何事にも、初めて取り組むときには慎重に取り組みます。失敗したくないですものね。その結果「ミスする可能性」が低くなります。
最初の仕事をデザインしていくとき、次から次へとフリルやら飾りやら余計なものが思い浮かんでくるのだが、それは「次回」使おうととっておく。そうこうするうちに最初のシステムが完成して、アーキテクトには確固たる自信とその手のクラスのシステムに対する経験が備わり、二度目のシステムの開発の準備ができる。
ええ。そういうものです。自転車だって、乗り始めはドキドキしますよね。コケないように、慎重に乗るわけです。坂道をブレーキいっぱい握りしーめてーゆっくりーゆっくりーくだってくーって感じですね。
二度目のシステムの罠
しかしながら、そうして得た自信と経験に、落とし穴があります。
一般的に、二度目のシステムはデザインし過ぎる傾向がある。このとき、最初のシステムデザインでは注意深く外したアイデアと装飾を使う。結果はオビディウスの言ったように（ちりも積もれば*）「山」となる。
その、具体的な例として、IBM709アーキテクチャが挙げられます。
7090で実現されたIBM709アーキテクチャを考えてみよう。これは非常に好評を博した過剰な飾りが無い704の改良型、すなわちセカンドシステムにあたる。命令セットがあり余るほど豊富で、通常使用されるのはその半分ほどにすぎなかった。
まぁ、ありがちですよね。何事も「慣れたころが危ない」んですよ。車の運転でも、恋愛でも、システム開発でも同じですね。そんな数多ある「慣れたころが危ない」もののなかでも、システム開発は「2回目」が危ないのだとブルックス氏は説きます。
二度目のシステムこそ、デザインするもののうちで最も危険なものである。三度目以降のシステムをデザインするときには、それまでの経験によってシステム一般の性質についてそれぞれ裏付けることができるだろうし、システムごとで違うものは、特殊で一般化できない経験の部分だとわかるものだ。
この「一般化」のくだりは、ビジネス経験においても同じです。何が一般化できて、何は一般化できないのかを体系的に理解できるかどうかが、仕事ができるかどうかの分かれ目だと言えるでしょう。いや、ほんとに。
セカンドシステム症候群の最たる例として、ブルックス氏は自身の関わったOS/360を取り上げて熱く語りますので、そのあたりは是非、原書をお読みいただければと思います。その経験を受けて、ブルックス氏が至った結論は極めてシンプルです。
「今回が、3回目以降のアーキテクトを雇え」。ええ、金言ですね。膝より深い水に入らなければ溺れない、的なアレです。（笑
なお、アーキテクト自身は2回目を避けて通れませんので、「すべての機能に”数値”をつける。即ち、処理時間と必要メモリを明確化することでボリューム感を常に把握する」というアドバイスをしています。ただ、このあたりは、近年のマシン性能の向上によりある程度解決されている部分もありますので、どちらかというと「コンセプトの主題からの距離が遠い機能は実装しない」のような、より強固な”自制心”が求められているのかもしれません。やはり、どこまでいっても、銀の弾はありませんね・・・。
「セカンドシステム」≠「パイロットシステム」
尚、19章でブルックス氏が反省の弁を述べていたように、セカンドシステムとパイロットシステムとは別物です。19章から引用します。
第5章で説明している「セカンド」システムとは、実地テストを済ませた二度目のシステムのことであり、追加された機能や装飾などをもたらす後継システムのことである。これに対して第11章の「セカンド」システムとは、実地テストされる最初のシステムの構築を試みる、2回目のトライのことなのだ。それは、新しいプロジェクトを特徴づけるスケジュールや才能、無知といったすべての制約のもとで構築される。すなわし、乏しい経験で行わなければならない制約なのだ。
ということで、本章＝第5章でとりあげた「セカンドシステム」と、第11章ででてくる「セカンドシステム（＝パイロットシステム）」は別物なのだな、と記憶の片隅に留めていただければと思います。詳細は、第11章の解説の際にとりあげましょう。
ビジネスサイドの人は、常に「セカンドシステム症候群」だ
ここで、非常に残念なお知らせがあります。というのも、システム開発において「ビジネスサイドの要件を出す人たち」の多くは、常に、つまり、ひとつめのシステムであろうと四つめのシステムであろうと「セカンドシステム症候群」を罹患しています。この事実は、システム開発サイドの人にとって悲しい出来事であるのは言うまでもないのですが、実は、ビジネスサイドの人にとっても極めて不幸な状態です。
ビジネスサイドの住人には「やりたいこと」「実現したいこと」が沢山あります。彼らは、それを、しっかりと頑張って（漏れないように）システムサイドの住人に伝えます。しかし、その数か月後に、自分が最も大事だと思っていたもの（そして、あんなに頑張って伝えたもの）が優先度を下げられてしまい、半年後のシステムリリースには実現されないと聞かされるのです。
この事態を招く原因が、「なんでもかんでも積み込みたいという思い」であり、それはアーキテクトにとっての「セカンドシステム症候群」に他なりません。このことに、ビジネスサイドの人が気づくことが、幸せなシステム開発の第一歩です。そのためには、システムサイドの人は「それらを全て入れるとシステムが破綻するのだ」ということをしっかりと説明して（つまり、論理的に構造化して、言語化する、ということですね）、ビジネスサイドに優先順位をつけさせる・トレードオフを選択させる、ということを行うことが重要です。
ちなみに、意識的に「何を得るか」ではなく「何を捨てるか」を選択してもらうように気を付けるだけで、世の中は少しだけ平和になると僕は思います。
以上、最後は少し横道にそれましたが「セカンドシステム症候群」についての解説でした。次回は、「第6章：命令を伝える」です。宜しくお願いします。
第12回：文書は、アーキテクトの”製品”であると知れ｜本気で読み解く”人月の神話”（第6章「命令を伝える」）
TAG : Strategy & Art | ギックスの本棚 | 人月の神話
目次
正しい文書をつくることが、コンセプトの完全性担保の鍵
人月の神話【20周年増訂 新装版】
今回は、前回ご紹介した「鍛錬と自制心」によって、アーキテクトが過不足のないデザインをしたとしても、その決定内容をどのように開発陣に「理解させ、実現させるのか」というお話です。
連載記事一覧は、コチラの最下段から
文書は製品だ
この章のメインメッセージは「文書とはアーキテクトが作成する主要な製品である」ということです。文書が製品であるならば、他者の使用に足るだけの品質を担保せねばなりません。幾つかの鍵となる部分を引用します。
高品質なマニュアル作成のポイント
マニュアルには、利用者が見ること全て、インターフェースも含め、記述しなければならないだけでなく、利用者の目に触れないことは記述しないようにもしなければならない。
これは、前章でも述べられた「アーキテクチャとインプリメンテーションの境界線」の話です。利用者の目に触れないということは、すなわち、インプリメンテーションの話であり、そこに踏み込むことはアーキテクトの仕事の範疇を超えているわけですね。ただ、その境界線を超えない部分、すなわち、アーキテクチャの守備範囲については、全てを網羅的に記述する必要があります。
文体は的確で過不足なく、正確に詳述されていなければならない。利用者は1つの説明だけを参照することが良くあるので、必要事項はそれぞれに繰り返されていて、それらすべてが一致している必要がある。
つまり、重複していてもいいから、誤解の内容に記載する、ということですね。そして、それは「すべて正しい」必要があります。
規定されていないものも規定されていることと同じように慎重に定義しなくてはならない
つまり「何を規定しているのか」だけでなく「何を規定していないのか」も大切ということですね。”わざと記述していない”とか”別のモデルでは結果が異なる可能性がある”とか、そういうものが例示されています。
品質担保のための打ち手
上述のポイントをしっかりと押さえたマニュアルをつくるために、ブルックス氏は「1人か2人でマニュアルをつくりあげる」ことを推奨します。
アイデアが10人ほどから出されたものであっても、文章と製品の一貫性を保つためには、文章として仕様書にまとめる作業は1人かせいぜい2人で行わなければならない。
慧眼ですね。その通りだと思います。後述しますが、コンサルティングの現場でも、同じようなことが言えます。
会議をうまく活用する。
続いて、文書だけではなく、会議の活用も有効だと説かれます。会議には、週次ミーティングと全体会議があります。概略を下図にまとめました。
（ちなみに、ブルックス氏がシステム/360の開発時に行った「全体ミーティング」は1年に1度だったようですが、「今もし同じ立場にいるなら、半年ごとにこの会合を開きたい」とのことです。）
そのほかにも、インプリテーションを複数同時並行で走らせることにより”仕様書”の絶対性が高まる、であるとか、独立したテスト機関を設けることで悪魔の代弁者としての機能を持たせる、などのテクニックがありますが、ここでは割愛します。
戦略コンサルティングでも同じ
この「正しい文書によって、情報を伝える」ということの重要性は、戦略コンサルティングの現場にも相通ずるものがあります。（戦略コンサルティングの位置づけについては、コチラをご参照ください）
まず、戦略コンサルティングにおける成果物は「紙（パワポ）」です。アーキテクトはインプリ担当に情報を伝えるためにドキュメントをつくり、戦コンはクライアントに情報を伝えるためにドキュメントを作ります。そのため、成果物における表現は、非常に重要です。（”何が書いてあるか”と同じくらい、”どう表現してあるか”が大事なのです）
さらに、その資料には、「パッケージ全体ではなく、たった1枚のスライドだけがクライアント社内で回覧されてしまう」というリスクがあります。これも、アーキテクトの作成したドキュメントが、利用者に一部のみを読まれてしまう、というリスクに通じます。また、戦略コンサルティングの場合、カラー印刷で提供した資料が、白黒コピーで回覧されたりもしますので「色鮮やかに作ったが、色が消えると却って伝わらない」というリスクも考えておく必要があります。そこまで考えきって初めて”プロの資料”です。
また、マニュアル作成が「1人かせいぜい2人」で担当されるべき、ということと同様に、戦コンの作成する資料（パッケージ全体）の責任は、誰か一人（プロジェクト責任者）が負うことが通例です。彼が、自分の言葉でしっかりと説明できるように全ての記述を”整合性を取って”まとめあげることが重要です。人に依るのでしょうが、僕の場合、一字一句に至るまで書き直すことが多いです。（説明には使わない参考資料でも、書き直しちゃう勢いです）
最後に、アーキテクチャが、インプリを規定しすぎてはいけないという話も、コンサルティング領域に当てはまります。上位コンサルタントがチーム内で「こういうことを考えてほしい」という際に、「例えば、ｘｘｘとか〇〇〇のようなことを明確化したい」と言ったとしましょう。そうすると、チームメンバーの多くは「ｘｘｘと〇〇〇を明確化する」という部分にリソースの大半を投下します。そういうこと言ってんのとちゃうっちゅうねん、それは”例”であって、考え方を踏襲して他のことを考えてほしいって言うてんねや！って感じですよね。ただ、本書を読むことで、これは、もちろん受け取り手の問題もあるものの、伝える側にも問題があるのだなと深く反省した次第です。
以上、本初の普遍性の高さを痛感したところで、第6章の読み解きは終了です。次回は、第7章：バベルの塔は、なぜ失敗に終わったか？です。（ちなみに、神の逆鱗に触れたから、ではありません。）
連載記事一覧は、コチラの最下段から
第13回：コミュニケーションの効率化がプロジェクト成功の秘訣｜本気で読み解く”人月の神話”（第7章「バベルの塔は、なぜ失敗に終わったか？」）
TAG : Strategy & Art | ギックスの本棚 | 人月の神話
目次
コミュニケーションを”減らして”から、”円滑化する”
人月の神話【20周年増訂 新装版】
本日は、「第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章で紹介された「外科手術チーム」を踏襲するのが良さそうです。つまり、アーキテクトを「執刀医」として、マネージャーを「管理者」と「秘書」にするわけですね。システム開発のような技術オリエンテッドのプロジェクトにおいては、この体制は非常にしっくりきます。（個人的には、戦略コンサルティングのチームも、この体制が望ましいと思いますね）
コミュニケーションは本当に大変で大切
チームで仕事を成し遂げる、という場合に、本章で述べられていた「組織」と「コミュニケーション」の設計は非常に重要です。
そして、そのためには、まず「言語化」することが重要です。ただ、言語化するだけでは忘れられたり伝わりそこなったりしますので「文書化」することが求められます。（文書化については、前回述べましたね）
そうして文書化したものを、組織内のコミュニケーションや、組織間のコミュニケーションに使っていきます。
しかし、残念ながら「文書化」が不得意な人も多いです。これは性格的な問題です。また、そもそもの「言語化」が不得意な人もいます。これは才能の問題でもあり、努力不足の問題でもあります。そのため、各メンバーのこれらのスキルをしっかりと見極めて要員配置をしなければ、思わぬ失敗を招きます。
若手のうちは、できるだけ多様な経験を積んだ方が良いと思いますが、ある程度年齢が進み、キャリアを積んだ後は特異な領域にドップリ浸かって戦う方が幸せだし、価値も出しやすいと思う今日この頃です。
連載記事一覧は、コチラの最下段から
第14回：”見積もり”にも銀の弾は無いのだ｜本気で読み解く”人月の神話”（第8章「予告宣言する」）
TAG : Strategy & Art | ギックスの本棚 | 人月の神話
目次
見積もりを無視する「わがまま」は禁じ手と知るべし
人月の神話【20周年増訂 新装版】
今回は、第8章：予告宣言する をご紹介します。
連載記事一覧は、コチラの最下段から
見積もり作業は、筆舌に尽くしがたいくらい難しい
18章でもご紹介した通り、本章「予告宣言する」の扉絵は、ベーブ・ルースの「予告ホームラン」の写真ではあるものの、その中身は「ホームランを打つと予告しよう」ではなく「失点しないという予告」です。
「必要な作業量（＝労力）をどのように見積もるべきか」を失敗例から考えていくというお話です。この「大変さ加減」については、原書にあたっていただくべきだと面ますので、ここでは簡単にサマリー形式でご紹介するに留めます。
他者とのコミュニケーションが発生しないとしても、プログラムの規模に応じて、必要工数は累乗で増加する
従って、プログラム開発とプログラミングシステム製品開発は、”別物”と考えないといけない（詳細は第1章を参照）
投下工数の半分くらいは、プログラミングやデバッグ”以外”の作業に費やされる（書類作成や打ち合わせなど）
相互作用（≒コミュニケーションの必要性）があると、プログラマの生産性は簡単に1/7くらいまで落ちてしまう
ブルックス氏のアドバイスは「粗い拡大推計はやめとけ」
第2章でご紹介した「コーディングは全体の1/6」というお話を覚えているでしょうか。計画が1/3、コーディングが1/6、単体テストおよび初期システムテストが1/4、すべてのコンポーネントを統合して行うシステムテストが1/4というアレです。
これを思い出すと、「え、それ、見積もりに使えるんじゃないの？」と思いますよね？僕も思います。が、しかし・・・
計画段階、コーディング、単体テスト、およびシステムテストに適用できそうな比率については既に述べた。コーディングの部分だけから見積もり、それからそれぞれ比率を適用し、全体の作業を見積もるということは決してしないと誓う必要がある。コーディングはせいぜい6分の1に過ぎないから、そういう見積もりh\屋比率での誤りは、ばかげた結果につながりかねない。
え、だめなの？と思うかもしれませんが、まぁ、ダメって言うから駄目なんです。（なんとなく、納得いかないんですけどね。）
ま、この比率は、最初の「粗々の見積もりください。今日中に。」とかって営業が無茶を言ってきたときには、とりあえず6倍しとく（といいつつ、怖いからバッファ積んで8倍にしとく）みたいな感じで使うんですかね。
システム開発は「ステップ・バイ・ステップ」だ
この章から直接的に学ぶべきことは「見積もりって難しいね」ということなのですが、もう一歩踏み込んで（あるいは引いて）考えてみると、違った示唆が見えてきます。
それは「システム開発は、積み上げる作業だ」ということです。
そんなこと当たり前じゃねぇかと言われると、まぁ、そりゃぁそうなんですが、これをちゃんと理解しているのは「システム開発の現場経験がある人」だけです。多くの人、特にビジネスサイドの人は「システムが積み上げられて作られていく」という本質的な部分を理解していません。
この「世の中に理解されていないということを、理解する」ということは非常に重要です。それを踏まえて、開発サイドは”理解されていない”という前提で説明せねばなりませんし、できることならば、ビジネスサイドは”理解できていない”という意識を常に持って打ち合わせに臨むべきです。
企画業務とシステム開発は全然違う
例えば、戦略コンサルティングは、少数精鋭チームが考え抜いて”資料”を作り上げるために「作業の密度の濃さ」により、短時間でアウトプットにたどり着くことができます。（もちろん、それはそれで死ぬほど大変なんですけどね。）これは、必ずしも、戦略コンサルティングが机上の空論だから、ということではなく、純粋に仕事しての性質の違いに由来しています。これは、経営企画などでも同じことです。「どういう企画にしたいかを考えて、その企画がなぜ他の企画よりも優れているのかを資料にまとめる」ということであれば、作業密度で時間を短縮することが可能です。時間をかけたからと言って、より素晴らしいアイデアが出てくるわけでもなければ、成功確率が上がるわけでもありません。(インプットとなるデータの精度はあがると思いますが、それが”意思決定”に及ぼす影響は通常は非常に軽微で、誤差の範囲だと言えます。）
一方、大規模システム開発では、そうはいきません。コミュニケーションの内容もルートも複雑になり、さらに、文書化の必要性が高まるとともに、その文書のメンテナンス業務にも膨大な工数がかかります。そして、ボタンを一つ掛け違うと、数週間、数ヶ月、ひどいときには数年間の”積み上げ”が一瞬で無に帰す恐れがあります。
このあたりを、経営者も、戦略コンサルティングの従事者も、しっかりと認識しないといけません。「安い」という理由でベンダー（特に上流工程のベンダー）を選ぶのは自殺行為です。もちろん「高けりゃいい」ということにもなりませんが、「何を決めるフェーズなのか」「どうやって何を管理していくのか」が明確になっているベンダーを選ばないと、”システム開発”に関しては致命的な結果を招きかねない、ということは、もっともっと啓蒙されてしかるべきだと僕は思っています。（※ちなみに、情報系システムと基幹系システムでは、大きく事情が異なります。このあたりは関連記事をご参照いただければと思います。）
システム開発の現場が、今回ご紹介したような大変な苦労をしながら、必死で見積もりをしていることを理解しましょう。そして、いきなり「この機能を追加してよ」だとか、「えー、もっと納期短くならないの？」だとかいうことを”その日の気分”で言わないようにビジネスサイドの人は気を付けていきたいものですねという自省とも警句ともつかない発言をしたところで、本日の「予告宣言する」の解説はおしまいです。次回は、「第9章：5ポンド袋に詰め込んだ10ポンド」ですよ。
連載記事一覧は、コチラの最下段から
第15回：メモリが安くなったからといって「無限」だとは思わない方が良い｜本気で読み解く”人月の神話”（第9章「5ポンド袋に詰め込んだ10ポンド」）
TAG : Strategy & Art | ギックスの本棚 | 人月の神話
目次
この章の内容は時代遅れだが、思想は踏襲されるべき
人月の神話【20周年増訂 新装版】
今回は、第9章：5ポンド袋に詰め込んだ10ポンド を解説します。本章は「有限なサイズ（5ポンドしか入らない袋）の中に、それ以上のもの（10ポンド）を入れようという無茶」という比喩で、ソフトウェア開発における「サイズの有限性」を説明しています。
ただし、本章は「キロバイト」とかいう単位が出てきてしまう世界ですので、正直なところ、「ギガバイト」「テラバイト」の世界に暮らしている僕たちには無縁な部分も多くありますので、「書いてあることそのもの」ではなく、その「エッセンス（本質）」に注目していくことが大切です。
連載記事一覧は、コチラの最下段から
時代は流れ、記憶媒体は廉価になった
CPUの進化において「ムーアの法則」の存在が明らかになったように、メモリやハードディスクなどの記憶媒体の価格は「ドッグイヤー」もしくは「マウスイヤー」と呼ばれるほどの”スピード感”で下落しています。（正確には、同じ価格で購入できる媒体のサイズが加速度的に大きくなっている、と言うべきでしょう）
その結果、プログラムそのもののサイズを意識せねばならない、という局面は少なくなってきています。例えば、いわゆる「組み込み系」の開発で、最近はやりのドローンとかに特殊な機能を組み込みたいというような場合にはプログラムサイズを気にする必要が出てくるかもしれませんが、比較的レアケースと言えるでしょうか。（ちなみに、昔だと、携帯電話の組み込み系ソフトは、サイズを気にする典型だったんですが、徐々に搭載できる記憶媒体が潤沢になってきていますのでどの程度センシティブな課題なのかはちょっと分かりかねますね）
とはいえ、スペースは有限だと知るべし
もちろん、いくら「メモリが廉価で潤沢だ」と言っても、それはあくまでも”昔に比べて”という相対的な話であって、現実的に無限大のメモリが与えられるわけではありません。
iPhoneやAndroidのアプリで、処理が重すぎるだとか、あるいは、良く落ちるだとか言う話には、この「処理中のメモリの使い方」に課題があるケースが散見されます。いずれにしても、「沢山あるから、あるだけ使ってしまえ」というのは、間違った思想だということですね。（年度末の風物詩である”官公庁の予算使い切り”の話を耳にして、違和感を感じたことのある人は、自分自身にも照らし合わせてみないとダメってことですね）
この”思想”の本質は「コントロールするという意思を持つ」ということ
本章で述べられていることの「本質」は、物事を自らでコントロールしようという意思を持つことの重要性だと僕は思います。
一般的に、何かを得るということは、何かを捨てることを意味します。自由な恋愛の楽しさを得るなら、幸せな結婚生活は捨てることになるでしょう。ダイエットによる適正体重を得るためには、欲望のままに食べる楽しみを捨てることが求められます。世の中は「トレードオフ」で成り立っています。
サイズとスピードのトレードオフは、どちらかと言うと急激に跳ね上がる。
当然のことながら、処理スピードを維持したまま機能を多くすればスペースも大きくなる。だから、職人技の第一の領域は、機能とサイズを交換することにある。
この「トレードオフ」を理解し、何をどの程度優先するかという”考え方”が重要です。そして、それに則った”意思決定（をするという姿勢）”が大切なのです。もちろん、世の中には様々な選択肢があり、さらに厄介なことに、似たようなシチュエーションであっても、実際には、都度都度、微細な条件が変化しています。そんな中で「どのように考え、どのように意思決定するか」ということが、物事を正しい方向に進ませるためには欠かせません。
表現は「プログラミングの本質」と知れ
ブルックス氏は、この章において、2つの提言をしています。それは
プログラミングテクニックの習得をさせる（古い経験ばかりではダメ）
プログラミングの”技法”と、コンポーネントの”組み立て”を意識させる（技法を正しく開発し、コンポーネントとして組み上げる）
の2つです。
これは、非常に基本的な提言ですが、この基本の徹底が「職人技」に繋がります。そして、優れた職人技が、発明を生むとブルックス氏は述べます。
職人技を越えたところに発明（アイデア）がある。簡潔で余分なところが無くてスピードの速いプログラムが誕生するのは、まさにそこである。そういうプログラムは、たいてい巧妙な奇策と言うよりも、戦略的突破と相場が決まっている。戦略的突破は、時には全く新しいアルゴリズムだったりする。（中略）
トレードオフを理解し、その中での最善のバランスを見極めていくという過程においてのみ、イノベーションが起こります。（意思をもって述べるのなら、「イノベーションを起こせます」と言うべきでしょう。）
本章を読んで「ああ、古い話だな」と一蹴するのではなく、その裏に隠れた”本質”を読み解こうという意識を持てるかどうか。これもまた、思考のスタイルであり、思考の深さの問題なのかもしれません。（関連記事：概念化すると伝えたいことを明確にできる ）
連載記事一覧は、コチラの最下段から
第16回：ドキュメントにまとめることは”形式”ではなく”本質”｜本気で読み解く”人月の神話”（第10章「文書の前提」）
TAG : Strategy & Art | ギックスの本棚 | 人月の神話
目次
文書は「みんなのため」に必要です
人月の神話【20周年増訂 新装版】
本章は、6章”命令を伝える”、7章”バベルの塔は、なぜ失敗に終わったか？”において、プロジェクト成功の重要な要素として取り上げられた「文書」に関するお話です。
連載記事一覧は、コチラの最下段から
ドキュメントは取るに足らないものだと思われがち
「文書（ドキュメント）にまとめて」というと、大抵のひとは「面倒くさそうな対応」をします。例えば、議事録を作るとか、討議に使ったホワイトボードをパワーポイントに焼き直す、などをイメージしていただければ分かりやすいと思います。ね。面倒くさいでしょ？（笑）
しかし、こういう面倒くさいところに、”本質”が潜んでいます。実際、優秀なコンサルタントは大抵「ドキュメント作成のプロ」です。これは「考える」ということと「書く」ということが密接な関係にあるからなのです。
書かれない思考は、思考ではない
「書かれない思考は、思考ではない」という名言があります。（関連記事：クリスタライズの手順）
多くの方は「考えている」というときに、考えていません。頭のCPUの30%くらいはその事象のために使ってるかもしれませんが、残りのの70%くらいは別のこと（夕食のおかずとか、昨夜の飲み会とか）に使っています。
しかし、書くという作業をすることで、例えば、【30%：考える ＋ 20%：言語化する ＋ 20%：手を使って書き記す + 30%：書かれたものを客観視して思考を深める】という具合に、リソースの大半（この例では100%）を「その事象」に注ぎ込むことができます。これは、非常に重要です。
ブルックス氏も、文書を作成することが重要である3つの理由を上げる際に、ひとつめに、その「書くことで、情報を客観視できること」を上げています。
また、文書という形式にまとめることで、他の人が「読んで理解する」ことができますので、コミュニケーションの効率も精度も向上します。さらに、自分自身の道標・ガイドとして、作成した文書を用いる事で、計画通りに進捗させる効果も期待できます
文書の種類はどうなってるの？
ブルックス氏は、そんな重要な「文書」にはどのようなものがあるかを、3つのシチュエーション（コンピュータ製品、大学の学部、ソフトウェアプロジェクト）を想定して具体的に列挙することで、一般法則を見出そうとします。
結論から言えば、一般法則は存在します。そもそも、項目が非常に近しくなります。さらに、「まず”目的”が明確化されねばならない」「予算とスケジュールは必須」「コミュニケーションプランが組織という形で定義されねばならない」などでしょう。
データ活用に関する”重要な示唆”もある
なお、本章のなかで「文書の重要性」の皮を被りつつ、実際には「経営層におけるデータ活用の肝」を説いている一説がありますので、そちらを引用します。
重役の時間のうちで、自分の頭の中に無い情報を必要とする仕事に割かれるのは、ごくわずかな部分、おそらく20パーセント程度しかない（中略）。残りの時間は、諮問や報告、指導や勧告、それに協議や奨励などのコミュニケーションに使われる。しかし、少しでもデータに基づいている場合では、一握りの重要な文書こそが不可欠であり、殆どすべてのニーズを満たすのだ。
つまり、重役は、
大抵の物事（8割くらい）を、頭の中に入っている情報（知識・経験則）だけで処理できる
残り2割の仕事も、そのほとんどがコミュニケーションする、という仕事であり、データなどは基本的に不要
ただ、何らかのデータ（あるいは情報）が必要になった瞬間に「文書」によってカバーする必要がある
ということです。
これは、システム開発におけるインプット情報としての話に限らず、経営・ビジネスに関する話と読み替えても良いと僕は思います。「勘と経験」というものに対して否定的なことを述べる人もいらっしゃいますが、世の中には経験則というものが厳然として存在します。そして、大抵の場合、その経験則に従って行動すれば物事はうまくいきます。ただ、その経験則も「きちんとデータで検証されるべき」であったり、「最新情報に更新されるべき」であったりすると思うのです。
勘と経験が悪いのではありません。勘と経験を最新化しないことが問題なのです。そしてそれは、現場を離れて管理職・経営者となった後には「データを用いて最新化するしか選択肢がない」のです。本章で論じられた3つのシチュエーションには含まれていませんが、「経営」というシチュエーションにおける「文書」には経営分析レポート・事業分析レポートなどが含まれていてしかるべきだ、ということになるでしょうね。（関連記事：「知るべきこと」に手が届く”意思決定”に使えるレポート）
実は、この章は、たった5ページしかないのですが、それでも、いろいろと示唆深いものがあります。ご自身の経験と照らし合わせながら読んでいただくと、得るものが非常に多いと思いますよ。
連載記事一覧は、コチラの最下段から
第17回：その場に留まりたければ、走り続けなくてはならない｜本気で読み解く”人月の神話”（第11章「1つは捨石にするつもりで」）
TAG : Strategy & Art | ギックスの本棚 | 人月の神話
目次
変化する前提で、つくるのだ。
今回は、パイロットシステムを”捨てる前提”でつくるべし、という思想が語られる「第11章：１つは捨石にするつもりで」を読み解きます。
連載記事一覧は、コチラの最下段から
1つめで成功する、なんてありえない
本章で語られるのは、「まず、パイロットシステムをつくり、そして廃棄せよ」という思想です。
これは、大規模システム開発においては必須の考え方であると説かれます。その必要性は、大規模プラントを作る際のやり方を例にとって説明されます。
化学工学技術者は、研究所ではうまくいく工程でも、工場となると一足飛びには実施できない、ということをずっと前からわかっていた。量的なスケールアップと過酷な実環境での運用経験を積むために、パイロットプラントという中間段階が必要なのだ。例えば、研究所での水の脱塩工程は、地域の水道システムで1日あたり200万ガロンの処理に対応するべく、パイロットプラントで1日あたり1万ガロンの処理能力がテストされる。
失敗できないからこそ、小規模で「ちゃんと動くかどうか確認する」ことが重要なわけですね。
19章では、違う話をしますよ！
が、以前ご紹介した19章では、違う話が出てきます。それは「捨石にする、ってのは誤りでした」というお話です。
19章では、本章（11章）での話は「ウォーターフォール型開発を前提にして、その課題を如何に克服するか」という視点で語っていたものの、その後の開発環境の変化などに鑑みて、漸増的（インクリメンタル）な開発こそが、開発成功の鍵だろう、と結論付けられます。
ウォーターフォール型開発の最大の課題は、「アーキテクト」→「インプリ」という順序が”絶対のルール”だということです。そのため、インプリが完了し、ユーザーがシステムに触れて最初の感想を述べる頃には、再構築なんてできないところまできちゃってる、わけです。
変化すること、を前提に考えよう
本章で主張されたパイロット・システムをつくり、捨てるというプロセスは、この「再構築を多少なりとも実現しよう」という思想を、ウォーターフォール型開発の中に組み込んでいたわけです。
一方、19章では、稼働するもの＝プロトタイプをつくり、それに対して徐々に機能追加していくことで「再構築したい」となった時点で、その追加中のコンポーネントに対して変更してしまえばよいではないか、と語られます。
つまり、「変化する前提で、どうやって変化を受け入れるか」という思想は変わっておらず、そのやり方（HOW）が変わっただけ、と理解するべきだと言えます。
変化に対応できる組織構造を用意する
このような「変化」に対応するために、組織構造を検討することが有効だと、ブルックス氏は述べます。
僕の古巣でもあるIBMの組織構造が例として引用されていました。（役職の名称は、僕の解釈で書き直しています）
障害は社会学的なものだ。これに打ち勝つには日頃の警戒が必要である。まず、マネージャーは往々にして年長者のことを「畏れ多くて」、実際のプログラミング作業に使ってはならないと考える。次に、管理という仕事がより高い権威を伴っている場合がある。（中略）IBMのように、昇格に関しては（中略）二重の機構を持っているところもある。対応する職位は理論上同格とされる。
この組織図のポイントは、「管理者」が「開発者」と対等である（＝決して、開発者が上ではない）と本人達にも周囲にも理解させることだとブルックス氏は説きます。
そして、組織図の中での「横移動」は、決して「昇格・昇進」ではないと理解させることが大切です。また、管理（マネジメント）側の上位職階プロジェクトマネジャーと、開発（テクノロジー）側の上位職階シニアプログラマは、能力的にも同等であるべきで、必要に応じて交換可能であることが理想です。
メンテナンスも変化だ
以上で、開発フェーズの話は終わりですが、本章では、リリース後のメンテナンスフェーズの「変化への対応」についても語られます。これがまた、一筋縄ではいきません。
プログラムメンテナンスの基本的問題は、欠陥の修正が実質的には別の欠陥を生み出す可能性（20~50%）を秘めていることだ。だから、この過程は全体として、2歩前進しては1歩下がるとなる。
「何かを直していたハズなのに、実は、新たなバグを仕込んでいる可能性がある」わけですね。また、それどころか・・・
モジュールの総数はリリース番号とともに線形に増加するのに対し、影響を受けるモジュールの数はリリース場号に対し指数的に増加する（中略）。もとのデザインの欠陥に対する修正がどんどん減少していき、その分ますます多くの労力が前回の修正によって発生した欠陥の修正に費やされるようになる。（中略）やがて、修正を加えても改善にはつながらなくなってしまう。1歩前進することで、どこかが1歩後退してしまうからだ。
より、混沌とした状況を目指して突き進んでいる可能性まである、と述べられます。いやはや。
尚、これについては、特に解決策は提示されません。それは、プログラミングというものの本来的な性質によるものだからです。
システムプログラムの作成は、エントロピーを減らす過程だから、本来準安定的なものである。他方、プログラムメンテナンスはエントロピーが増加する過程であり、どんなに器用に行っても、できるのはシステムが修正不能な陳腐化へと沈んでいくのを遅らせることだけである。
ビジネスだって同じだよね
今回のメインテーマである「変化するのが当たり前」という価値観は、ビジネスの世界でも同じです。絶対的に不変のものというのは、世の中に殆どありません。大抵の物事は、簡単に変化します。それに文句を言っていても進歩はありませんので、変化に対応していくことが求められます。
スタートアップ界隈で、読んでいない人はいないであろう名著「リーン・スタートアップ」は、（11章ではなく）19章と同じやり方での製品開発を推奨していますし、製品開発だけではなくビジネスそのもののピボットに関しても同じ文脈で語られます。
物事が変化する、ということを考え方の軸に据えると、戦い方も変化するわけですね。
そこで、今回のタイトルに用いた「その場に留まりたければ、走り続けなくてはならない」という言葉を思い出してください。この言葉を、皆様ご存知でしょうか？これは、鏡の国のアリスにでてくる赤の女王のセリフです。
It takes all the running you can do, to keep in the same place.
色々な解釈ができる言葉ですが、今回ご紹介したシステム開発における課題や、ビジネス運営の考え方と照らし合わせると、なかなか趣深いと思いませんか？
というところで11章の読み解きは以上です。次回は、12章：切れ味のいい道具 をご紹介します。
第18回：「考える」と「作る」は別物｜本気で読み解く”人月の神話”（第12章「切れ味のいい道具」）
TAG : Strategy & Art | ギックスの本棚 | 人月の神話
目次
大量生産は、生産プロセスの画一化が重要
本日は、第12章：切れ味のいい道具 をご紹介します。
連載記事一覧は、コチラの最下段から
プログラミングの門外漢にはつまらない章
この章は、開発の現場において、どのような「ツール」が必要か、というお話です。したがって、本章は、プログラミングの現場にいないと、何を話してるんだかさっぱりわからない（あるいは、興味を持てない）内容になっています。さらに悪いことに、ターゲット機械、媒体機械というような表現も理解を困難にしています。（ちなみに、ここでの「機械」は、「ハードウェア」ということになります。ターゲット機械は本番環境で、媒体機械は開発環境とでも理解すべきでしょうかね。）
いずれにしても、本章の内容についてクドクド語るのは、当連載の立ち位置（すなわち、ビジネスサイドの人も含めて、しっかりと”人月の神話”を理解する）としては、少々お門違いな感じがしますので、今回は、本章の「タイトル（＝切れ味のいい道具）」に注目し、もう少し一般的な事柄として読み解きを進めていきたいと思います。
切れ味のいい”個人的な”道具は「考える場面」では有効
タイトルである「切れ味のいい道具」に関しては、本章の冒頭から引用します。
熟練した機械工はそれぞれ、長年にわたって収集し、大切にしまって守ってきた、見れば力量までわかるような自分専用の七つ道具を持っている。全く同じように、プログラマはちょっとした編集プログラムやソートプログラム、2進数表示ダンプ、ディスクスペースユーティリティなどを揃えて、自分のファイルにそっとしまっておく。
これは普遍的な話です。例えば、コンサルタントも、”あんちょこ”というか、”虎の巻”というか、まぁ、そういう類のものを独自で持っているものです。市販されている書籍の場合もあれば、過去に携わったプロジェクトの”考え方”に相当する部分の資料（大抵はクライアント名などのプロジェクトの特定される情報を消した資料＝サニタイズされたものです）であったり、討議した際の手書きのメモ書き・ノートであったりすると思います。これらを集積しておけば、生産性は何倍にもなります。あるいは、エクセルなども、過去資産を参考にすることがあります。（まぁ、これも、エクセルそのものというよりは、それを作る際の”考え方・設計思想”ですが。）
しかし、このやり方はプログラム開発の現場においては、馬鹿げている、とブルックス氏は一蹴します。
しかし、そういうやり方は、プログラム開発プロジェクトから見ると、馬鹿げている。第一に、本質的問題はコミュニケーションであり、個人的なツールはコミュニケーションの助けというよりも、妨げになるものだ。第二に、機械や使用言語が変われば、技法は変わるものだから、ツールの寿命は短い。最後に、汎用的なプログラミングツールを共同で開発・メンテナンスする方が、どう見てもはるかに効率的だ。
これはこれで、真理です。なぜなら、システム開発は「モノづくり」の領域だからです。
一方、コンサルティング（特に、戦略コンサルティング）の領域は、「理論と概念」の世界です。ここにおける「個人的なツール」は、コミュニケーションの妨げになりません。その個人的なツールによって思考の幅を広げる事は非常に良いことです。ただし、その思考の結果を、みんなに分かりやすく伝える（コミュニケーションする）ことにはしっかりと留意する必要があります。これは、プログラム開発と何ら変わりません。
そう考えてみると、アーキテクトの領域においては、切れ味のいい道具の”個人的な”蒐集は推奨されるべきでしょうね。
本章で語られるのはあくまでもモノづくり＝インプリメンテーションの領域の話です。
大規模システム開発の現場は、大量生産品をつくる工場と同じ
さらにいえば、本章で取り上げられている大規模システム開発は、伝統工芸でもなければ家内制手工業でもありません。そこで必要となるのは「画一的に生産する体制」です。
これを意識せずにシステム開発に取り組むと、痛い目にあいます。多くの企業が、システム開発において失敗するのは、どの部分が伝統工芸・家内制手工業で、どの部分が大量生産なのかを見極められていないことが原因です。「考える部分」は伝統工芸・家内制手工業で、「作る部分」は大量生産です。
自社製品をつくる際に、生産量を急に5倍に増やそう、とした場合にどうなるかを考えてみると良いでしょう。
いまこの瞬間が減産期で、工場の生産ラインに大きな余裕がある状況ならば「明日から5倍に増やす」ということも可能かもしれません。しかし、普通の状況ではそんなに急激な増産は不可能です。生産ラインはそんなに簡単に増やせませんよね。また、仮に生産ラインに余裕があったとしても、その操作をできる人材を一定数確保できないといけません。それには、最低限の”熟練”が必要です。これも、急激に増やすのは簡単ではありません。（余剰に囲っている、なら可能です）
あるいは、ライン式生産方式ではなく、セル生産方式だったとしても、熟練工の確保は課題です。道を歩いているお兄さんたちをスカウトして、労働者を5倍の人数に増やしたとしても、いきなり5倍になることは無いでしょう。（生産プロセスを画一的に設計できていれば、短時間で、5倍に引き上げていくことは可能だとは思います）
画一的な生産体制をつくろう
つまり、大規模システム開発が、大量生産を行うことだと理解すれば、皆が「画一的に」動くことが求められるわけです。そうすると、そこに「個人的に蒐集したツール」が歓迎されないのは自明です。
ですので、本章の中では「切れ味のいい”共通的な”道具」を用意しよう、という話になっていきます。
実のところ、汎用的なツールだけでは、十分とは言えない。特殊なニーズや個人的な好みから、特化したツールも求められる。だからプログラミングチーム内で話し合い、私はチームごとにツール責任者を要求した。その製作者は共通のツールすべてに熟達していて、顧客の立場にある上司に使用に関して教育することができる。また、上司が必要とする限定したツールを作ることもできるのだ。
ということで、チームという単位での共通ツールと、プロジェクト全体における共通ツールの2階層できることは許容するが、”個人レベル”での便利ツールは使わせないようにして、生産性の向上と生産プロセスの画一化を両立させよう、というわけですね。
システム開発は”積み上げ”の作業です
第8章の解説でも述べましたが、システム開発とは積み上げの作業です。トップダウンでテーマを決めたとしても、建築のように、徐々に作り上げられていくものです。
土台として何があり、どの部分にどの素材を使い、どの順番で作って行くのかを、チーム全員が理解している必要があります。ピラミッドを3日で作るのは無理ですよね。秀吉の一夜城も所詮は伝説で、事前準備なども勘案すれば工期はそれなりにかかっています。現代のプレハブ住宅も、現地の組み立ての前に工場での作業も発生しているわけですし、そもそも土台づくりが必要ですので、順番論は大切なのです。同様に、システムも、いきなり完成させることはできません。そんな「魔法」はないのです。
これは、漸増的開発（インクリメンタルな開発）をしたとしても同じです。最終的に納品できる商品・製品をつくり上げるためには、開発の順序やクリティカルパスなどの”制約”からは逃れられません。
開発体制（＝生産体制）を確保し、開発プロセス（生産プロセス）を画一化し、適切なコンポーネント（素材）を配置し、適切な順序で開発（組立て）を行っていくというモノづくりの世界において、たんなる思い付きや、気分の変化が仕様に影響を与えることは、あってはならない事態です。システム開発とは、クライアントとベンダーが、相互に信頼しあって初めて達成できる「プロジェクト」だということを、もっともっと理解する人が（開発側にも、クライアント側にも）増えるとよいなと思う次第です。
連載記事一覧は、コチラの最下段から
第19回：プログラムを書いても、動くとは限らない｜本気で読み解く”人月の神話”（第13章「全体と部分」）
TAG : Strategy & Art | ギックスの本棚 | 人月の神話
目次
「動く」を担保するには「思想」が重要
人月の神話【20周年増訂 新装版】
今回は、「第13章：全体と部分」を読み解きます。本章では、コードのカタマリを、きちんと機能を果たすシステムとして成立させるための重要なステップである「デバッグ」について語られます。
連載記事一覧は、コチラの最下段から
全体＝システム、部分＝コンポーネント
本章のタイトル「全体と部分」の、「全体」は統合されたシステム全体をさします。そして「部分」はそれを構成する個別のコンポーネントです。
そして、その「全体」と「部分」それぞれで、どのように「デバッグ」を行っていくべきかについて述べられるわけですが、細かい部分はビジネス側の住人にはあまり関係が無いので、割愛したいと思います。（興味のある方は、ぜひ、書籍をお読みください。）
細かなデバッグのノウハウの前に、非常に重要なことがあります。それは、「デバッグの思想」です。本章は、3つの節に分かれていますが、その1節目が「バグを取り除くデザイン」つまり、デバッグの思想ですね。2つ目は「コンポーネントのデバッグ」すなわち部分のデバッグであり、3つ目は「システムデバッグ」すなわち全体のデバッグです。今回は、この1節目について読み解いていきます。
デバッグは、そもそもの思想が大切
デバッグのための思想として、4つの手法が述べられます。
バグ検査ができる定義にする
仕様書をテストする
トップダウンデザイン
構造化プログラミング
簡潔に解説すると
バグ検査ができる定義にする：コンポーネントをつくる人々の「前提」を揃えることが重要。慎重に機能を定義し、それに沿って細かく仕様書を作ることが大前提。
仕様書をテストする：しかし、仕様書そのものが間違っていてはどうしようもない。外部のテストグループが「仕様書をテストする」という手順を踏むべき。これにより、都合の良い解釈の余地を潰しこめる。
トップダウンデザイン：デザインを一連の洗練していくステップと捉える。大まかな定義からはじめて、細かいステップに分割していく。個別のモジュールを洗練していく作業を進める中で、トップレベルへの変更の要否を見極めて、システム全体を洗練させる。
構造化プログラミング：DO-WHILEとIF-THEN-ELSEで記述する。GOTO文の”無節操な”使用は悪であることを理解する。但し、重要なのは個別の分岐文の書き方の問題ではなく、制御構造全体として考えること。
4つ目の構造化プログラミングは、まぁ置いておくとして、最初の3つは”ビジネス領域”においても非常に示唆深いです。
全体整合性を持って、実効性を担保せよ
では、この3つの「デバッグの思想」の実現手法を、ビジネス領域に転用して考えてみましょう。
1．バグ検査ができる定義にする
まず、「バグ検査ができる定義にする」ですが、ビジネスにおいても、”前提を揃える”ことは非常に大切です。
要約すれば、製品に対するコンセプトの完全性こそが、製品を使いやすくするばかりでなく、構築を容易にしてバグから逃れやすくもするのである。
何らかの戦略を立てる、もしくは、新たなビジネスモデルを企画する、という際に、この「前提」決まっていることが重要です。
良くある失敗として「個別のKPIが先に決まっていて、大上段の目的・目標が定まっていない」であるとか、「個別の戦術が先にあり、それが”制約”になってしまっている」であるとか、そもそも「”やる”ということは決まっているが、なんのためにやるのかはよくわかっていない」というようなことがあります。
この状況だと、前提が揃っていないわけですから、個別の戦術や施策の間での整合性をとることは不可能です。そもそもの「コンセプトの策定と浸透」が大切だと言えます。
2．仕様書をテストする
続いて、「仕様書をテストする」です。ビジネスにおいては、想定している状況が、本当に正しいのか？を考える、ということになります。
これも、実ビジネスではおろそかにされがちです。いわゆる「仮説検証」とはコレにあたりますが、「仮説＝思い付き」という誤解があるためか、いまひとつビジネスの現場に浸透していません。何かを実現するためには、まず、仮説（こういうことになるのではないか？）を立てて、そのために必要な条件（反対にいえば、何が足りなければ、その仮説は成立しないのか）を洗い出し、その条件が実際にその通りになるのかを確認していく作業が必要です。これは「仕様書が正しいかどうかをチェックする」のと同じです。
戦略を立てて、その戦略の実効性を（机上であるとしても）考えてみることで「やってみて失敗した」という場合に、何が間違っていたのかを理解し、次につなぐことができます。しかし、戦略の実効性を検証しないまま走り出すと、戦略そのものの考え方が間違っていたのか、前提条件が間違っていたのか、実行の方法間違っていたのかを理解することはできないでしょう。
3．トップダウンデザイン
最後に、「トップダウンデザイン」です。ビジネスに当てはめると、先ほど述べた「バグ検査ができる定義」の話と裏表の話と言えます。
まず、そもそも何をしたいのか？何のために行うのか？を明確にするのがスタートです。そして、その理想形を実現するために、どういう作業（＝タスク）が必要なのかを考えていくことになります。それらの作業は、それぞれに「実行可能かどうか」「実行のためには、どんな障壁を超えなければならないのか」という視点で、”洗練”されていく必要があります。
一方、この個別の障壁を洗い出していく中で、クリティカルな壁にぶつかることもあります。これに対する対処法も「トップダウンデザイン」に記載されている方法で対応できます。
ステップごとの洗練というプロセスは、予想外に混乱した詳細に直面した場合、後戻りしたり、トップレベルを破棄し、全く最初からやり直すことをしないという意味ではない。実際、そういうことはしょっちゅう起こるものだ。しかしこうすれば、ひどいデザインを廃棄してやり直すべきタイミングと理由をはるかに理解しやすくなる。多くの貧弱なシステムは、まずい基本デザインを化粧品で塗り固めて救い上げようとした結果の産物だ。トップダウンのデザインでは、こうした誘惑も少なくできる。
つまり、戦略を実行計画に落とし込む過程で、仮説検証を行っていくことになるわけですね。
鍵は、戦略仮説の立案・検証だ
この「デバッグの思想」をビジネス領域に転用した結果は、以下の流れにまとめることができます。
まず、全体の方向性（戦略、ミッション）を決める ＝バグ検査ができる定義にする
その戦略を実行するための必要な要素・条件を洗い出し、それらがあれば本当に「戦略」が達成可能かを考える ＝仕様書をテストする
続いて、その方向性を実行計画に落とし込みむ。その際、常に「これは実行可能か」を念頭に置きながら詳細化・具体化を進める ＝トップダウンデザイン
当然ながら、本来の目的である「戦略」との方向性に差異が無いことを、常に確認しながら進める ＝バグ検査ができる定義にする
万が一、実行可能ではない・障壁が高い、あるいは、目指す戦略と乖離してしまう、という事があった場合は、そのレベルのやり直しをすべきか、あるいは、上位の階層まで立ち返って方向性を変更すべきかを検討する ＝トップダウンデザイン
要するに、「最初に戦略（の仮説）を持つこと」「その仮説を、常に検証すること（戦略レベルでも、実行施策のレベルでも）」が大切なのです。そして、そのためには、本章で説かれているように、「バグ検査ができる定義、即ち、そもそもの狙い・コンセプトが明確に定められていること」必須になります。
これまで、様々な戦略コンサルティングプロジェクトに携わってきましたが、往々にして「何のためにやるのかが定まっていない」という状況に出会います。これは、日々のやるべきことの延長線上に戦略（のようなもの）を定義しようとしてしまうことが原因です。戦略とは本来”勝ち”の定義であり、戦術はその”勝ち”を実現するために何をするかを考えることを意味します。にもかかわらず、日々のやるべきこと＝戦術を積み上げて、戦略（のようなもの）を作り上げるのは「自分が到達できると自信をもって言えるものをゴールに据える」というお手盛りなゴール設定と言えるでしょう。絶対に避けるべきです。
当然ながら、システムそのものも「何を成し遂げたいのかという戦略」という達成すべき目的があって初めて「何を作るのか」が決まるわけです。（関連記事：上流（ビジネス）と下流（システム）の切り分け）
僕が、本書「人月の神話」はシステム開発のみならず普遍的に使える教訓に満ち溢れていると感じているのは、本初の題材であるシステム開発が、そもそも戦略を実現するための一要素だからなのかもしれません。
連載記事一覧は、コチラの最下段から
第20回：今日の遅れを見過ごすな｜本気で読み解く”人月の神話”（第14章「破局を生み出す事」）
TAG : Strategy & Art | ギックスの本棚 | 人月の神話
目次
物事は1日にして成らず。遅延は1日で起こらず。
人月の神話【20周年増訂 新装版】
18章（まとめ）から始まり、16章→17章→19章→エピローグ/訳者あとがき→1章→2章・・・という順序で読み進めてきた本連載もいよいよ大詰めです。今回は、プロジェクトの遅延に対抗するための手法を説く「第14章：破局を生み出すこと」を読み解きます。（そして、次回の15章で読み解き完了です。）
連載記事一覧は、コチラの最下段から
スケジュール無くして、スケジュール遵守は無い
極めて当然のことですが、「スケジュール」が無ければ遅延することはありません。しかしながら、これまた当然ながら、「スケジュール」が無ければスケジュールが順守されることもありません。
別に、システムを作ることには限らず、大抵の仕事は、1日にして成りません。システム開発の場合には、開発規模が大きくなったり、恒久的に安定的に動くことを目指したりするのであれば「徹夜すれば何とかなる」という考え方は捨てないといけません。システム開発は”積み上げ”ていく作業です。また、一般的なビジネス上のタスクも、殆どは”積み上げ”ることが求められます。
ですので、何はさておき、まずはスケジュールを引きましょう。
余談ですが、例外的に、戦略コンサルティングはちゃぶ台返しが効きます。考えることが仕事であり、考えた結果が成果物だからです。もちろん、それまでに収集したデータや調査結果は最大限に活用しますが「昨日までと180度違う結論」だとしても、それが絶対的に正しいという確信があれば（あるいは、昨日までが絶対的に誤っているという確信があれば）、深夜12時に、翌朝に向けて真逆の方角へ走り出すことも可能です。で、あるが故に、世の中の戦略コンサルティングファーム出身者の中には、世の中の多くの物事に、この性質を適用してしまうという致命的なミスを犯す人もいます。僕自身、自戒を込めて、非常に注意せねばならないポイントだなと思いますね。
確固たるマイルストーンを置こう
さて、スケジュールが引けたとすると、次に行うべきは「マイルストーン」の設定です。
ここで間違ってはいけないのは、”解釈の余地のあるマイルストーン”は、役に立たないどころか、かえって悪い影響を与えるということです。
マイルストーンを鋭利な刃のようにあいまいなところをなくすことは、上司が確かめられるようにすることより重要だ。人は、マイルストーンが自分も欺けないくらい鋭利だと思えば、マイルストーンの進捗をごまかそうとはめったにしない。しかしマイルストーンがファジーなら、上司はしばしば報告を提出した本人とは異なる意味に解釈してしまう。
マイルストーンが明確でなければ、進捗報告は曖昧なものとなり、遅れているのか遅れていないのかが誰にもわからなくなるわけですね。そして、それは即ち「遅れている」ということを意味するのです。ええ。残念ですが、管理されないスケジュールは、常に遅れ続けるのです。
遅れは悪だと認識せよ
マイルストーンが明確に定義されたら、今度は「認識」を変えましょう。遅れてよい物事はありません。遅延＝悪だと強く心に刻み込みましょう。
人は、プロジェクトのスケジュールが破滅的に遅れていると聞くと、たいへんな災難が続けざまに起こったに違いないと想像する。しかしたいていの場合、そういう破滅的状況は竜巻のような突発的なものではなく、白アリのようにじわじわ忍び寄ってくるものが原因である。スケジュールは、情け容赦なくではなく、ごくわずかずつ遅れてきたのだ。
これまでみてきたように、1日の遅れにも躍起にならなければならない。この程度の遅延こそが、まさしく破局の要素なのだから。
「どうせ他も遅れているから」とか「自分たちだけ納期に間に合わせても仕方がない」という思想そのものが積み重なった結果、プロジェクト全体を壊滅的な遅延に追い込みます。言い訳をしてはいけません。遅延は悪です。
そして、隠すな！
もちろん遅延は起こるものです。しかし、それは「まあいいや」ではなく、「起こるべからざることが起こっている」という認識で、周囲に共有され、必要に応じ、然るべき対策が講じられるべきなのです。
というわけで、大事なのは「遅延を隠さない」ということです。
現場リーダーが、自分のチームの遅延を上司に報告することを厭う理由として、ブルックス氏は以下の2つの理由を上げます。
自分自身で解決できる可能性があり、それこそが自分自身の仕事の本分のはずだ、という自負
問題を報告したら、権限を奪われ、今のままでも上手くいくはずの他のことまで台無しにされてしまうのではないか、という危惧
まさに、この2つの理由で、多くの遅延が（ブルックス氏の表現でいえば）じゅうたんの下に隠されていることでしょう。そして、その遅延は、じゅうたんの下でどんどん大きくなり、気づいた時には取り返しがつかなくなるのです。
この課題解決のための手段として、ブルックス氏は「上司が、現場リーダーの話を落ち着いて聞き、パニックに陥ることもなければ、頭越しに権限を発動したりしないこと」および「マイルストーンと、それに対する進捗状況を相互に共有できる仕組みで運用すること」を上げています。
これは、本当に重要なことです。もし、上司が「遅延しているなんて台詞は聴きたくない（もしくは、そんな報告を自分の上司にしたくない）」という反応をすると、遅延は隠されてしまいます。「遅延しているという報告ではなく、どうやったら間に合うかを報告しろ」という指示も適切ではありません。もちろん、対応策は現場から提示されて然るべきですが、どう頑張っても間に合わないという状況もあります。そういう場合には、それを前提として、どういう対策を練るべきか・どういう対処をすべきkを”プロジェクト全体”として考えることも必要になります。それこそが「上司」の役目です。
こうした全体のプロセスは、上司がミーティングや評価・検討会あるいは大きな会議を、状況検討のためか問題対策のために開くのかはっきりと区別し、それに応じて自分自身をコントロールすることによって促進される。人は、状況検討ミーティングの結果、問題が自分だけの手におえないと考えたら、問題対策ミーティングを招集するはずだ。
ありきたりな台詞で恐縮ですが「風通しの良い組織」をつくることが、情報隠匿を排除し、結果的に、致命的な遅延を防ぐことに繋がるわけです。（もちろん、どうしたって遅れるときは遅れるわけですが、プロジェクト全体でのリソース再配分などの対応策を”早期に”打つことが大事なのです。プロジェクト後半に人員を追加することが逆効果だということは、もう、皆さん、重々ご理解されていますものね。）
次回は、この読み解きの最終章である「15章：もう1つの顔」です。
連載記事一覧は、コチラの最下段から
第21回：ユーザーのための文書も”製品”の一部だ｜本気で読み解く”人月の神話”（第15章「もう1つの顔」）
TAG : Strategy & Art | ギックスの本棚 | 人月の神話
目次
それ、誰のためにつくってるの？
人月の神話【20周年増訂 新装版】
本日は、順番に読み解いてきた人月の神話の”最後の章”「第15章：もう1つの顔」を解説します。（16章~19章は、連載の前半で解説しています）
連載記事一覧は、コチラの最下段から
文書作成の”実践”を解説する
なんか、こう、頭に入ってこない文章なのですが（僕の頭が悪いのかもしれませんが）、本章のテーマはこの一文に集約されていると思います。
数年にわたって私は、優れた文書の必要性と正当性についてソフトウェアエンジニアリングの授業で講義し、これを熱心かつ雄弁に勧めてきた。しかし成果は上がらなかった。適切な文書作成の方法は学習しても、実践しようという熱意がないために失敗したのだろうと私は推測した。そこで、（中略）実際にどのように実践するのかを示した。これはずっとうまくいっている。というわけで、ここからは優れた文書の作成の「しかた」をあまり熱心に勧めたり集中して説明したりはしないことにする。
僕の理解のために、端的にまとめると、
文書は必要だと講義してきた→成果は上がらない
理由は”文書作成”の知識ではなく、”実践の熱意”が無いのだろう→その通りだった
”実践”してみせた→うまくいった
だから、本章では”文書の作成方法”はもう述べない（”実践”してみせる）
ということになります（よね？）。
「システム」は誰のためか？
さて、ここでいう「文書」ですが、これまでに議論されてきた「文書」とは位置づけが大きく異なります。本章のタイトルが「もう1つの顔」が指し示すように、これまでは「作り手の側からみた文書」の話をしていましたが、この章では「使い手（ユーザー）の側からみた文書」のお話となります。
これは、至極当然な話で、システムとは作り手のためにあるのではなく、使い手のためにあるのです。如何にしてうまくつくりあげるか、は非常に重要ですが、しっかり使ってもらうこと、がより重要なのは言うまでもありません。
「動かないシステム・動かないコンピュータ」という表現は、大きな問題として取り上げられていますが、それよりも頻度高く、日常的に起こっている問題は「使われないシステム」です。コチラの記事でも解説しましたが、システムは所詮システムですし、ツールは所詮ツールです。それ以上でも以下でもありません。それを使って、なんらかの結果につなげていくのは人間の仕事です。（関連記事：OUTPUTとOUTCOME）
ユーザーのための文書は、目的から始めよ
では、そんな「ユーザーのためのシステム、のための文書」はどのようにあるべきなのでしょうか。引用します。
各利用者にはプログラムの散文的な記述が必要だ。ほとんどの文書は概要の説明が十分でない時点で落第である。樹木についての説明があり、樹皮や葉の注釈もあるのだが、森の地図が無い。役立つ散文的記述を核には、遠くに立ってみてからゆっくり近づくことだ。
そうなのです。システム文書に限らず、多くの文書は「目的」を語りません。いきなり、個別事象を語り始めるのです。なぜそんなことになるのか？ 多くの場合、人は「自分の考えた順番」と「人に説明するのに適した順番」が異なるということに気づいていないからです。大抵の人は、いろんな個別具体的な物事をしっかりと理解してから、全体を組み立てます。しかし、人に説明するときには、全体を説明してから枝葉に落ちていくことが重要です。（どうしても個別具体的なことから話を始めたいのならば、自分が考えたのと同じだけの時間をかけて、共に悩み、共に苦しんで、同じ全体像に至るように手順を踏むしかありません。まぁ、それが必要な場合も時にはありますけどね。）
これは、第3章や、第4章などで、口酸っぱく語られてきた「コンセプトの完全性」、あるいは13章の「トップダウンデザイン」に相通ずる話です。システムが、どういう思想の下に、何を実現するためにつくられているのかを利用者は理解すべきです。
もちろん、現実的には、裏側に隠された部分への理解は不要で、表に見える部分だけ理解すればよいでしょう。しかし、それでも「GUIは何を目的として設計されたのか」であるとか「iPhoneはどういう使われ方を想定し、どういう価値を提供するために生み出されたのか」であるとかを理解してもらうことは、ユーザーにとっても、作り手にとっても、時間を使う価値があると言えます。
もっと高度な”利用”も想定しよう
とはいえ、目的だけが書いてあればよいわけではなく、そのほかにも実行環境や、入出力フォーマットなどが記載されるべきとブルックス氏は説きます。それらも重要ですが（まぁ、現在のGUI主流の世界においては、実行環境が書いてあれば十分なのかもしれませんが）、その先にある「更なる高度な利用者」も想定するべきだと、本書は続けます。
使用方法の説明には、正常に実行されていることがどうしたらわかるか、ということについての記述が補足されていなければならない。これはつまりテストケースのことだ。
現代において、多くのユーザーは「正常に実行されているかどうか」を検証することはないでしょうが、本来的には、上記のようなテストケースがあってしかるべきでしょうね。
プログラムを改良したり修正したりするには、これまでより相当多くの情報が必要になる。（中略）必要なのは、今度は内部構造についての明白で要領を得た概要なのだ。
さらに、プログラムを修正するような、やや特殊な使い方をする場合には、より詳細な情報が必要になります。
これも、別にシステム文書に限った話ではありません。例えば、戦略コンサルティングの資料は「読めばわかる」資料になっている必要があります。良くある誤解として「字が多い資料はダメだ」というお話がありますが、それはケースバイケースです。戦略コンサルティングプロジェクトのパワーポイント資料は、字が細かく、たくさん書きこまれていることが非常に多いです。（関連記事：文字が多いパワーポイントは本当にダメなのか）
なぜ、そんなに細かいのか。理由は2つです。ひとつめは、「直接説明を聞いていない人が読んでも、何が書いてあるのかを理解できなければいけないから」です。まさに、文書としての役割の基本ですね。（これは、第6章の解説でも述べたとおりです。）ふたつめは、「その戦略・施策を実行する際に、しっかりと共感し、自ら動こうと思ってもらわないといけないから」です。多くの場合、施策を考える人と、施策を実行する人は別です。戦略コンサルタントは施策を考える人と共に考えますが、実行する人は検討経緯などを知りません。その状況で「書いてあることを理解する」だけでは不十分で、「やろうと思う」ことが肝心なのです。そうすると、「経緯」「理由」「データの裏付け」などが、きちんと書き込まれていることが重要です。つまり、現場の担当者が”自分なりに具体化し、実行する”ための材料を揃えておくわけです。
このように「文書」は、どのような場合であっても、それを読む人のことを慮って記述することが求められるのです。
読み解き、これにて終了。
以上をもって、人月の神話の読み解きは終了です。第0回を含めると、22回連載の長丁場となってしまいましたが、お付き合いいただきましてありがとうございました。
次回、総まとめとして本書「人月の神話」の現代における価値に関する私見を述べさせていただいて、連載完結とさせていただきたいと思います。
連載記事一覧は、コチラの最下段から
読まれない名著「人月の神話」を本気で読み込んでみた（まとめ）
TAG : Strategy & Art | ギックスの本棚 | 人月の神話
目次
まじめに読まれない”40年前に書かれた古文書”
人月の神話【20周年増訂 新装版】
本日は、田山花袋の蒲団と同じくらい、知られているけど読まれていない名著「人月の神話」についてご紹介します。
人月の神話とは？
人月の神話というのは、ソフトウェア開発の”単位”である「人月」という概念が、神話に過ぎない（つまり、意味をなさない）という悲しい真実を軸に、ソフトウェア開発が如何に困難を伴うものであるかを説いた名著です。一言でいえば、10人月の仕事＝1人で10か月かかる仕事は、「人月という単位が絶対であれば”10人で1ヶ月”でできるハズ」だが、そんなことは起こりえない、というお話です。そして、この状況を打破し、遅延したプロジェクトに100人投入して一瞬でシステムを完成させるような「魔法の道具（＝狼男に決定打を与える”銀の弾”）」は存在しない*と結論付けられます。
本書は、1975年（40年前！）に初版が発行されました。それが本書の1~15章です。その後、補稿とも言うべき「銀の弾などない（16章）」「銀の弾などない 再発射（17章）」が発表された後、初版から20年が経過した1995年に「人月の神話から20年を経て（19章）」が発表されました。
そして、その1995年から現在までには、さらに20年が経過しています。もはや「古典」を飛び越えて「古文書」と称されても仕方ないくらいの一冊です。
非常に今日的で、普遍的。
この書籍では、40年が立った今日でも全く色褪せることのない真理が沢山語られています。そして、その内容の大半は、ソフトウェア開発に限らず、非常に普遍的なものです。本書をしっかりと読むことは、様々な職種の人にとって、得るものが多いと僕は思います。
本気で読み込みすぎたという反省
というわけで、本当に気合を入れて読み込んでみました。
ただ、気合を入れすぎて、第0回~第21回の「22回連載」となりました。総文字数が（引用文も含んで）7万4,000字になってしまったので、もう、それ、直接書籍を読んだらいいんじゃないの？と我ながら思ったりもしつつ、とはいえ、書籍は30万字くらいあるのでそれよりは幾分マシなんじゃないかと思う次第です。まぁ、折角書いたので、お時間のある時に興味のある項目だけでもピックアップしてお読みいただければと思います。（とりあえず第0回を読んでいただいて、その後、興味のある回を選んでいただくのがオススメです）
「読み込み」の目的と狙い
本書を読み込んでいくにあたり、幾つか気を付けたことがあります。
明らかにシステムに特化した部分には、踏み込まない
時代遅れになってしまっている概念には、極力触れない
翻訳が回りくどかったりする部分は、思い切って「僕の解釈」でシンプルに書き直す
システムに明るくない人＝ビジネス領域の人が読んでも分かるような具体例を可能な限り付加する
僕は、SE → 戦略コンサル → 起業 というキャリアを経てきました。そのキャリアを歩む中で、世の中における「ビジネス世界の住人の、システム領域に関する無理解」が、著しい非効率を生んでいるように感じています。システムは、ビジネス課題を解決するためのツールに過ぎません。どんなシステムを作るのか？は、どんなビジネス課題の解決を目指すのか？と同義です。にもかかわらず、多くのビジネスマンは、システムのことをあまり理解しようとせず、ベンダーにもやっとしたボールを丸投げして終わります。（関連記事：上流（ビジネス）と下流（システム）の切り分け）
この状況を打破するには、ビジネス世界の住人が「システム開発とはどういうものであるか」を”もう少しだけ”理解することが必要だと思うのです。現在は、その仕事をシステム世界の住人に押し付けている状態だと思います。「ビジネスがどういうものであるか、システムサイドが理解しろ」という要求をしているわけですね。これは（ある意味ではシステムサイドの方に失礼かもしれませんが）実現不可能な無理難題です。そんな無理難題をシステムサイドに押し付けるから、その間に入るコンサルティングファームが高い報酬を得て、”要件の翻訳作業”をすることになるわけです。（それはそれでもちろん価値があるんですけれど、コンサルはもっと有益に使うべきだと思うんですよね・・・高いんだし。）
それらを踏まえ、今回の一連の読み解きにおいては、ビジネス領域にも適用できる普遍的な部分を括りだしていくことに留意しました。それによって、本連載を読んだビジネス世界の住人が「自分事」としてイメージしやすくなることに加えて、システム開発における勘所も何となく理解できるようになることを目指してみました。その試みが上手くいっているかどうかは分かりませんが、騙されたと思って、ちょっと読んでみてくださいませ。
脚注） *：正確さを期するなら「ソフトウェア開発には固有の困難性（むずかしさ）があるので、人月の神話が成立しない。その困難性を魔法のように解決しうる銀の弾はない」という表現の方が適切だと思いますが、そのあたりは個別解説記事でご確認ください
連載目次：
第3回：反論に対する反論（17章：前編）
第10回：コンセプトの完全性を優先せよ（4章）
第14回：”見積り”にも銀の弾は無いのだ（8章）
第18回：「考える」と「作る」は別物（12章）
第20回：今日の遅れを見過ごすな（14章）
おまけ：読まれない名著「人月の神話」を本気で読み込んでみた（まとめ） ※本稿
よろしければサポートお願い致します。いただいたサポートはこれからの投資のために使わせていただきます。