「プログラミングの心理学 または、ハイテクノロジーの人間学」の概要

本日、読み進めていきたい本は「プログラミングの心理学 または、ハイテクノロジーの人間学　25周年記念版」です。原題は「The Psychology of Computer Programming. Silver Anniversary Edition (1998)」になっています。

この書籍はプログラミングを人の活動とし、その人間に焦点を当てた初期の本のうちの一つです。

著者は前書きにおいて以下のように語っています。

現在働いているプログラマは何十万人にものぼっている。著者らの経験に少しでも意味があるとするならば、プログラマ自身とその管理者が、彼らを一台の機械としてでなく一人の人間としてみるようになるなら、彼ら一人一人がより効率よく働き、それにより深い満足を覚えるようになる可能性があるのだ

この人間に焦点をあてる思想はXP、アジャイル、スクラムとった現代の開発手法につながりますし、それらの開発手法をとっていない組織であっても、優秀といわれる管理者にとっては意識的、無意識的…いずれにしても心得ている常識になっていると思います。

それらの「人間に焦点をあてる思想」に興味を持っている方にとっては本書は、おそらく自身の活動に有用なヒントを与えてくれると思っています。

なお、日本では現在、入手できるのは以下の訳書が入手できます。
https://www.amazon.co.jp/dp/4839915946
https://www.amazon.co.jp/dp/B00F0FQ8C4

著者　ジェラルド・M．ワインバーグについて

（amazonの画像より）
ジェラルド・M．ワインバーグ(Gerald Marvin Weinberg ('Jerry'),1933年10月27日-2018年8月7日)はコンサルタント、プログラマー、技術リーダー、そして管理者の役割について数々の記事や書籍を出したアメリカのコンピュータ科学者であり、コンピュータソフトウェア開発の心理学と人類学の著者であり教師です。

以下のようなエピソードがあります。

• 学生のころクローン病にかかり、治療のために処方されたモルヒネで薬物中毒になった。
• 1956年からIBMで働いている
• 米国の最初の人類宇宙飛行計画の労働者の一人でオペレーティングシステムの設計と実装をおこなっていました。参考
• 数々の書籍を出版。日本でも、大きな本屋にいけば、彼の書籍は数冊みつかります。たぶん「ライトついてますか」か「ソフトウェア文化を創る」シリーズのなんか。
• 幼少のころより、ピンボールを鍛え続け、市のチャンピオンの栄光を勝ち取り、近所の子供らに尊敬されていた。
  • なお、その栄光は１２歳のチビに奪われた模様。
  • ビデオゲームは苦手の模様。

その他、著者について深く知りたい場合は、Wikipediaやワインバーグ自身のホームページに記載があるので参照してください。
https://en.wikipedia.org/wiki/Gerald_Weinberg
http://www.geraldmweinberg.com/Site/About_Jerry.html

読み進める上での留意事項

日本の書籍においては、すくなくとも4つの時間軸の人間がかかわっていることを留意して読み進める必要があります。

• 初版(1971年)
• 初版の訳(1994年)
• 25周年版(1998年)
• 25周年版の訳(2005年)

つまり令和の時代の目線だけで読み進めると、いくらか読み誤ることがあります。
たとえば、プログラミング言語にしても当時はC言語(1972～)の誕生より前に執筆されており、本書で触れられるプログラミング言語はFORTRAN(1956～)であり、COBOL(1959～)であり、PL/I(1964～)です。
Fortran、COBOLあたりは現在でも、プログラミングの環境を作成することは可能かもしれませんが、PL/Iに至っては努力はしましたが無理でした。
※いくつかPL/IをWindowsやlinuxで動かす方法がありそうでしたが、あきらめました。

そして、現在と違ってパーソナルコンピュータが出たか出ないかの時代なので、プログラミングの実行にある種のコストがかかり、試行錯誤が難しい時代であったことは留意しておく必要があります。

また、技術的な側面だけでなく社会的な側面でも当時の状況を考慮して読まないと読み誤る箇所があります。たとえば1970年ころは女性解放運動の最中で、現代では問題になるような表現があります。「管理職が女性だった時」の話や、技術者の配偶者を「妻」という表現をしているのは、おそらく現代では異なる書き方になっているでしょう。

プログラミングの心理学またはハイテクノロジーの人間学

これより本書の2019年時点の私の解釈を述べていきますが、主観が多分にふくまれており、おそらく、別の人間が読んだ場合と異なります。

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

第一部ではコンピュータプログラミングが人間の活動であることとし、その活動を人間の立場から考えるための機会をあたえるものになっています。

第1章 プログラミングを読む

プロジェクトの途中で参画する場合、我々はプログラミングを読むことがあります。
また、レビューの際にも人のプログラミングを読むでしょう。

