"人月の神話" Frederick P. Brooks, Jr. 著

コンピューティングの世界は日進月歩。チューリングマシンが考案されて一世紀に満たず、いまだ過渡期にあるのだろう。ここに、出版後20年経っても色褪せない書がある。プロジェクトの事情はあまり変わっていないようだ...
「人月」という用語は、開発、設計、製造などあらゆる生産工程において用いられる。それは、人と月の積で表される工数の単位で、二つの項が互いに交換できるという意味がある。人と月が交換可能となるのは、作業者たちの間でコミュニケーションを図らなくても仕事が分担できる場合や、機械的な作業に徹することができる場合。エンジニアのスキルには個人差があり、時には十倍もの能力差を見せる。
にもかかわらず、人月の幻想に憑かれたお偉いさんは、労力と進捗を混同した見積もり計算を続ける。マイルストーンを美しく見せることが管理者の仕事と言わんばかりに... 表面的な技術を寄せ集め、結合すればいいという安直な考えに走れば、却って現場を混乱させ、お粗末な結果を招くことは何度も経験してきたはずなのに... ゴールとスケジュールが予算に適ったものなど見たことがない。そして、ブルックスの法則がこれだ。
「遅れているソフトウェアプロジェクトへの要員追加は、さらにプロジェクトを遅らせるだけだ！」
尚、著者フレデリック・ブルックスは、1999年チューリング賞を受賞し、IBM System/360 の父としても知られる。再読に際して、20周年記念増訂版を手にする...

「銀の弾などない！」という主張は、なかなか挑発的である。ムーアの法則に従って、メモリ容量やCPU性能など、ハードウェアリソースが飛躍的に進化する中、ソフトウェアの生産性において格段の向上をもたらすプログラミング技法は、ここ10年登場しない！と断言しているのだ。
確かに、構造化技法やオブジェクト指向といったパラダイム変化を見せつつも、これが最高というものがなかなか見当たらない。複合的に技法を導入し、しかもプログラマのセンスに委ねられているのが現実である。その状況は、多様化するプログラミング言語に見てとれる。関数型プログラミング、オブジェクト指向プログラミング、ジェネリックプログラミング...  あるいは、マルチパラダイムプログラミングなどなど。言語に愛着を持った連中が、それぞれにこれが一番だと主張する様は宗教論争にも映る。
本書は、そうした技法を度外視して、プロジェクトチームの在り方や管理手法の側から問うている。その前提に本質性と偶有性とを混同しないこととし、概念構造体やソフトウェア実体の側面から議論を展開する。
「すべてのソフトウェア構築には、本質的作業として抽象的なソフトウェア実体を構成する複雑な概念構造体を作り上げること、および、偶有的作業としてそうした抽象的実存をプログラミング言語で表現し、それをメモリスペースとスピードの制約内で機械言語に写像することが含まれている。」
本質性と偶有性とは、アリストテレスを彷彿させる概念だ。ここでの偶有性には、偶然発生するという意味ではなく、副次的や付随という意味が込められているようだが、本質に対するその場しのぎ！という意味も感じられる。そして、最も重要な事柄は、「コンセプトの完全性」と「アーキテクトの資質」であるとしている。ハードウェアリソースの奴隷となる前に、ソフトウェアとして見失ってはならないものがあろう。これはソフトウェア論ではない。ある種の組織論である。

手段に目を奪われがちなのは、なにもソフトウェアに限ったことではない。おいらはプログラマではないが、ここに語られるチームの鉄則は他の業界にも十分適用できるだろう。ソフトウェアの構築には、強い変化を意識させられる。自分自身を変えよ！と要請してくるほどの。プロジェクトマネジメントは極めて社会学的で心理学的な分野であるからして、ソフトウェア手法の柔軟性の高さは、不変な精神活動において大いに参考になるはずだ。
「ソフトウェアエンジニアリングというタールの沼は、これから当分の間厄介なままだろう。人間が、手の届く範囲の、あるいはぎりぎりで届かないところにあるシステムを、ずっと試していくことは容易に想像がつく。おそらくソフトウェアシステムは、人間の作り出したもののうちで最も複雑なものだろう。この複雑な作品は私たちに多くのことを要求している。この分野を引き続き展開させていくこと、より大きな単位に組み立てることを学ぶこと、新しいツールを最大限使用すること、正当性が立証されたエンジニアリング管理方法に最大限順応すること、常識から自由になること、それに誤りを犯しがちな点と限界を気づかせてくれる神の与えた謙遜の心を。」

