『プログラミングの心理学』を読んã

在宅の日々、だいたいラジオをきいて過ごしている。radikoだけでは飽き足らず、この世のすべてのラジオアプリをインストールし、Podcastをダウンロードし、耳から注入している。

shop.nikkeibp.co.jp

先週読んだCode Completeにおいて、複数の章で参考図書として紹介されていた。著者はGerald Weinberg氏で、ソフトウェア界における偉人の一人。著作では『ライト、ついてますか』も有名っぽい。

初版はなんと1971年。磁気テープを用いた開発や、プロジェクト例などは歴史を感じさせる。本筋であるプログラマの心理面の問題意識や実験結果、考察は、いま読んでも古さを感じない。そのこと自体が、本書のテーマが本質的な問題であることを示唆している。一方、プロとアマチュア、マネージャとプログラマ、また（職業人としての）男性と女性を区別した記述がやや軽薄に感じた。これは著者の不足ではなく、プログラミングに関わる、あるいは一般に人間の心理という領域が、当時の状況や著者が想定したよりもはるかに複雑だった、ということなのだとおもう。

本書の重要な目的はただひとつ。新しい研究分野を切り開くきっかけを作ることだ。(204)

プログラミングの心理学という領域を切り開きたい、ということだが、前述のとおり、現状をみるとその領域はまだまだ問題を解決するには至っていないと感じる。当時はおそらく「プログラマを人間として扱う」という発想自体が新しかったのかもしれない。

第1部 人の活動としてのプログラミング

プログラムに対するあらゆる要求の中で、何よりも重要なのは「正しい」ことである。(p.19)

プログラムが「動く」というのは、「コンパイルできて実行時にエラーにならない」ということではなく、「正しい」ということである。他のあらゆる要求、例えばパフォーマンスやコードの綺麗さは、正しいという前提の上に追求されるべきものである。当たり前のことのようだけど、認知的不協和の観点からも、しばしば正しさよりもそれ以外がプログラマの時間を消費する。

私は長年かけて、本章の事例を一般化した品質の定義にたどり着いた。品質とは、誰かにとっての価値である。(p.30)

要求を満たした上で品質を追求するのだけど、だれにとっても価値のない、あるいは勝ちを決める人にとって価値のないことは、品質の向上に寄与しない。きれいなコードを書くことが自己満足と揶揄されるのは、このあたりの不理解により起こる。ある人からみると「きれいなコード」は将来の開発生産性に寄与することを想定しているが、他の人からみると、その意識がないかもしれない。「なぜそうするのか、そうするべきだと思うのか」を言語化するのが大事っぽい。その合意なく、立場や性格の差異により非難されたり修正を強制されるのは、一番ダメ。

第2部 社会活動としてのプログラミング

25 年前と同じく、個人差はプロジェクトの予測可能性にとって大きな障害である。(p.52)

まさに『人月の神話』というかんじ。個人差が生まれないということは実質ありえない。予測可能性は経験から導くしかない。対策があるとするなら、それがプログラミングの社会的素養、つまりチームを組成することだと思う。人間を交換可能なリソースとしてではなく、ここの人格として理解を深め、その前提で計画をたてる。

人間の目には、見たくないものを見ないという無限の能力が備わっているのだ。(p.67)

コードを書いた人間と、それをテストする人間は、可能な限りの努力を持って分離すべき。同一人物がやる場合は、疎結合にしておく。典型手法として、テストを事前に書く、あるいはテストの項目を作り、他者のレビューをとおす。自分が人間であり、そういった性質を持っていると自覚することが重要。

どのような人が有力なリーダーになれるのだろうか。前にも述べたように、それはチームに要求される仕事による。(p.107)

プログラマと同様にリーダーもまた人間であり、個人差がある。プロジェクトの要求が「多少品質が悪くても早く完成させること」なのか、「最高品質で完成させること」なのか、その間なのかで、そのプロジェクトをリードするべき人間の性質は変わってくる。要求を見極めアサインすることはもちろんだが、アサインされたリーダーがその要求を理解し、自身をフィットさせていく、その領域を学ぶと明示的に意識することも、同様に重要にかんじる。

長期にわたって安定したプロジェクトを完遂するには、マネジャーはプロジェクトを一種のプログラマー加工工場のように機能させなければならない。(p.122)

プログラマは自分の知識を駆使したいという欲求が生まれる。別の問題、あるいはより高レベルの問題を解決したいと思うようになる。同一のプロジェクトに特定のプログラマを留まらせることは、その欲求に反することになる。また、その知識を必要としている他のプロジェクトにとっても機会損失になる。このあとにもでてくるが、そもそもプログラマを「選別」するのではなく、「学習」に主眼を置くべきである。