この章では、そういった時のためのヒントがかかれています。

たとえば、不可解なコードにあった場合、今時点の自分の視点だけ安易な評価や判断をする場合があります。
これについて「コンピュータ側の制約」、「言語側からの制約」、「プログラマ側からの制約」、「歴史的痕跡」の視点について考慮する必要があることを述べています。

これらの具体例としては以下のようなものになります。

コンピュータ側の制約の例としては大量のメモリを確保できないので、あえて冗長な書き方をしている場合などです。

言語側の制約としてはプログラミング言語で、できなかったことです。たとえば今のJavaScriptではletやconstで宣言すべき箇所が、varで宣言されている場合などがコレに当たります。

プログラマ側からの制約っていうのは、VBAでいうとCollectionなどの存在を知らないため、なんでも配列で処理しようとしているなどの「言語や機能を知らない」ところから発生している問題です。

歴史的痕跡の例としては、長いプロジェクト期間で昔あった機能がなくなったとか、「暫定対応」とか「臨時対応」が必要だったとかがあります。

いずれにせよ、「なんでこのプログラムはこう書いてあるか」という自問が肝要です。

昨今でも、レビューやペアプログラミングで言われているように他人のプログラムを読む重要性が増しています。そして、構成管理や改訂履歴やレビューツールの発展などで、プログラミングを読みとく行為はマシな状況になっているといえるでしょう。
しかし、半世紀前にワインバーグ氏が示したプログラムを読むコツについての提言は、それらのツールよりも重要なものになると思います。

第2章 よいプログラムとは

プログラムのよしあしを語るのは簡単なことではありません。プログラミングは人の複雑な活動だからです。
たとえば、一見エレガントといわれるプログラムであっても、要求仕様を満たしていない場合、それに価値があるのか、例えば必要なスケジュールに間に合わなかったものに価値があるのか、将来の変更に適応できない場合はどうなのか、効率が悪い時はどうなのか、これらは簡単に答えられるものではないです。
すくなくとも本書において、「よいプログラム」とか「よいプログラマ」といった言葉を合意が得られる、得られる可能性がある、それが望ましいという顔で使うのは慎んでいます。

重要なのは、この章の巻末問題で、管理者とプログラマに、先にあげた要求仕様やスケジュール、適応力、効率といった要素をどう考えるか問うているところにあります。

それぞれが、それぞれの立場で自分なりの回答を考えることが重要であり、おそらく、このことは50年近く前から変わっておらず、50年後も変わっていないでしょう。

第3章 プログラミングの研究方法

50年前は人の活動としてのプログラミングの研究は少なく、どのようにすすめていったらいいかという考えが記述されています。
おそらく、現在は当時とことなり、ある種のスマートな答えが用意されているかもしれませんが、ここでのワインバーグ氏の思考は、計測できない複雑なものに対応するための思考方法のヒントとなりえると思っています。

初版から25年後の補足として興味深いのはホーソン効果（観察されているという事実が、しばしば人々の成績向上に向けて動機付けする）という話のなかで出てくる下記の発見です。

こういった経験を通じて、私は管理の心理学に関する一つの基本原理を発見した。「人々に注意を向ける管理者はよい結果を得る」というものだった。

この人々に注意を向けるという考えはトム・デマルコのデッドラインの正しい管理の四つの本質にも通じるものがあると思います。

正しい管理の四つの本質
　　　・適切な人材を雇用する
　　　・その人材を適所にあてはめる
　　　・人びとの士気を保つ
　　　・チームの結束を強め、維持する
　　（それ以外のことは全部管理ごっこ）

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

この部ではプログラマの集団を３種類にわけて語られています。

• プログラミンググループ
  • 同じ場所で、おそらくは同じシステムを使っているが、別々のプログラミングを作っている集団
• プログラミングチーム
  • 一つのプログラムを共同で開発しようとしているプログラマ集団である。
• プログラミングプロジェクト
  • プログラマの集団と支援部隊を合わせたグループであり、それはしばしば、システム支援、標準化、文章化などのための特別なチームを持っていることもある。

この辺りの分類は歴史的な側面があります。現在はコンピュータを個々人が持つことになっており、計算室というものがあって１つのコンピュータを共有して使用するという姿は見ないものになりました。また、技術的進化でリモートワークなどが可能になり、当時の環境とは大きく異なります。

50年前ではプログラミンググループを「 同じ場所で、おそらくは同じシステムを使っているが、別々のプログラミングを作っている集団」と定義していますが、「同じ場所」という制約はインターネットの発達により解除されたものと考えられます。50年たった今で、ワインバーグ氏が、この部をどう構成しなおすかというのは興味があるところでありますが、それは50年後の読者の宿題となるでしょう。

第4章 プログラミンググループ

