書評 『プログラマが知るべき97のこと』

今回のお題はこれ。著名プログラマのエッセイを集めた『プログラマが知るべき97のこと 』。例によって積ん読本から。手元にあるのは初版第3刷（2011）。英語版のタイトルは "97 Things Every Programmer Should Know”。

プログラマが知るべき97のこと

全部で海外の著名プログラマのエッセイ97本と日本人プログラマのエッセイ10本、合計107本のエッセイが収録されており、大変お得です。

5年ほど前に一世を風靡した本になります。

個人的に特に勉強になったエッセイ

タイトルは「〜知るべき」なので全部読めと言わんばかりですが、自分の興味のあるテーマについてのエッセイをピックアップして読めばいいと思います。

他のエッセイで私が特にいいと思ったものは以下の通り。

• 14: 『コードレビュー』by マティアス・カールソン
• 22: 『1万時間の訓練』by ジョン・ジャガー
• 49: 『見積もりとは何か』by ジョヴァンニ・アスプローニ
• 36: 『ハードワークは報われない』by オルブ・モーダル
• 64: 『プロのプログラマとは？』by ロバート・C・マーティン

このエントリではNo. 49の『見積もりとは何か』をピックアップして個人的見解を書きたいと思います。

IT企業の経営者、（と人事部？）に読ませたい古典。『プログラミングの心理学』

読書メモのまとめ。個別の章についてはここ2週間ほどだらだら書いてますのでそちらへ。

プログラミングの心理学―または、ハイテクノロジーの人間学 25周年記念版

プログラミングの心理学　【25周年記念版】

感想。

本書を読んだ感想は、「やっぱり人」、ですね。

どんな開発手法を採用したところで実際に仕事をするのは機械ではなく人間。

働く機械ではないんです。コーダーだのPGだの呼び方を変えたってダメ。 プログラミングは血の通った人間の仕事。

プログラマ、つまり大なり小なりコンピュータが好きな人間たち。パズルのような知的な遊びが好きな人もいれば、天邪鬼（あまのじゃく（タイプまで千差万別ながらある程度の共通項があるはず。少なくとも機械じゃない。

人件費という数値（＝コスト）ではなく、感情のある生き物として扱っていただきたいと思います。

プログラマに限った話ではないですが、頭ごなしに締め切りを押し付けて、仕事の意義を説明することもなく、まるで家来のようにこき使う。 それでは上手くいきませんよ。

本書にはプログラマ個人へのヒント、チーム運営のヒントが散りばめられています。ただ、様々な事例をとりあげている関係で、時間のない方には読みづらいところも多いかなと思います。今時の自己啓発書やビジネス書のように要点が簡潔にまとめられていたりはしません。小手先のテクニックを解説するような本でもなく、手っ取り早く正解が得られるようなものでもないです。

もともとが1970年代はじめの本なのでIT系の人間からしても現物を見たことがない機器の話も登場します。時代は変わってもソフトウェア開発の現場は様変わりしているはずですが、人間の習性はそれほど変化していないようです。ソフトウェア開発の経験者であれば「この業界、あまり進歩してないなあ」と苦笑いしたくなる部分も多いはず。

本書は良くも悪くも「思考の材料」*1です。本書を片手にソフトウェア開発の現場のメンバーと、経営畑や人事畑の方で一緒にディスカッションするというのも面白いと思います。

ちょっと文章が古臭いという点は否めませんが、古典的名著といわれるだけのことはあります。

最近のビジネス書に食傷気味の方、タイムスリップした気分で夏休みの課題図書なんかにいかがでしょうか。

後はこの本から得た気づきをどこで活かすか、ですかね。まずは著者の勧めるとおり、「プログラムのソースコードを読む」かな？。

以上、購入してから7年後の感想でした。

*1:まさに本書のオビにも、『まえがき』にもそういう記述があります

『プログラミングの心理学』をコツコツと読み進める試み その14

読書メモはこれで最後。

audiobook.hatenablog.com

『第5部 エピローグ』

