第3回:反論に対する反論|本気で読み解く”人月の神話”(第17章:前半)

AUTHOR :  田中 耕比古

俺が9年前に言ったこと、別に間違ってなかったよね by ブルックス

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

今回は17章「銀の弾などない 再発射」です。これは、前回解説した16章「銀の弾などない」の9年後に発表された論文で、その内容は「第16章で行ってたことに対する色々な意見に対する答え+大きくは変わらない結論」という感じです。「銀の弾などない」を理解するためにも、一読すべきと思います。では、その内容を見ていきましょう。

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

 

本質から目を背けるな(ついでに「偶有的」は「副次的」と読み替えよう)

この章で語られることのなかで、最も重要なのは「偶有的」という言葉の捉え方です。「偶然起きた」という意味で解釈されがちだが、これは「副次的」という意味なんですよ、と述べられます。第16章で、本質的と偶有的って何なんだよ、と思った方も、これでスッキリですね。

尚、ブルックス氏はこの件も含めて「曖昧な表現しちゃったから誤読させちゃったよね。それは申し訳ないけど、俺の言いたかったことがちゃんと伝わらなかったってだけで、俺自身および俺の思想は全然間違ってないからそこんとこよろしくね」というスタンスなんだと僕は理解してます。まぁ、個人的にはそういうとこ好きですけど、世間的には嫌われそうな気がしますよね。

さて、その上で、「本質的」と「副次的」なもののうち、なぜ、本質的なものを攻略しないといけないのかということについて、以下のように述べられます。

私が本質と言っているソフトウェア構築の部分は頭の中で概念構造体を作ることであり、偶有的事項と言っている部分はインプリメンテーション過程のことなのだ。

(中略)

作業の偶有的または表現的部分は今や全体の約半分以下に減っている、ということが私の言いたいことのすべてだ。(中略)「銀の弾などない」では、作業の偶有的部分が全体の9割より少ないのであれば、これをゼロに近づけること(魔法が必要だ)は大きな生産性向上をもたらさない、と明白に主張している。つまり、本質を攻略しなければならないのだ。

ちょっと持って回った言い方なので、僕の解釈を図にまとめてみました。

  • 仮に、偶有的困難が9割を占めるならば、それを減らすことにも意味がある
  • でも、既に(偶有的困難を減らす取り組みが沢山走って、効果を出してきたので)1:1以下に減っている
  • と、すると、手つかずの「本質的困難」に対して攻略するしかない

ということですね。まぁ「付随的なところを頑張るのは勝手に頑張るとして、本質的なところで頑張ろうぜ」というのは、非常にまっとうな意見に聞こえます。

徹底反論開始

上記前提に立って、16章「銀の弾などない」発表後、7年間に寄せられた各種コメントにたいして、徹底抗弁をすすめます。すごいなー。強いなー。って思いますね。具体的にみていきましょう。

vs ブラッド・コックス

まず、objective-Cを開発した、ブラッド・コックスさんの「銀の弾は存在する」に対して、ブルックス氏はこう反論します。

コックスは「銀の弾などない」を2つの点で誤解している。

バッサリ一刀両断ですね。折角なので、内容を見ておきましょう。

一点目は、「プログラマが、ソフトウェアを構築する方法として正しいものを持っていないから、ソフトウェア開発が難しい」と誤読しているというわけです。実際には「方法とかいう問題じゃねぇよ、ソフトウェアってものは概念的にそもそも複雑なんだから、難しいんだよ。ばーか。」って感じです。

続いて、二点目。これは「俺は『ソフトウェアの概念構造体を作ることそのものに”複雑性・同調性・可変性・不可視性”といった固有のむずかしさがある』と書いたのにも関わらず、コックスは『ブルックスは”本質的困難を攻略できる見込み”がないと力説している悲観論者だ』と誤読しているんだよね、ほんとに読解力ねぇなーコイツってば。」的な感じです。喧嘩売りまくりマクリスティですね。

特に二点目については、「4つのむずかしさ(複雑性・同調性・可変性・不可視性)それぞれが引き起こす問題は、改善できる(と俺は昔から言ってんだよ)」とブルックスさんはブチ切れてまして、次の項まで、その話を引っ張ります。

ソフトウェア構造体における概念上の複雑性の大半は、アプリケーションそのものの自由さがもたらす複雑性から来ている(といってもすべてではないが)。

要するに「インプリじゃなくて、設計段階・構想段階なんだよ、難しいのは」ってことです。「何を作るのか」が一番難しい、と。

その解決策として、「再利用」が鍵になると考えていること。そのためには、階層性(階層化したモジュールがないと再利用できない)と漸増性(常に動いているものを、徐々に機能拡張していく考え方)が非常に重要である、と、以前から言ってんだろうがちゃんと読めや。という感じですね。

vs デービッド・ハレル

続いては、UML(Unified Modeling Language)にも影響を与えた、状態遷移図の開発者、デービッド・ハレルさんの「銀の弾丸をかみしめて」に対しての反論を見ていきましょう。

悲観的、だと読み違えるなんて、勘違いも甚だしい

まず、先ほどのコックスさんへの反論と同様に、そもそも「銀の弾なんてない。未来は暗い!と主張する悲観的な論文」という大きな誤解に対しては、非常に納得がいかないようです。

私の妻や同僚や編集長などは、私が悲観的になって判断を誤るよりも、楽観的になって判断を誤ることの方がはるかに多いことを知っている。