プログラミンググループは、プログラミングチームやプログラミングプロジェクトといったものと性質がことなります。プログラミングチームやプログラミングプロジェクトはある種の共通の目的のために公式に作られるものですが、プログラミンググループはある種、非公式の結びつきになります。

非公式な組織

本書で非公式な例で出てくるのは大学の計算機センターの共用スペースの自販機のまわりでぺちゃくちゃやっている連中の例をあげています。外からははた迷惑なおしゃべりにしか見えていなかった集団でしたが、実際のところ、プログラミングの相談をコーヒーを飲みながらおこなっており、学生は問題を解決しあっていたのです。

本書ではいくつかの非公式的組織の事例をあげ次のようにまとめています。

これらの物語の要点はこうだ。非公式的機構は必ず存在する。それを理解せず物事を変更するのは危険だ。でないと、円滑に働いていて、同程度の費用では置き換えが効かないようなシステムを混乱させてしまう恐れがある。

エゴレス方式(エゴレスプログラミング)

プログラマは作ったプログラムに多かれすくなかれ執着します。少なくとも私は、ある程度の執着は持ちます。
本書では、この執着が、が強くなると自身のプログラミングが間違っていることを受け入れなくなっていくということを事例を交え解説しています。

これらのエゴの問題に過去の偉人はどう対応したのでしょうか。
本書ではジョン・フォン・ノイマンの事例が紹介されていました。

エゴの問題を克服したプログラミンググループは実在している。事実それはコンピュータ技術の最初期から存在していた。自分は自分のプログラムを調べる能力がない、ということに気づいた最初のプログラマは、恐らくジョン・フォン・ノイマンその人である。彼の知人たちが伝えるところによれば、彼は絶えず自分がいかに下手くそなプログラマかを力説し、しょっちゅう人にプログラムを押し付けては、読んで間違いや下手のところを見つけてくれ、と頼んだという。

自分自身のプログラミングの間違えは見つけられないと自覚していたのです。凡人たる我々が自信の完璧さを信仰して分の悪い賭けをおこなう必要はないでしょう。本書では、作成者は自身の成果物より一歩さがって他人から改善点を指摘してもらうというエゴレスプログラミングを提唱しています。

これは、後世のピアレビューやXPのペアプログラミング、ひいてはオープンソースの文化につながる考えの原点の一つと考えられます。

なお25年後にワインバーグ氏は「エゴレス方式」について下記のように記述しています。

プログラミングにおける「エゴレス」方式の概念は原著にあらわれたすべての概念のうちで恐らくもっとも多く引用され、誤解され、否定されたものである。私は何度となく、この部分はもっと説得力豊に書けなかったものだろうか、と考えた「less-ego programming」、つまりエゴなしのプログラミングでなく、エゴを少なめにしたプログラミングという名前にしておけば、論争を引き起こさずに済んだかもしれない。または、もっとたくさんの例題、またはもっとよい例題が必要だったかもしれない。または、実験的証拠がもっとたくさん必要だったかもしれない。

第5章 プログラミングチーム

一人の人間では満たしきれない作業要求にこたえて作られるべき、プログラミングチームの理論については半世紀前から、ゆっくりでありますが確実に進歩していると思います。

チームビルディングやファシリテーションについて、この半世紀で様々な書籍や社会的実験結果が積み重ねられてきました。
一部の優れた組織や、管理者はそれらの教訓を生かしていますが、平均人においてそれらが浸透しているとは言い難い状況です。

ワインバーグ氏は25周年版でコメントを残しています。

プログラミングプロジェクトにおける最悪のやり方は（それが今日もっともふつうのやり方になっているのだが）訓練生の大群を雇って圧力をかけ、監督なしではたらかせるというものなのだ。

ここ１０年ほどでこの最悪のやり方は消えたように見えますが、二番目に悪いやりかたは依然として、続いていると語っています。

あちこちから契約社員（実は化けの皮をかぶった訓練生かもしれない）の大群を雇ってきて圧力をかけ、監督なしで（または過剰な監督つきで）働かせる

残念ながら、氏の残したコメントは四半世紀後の令和の時代でも依然として続いていることから、いまだこの章は多くの人間にとって有用なヒントを与えるものになると思います。

第6章 プログラミングプロジェクト

２つ以上のチームが目標を達成するために協働するというならば、より複雑な事態になることは簡単に想像できます。
この章に書かれている「変化を通じての安定性におけるキーマンこそ早くおいだせ」や「作業成績の測定におけるチームリーダたちの極端な値を排除して呼び出さるのを回避する心理」など様々な教訓が得られる章ですが、特筆すべきは25周年版のコメントでしょう。