セミナーに参加して1年経ったあと、彼らが漏らす典型的な感想はこうだ。 「こういうことについて話すのは十分楽しいことでしたが、だんだん私の目にも職場で起こっていることが見え始めてきました。うわあ、何だこれは！」

概ね同感です。私の以前いたSIerの開発現場について、「何だこれは！」というコメントをせずにはいられません。 在籍当時も「ダメだこりゃ」とは思っていましたが。

まさにマネジメント、本書の言葉で言うと「管理の問題」でしたね。このエピローグにおける一番の要点は、「コンピュータのOSを使いこなすよりも、意識というなの自分自身に搭載されたOSを使いこなせ」というのが著者の主張。

目の前の事象から少し距離を置いてものごとに立ち向かえ、ということでしょうか。

だから私は、この本が圧政側の勢力によって利用されないことを望む。だがまた私は、それが必ずや彼らに利用されることを知っている。 だから私としては、この本が彼ら以外の勢力によって大いに利用され、それによって圧政を利することへの埋め合わせができますように、と願うばかりである。

オープンソースソフトウェア（OSS）の開発にかなり影響を与えているという意味で、著者の願いは叶えられていると思う。 おそらく著者の言うところの圧政側は官僚組織だろうから、この本の説くような方法はなかなか導入できないだろう。

よくよく思い返すと、私が以前働いていたSIerにおいても、この本の影響を受けていたのかもしれない、と思う部分がないこともない。 ただ、やはり「縦割り」というか、コンポーネントや業務単位で担当者を固定、つまりソースコードや作業の属人化によってその恩恵は限定的だったのではないかと思う。むしろ、この本に紹介されているダメ事例を彷彿とさせる失敗がほとんどだった。

『第5部 「エピローグ」へのコメント』

このエピローグは時の試練に耐えた。私は一言も付け加えることがない。

購入してから数年経って読んでいるわけですが、まさに時の試練に耐えましたね。

購入した当時、つまり学生時代にこの本を読んでいたらほとんど素通りして古臭い本で終わっていたかも。SIerの現場を経験した分、著者の言い分がよく理解できたと思う。 そういう意味では積ん読状態にしておいたのも無駄ではなかったかな。

著者のワインバーグ氏についてWikipediaを参照。 ジェラルド・ワインバーグ - Wikipedia

だいたい2週間ちょっとで読破。

プログラミングの心理学―または、ハイテクノロジーの人間学 25周年記念版

また整理して書評としてまとめる方向で。

『プログラミングの心理学』をコツコツと読み進める試み その13

audiobook.hatenablog.com

第13章はプログラミングの周辺ツールについて。

『第13章 その他の道具』

だが現実には「小さい誤り」などというものはない。というのは、「たった一つのハイフン」すら大損害に結びつくからである。 プログラミングという仕事の性質がそういう物である以上、誤りの「大きさ」とその結果生じる問題の間には何の関係もない。 だからプログラムのテストにおける目標何かと問われても、「誤りを根絶すること」という以外には答えようがない。 そしてそれは不可能事なのだ。

至極まっとうな話。ただ最後の不可能事ってのを理解してくれない人が多すぎる。

プログラムのテストにおいて信頼感を得るためには、その時点までになされたテストによって、プログラムのどれだけの部分が実際にテストされたかを知りたいと思う、というのは自然なことである。

今でいうところのカバレッジ測定ツール。この本が執筆された1970年代初頭から考えられていたのか。

一様性や簡潔性を測ることはそれよりもう少し難しいかもしれないが、コーディングを始める以前に一定の仕事に対してプログラムの長さはどの程度が妥当か、見当をつけることができれば、簡潔性を値踏みする助けになるだろう。

ダウト。「一定の仕事に対して」というのは上手くいかない。それができるなら既存のプログラムをわずかに改修するだけで事足りるはず。

未だに存在しないプログラムを書くからお金になるはずで、それは人類にとってではないにしても、未踏の部分、つまり不確定要素を含むはず。 仕様書が何ページだからプログラムがどのくらいの行数になるはずだ、という見積もりがデスマーチの元。

この発想は危険すぎてどういできない。