1. コンセプトの完全性
「コンセプトの完全性こそ、システムデザインにおいて最も重要な考慮点だと言いたい。一つの設計思想を反映していれば、統一性のない機能や改善点など省いたシステムの方が、優れていてもそれぞれ独立していて調和のとれていないアイデアがいっぱいのシステムよりましである。」
ソフトウェアの目的の一つは、システムを使いやすくすること。使いやすいとは、機能を使うためにマニュアルを読んだり、知識を覚えたり、調べたりする労力を省いてくれることである。そのために様々な言語に対応したり豊富な機能を備えるわけだが、複雑な処理をシステムに肩代わりさせるのに、一切のマニュアルなし！というわけにもいくまい。あるいは、使いやすいく簡単というだけでも、豊富な機能というだけでも、良いデザインとは言えまい。
「システムのアーキテクチャとは、ユーザーインターフェースについての完全かつ詳細な仕様書であると考える。それは、コンピュータにとってはプログラミングマニュアルであり、コンパイラにとっては言語マニュアルである。制御プログラムにとっては、機能を呼び出すのに使用される言語のマニュアルである。そして、システム全体にとっては、利用者が自分の仕事全部をこなすために調べなければならないマニュアルを集めたものになる。」
古くから、機能の豊富さこそが最高のものとされる傾向がある。ソフトウェアの軽快さを犠牲にしてまで、使いもしない、見向きもされない機能が装備されるとは、これいかに？セカンドシステム症候群とは、まさに多機能主義に陥って、最初の哲学を見失った姿だ。哲学のない技術は危険であろう。とはいえ、システム設計者にとって、システムの一貫性を保つことほど難しいことはない...

2. アーキテクトの資質
コンセプトの完全性とは、一つの原理を反映することであり、ある種の芸術性を具えている。鑑賞者や批判者の意見をすべて取り入れては、芸術の高邁さは失われる。芸術とは、啓発された利己主義者のものだ。そこで、一つのシステムは、一つの芸術作品として捉えたい。
「制約が芸術のためになると納得させるような美術や工芸品の例はたくさんある。芸術家の格言に曰く、"形式は自由な創造の源だ"。最悪の建築物は、用途に対してコストを掛け過ぎたものだ。バッハの創造的な作品には、定められた様式のカンタータを毎週作り出さなければならないという要請に押しつぶされたところなど微塵も見られない。」
芸術作品となると、少数のアーキテクトによってアイデアが創出されることになり、プロジェクトマネージャの権限は絶大となろう。プロジェクトチームは君主制になりがちだ。とはいえ、アーキテクトが創造的楽しみを独占し、実装者の創意工夫を締め出すのでは、単なる作業者の集団に成り下がる。インプリ屋に成り下がって、ただ仕様書に従うだけではチームの活力が失われ、ましてや予算とスケジュールに押し潰されれば、命令に対して感情的にもなる。やはりチームには民主制の余地を残したい。メンバーが自由に発言し、それを芸術の域にまとめ上げるのが、プロマネの仕事としておこうか。
実際、好転したプロジェクトには、あらゆる意思決定の権限を持つマネージャが、穏やかな独裁者として振る舞っているものである。メンバーに高位な意思を伝授し、相互に切磋琢磨し、技術に対して積極的な関心を持つ風潮を大切にしたい。とはいえ、メンバーに作る喜びを与え続けることほど、難しいものはないのだけど...

