最後に、これらすべての内容を一通り消化したときには、いくつかのプログラミングに関する神話、すなわちプログラミングに関する信仰を検証できるぐらい客観的な考え方が身についているかもしれない。バートランド・ラッセルが言ったように、信仰とは根拠のないものを信じることである。そして神話とは、アンブローズ・ビアスがかつて定義したように、他の人びとの神聖な信仰である。
P.47
「いかなる場合でも、プログラミングチームの規模と構成の基本ルールはこうである。最小限のコストで最高のプログラミングを実現するには、可能なかぎり最高のプログラマーに十分な時間を与え、最小限の人数ですむようにすることである」
P.113
「・・・・・・プログラミングプロジェクトを進めるにあたって最悪の方法は、多数の新人を雇い、プレッシャーをかけて監督もなしに働かせることである。現在あたりまえのように行われている方法ではあるが」
P.113
この研究の性格は、「なぜプロジェクトは成功するのか、または失敗するのか」といったものだ。期日までに予算内で要求を満たし、顧客を満足させたプロジェクトを「成功」としている。この基準をもとに１０～１２件のプロジェクトを調べたところ、成功は１件だけで、あとは全部失敗だった。
プロジェクトマネジャーと、過去にプロジェクトの評価を行った人たちの話をもとに失敗の理由を分析した。彼らはプロジェクトの失敗の背景にあるさまざまな理由を挙げたが、そのほとんどが本質的にマネジメント上の失敗だった。われわれが問題にぶつかるのは、技術そのものが足りないからではなく、持っているものを運用する方法を知らないからだ。P.137
世代が入れ替わっても、あいかわらず上層部のマネジャーの多くは、ソフトウエアのあらゆることがわかっていない。しかし、少なくとも現在は、ソフトウエア業界の好況のおかげで、ソフトウエア開発者にも自分たちが上級管理者としてやっているけることを証明するチャンスがある。非常にうまくやっている人もいれば、マネジメントに問題があるのはソフトウエアの経験が足りないせいではないことを実証している人もいる。また、近年は、ソフトウエアの経験がまったくない人が大規模なソフトウエアプロジェクトの運営に成功する場合があることがはっきりした。つまり、問題はソフトウエアのスキル不足ではなかった。ずっとマネジメントのスキル不足が問題だったのだ。ソフトウエアのスキル不足は、自尊心のないマネジャーにとって格好の言い訳になっていたにすぎない。
P.142
・・・つまり、プログラマーに別の人のスタイルで考えさせることは、そのプログラマーの問題解決能力を減じることになる。そこで、最大の課題は創造的思考ではなく、創造的コミュニケーションである。自分の考えを、互いに独自のスタイルをもつ別の人が理解できるように表現することである。
P.212
人びとはCOBOL設計者の当初の意図を見失ってしまった。設計者の１人、ジーン・サメットの言葉を借りよう。
COBOLが意図した対象ユーザーは、実は、企業のデータ処理問題に関わる２種類の人びとだった。１つはCOBOLの自然さが資産となるような比較的経験の浅いプログラマー、もう１つのユーザータイプは、基本的にプログラムを書いたことのないすべての人である。言い換えると、COBOLのプログラムは読みやすいため、管理者や経営者など、プログラムを検査したいと考えるあらゆる人にとって文書のように扱うことができる。プロのプログラマーの要求に対応しようという意図はほとんどなかった。・・・・・・
P.282
人間の精神は、通常は10%しか使っていない。残りはオペレーティングシステムのオーバーヘッドである。
P.324
本書は『CODE COMPLETE』を経て着手に至ったが、同書でも言及していたように『プログラミングの心理学』というタイトルはまずいという評には同意であり、タイトルが示すような内容では、必ずしもない。しかしながら、COBOLにトラウマがなければ、特に避けるべきではない読物と感じられる。特にプログラマーを使用する立場の人物には必読と思える。
ただし、PL/IやCOBOL、FORTRANが主要言語として採用されているので、その辺を適宜処理する必要がある。特に後半はこれらへの怨嗟に満ち満ちた筆致で綴られているので、良い思い出がある人は読まない方がいいかもしれない。
本書を読むうちに、これまで自覚はなかったが、COBOLによる被害はPTSDレベルであることがわかった。プログラマー歴20年を超えて初めて、ほんの数か月、半年に満たない期間だけCOBOLに接した。その時初めてプログラマーをやめようかと思うようになった。プロジェクト管理手法は逆流するウォーターフォールであったが、いくつかの修正案件に関わり、既存ロジックの問題点を明らかにするなど、作業そのものはうまくいき、継続依頼をいただいたにも関わらず、である。嫌で嫌でたまらなく、逃げ出すように契約を終了した。
それから数年が経ち、苦い思い出の一つになったと思っていたのだが、本書に登場する関連ワードを見ているうちにそうではないことが明らかとなった。知らず、特に理由も感じられぬままに、プログラミングへの熱意が失せていたのである。やる気がでないのだが、やる気がないのとはなんか違うカンジなのが新鮮だったが怖かった。
本書に出現するCOBOLワードが原因ではないかと疑うようになってからは、自覚的にそれを念頭に置き、かつ、この時並行して独学を開始していたGraphQLの実装を強行した。入門者であるゆえに敷居は低くなく（特にsequelize）、ただでさえやる気がでにくい塩梅だったが、なんとか動くものを作り上げて、その達成感をもってようやく払拭された。じっくり勉強してから実装するつもりだったのだが、突貫気味になってしまった。じっくりやってたらCOBOL鬱につぶされてしまいそうだったのだ。
このような問題がない読者ならば、本書からは大いなる啓発を得るかもしれない。1970年代から、少なくとも日本のIT企業の一部は現在までも、本書が問題として扱っている諸事を全くクリアできていないことが読み取れる。
本書が指摘するように、プログラミングとはそれくらい難しいということなのだろう。これについては、本書が指摘する形とは少し違う形で、個人的には理解してきた。「自分が日々行っている業務を正確には理解していない顧客からヒアリングした内容をコンピュータにやらせるために翻訳する」ことは難しい、と。
システム開発技術が進歩を止めていない現実からすると、プログラミングに関連するアレコレはやはり難しいのだということになろう。