簡単な例として、同じプログラムの中で、N1、N2、N3、N4、N5といった似たような名前が使われている、という場合を考えてみよう。 そうした名前は、まずもって誤りを犯してくれといっているようなものだ、ということをわれわれは知っている。 というのは、そのどれか一つを他の一つと書き違ったり読み違ったりすことは、たやすいことだからである。

まともな話。記述が冗長であるとか、見るからにダサいという場合は、そこが不具合の温床である兆候と見なせるだろうが、それは主観の判断。

ただ何処かの会社でこういう変数の名前つけ方をしている、という噂を聞いたことがある。勘弁してほしい。

プログラムのテストについていえば、自分のプログラムについて早期に「成功」を収めたプログラマはとにかくテストをあまりに早くやめてしまうものだ。 この過ちから身を守るための一つの方法は、テスト問題をテストをはじめる前に、いやそれどころかもし可能ならばコーディングをはじめるまえに作っておく、というものだ。

こんなに昔からテスト駆動開発の源流とでもいうべき発想があったってこと？
某社でも理想的な開発工程では仕様策定完了段階でテスト項目を作成することになっていたんだよね。理想的な場合には。
まあ実際はお察し下さいなんだけど。

テスト自動化システムにも言及されているのは意外。

自動的虫取りシステムの場合には、プログラマが同じ場所を一定時間以上見ていたときは、彼の注意を強制手にプログラムの別の局面に向けさせるという方法があろう。 次にどこを見せるかについては、ありとあらゆるアルゴリズムが考案できようが、もっとも大切なことは彼を突っかかっている場所から引き離すことなのだ。 実は単にしばらく端末をオフにし、彼に樹木や芝生やミニスカートや、そのほか何にせよプログラムの見当違いの場所ではない何かを眺めるチャンスを与えるというのは一つの良いやり方である。（p.379、強調は引用者）

どうみてもセクハラですよ、ワインバーグ先生。樹木や芝生とミニスカートを同列に扱うとは恐れ入る。というかこの場合、女性の大腿部では？

気分転換の有効性は否定しませんが、プログラマに女性が少ないとは言っても、この表現はいかがなものかと。

『オベレーティングシステム』

OSの一部として性能評価ツールを提供することの重要性を論じている。また、パンチカードの時代の逸話があれこれ紹介されているが、省略。

現代で言うところのシェルスクリプトの必要性についても言及しているところは興味深い。

『TSSとバッチ』

まあこれも昔話。当時の時代背景を知るという意味では貴重なのか。

『ドキュメンテーション』

ドキュメンテーション（解説文書）はプログラミングにおけるヒマシ油である。管理者たちはそれがプログラマのためになる、と思っている。 そしてプログラマはそれを忌み嫌っている。

下剤ってことなのか、それとも民間療法ってことなのか。迷信の類と言いたいのかな？

だがドキュメンテーションは、それが優れたものでない限り現実の価値を持たないのだ。ダメなドキュメンテーションは、ドキュメンテーションがないよりもっとまずい。

まあ不正確なドキュメント資料が極めて迷惑なのは認める。それでもアリバイ工作の手段としては有用ではないかな。

どんなドキュメンテーションにも決してできないことがある。 早い話、あるプログラムについて知るべきことのすべてを、訓練を受けたことのない人に二十五語以内でわからせることなどできるわけがない。

まったく仰せの通りです。何か要約しろと言われて困った経験でもあるのだろうか。

最良のドキュメンテーションを伴っていてさえ、いつかはそのプログラムを捨てて、もう一度作りなおしたほうが得、という時がやってくる。

ドキュメント云々はともかく、ソフトウェアには寿命があるというのは同意。ハードウェアの進化であるとか、環境の変化によって基本設計自体が時代遅れになる時がある。ただそれを、中間管理職が理解していないケースが多いのではないか。

少なくとも某社の執行役員は理解していたけれど、事業部長クラスには伝わっていなかったように思う。まして課長クラスは完全に逃げ腰だった。 闇雲に作りなすのは論外だけど、5年なら5年、10年なら10年の間、拡張が可能な基本設計、アーキテクチャを考えないといけない。