3. 生産性 vs. 品質... 本当に銀の弾はないのか？
銀の弾などない！とは、憂鬱なテーマでもある。間接的にゲーデルの不完全性定理を語っているような。ただ、これを悲観主義とするのはあんまりだ。楽観主義では何も解決できないし、最終的に勝利するのは現実主義であろう。まったく市場原理と似ている。ブルックスは、プログラマの楽観主義は職業病だと言っている。
「懐疑主義は楽観主義とは違う。輝かしい進展は見えないが、そう決めてかかることはソフトウェアの本質から離れている。実際のところ多くの頼もしい新機軸が着々と進められている。それらを開発、普及、利用するという厳しいが一環した努力こそ、飛躍的な改善をもたらすはずだ。王道はない。しかし、道はある。」
あれだけもてはやされたオブジェクト指向は、銀の弾になりえたであろうか？このパラダイム変革には、様々な見解がある。モジュール性と美しいインターフェースを励行することや、カプセル化を強調すること、あるいは、継承を強調すること。別の見方では、強い抽象データ型を強調し、特定のデータ型には特別な操作によってのみ扱うことが保証されるべき... などなど。様々な特徴を有するが故に、コードを書く人の必要と好みに応じて取り込まれる。ちなみに、ある組織では、継承禁止令！があると聞く。権限者が理解できないから、嫌いだから、禁止ってのもどうかと思うが...
コーディングルールをあまり厳密にすると、思考の柔軟性が失わる。それよりも、変わったコードを書く人には、コードレビューを開催してもらうことだ。手段ではなく、哲学の方を共有すべきであろう。
カプセル化は大好きな概念だが、見知らぬ人が設計したものをブラックボックスで流用するとなると、ちと抵抗がある。ソフトウェアの再利用は、生産性と品質の双方において重要な役割を果たすだけに、お偉いさんは工程が短縮できると信じこむ。そして、中身の検討を無視し、もはや何を設計しているのかも分からなくなる。
「右手がやっていることを左手が知らないせいで、スケジュールの惨憺たる状態だとか、機能がうまく合っていないとか、システムのバグといったことが一度に生じる。... チームは憶測でばらばらになっていく。」
ところで、ソフトウェア業界は、生産性と品質のどちらに目を向けるべきであろうか？現代の風潮は、品質よりも利便性が圧倒的に優勢にあろうか。実際、Webサービスには、些細な不具合が何年も放置されたまま。無料だから仕方がないと諦めているユーザも少なくあるまい。実用面で問題にならないと言えばそうなのだが...
しかしながら、品質を着実に確保していかなければ、そこから派生する設計までも爆弾を抱えることになる。品質はコストに影響を与えるために、お偉方は目を瞑りたいようだが、品質を重んじなけば、自己の進歩も見えてこない。多くのプロマネは、系統だった品質管理の欠如とスケジュールの破綻に相関関係があることを経験的に知っているだろう。
確かに、完全な品質を実現することは不可能だ！ただ、人類の進化論には、突然変異という離散的な現象がある。それは、継続されたな意志によって生じるエネルギーの蓄積からもたらされる。つまり、こだわりってやつよ。楽観主義から意志エネルギーの蓄積は望めまい。
ソフトウェアの歴史は、いまだ過渡期にあり、一概に銀の弾はない！とも言い切れまい。いや、人類の歴史そのものが、いまだ過渡期にあるのかもしれん。そういえば、ケイパーズ・ジョーンズ氏は日本講演で、ソフトウェア業界には大事なものが欠けていると語った。本書にも、彼の言葉が紹介される。
「品質にこそ焦点を絞るべきなのであり、生産性は後からついてくる。」

4. ドキュメントの試行錯誤
自然言語は、定義のための厳密性を欠く。そこで、現実的な手段として形式的定義といった表記を用いる。プログラミングとは、まさに形式的な記述の積み重ねだ。厳密な記述は、分かりやすい記述とは性質が異なる。それ故に、マニュアルが曖昧になることもしばしば。法律の条文が極めて形式的なのは、厳密性を求めるからである。求めたからといって、得られるとは限らんが...

「簡潔に言うっていうのはすごくいい。自分が今どこにいるか知っていようが知っていまいが。」...サミュエル・バトラー

かつて、コードを説明する手段としてフローチャートが過大評価された。今では、フローチャートという言葉すらあまり聞かない。UMLのアクティビティ図のような派生的な技法は見かけるものの。コードを読む手がかりとしては、むしろテーブルやデータ構造、あるいはモジュール定義や構造記述の方が重宝される。
プログラミング言語が進化すれば、ドキュメントの書き方や用い方も変化するだろう。形式化と柔軟性の按配は、いつの時代でも、どんな分野にも、つきまとう問題である。いつも言っていることだが、我がチームではドキュメントの書き方を規定しない。分かりやすく、好きなように、思ったように書くようにと... 参考にするのはいいが、少しは独自性を見せようと... 芸術性とは主観性に支配されるもの、存分に精神を解放しようではないかと...
「表現はプログラミングの本質である。」