でぃするだいありー?

そんな気はないんだれど、でぃすっちゃってる。 でぃすでれ?

読物 『人月の神話 新装版』

 理論の上では決してそうではなかったが、実際にはいつもそうだった。システムデバッグは、いつだって天文学のように夜中に勤務する三交替性要員のような仕事だった。二十年前に701を使いながら、夜明け前の非公式生産というものを私は学んだ。それは、機械室のボスは全員家でぐっすりと眠っていて、オペレータは規則のことなどやかましく言う気をなくしている時間帯だった。機械にして三世代の時が過ぎ、テクノロジーはすっかり変わり、オペレーティングシステムまで登場したものの、この非常に親しまれた仕事のしかたはまだ変わっていない。長続きの秘密は、何より生産性が高いことだ。生産性を認め、実践から成果が上がることを公然と受け入れる時が来たのだ。

P.119

エス ノー
Unix Cobol
APL PL/I
Pascal Algol
Modula MVS/370
Smalltalk MS-DOS
Fortran

図16.1 わくわくさせる製品

P.189

 そういうわけで、私は現在進行中の技術を伝えることやカリキュラムを開発する努力には大いに賛成なのだが、私たちにできるもっとも重要な努力は、偉大なデザイナーを育てる方法を開発することだと思っている。

 ソフトウェア会社(団体)なら、この挑戦を無視できないだろう。優秀なマネージャーは、数は少ないとしても、優秀なデザイナーよりは多いはずだ。偉大なデザイナーと偉大なマネージャーは、どちらも非常にまれな存在である。たいていの会社は、管理面で有望な人材を見つけて育成することには相当の時間を費やしている。だが、偉大なデザイナーの発見と育成について、同様の労力を費やしている会社を私は知らない。製品の卓越した技術は本質的に彼らに依存するのだが。

P.189

複雑性はレベルによる

 例えば複雑性はもっとも深刻な本来的問題だが、すべての複雑性が必然的なものとは限らない。ソフトウェア構造体における概念状の複雑性の大半は、アプリケーションそのものの自由さがもたらす複雑性からきている。(と言ってもすべてではないが)。実際、多くの多国籍企業を顧客に持つ管理コンサルティング会社、MYSIGMA・ソダール・アンド・パートナー社のラーズ・ソダールは、次のように書いている。

 私の経験では、システム作業で直面したほとんどの複雑性は、組織的機能不全の症例である。この現実を同じように複雑なプログラムでモデル化しようとすることは、問題を解決する代わりに、実際にはそのごたごたを温存させることなのだ。

 

 一方、ノースロップ社のスティーブ・ルカシクは、組織的複雑性さえもおそらくは自由、気まぐれなものでなく、ある種の秩序原則の影響を受けているのではないかと主張している。

 私は物理学者として教育を受けたので、「複雑な」物事を単純な概念を使って記述したくなる。ここでは皆さんのおっしゃることが正しいのだろうから、複雑な事物も何らかの秩序原則の影響を受けやすいとは主張しないことにする。・・・同様な議論のルールに従えば、皆さんもそうではないと主張することはできない。

 ・・・昨日の複雑性は今日の秩序となる。分子の無秩序という複雑性は、気体運動論と三つの熱力学法則に取って代わられた。現在のソフトウェアは、いずれそうしたたぐいの秩序原則を見せてもいないのかもしれない。しかし、なぜそうなのかという説明は皆さんがしなければならないものだ。私は別に、いつの日か、(物理学者に一様な)より高い秩序という考え方から、ソフトウェアの「複雑性」が理解される日が来るのを信じている。

P.197

この本の最初の版が世に出たのは我が身が幼稚園児の頃。新装版は、我が身が社会人になった頃のこと。

書いてある内容は、ソフトウェア業界に何年か勤務すればおおよそ体感できることであろう。少なくとも、火消しのような仕事に連続で従事させられるようなキャリアにされてしまえば、長くとも3年程度で実感できるはずだ。

人月というのはソフトウェア業界独自の概念ではないだろうが、少なくともソフトウェア業界が頻繁に使用するコストの単位である。「三人月」といえば、一人で三カ月ないしは三人で一ヶ月ということになる。ただし、後者の場合、同程度のパフォーマンスを有する「人」でなければ計算があわない。一ヶ月で引継を命じられた時、我が身と同程度の能力を有する人物になら二週間で可能であると応じたが、割り当てられた人材のアレはナニだったことがあるが、それは余談である。

書籍を含めていろいろな情報に接してきた今では、繰り返しになるが本書に新鮮味はない。そこは大して重要ではない。重要なことは、執筆されてから40年弱が経過するというのに、依然として未だ、銀の弾丸は登場していないということである。

銀の弾丸」とは、ソフトウェアがもつ複雑性を人狼に例えたとき、この恐るべき怪物を打倒ないし理解するための決定的な要因となるべきもののことである。生産性の劇的な向上に役立ったに違いないGUIオブジェクト指向ですら、銀の弾丸たりえない。本書はそう述べている。Appleをageて、MSをdisりながら。

本書が引用する「ソフトウェアの持つ複雑性は人間の複雑さである」という意見は持論である。

いわゆる業務というものがどれだけ人間力で回されているか。企業は何故マニュアル化に励むのか。なぜ市販のパッケージソフトウェアを導入しようとしない/できないのか。「システム担当」という役割に適材を当てられない間は、きっと解決しない。

「組織は人を育てない」とは、誰の言葉だったか。