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

スーパーエンジニアへの道は 1986 年、本書は 1971 年に書かれてる。 著者のシリーズの源流が本書らしい。各章に著者の振り返りがあって答え合わせしてくれてるのもあり、読みやすい。 当時としてはプログラミング(というかシステム開発)を人間の活動から理解しようとしたのは画期的だったらしい。

2025-08-16, read count: 1, page: i ~ xv, pages read: 15

第Ⅰ部 人間の行動としてのプログラミング。 プログラミングと機械の関わりばかりが注目されてきたが、本書はプログラミングを人間的な観点から捉える。 初版から 25 年経った振り返り時点でも当時より膨大な金がプログラマーに投じられるようになっていた。現代もその高騰は続いている認識。 更にいえば AI が登場しても(一部の代替可能な層を除き)プログラマー不要論が現実にならないのは、プログラマーが単にコードを書くのが仕事でなく人間的な側面がその本質だったからって感じかな(今後は知らんが)。

2025-08-17, read count: 1, page: 1 ~ 3, pages read: 3

第 1 章 プログラムを読む。 プログラミングを学ぶ術は、書くことと読むこと。読むときには諸々の事情がコメントに残されていることは少なく、何故そうなったか知るのは難しい。 そうしたコードには、コンピュータ・プログラミング言語・プログラマの知識の制約、事故の応急処置、仕様に基づく必要・不要な記述が混ざっている。 その背後には人の心理的要因があり、理解するのに人間の行動を研究する価値がある。 サンプルコードが PL/I で時代やな～と感じる。にも関わらず現代も状況はさほど変わらない。 コードを読め、コメントには意図を残せとか諸々の手法が発展してきても状況に大差ないのは、原因が人間の心理的要因にあるからということか。

2025-08-18, read count: 1, page: 4 ~ 16, pages read: 13

第 2 章 良いプログラムとは何か。 プログラムを評価するのは難しい。 判断の絶対的な指標はなく、相対的な指標でも、仕様を満たす(動く)か・計画に間に合ったか・プラットフォーム移行の容易さ・実行効率といった複数の基準があり単純に評価できない。 良いプログラムとは何かという問題自体が適切でないと言える。 振り返りでは経済的指標も増えてなおさら難しくなってる。 ここで言う「良い」は後の著者の本でいう品質みたい。 なんかまだ「スーパーエンジニアへの道」ほど面白い感じはしないな。

2025-08-19, read count: 1, page: 17 ~ 32, pages read: 16

第 3 章 プログラミングをどのように研究するか。 プログラミングの人間的な活動を研究する術として、行動科学の手法を流用する話。 その際に行動科学の研究でも陥る内省・観察・実験・計測・利用するデータなどの誤りについて触れ、さらにプログラミング固有の難しさについても言及している。 個人でなく集団を研究すべきだというのはせやなと思ったが、まだ全体的に面白みはないかな。 1970 年代にこの内容が書かれたという点で、その何らかの派生物の影響を自分も受けてるだろうから驚きがないのかもな。

2025-08-20, read count: 1, page: 33 ~ 52, pages read: 20

第Ⅱ部 社会活動としてのプログラミング。 プログラムの多くは 1 人で書かれるものではないので、誰かと一緒に仕事することで様々な人間関係が生まれる。 この部ではグループ(別々のプログラムを開発する人々)・チーム(協力してより良い製品を開発する人々)・プロジェクトに分けて考察する。 振り返りによればチームの定義は先述の通りに改定された。多分チームの重要さからかな。 今のわたしはグループかな。許可をもらったり依頼する・されることはあれど、自分が学習してるのは確かだが周りがそうかは定かでない。

2025-08-21, read count: 1, page: 53 ~ 56, pages read: 4

第 4 章 プログラミンググループ。 公式な組織構造は往々にして機能不足であり、そのため非公式な組織がそれを補完する。 一方で組織や物理的な構造の変更が非公式な組織を破壊し、機能を損なうこともある。 プログラマーの自己同一性の未熟さは、書いたプログラムに対して認知的不協和を引き起こし、誤りを認められなくなる。 スパエンのときはやる気のある人たちが高めていくような話だったので面白かったけど、本書は今のところ未熟な人たちの底上げっぽく感じている。 自らの未熟さを知り学習するのは好きだが、未熟な人たちの底上げは興味ないから、そこが面白みを感じにくい理由かもな。

2025-08-22, read count: 1, page: 57 ~ 67, pages read: 11

