"ソフトウェアエンジニアリング論文集 80's" Tom DeMarco & Timothy Lister 編

日ごとに歩みを加速させるソフトウェア。まともに相手をしていると目が回る。40年間の歩みで容量や速度は9桁も伸び、単位系は Kiro から Giga 経て、Tera へ。9600ボーは、もはや古代遺跡か。最先端の技術に振り回され、技術から生み出されたオモチャに振り回され、まったく自分の足で歩いているのやら、人の足で歩かされているのやら。仮想化ってやつが、自由意志までも曖昧にしていく...

しかし、だ。ソフトウェア技術がいくら進歩しようとも、コンピューティング哲学が、そうやすやすと廃れることはあるまい。
二千年以上前の自然哲学は未だ健在だし、相対性理論に否定されたニュートン力学だって未だ権威を保っている。そればかりか、ルネサンス風の原点回帰で一役買い、むしろ輝きを増している。
構造化プログラミングにしても、オブジェクト指向にしても、それぞれ、60年代、70年代に考案された方法論だが、80年代に花開き、21世紀の今でも輝きを失わずにいる。手法を盲目的に用いるのではなく、思想観念として独自のスタイルで実践する。哲学とは、そういうものであろう...

原題 "Software State-of-the-Art: Selected Papers"
ここに紹介される論文集は、80年代のもので、「デマルコ・セレクション」と副題される。編集は、「ピープルウェア」や「アドレナジャンキー」のトム・デマルコとティモシー・リスター。このコンビの名だけでも、なんとなく手に取ってしまう。おいらは暗示にかかりやすいのだ。
良いと感じるものは、なんでも真似したくなる。真似したからって、どうなるものでもないけど。真似る価値があるかどうかも、後にならないと分からないけど...
合理的な設計者であることは難しい。プロセスを真似ることすら難しい。あっさりと真似て独自のスタイルにしちまう人は、失敗の経験も豊富なのだろう。おそらく...
達人の書いたプログラムには、書き方を超えた何かがある。エレガントなアルゴリズムは、忘れかけていた何かを思い出させてくれる。おいらはプログラマではないが、ソフトウェア工学の考え方は技術屋の視点から非常に参考になる。生きる上でも...
尚、本書は、二人がセレクトした 31 の論文集から、監訳者児玉公信が 12 を厳選。

1. 「ソフトウェア工学の超構造化管理」Gerald M. Weinberg
2. 「銀の弾丸はない: ソフトウェア工学の本質と課題」Frederick P. Brooks, Jr
3. 「ソフトウェアコストの理解および制御」Barry W. Boehm, Phillip N. Papaccio
4. 「ソフトウェア研究についての私見」 Dennis M. Ritchie 
5. 「ソフトウェア開発見積りのメタモデル」John W. Bailey, Victor R. Basili
6. 「生産性改善のためのソフトウェア開発環境」Barry W. Boehm, Maria H. Penedo, E. Don Stuckle, Robert D. William, Arthur B. Pyster
7. 「ボックス構造化情報システム」H. D. Mills, R. C. Linger, A. R. Hevner
8. 「STATEMATE:複雑なリアクティブシステムの開発作業環境」D. Harel H. Lachover, A. Naamad, A. Pnueli, M. Politi, R. Sherman, A. Shtul-Trauring
9. 「Pascal の問題に対する一解決 = Modula-2」Roger T. Sumner, R. E. Gleaves
10. 「合理的な設計プロセス: それを真似る方法と理由」David L. Parnas, Paul C. Clements
11. 「セルフアセスメント手順 IX、コンピュータ利用における倫理に関する...」Donn B. Parker, Eric A. Weiss
12. 「TeX のエラー」Donald E. Knuth

ソフトウェアエンジニアリングといえば、プログラムの設計、運用、保守といった方法論に目が向くが、ここでは、ちと視野を広げて、マネジメントや開発環境、コストや見積もり、エラーログの有用性、さらには、倫理面にも目が向けられる。
たいていのプロマネは、技術の問題よりも人間の問題の方が深刻だということを痛感しているだろう。日程やコストに追われ、限られた人員で、いかに合理的に仕事を進めるか。たいていは、目先のことに囚われる。悪臭漂う流用モジュールを政治的に押し付けられれば、拒否した時の失敗の責任を考え、成功率の低い方を選択しちまう。品質を犠牲にすれば技術者たちのモチベーションまで下げてしまい、不合理きわまりない。
プロマネがまともに仕事をやろうと思えば、首を賭ける覚悟がいる。しかし、その覚悟は、そんな大層なものではない。自分のやり方を通す方が気楽なこともあるし、生き方もシンプルでいい。政治的な組織は、あっさりとおさらばするぐらいでいい...

プログラムってやつは、簡単に言っちまえば、文字の羅列。その意味では文学にも通ずる。いや、人間の文化そのものが、文字や記号で成り立っている。芸術作品も、建築物も、音楽も、方程式も、形式的な記述によって。宇宙を構成する素材も、ある種の暗号で記述されている。人間にとっての記述とは、解釈の道具ということになろうか。
ならば、ソフトウェア工学は、文学、社会学、生物学、量子力学... など垣根を越えた学際的な学問となろう。開発チームの運営は、極めて社会学的。使い勝手を追求すれば、極めて人間工学的。言い換えれば、ソフトウェア工学は、人間の能力に束縛されてきたという見方もできる。
実際、本書は、コンピュータ工学の書でありながら人間味に溢れている。まさに人間学。ならば、ソフトウェア工学が人間から解放されると、どうなるだろうか...

コンピュータは数学的な構造を持っている。これを動作させるソフトウェアも数学的に記述する方が合理的なはず。少なくとも、チューリングマシンの思考原理は数学的である。
しかしながら、記述するのは人間だ。現実に、人間が理解しやすい形式で記述する方が、合理的なケースが多い。ソフトウェアが複雑化し、大規模化すればするほど、プログラミング言語も人間味を帯びてくる。機械語から、アセンブラ言語、C言語、そして、スクリプト言語へ。人間に近づけば近づくほど高級言語とされる。人間の思考原理が、高級かは知らんが...
AI がプログラミングすれば、わざわざ人間に理解させる必要はないだろう。CPU が直接理解する記述方式の方が合理的なはず。するとソフトウェア工学は、さらに進化を加速させ、人間の理解の及ばない怪物となりそうだ。人間はコンピュータの奴隷になる運命にあるのか...
なぁ～に、心配はいらん。生まれつき奴隷説は、二千年以上前に既に唱えられている。仕事をすべて奪われた奴隷とは、なんと滑稽な。そして、ヘーシオドス風の精神原理に回帰せずにはいられまい。仕事に生き甲斐とやらを求めて...
ところで、生き甲斐ってなんだ？？？