誰でも、どんな経歴の持ち主であっても、どんな訓練を受けてこようとも、きちんとしたプログラミングの仕事ができる、などということはないことがわかってきた。プログラマたちはそのことを知っている。 だが、だとしたらなぜ彼らは、街で手当たりしだにひっ捕まえてきた人物にドキュメンテーションができると信じるのか。

プログラミングが誰にでも「ちゃんと」できる仕事ではない、とプログラマが主張するように、「ドキュメント作成」も誰にでもできるわけではない、と主張している、のであろう。

ドキュメント作成を軽視するプログラマへの痛烈な一撃、といったところか。個人的には同じことはプログラムのテストにも言えると思う。 ドキュメント作成ととテスト作業（動作確認）は花形の仕事とされることはない、という点で共通している。

どちらも設計やコーディングに比べると下等な仕事とされ、私のいたSIerではプログラマに向いていないとか、大きな納期遅延を引き起こした担当者がアサインされることが多かった。そういう場面を見てきた人間からすると、不思議な納得感がある。

『まとめ』

この章でいおうとしたのは単純なことである。それは「システムは複雑だ」ということにほかならない。

ハードウェアとソフトウェア、そしてそれを取り巻く人間達と文化も含めてシステムだ、と言いたいらしい。 人間心理を左右するのはハードウェアだけではないし、ソフトウェアだけでもない。様々な人々が関係すると、それぞれに相互作用が生じてくる、と言いたいのだろう。

『第13章 「その他の道具」へのコメント』

近年、様々な開発補助ツールが登場しているにもかかわらず、それが浸透していないことへの著者の嘆き節。

（前略）今日残る大問題は、エゴ丸出しプログラミングという問題、および専業のプログラムテスト要員が置かれている社会的地位という問題である。 明らかにこれらの問題への回答は、テストの道具の改善によっては得られない。管理の側における改善が必要である。

エゴ丸出しプログラミングというのはちょっとよくわからないが、インターネットによるコミュニケーションの大きな変化がこの問題をクリアしているように思う。テスト要員の地位についても、MicrosoftやGoogleにおいては改善しているのではないだろうか。

統合が進むにつれてどんな行動が起こってきそうか予見することはできそうもないが、いまわれわれプログラミング作業の本質的部分と思っているものが、将来は本質的でない記帳作業と見なされるようになるだろう、というところまでは予想できる。 なぜそんな予測ができるのか。 プログラミングの発展しは、本質的部分と思われていたものが非本質的部分に変換されることの繰り返しだった、ということを思えば、である。

これは確かにその通り。アドレス管理、プログラムのメモリへの配置。近年の例だとメモリ管理かな。プログラミング言語とOS、ツールの進化で抽象的な概念に集中できるようになってきている。

さらに言えば、仮想化技術の普及によって、ハードウェアを意識しなくなり、さらにはサーバー管理さえツールにより自動化されようとしている。 泥臭い下位レイヤからプログラマのみならずエンジニアのほとんどが遠ざけられている。

ほんの一握りのスーパーエリートプログラマ（or エンジニア）と、それ以外の二極化が進行しているのだろう。

だがコンテントが一番大切、ということは変わっていない。そして真にコンテントを向上させるような道具はほとんどない。

それはその通り。DTPの普及で見た目はきらびやかになっても、中身の文章の価値は変わらない。

あとはエピローグだけ。

続きます。

『プログラミングの心理学』をコツコツと読み進める試み その12

相変わらず続き。

audiobook.hatenablog.com

『第12章 プログラミング言語の設計原理』

プログラミング言語について、心理学的な面から生産性への影響と概観しようとする章。その試みは成功していると思う。

『一様性』

一様性の原則=Rubyでいうところの「驚き最小の原則」？

初期のFORTRANにおいて、配列のインデックスとしてKを符号なし整数とするときK-21は許容されるが、 21-Kは許容されないらしい。 あくまでも"初期の"言語仕様なんだけど、プログラマを臆病にさせるには十分すぎる。これがダメだとすると、他のケースもダメなのか？と、エラーメッセージを拝むくらいなら無難な記法で行こう、と考えたくなるのが人情というもの。