第 4 章 プログラミンググループ。 自分をプログラムに投影してしまうことで感情的・防御的な反応を引き起こし、誤りを認められなくなる。 正しくフィードバックを受け入れるためにも、エゴレスプログラミングが重要であるとする。 またプログラミングの社会的環境を維持することの難しさとその弊害について。 昔からそうなんだろうが、問題となるようなプログラムや組織にエゴを持ち込むプログラマの振る舞いは、個人の未熟な自己同一性によるものよな。 本当に良くしようとして開発してるなら、そんなことを気にしてる暇ないと思うけどな。

2025-08-23, read count: 1, page: 67 ~ 82, pages read: 16

第 5 章 プログラミングチーム。 プログラミングチームを編成する際の戦略面の話。 理論上は最低限のスキルがあればよいが実際はそうではなく、最短納期でシステム開発したい場合は最高のチームで臨む必要があるとか、メンバーの余剰を持たないと不測の事態に対応できないとか。 チーム内で割り当てる仕事が原因で不合理な地位が生まれるので慎重に割り振らないといけないとか。 チームの目標設定に合意していないと、不満を持って同じ目標を目指さない人がいるとか。また圧力に屈して誤った合意に至ってしまう。 現代でもよくある話ばかり。みんな大変やなという感想。そこまでケアしてもらわないと働けないプログラマとは一体。

2025-08-24, read count: 1, page: 83 ~ 95, pages read: 13

第 5 章 プログラミングチーム。発熱であまり読めず。 チーム内でリーダーシップを取る人は外部から指名された人ではないというスーパーエンジニアへの道でも触れられていた話。 課題に合わせて民主的にチーム内のリーダーが入れ替わる。ただし機会は平等ではない。 「降りる覚悟のあるリーダーだけが、ほんとうに成功する可能性がある」某アニメのようやな。

2025-08-25, read count: 1, page: 96 ~ 102, pages read: 7

第 5 章 プログラミングチーム。熱まだ下がらず。 チームの危機はメンバー追加・交代、リーダー交代、メンバー同士の関係性など。 それの危機らはチームが民主的か権威的かで対応の難しさも変わる。 民主的なチームは人を足すのが難しい、権威的なチームはリーダーを変えるのが難しい、等。 概ねメンバーに対人スキルが要求すると考えて良さそう。あとから付けるのが技術力より難しい。 本書の当時になかった言葉だが、民主的なチームのメンバは HRT(Humility Respect Trust) を持って行動すべきだというところか。

2025-08-26, read count: 1, page: 102 ~ 116, pages read: 15

