『プログラミングの心理学』をコツコツと読み進める試み その1
書評ではなく読書メモです。対象が対象だけに一気に読めそうにありませんし、購入したのは2008年。
購入後、7年近く積ん読状態だった本をこんどこそ読もうかと。
他人の目というプレッシャーを使ってどうにか読破しようと思います。
タイトルの通り、対象はコンピュータ関連では名高いジェラルド・M・ワインバーグ氏の名著、「プログラミングの心理学―または、ハイテクノロジーの人間学 25周年記念版」。 事情はよくわかりませんが、毎日コミュニケーションと日経BPからそれぞれ出版されています。私が手元に持っているのは2005年の毎日コミュニケーション版。
原著は、"The Psychology of Computer Programming Silver Anniversary Edition"。 原著が1971年の初版に25周年時点のコメントを追記した構成で、翻訳版も同様になっています。
本書は5部構成、13章に分かれているので、各章ごとに読書メモを書いていこうと思います。*1
今更ワインバーグかよってツッコミは勘弁してやって下さい。
『まえがき』についてのメモ
1971年版の「まえがき」（p.18）より
この本の主な目標はただ一つ、新しい研究分野をスタートさせることである。
なかなか面白書き出しですが、25年版の「まえがき」にあるように、著者にとっての新しいスタートなのでしょうか。 現状の日本において、ソフトウェア開発工学はあっても心理学は聞いた覚えはないです。 ただ、ユーザーインターフェイスにおいては「ユーザー心理」を考慮するようになっているかと思います。
「はじめに」で私が驚愕した文章。
著者らの経験に少しでも意味があるとすれば、プログラマ自身とその管理者が、彼らをもう一台の機械としてではなくひとりの人間と見るようになるなら、彼ら一人一人がより効率よく働き、そしてより深い満足を覚えるようになる可能性があるのだ。
私が某SIerに3年在籍していたときの違和感の一つがまさにこの文章にあります。 人間の感情をこれっぽっちも理解していないんですよ。部下が無条件に指示に従うのが当然と思っているというか。日本に限った話でもなく、幼稚な考えと言われても仕方がないですけど。
給料を貰うからには、仕事をするのは当たり前なんですけど、理不尽がまかり通るというか。（この辺りは読書メモを通り越しているので別の機会に書きたいと思います。）
上手く説明できませんが、「納得感」が欠落したまま「仕事だから」と無理やり自分を押し殺してまさに機械のごとくプログラムを書いていたことがあります。 プログラミングに限らず上司の言うことを素直に聞く部下というのはある意味、もう一台の「機械（machine）」なのかも。
『第一部 人の活動としてのプログラミング』についてのメモ
第一部のまえがきみたいなもの。
多年にわたって経営層は、プログラマを取り除きたいという彼らの願望に、呆然とするほど多額の投資をすることによって裏付けを与えてきた。
「プログラマを取り除きたい」というより「プログラマにかかる人件費を減らしたい」ではないかと思います。この文章から読み取れるのは、プログラマ＝（高額な）人件費、すなわちコストとして捉えてきたということなんでしょう。その上で、利益を出すために、高コストな人材であるプログラマを減らしたいと考えていた。
逆に言えば、経営層が（少なくとも私が在籍したSIerがそうしているように、）プログラミング（コーディング）を誰が担当しても同じであり、下等な作業と捉えてきた、というようにも解釈できるように思います。確かに会社のベテラン社員からは「ウォターフォールで開発コストを削減するならコーディングかテスト工程だ」と聞いたことがあります。
これも私がSIer時代に感じていた違和感の一つです。
早い話がプログラマの生産性、優劣にそれほどの差は存在しない、プログラマ（コーダー）は容易に交換可能な人員という考え方でしょう。
この考え方には個人的にかなりの疑問を持っています。
『第1章 「プログラムを読む」』についてのメモ
さまざまな制約
3番目はプログラマがプログラミング言語の提供する便利な記述法や高度な機能、あるいは最適なアルゴリズムを知らないというパターン。
仕様
仕様はプログラムおよびプログラマと共に進化する。プログラム書きは、プログラマにとっても、またプログラム発注者にとっても、一つの学習プロセスである。
若手に経験を積ませたいという、上司の親心のために、とんでもない構造欠陥ミドルウェアが生み出された事例を、私は知っております。 詳細についてはお察しください。
この文章の「プログラム書き」というのは設計からコーディングまでを指していると解釈するのが自然かな。 すでにあるプログラムと同じプログラムを作れ、というケースよりは、今までにないプログラム or （他社の後追いであるにせよ） 今まで自社で作成したことのないプログラムを作れというケースが一般的でしょうから、発注側も受注側も手探りである場合がほとんどでしょう。
ソフトウェア開発が遅れる理由の一つが垣間見えるように思います。
『まとめ』についてのメモ
プログラムを本当に読んでみると、ある部分はコンビュータ側の制約ゆえに、またある部分は言語側の制約ゆえに、またはプログラマ側のゆえに、または歴史的な事件ゆえに、そしてまたある場合には（有意義な、または無意味な）仕様ゆえにそうなっているのだ、ということに気づく。（p.43）
『設問』
読者向けのワークからひとつだけピックアップしておきます。
もし読者が第一線の管理者であるなら、読者は部下のプログラマが書いたプログラムを読む能力を持っているか。 または、読者の能力は何世代かにわたる機種または言語の変遷につれて衰退したか。 もしその能力があるのならば、読者は彼らのプログラムを読んでいるか。 もし読んでいないのなら、やってみて、何がわかるか見てみたらどうか。
これもなかなか厳しいところをついていますね。私は末端のワーカーだった訳ですが、自分の書いた仕様書やコードを レビューするのは同僚または係長相当のポジションまででした。
つまりですね、ボーナスや昇給を左右するのは「締め切りを守ったか」、そしてなにより「評価面談シート」という名のExcelファイルでした。まあ、そういう会社だったということです。
『第1章 「プログラムを読む」にへのコメント』（※ 原著者のコメント）
面白いことに、優れた開発者ほどウォークスルーインスペクションに価値を見出し、そうでない開発者は価値を見出さないものだ。 だから、いつものことだが、優れた人々はますます腕を磨き、駄目な連中はますます駄目になっていくのだ。（p.46）
いまひとつしっくりきませんが、腕に実力のある人ほど批評を恐れないし、自分（の書いたプログラム）をさらけ出せる、ということか。 確かに堂々とgitリポジトリを公開している方はどんどんとレベルアップしているように見えます。
愚痴くさいメモになってますが今日はここまで。
*1:申し訳ないですが、順調に行くとこのネタで2週間続きます。