なるほど確かにプログラミング言語がプログラマの心理に影響を与えている。

著者の言う一様性というのは「同じものは、どこにあらわれても同じことする」ということらしい。まさにRuby界隈でいうところの「驚き最小の原則」である。

言語に制限事項がいくつかあると、プログラマは他にもあるのではないか、と萎縮してしまう。

あまりにもたびたび「いけません」といわれた子どもと同様、一様性の欠けた言語を使っているプログラマは新しいことを試してみようという気を無くしがちである。

なるほど。同感。何度もコンパイラからエラーメッセージをや警告メッセージを浴びせられると、どうしていいかわからなくなる時がある。 プログラムが思い通りにいかないときもそうだし、いわゆる成功体験がないと挫折してしまうだろう。

一様性のもう一つの重要な側面は、構文上同じ形をしたものは違う文脈に現れたときにも同じ意味を持つことが望ましい、というものである。

これは重要。PL/Iというプログラミング言語のカッコの数で挙動が変わる例が紹介されているが、現代プログラマの感覚からすると狂気の沙汰である。

『簡潔性」

プログラミング言語における省略（短縮系）についての話題。いろいろと例が挙げられている。 変数名のつけ方からプログラミング言語の構文として、省略時の解釈について述べている。 要約すれば、ある程度頻繁に使えるのでないと意味がないということか。

『局所性および逐次性』

ここでいう局所性というのは、プログラミング言語における変数の有効範囲と、プログラムのソースコードの字面上の記載箇所の話がごっちゃになっている。ソースコードの一箇所に変数定義が集中していた場合にどうなるか、あれこれ思索している。 ソースコードの変数の登場箇所のそばに変数定義（初期化）があったほうが、プログラムを読む上で有益だとか云々。

正直、このあたりの話は近代プログラミング言語はとっくに解決していると思う。

『伝統と革新』

プログラミング言語の設計において、既存のプログラミング言語との類似性をどこまで保つべきか、それとも自然言語、あるいはプログラマの思考との調和をどうするかについて述べている。

プログラミング言語の構文において、ある程度のルーズさ、同じ意味を持つ複数の構文の存在が有益だとも主張している。 また、言語同士の差異と、プログラミング言語の習得の容易さへの影響を論じている。

『専用言語、多目的言語、おもちゃ言語』

この種の制約が、非利用者にとって自明な割には利用者にとって自明でない理由の一つは、紛れもなくプログラミング言語が、思考過程を型にはめるという性質を持っていることによる。

これは自然言語についても同じようなことが言えるんではないかなと思う。数字の数え方とか、単数・複数の区別とか。

『まとめ』

プログラミングは数学の一分野ではなく、人が能動的な役割を、そしてコンピュータがしばしば受動的な役割を演ずる、特異なな形式を持った情報交換なのだ。

時々プログラマおよびシステム管理者はコンピュータの下僕ではないかと思う時がある。もっと言えば、雇用主とコンピュータの二重の下僕ではないか、暗い気分になることがある。こういう文章を見ると、少なくともコンピュータの主人は（プログラミング言語を使いこなす限りは）自分たちだと再認識できる、ような気がしている。

書いてあることは至極まっとうなんだけど、どうもこの章は面白みに欠ける話に思える。 1970年代に書かれた文章であることを考えると、実はすごいことなんだけど。

例としてあげられている言語が古いというのが一番大きな理由かな。

『第12章 「プログラミング言語の設計原理」へのコメント』

著者の思い出話。意外なことにワインバーグ氏はプログラミング言語の設計に関与したこと一度や二度ではないらしい。 ITコンサルタントの草分け的な存在というイメージが強いだけにびっくりした。

1970年代に東ヨーロッパを訪れたとき、私は「プログラミング言語の帝王」である、と紹介されてショックを受けた。

よほど成功したプログラミング言語の設計者でもこんな紹介はされないだろう。

あとは13章とエピローグを残すだけ。もうしばらく続きます。

プログラミングの心理学―または、ハイテクノロジーの人間学 25周年記念版