もはや、人間性の話になってます。(笑

悲観的だと読み解いている論拠も、全然ちがうんだよね

さらに、ハレルが「悲観的だと誤解」した論拠が3つあるが、その読み解き方が全然違うんだよね、とブルックス氏はのたまいます。その3つとは、

  • 本質と偶有的事項とにはっきり分けていること
  • 銀の弾になりそうな候補を1つずつ単独で取り扱っていること
  • 「なんらかの目覚ましい改善が期待できる」のに十分な時間ではなく、たった10年間についてだけ予測していること

だと述べた上で、それぞれの「解釈」にたいして反論を進めます。

  • 1つ目の「本質と偶有的」の分離は、「それこそが論旨であり主題であり、真実だ。悲観的とかじゃなくて真実なのになぁ。わかんねぇかなぁ。」
  • 2つ目の「単独で取り扱う」ことについては、「だって、それらの”候補”は、実際に”1つずつ”世の中に登場したんだから、評価も1つずつ行って然るべきじゃん。」
  • 3つ目の「10年って短すぎ」に対しては、「40年かけて大進歩したって、それ”魔法”って呼べなくない? 反対に、10年後に効果が出ますよ、って言ったとしたら、むしろ長すぎるくらいでしょ???」

という感じです。

1950年の話と混同するってのは、頭良くない

また、ハレル氏が、1950年代に書かれたと仮定して議論を進め「そこから25年間で凄い進歩したんだから、今後も進歩するよ」という論陣を張るのは、前提を覆してるし全然お話ならない、と言います。

これは、上述した1:9の話と関連しますが、「1950年代は、偶有的困難の比率が非常に高かったので、そりゃぁ、偶有的困難を減らしていく活動に意味があるに決まってるし、そんなこたぁ、俺だってわかってんだよ。それが、十分に削減された「後」の話として、本質的困難に立ち向かう必要性を論じてるんだよ。」と仰ってます。はい。

お前の主張してる解決法も、俺の言ってる”枠組み”の範疇じゃん

さらに、ハレルさんが提唱する「バニラフレームワーク」というものを取り上げて、「それも、要は”概念構造体を適切に作って修正する」という手法であり、ブルックス氏の言うところの「本質へのアプローチ」を試みてるだけじゃん、と述べます。俺の掌の上で踊るが良いぜ、的な感じでしょうか。

不可視性は難しさであって、視ようとする努力は否定してないよ

最後に、ハレルが主張する「ソフトウェアの概念構造体の多くが本来トポロジカルであり、それらの関係は空間的・図形的表現の中に自然に対応させることができる」に対しては、考え方は非常に近いと思っているよと述べます。その上で、仮に2次元以上の多次元的な表現方法を用いたとしても、複数の図式が必要だったり、そもそもうまく表現しきれないものがあるのも事実で、ただひたすらに難しい、と言っているだけだよ。と優しく説きます。そして、優秀なプログラマは、空間的感覚が非常に高いので、そこが「本質」なんだよね、と主張します。

というわけで、ハレルさんにも徹底抗戦を完了し、次なる獲物へ進みます。

vs ケーパーズ・ジョーンズ

続いては、ソフトウェア開発における”定量的な見積り”の先駆者と言われる、ケーパーズ・ジョーンズさんです。大きな違いは「生産性」と「品質」に関する立ち位置です。

「銀の弾などない」は、当時の書物一般と同様、入力構成単位ごとのソフトウェア出力という生産性に焦点を当てていた。ジョーンズはこう言っている。「そうではない。品質にこそ焦点を絞るべきなのであり、生産性は後からついてくるものなのだ」。

しかし、ここについては、意外と素直に同意します。

彼は、費用がかかってしかも遅れているプロジェクトは、仕様書やデザイン及びインプリメンテーションにおけるエラーの発見・修正に余分な作業と時間のほとんどを投入している、と主張している。そして、系統だった品質管理の欠如とスケジュールの破綻との間の強い相関性を示すデータを提供している。私はそれを信じる。

ただ、生産性の計測については、非常に困難であるとして明言は避けます。「ワークステーションとソフトウェアツールのおかげで5倍もの改善を得た人々がいる」という意見と「バスケット一杯のテクニックによって、10年間に大規模な改善ができるというあなたの予想は楽観的だ。私は大幅に改善した組織など見たことが無い」という意見を紹介するにとどめています。

品質+生産性の向上には「パッケージソフト」が効く

先ほどのジョーンズからの指摘を踏まえた「品質と生産性」の議論において、何がそれらを向上させる鍵なのかに関する一つの答えとして、「パッケージソフト」が挙げられます。

もともとの「銀の弾などない」の中でも、「マスマーケット(大量生産)のソフトウェアの可能性」を述べていたブルックス氏は、ほーらいった通りでしょ、と上機嫌です。

「銀の弾などない」における1986年の評価の1つで、自分では正しいことが証明されたと思っているものがある。それは「マスマーケットの発展は、ソフトウェアエンジニアリングにとって最も意義深い長期的な動向である」というものだ。

(中略)

情報管理システムプログラマの生産性を改善させる最も劇的な方法は、地元のコンピュータ販売店へ行って、店頭に並べられている商品をすぐさま買ってくることだ。これは別に馬鹿げたことではない。安価で強力なパッケージソフトは、従来ならソフトウェアを発注しなければならなかった多くのニーズを満たしていて、すでに使用できる状態にあるのだ。

さらに言えば「むしろ、過小評価していたと反省している」くらいの勢いです。へりくだったかのうようにふるまいつつ、自分の正当性をしっかりとアピる感じ、好きです。

 

さて、ここまでは「反論してきた人を全力でコテンパンにやっつける」というところに注力してきたブルックス氏ですが、売られた喧嘩を買いまくって満足したのか、この論文(17章)の後半は「オブジェクト指向」と、その結果もたらされる「再利用性」に関して、(特に誰かを批判するわけではなく)淡々と持論を述べるフェーズに入っていきます。本稿も少し長くなりましたので、こちらについては、次稿でご紹介することとします。

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

SERVICE