第3部 個人の活動としてのプログラミング

「プログラミング」は、「恋」と同じように、限りなく多様な活動を意味する言葉である。(p.149)

急にロマンティック。その経験がない人間からみると、プログラミングという行為が、「キーボードを通じて画面に文字を打ち込む作業」を意味すると取られかねない。実際にその作業をしているのは、体感で1割以下だったりする。また、プログラミングをして価値を生み出しているつもりでも、その前段の要件や設計が的外れで、価値が無に帰すこともある。そのあたりも恋と等価である。

パーキンソンが「仕事量は与えられた時間いっぱいまで増大する」と言ったのは、スケジュール目標の存在そのものが仕事の速さに影響するということを私たちに気づかせようとしたのだ。(p.160)

いわゆるパーキンソンの法則というやつで、いまでも健在であり、普遍的な課題であることがわかる。計画ギリギリになる人は、仮にその計画がゆるめに設定されていたとしても、変わらずギリギリになる。通常、「キツめの計画で少しオーバーする」よりも「ゆるめの計画でまにあう」ほうが1億倍評価されるので、計画をたてる側としては、なるべくゆとりをもちたい。管理側としては、はやくしてほしい。利害が衝突するのはしょうがない。その計画が結果的にどうだったかに関わらず、計画時点で合意していることが最も重要そう。

それぞれのプログラマーに、 最も 苦手 な部分のスペシャリストになるよう指示すると、学習の速度は最大化する。(p.164)

この発想はあまりなかった。ソフトウェアを開発する工程における不確実性を前提にすると、そもそも苦手としている部分が、本当に苦手かどうかがあやしい。コミュニケーションが苦手、と言っている人は、単にコミュニケーションの技術を学習してきていない、その方法を知らないだけかもしれない。それはもったいない。パレートの法則しかり、100点を目指すよりは能力の標準偏差を下げるほうが、少なくとも組織における価値を最大化する有効な戦略だとおもう。そのためには、まず何が苦手かを知る必要がある。ここでも前述のとおり「人間は見たくないものを見ない」ので、周囲からのフィードバックや、客観的な自己評価をがんばる。

求職者に、プログラミングが 好き かとたずねることを考えたことがある人はいるだろうか。(p.188)

これもわりと盲点だった。プログラミングの適正があるかどいうかを、あの手この手の試験や心理テストで判断しようとするより、本人に聞けばよい。説得力を持った説明を提供してくれること自体が、その資質といってもいい。

私の生徒になりたいと希望する学生に対するテストで私が知るかぎり最も強力な方法は、母国語を完全にマスターしているかどうかを見ることだ。それには、学生の話を聞くだけでよい。(p.210)

ダイクストラ氏のお言葉。母国語と完全にマスターしているというと、簡単そうだが、実際にこれ以上高いハードルはないとおもう。論理をマスターしていると同義であって、ダイクストラ氏に対して論理的に筋のとおったスキのない話をすることができれば、またそれが判断できれば。いまリモートワークをしていて、実オフィスにいるとき以上に、説明能力が浮き彫りになっていると日々かんじている。伝えるべき情報を任意の言語で伝えることができる能力が要求される。

第4部 プログラミングの道具

何かを学ぶ方法を学ぶための第一歩は、自分の資産と負債を学ぶこと、「汝自身を知る」ことである。(p.227)

現在の上司にあたる人物が、3年くらい前に、「自分のことを優秀とは思わないが、自分ができることとできないことはわかっている」と言っていたのが強く印象に残っている。自分というリソースを最適に活用する方法を考えている、という話だったのだと思う。

プログラミングは数学の分派ではなく、人間が積極的な役割を担い、コンピュータが時に受動的な役割を担う独自のコミュニケーション形式である。(p.285)

プログラミングは確かに言語表現であるが、一般に人と人とのコミュニケーションとは性質が異なる。例えば、我々はプログラミング言語を用いてコンピュータに情報を伝えるが、コンピュータはその言語を用いて我々に語りかけない。つまり双方向ではない。ただ、本書とは時代背景が異なり、プログラミングは同僚や未来の同僚、あるいは未来の自分という人間に対して情報を伝える、より人間同士のコミュニケーションに近い様相を呈してきていると思う。

第5部 エピローグ

あなた がコンピュータで行っていることは、やる価値のあることだろうか。(p.324)

本質 of 本質。著者は、自身の本を参考に非倫理的な動物実験が行われた（可能性がある）、ということを知った。各位は、日々プログラミングをしている目的について自覚し、その価値を説明できるだろうか。