第 6 章 プログラミングプロジェクト。 プロジェクトはどのメンバーよりも長生きする。 そのため 1 人のキーマンの離脱でプロジェクトを崩壊させないよう、プログラマー加工工場のように新メンバーを継続的に育成・交替させる新陳代謝的な体制が必要。 大規模プロジェクトの成果測定は難しい。 報告が目的化し、成果がただの予測であったり、無難な数字で調整されがちで、実質的に無意味になる。 また同調圧力で順調を装う傾向があり、この解消には反論役(Devil's advocate)を据えると効果がある。 ただし反論役自身が大きな社会的圧力を受けることもあり、機能を損なわないために持ち回る等運用上の工夫が必要。

2025-08-27, read count: 1, page: 117 ~ 129, pages read: 13

第 6 章 プログラミングプロジェクト。 大規模プロジェクトを効率的に管理するために機能毎にチームを分割し、軍隊式の階層的組織にまとめる方法がある。 分割によって同じチームの目標がプロジェクトの目標と一致しなくなったり、マネージャーの偏見が評価差を生み、チーム間のいがみ合いが起こることがある。 階層毎のマネージャーは特に上位ほど現場をほとんど監督せず(できず)、自己の権威付けだけに熱心になる。 プロジェクトの失敗は殆どはマネジメントスキルの欠如による。 今は知らんが少なくとも 2010 年代でもこんな感じやったよな。だから二度と関わらないと心に決めてる。

2025-08-28, read count: 1, page: 129 ~ 144, pages read: 16

第Ⅲ部 個人の活動としてのプログラミング。 個人の活動としてのプログラミングにおける個人差を正確・知性・訓練・経験のカテゴリに分類して分析する。 著者が振り返りでいうには、時代を経てもプログラマ自体はいずれのカテゴリでも変わっておらず、ただツールやその他の要因による生産性がはるかに向上しているということらしい。 それ自体は社会活動としてのプログラミングの体たらくからも、想像するに易い。

2025-08-29, read count: 1, page: 145 ~ 148, pages read: 4

第 7 章 プログラミング作業の多様性。 プログラミングというと恋という言葉と同じくらい多義的である。 その作業の多様さは、プロ・アマの違い、プロジェクト目標の違い、作業が設計やテスト等のステージで不可分だという点に起因する。 著者は振り返りで、多様さが目に見えて明らかな今(90 年代)なら書くことはなかった、と触れている。 ただ現代でも実際にそう理解しているのは、プログラマーか否かに関わらずさほど多くないという実感がある。

2025-08-30, read count: 1, page: 149 ~ 170, pages read: 22

第 8 章 プログラマーの性格。 プログラマーの性格がプログラミングに与える影響を考察する。 例えばシステム全体を異常終了させることでオペレータの間でも評判の悪かった 2 名は、それぞれ、無知が恥ずかしくて試行錯誤を繰り返していたパターン、自己中心的で他者の意見を受け入れられなかったパターンであった。 後者のような自己学習に謙虚でない性格は、個人的な観測の範囲でも、最新技術への追随を除いたとしても日常的に同じ間違いを繰り返して改善できない。 プログラマーとして向かない性格≒学習姿勢に問題があり機能しない、ということかな。

2025-08-31, read count: 1, page: 171 ~ 173, pages read: 3

第 8 章 プログラマーの性格。 性格には変化する部分と不変の部分がある。 性格の変化に関し、外面的な変化だけで問題を特定せず、得られる限りの情報を得るのが問題にうまく対処できる可能性を高める。健康状態や私生活の悪化が性格の悪い変化を起こしているかも知れない。 外面を取繕っていたり、権威に弱い人が相手によって性格を変える場合もあるため、性格の内面を推測することには慎重に。 性格の不変の部分と要求される特性とのギャップが強いストレスを引き起こすこともある。例えばテスターは信じ深い性格だったとしても疑り深くある必要がある。非難に「順応」するよう追い込まれないように、役割を持ち回るような運用が必要となる。 プログラマーとして失敗しないタイプの性格特性としては、ストレス耐性、変化への適応、几帳面さ、謙虚、自信、ユーモアのセンス、が挙げられる。 個人的に、ストレス耐性と変化への適応は同じ要素かな。変化のストレスに耐えられる容量がないと常に変化し続けられない。

2025-09-01, read count: 1, page: 173 ~ 183, pages read: 11

第 8 章 プログラマーの性格。 本書が書かれた当時はプログラマを選別する性格テストに最適なものはなかったといえるようだ。 唯一「プログラミングが好きか」という問いだけ。 25 年後の振り返りでは MBTI(Myers-Briggs Type Indicator)が有用であると触れられている。 16 Personalities のやつか。 性格テストは偽装することができるので注意が必要だが、偽装するだけの能力があるということは向いているというのは面白いな。 SPI も同じ印象。転職に慣れてると出がらしの問題ばかりで高得点になるし、性格特性の調整もお手の物やからな。

2025-09-02, read count: 1, page: 183 ~ 190, pages read: 8

第 9 章 知能―問題解決の能力。 プログラミングに影響する知能とはなにか。 心理的「構え」がある種の間違いを引き起こす。それは誤字・ leet のような判別しにくい記号の利用・間違ったコメントなどからコード読解の誤りにつながる。 正しく問題解決の知能を測るには問題回避についても同様の測定が必要だが、起こっていない現象を評価するのが難しい。他に記憶力。 「構え」は認知バイアスのことみたい。 昔 4GL のエディタがフォント変えれなくて本書に書いてるような 0 と O の間違いをしてバカにされたのを思い出したわ。そういう「気を付ける」問題じゃないねんよな。 今は気合で認知バイアスを回避するような時代ではないから、どう誤りうるかを知り、フォント変える等の誤りが発生しにくい習慣を身につける方が重要やろうな。

2025-09-03, read count: 1, page: 191 ~ 200, pages read: 10

第 9 章 知能―問題解決の能力。 プログラミングに必要な知能を測る適性検査(PAT)とその効果がないことについて。 振り返りによれば本書のレビュワに適性検査の事業に関わる人がいたため出版社を満足させるために適性検査について書いたらしい。 現代であればはコーディングテストやディスカッションがプログラマを「オーディション」する術になるのかな。 とはいえわたしはそれらも苦手で嫌いだし、何より値踏みされるのが嫌なので、なるべくそういうのに関わらずに生きたい。

2025-09-04, read count: 1, page: 202 ~ 212, pages read: 11

第 10 章 動機づけ・訓練・経験。 すべての訓練・経験の要素を計測に含んでもプログラマの成績を説明できない部分が動機づけ。 動機づけが過剰すぎてもプレッシャーとなっていけない。金銭などの外的動機づけよりプログラマーの好きにやらせる内的動機づけの重要性。 教育は一般原則とスキルを身につけるため、訓練は具体的なスキルを身につけるためだが、訓練を前提にしないと教育できないものもある。 学習を妨げる力。失敗を見られることを恐れる。「行き止まり手法」に固執して新しいものに対する恐怖。弱さを認められない。 動機づけはスパエンへの道で十二分に見たので、本書の初期の動機づけに関するアイディアからは目新しく得るものはないかな。

2025-09-05, read count: 1, page: 213 ~ 227, pages read: 15

第 10 章 動機づけ・訓練・経験。 プログラミング学習における独学。自分の好みの学習スタイルを知っている人は稀である。 独学においては計算機が提供するエラーなどの情報を余すことなく利用することが必要となる。 また業務においては実務を優先するだけでなく学習で得た見識を反映していくバランスが重要。 思うに、昔であればマニュアルから学ぶしかなかったが、今は計算機が身近になり、エディタのサジェストや AI を教師にすることで独学を追求する術が増えている。 となればあとは本書でも触れられている自身の動機づけと学習スタイルの理解さえあれば、効果的に独習できる。 時代の移り変わりの影響が大きい部分だし、著者は既に亡くなられているので実現しないが、 50 周年記念版の振り返りも見てみたかったな。

2025-09-06, read count: 1, page: 227 ~ 236, pages read: 10

第 Ⅳ 部 プログラミングの道具。 腕の良い職人でも欠陥があったり悪い道具を使うと二流の仕事しかできず職人も二流になる。 プログラミングでも同様に言語のような道具を正しく利用することで良い仕事ができる。 個人的に、この話題が出ると必ず弘法大師も実際には筆を選んでいた話をするが、案外伝わらない。それ以前に仕事で関わるプログラマには道具の特性を意識しない人も多い。 仕事ではプログラミング言語等の技術スタックを選べないこともままあるが、道具の欠点を知っていれば後付のツールで補完できることもある。当然道具自身の特性をカバーするのは楽ではないけど。

2025-09-07, read count: 1, page: 237 ~ 240, pages read: 4

第 11 章 プログラミング言語。 心理学的な意味で人間向けに設計されていないプログラミング言語が人間と機械のコミュニケーションエラーを引き起こすというような内容。 あと習得済み言語のサンクコストが新しい言語へ移行する心理的なハードルになるという話。 なんとなくだが、本書の執筆当時だと機械語・アセンブリ・原初の高級言語という感じだったので、自然言語でプログラミングすることへの憧れがあったのではないかな。 生成 AI が自然言語を受けて代わりにプログラミングする時代になって、文字通り自然言語でプログラミングする時代になってきているが、自然言語のような曖昧化しやすい言語でプログラミングするのにどうにも違和感がある。 具体的な指示を詳しく自然言語で書くより、形式化された DSL としてのプログラミング言語を利用することの方が効率的でない？ 逆パターンもある。今多くのプログラマは AI に書き散らしてもらった大量のコードをレビューしてるけど、自然言語だと中々レビューも難しいんじゃないかな？どうだろう。 達人が道具を選ぶ際に汎用的な道具を選ばずに特化した道具を使うのと同じ気がするのだけど、わたしの先見性がないだけなのかな。

2025-09-08, read count: 1, page: 241 ~ 254, pages read: 14

第 12 章 プログラミング言語の設計原則。 統一性がある構文でなければ、ヒトは例外パターンを記憶しきれず自分の能力に不安を感じる。 その心理的曖昧さのため、探索的にいろんな機能を使えなくなり、過剰なカッコを使う等の防御的な行動を起こす。 ただし統一性に関する責任の多くはプログラマー個人の仕事(名付けやスタイルの非統一性)にある。 この章の話題はプログラマー脳で触れられていたものと同じか。 やろうと思えば構文ルールの統一性は何らかのメタな検査器で検査しうるだろうけど、名付けの統一性を測る術はプ脳でも命名の雛形を作るとかのヒトの頑張り次第な印象だった。 人がプログラミングし続ける限りずっと付きまとう課題なんやろな。

2025-09-09, read count: 1, page: 255 ~ 263, pages read: 9

第 12 章 プログラミング言語の設計原則。 チャンキングによってプログラミングの理解をコンパクトにできる。これはデータ構造を定義して使うこと等でも同様。 プログラムの局所性・線形性はヒトの記憶でいう共感覚記憶・逐次記憶に対応する。 局所性を高めることはコードそのものの理解を助け、線形性を高めることは順序立てた処理の理解を助ける。 やっぱプ脳と重なる分野の話。共感覚記憶・逐次記憶は触れられてなかった記憶だが。 時代を考えると相当進んでるな。

2025-09-10, read count: 1, page: 263 ~ 273, pages read: 11