四半世紀にわたってソフトウェアプロジェクトに関わってきた者として、私はオーストリア式軍隊モデルが（少なくともたいていの管理者の頭の中では）いまも主流を占めていると、確信できる。誰が誰に命令するかといった具体的な細部は当時とは違っているようだし、当時のやりかた自体、もとのオーストラリア陸軍での状況とは違っていたに違いないとはいうものの、である。ただし、現在ではほかのモデル、特にプロジェクトの成功のための不可欠の中核部分としてチームワークを強調しているようなモデルについて話したり文章に書いたりすることも許されるようになったのは喜ばしいことだ。

さらに時代の進んだ、令和の今現在も、完全で完璧な状況ではありませんが、チームワークについて論じることがあたりまえになってきたとは思います。
少なくとも、個別の事例はともかく、Twiiterや、はてな匿名ブログで「弊社がオーストリア式軍隊モデルを採用している件」とか書いて投稿すれば、恐らくは炎上するでしょう。

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

第7章　プログラミング作業の多様化

プログラミングとひとことでいっても、それはしばしば、本書では、もう少し細かいカテゴリーに分類しています。

• 問題の定義
• システム分析
• フローチャートの作成（今の時代なら設計になるでしょう）
• コーディング
• テスト
• ドキュメンテーション

現在では、これらの多様化はより進み、環境の構築や、構成管理、自動ビルドや自動テストのメンテナンスなどの話も追加されるでしょう。

さらにここであげた作業もさらに細かくわけることができます。
たとえば、テストといった場合、「テスト仕様書を作成する」という作業、「誤りを見つける」という作業、「誤りのありかをみつける」という作業、「誤りを直す」という作業があるわけです。

こういった多様な多面にわたった作業に秀でている人間がいないわけでないですが、多くの場合、そういうことは難しいでしょう。
これらの多面性、多様性は、先にあげた「よいプログラム」とはなにかと考えるのが難しいのと同様に、「よいプログラマ」とはなんであるかということを、絶対的尺度で表せないことを示します。

第8章　性格上の要因

この章であげられた性格上の要因が、プログラミング作業に与える影響の例はためにはなりますが、いささか古くもあります。

事実、著者が25年版に述べている通り、もう一度書き直すならこの章が一番変わることになるとあり、後年発売されたワインバーグのシステム行動法ではMBTIモデルをソフトウェア制御の仕事に関連付けた話が記述されています。

第9章 知能ないし、問題解決能力

この章では、問題解決能力の話が出てきますが、これは後年、氏が発表した名著「ライトついてますか—問題発見の人間学」の種になっているでしょう。

プログラミングにおける知能の話も出ていますが、氏は下記のように述べています。

知能は性格、作業習慣、および訓練といった要素と比べて、この問題にとっての重要性が低いように感じられる。そしてそれらの要素は、知能とちがって人生におけるその後の経験によって変わりえるものだ。だから問題はプログラムを選ぶことよりはむしろ育てることにある。

なお、この「育てる」については最良の思考形式を強制することではないと、氏は述べています。そいういった思考スタイルの強制はむしろ、そのプログラマの問題解決能力をそぎます。それよりはわれわれの考えを、それぞれ独自のスタイルを持ったほかの人々に理解可能なように表現するということが重要であると。

第10章 動機づけ、訓練、経験

プログラマの作業成績に影響を及ぼす道は大きく２つあり、「動機付け」と呼ばれる道と「訓練」または「教育」と呼ばれる道です。

そして、「動機づけ」といわれるものは教育や訓練に影響を与えます。
人が動機づけをもっていなければ、学習させることは容易ではないし、動機づけを持っているとすれば学習をやめさせる方法はないからです。

また、この動機づけはある種やっかいな性質があり、なにかをすれば強めることができるものでもないということです。
たとえば、資本主義社会の共通価値である金銭による動機付けが、目標設定への参画や仕事の質への関心といったものほど効果が薄い傾向があります。

この辺りのプログラマの動機付けについて、氏は古い格言を用いて言い表しています。

古い格言にこんなのがある「チェスは、女性や音楽にも劣らぬほど男を幸福にする。」私はこうもいえると思う。「プログラミングは、チェスや女性や音楽にも劣らぬほど男を幸福にする。」

管理者の立場として、こんなもんどうしろと、という話になりますが、後年発売されたワインバーグのシステム行動法では、MBTIモデルの16の性格タイプを４つに分類し、それぞれの気質が評価し賛成する管理行動を纏めています。

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

さすがに初版から半世紀もたつと、これをそのまま現在にあてはめるのは難しいものがあります。

さいごに

初版から半世紀前の書籍というものは、今現在の視点から見れば古いものもありますが、同時に半世紀は変化しない共通的な根っこの部分を見出すには役に立つものです。

この機会に半世紀近くにわたりソフトウェア業界について記述し続けたワインバーグ氏の書籍を読んでいただければ幸いです。