プログラミングの心理学。ワインバーグの本の中ではそこまで話題には上がらないが、自分はこの本が一番好きだった気がする。
他人に向けての発信 - なーんだ、ただの水たまりじゃないかでも書いたように、何かプログラム関連のエッセイを書くのがいいんじゃないかという気がしているのもあり、 プログラム関連のエッセイを読みたい気分だったので、昔読んで悪くなかったプログラミングの心理学を再購入。 一応改訂されているらしい。 この本、タイトルで心理学を期待すると全然違うので騙されたとなるので注意。 心理学は学問的な意味では無くてプログラミングにまつわる人間の心理に焦点を当ててる、くらいのニュアンス。
たとえば現代のプログラムの良くあるシチュエーションとの違い、みたいな事は、全部の章にまたがる話題と思うけれど、 読んで思った都度メモを残しておきたいと思うと、全部読んでまとめるのは少し書きづらいし読む側も何を指しているのか分かりにくいと思う。
という事でこの本の感想は適当に何章かまとめて、その範囲内で思う事を書く、という事をやっていきたい。 他の章で同じ事を考えて重複するような雑感のメモが出来る事もあると思うけれど、書きやすさ優先という事で。
ほとんどのプログラマはプログラムを読まない、という話をしているが、これはそうでも無いように思う。 少なくとも皆がプログラムを読んでいると主張はする程度には一般的な事では無いか。
適応性の事は全然考えられない、というが、現代的にプログラムの良し悪しを語る時に、変更の容易さを議論しない人も居ないように思う。 なんかこの辺はプログラマーのプログラム観の、時代による変化をかんじる。
全体的に、仕様書があってプログラマは集団でそれを満たすものを作る、というような世界観があって、 昔のメーカーとかのプログラム環境を前提としている部分を大きくかんじる。 それは現代の大多数のプログラム環境をあまり代表してないようにかんじるな。
「みんなが思っているプログラムはこうだけど、実際はそれは間違っているよ」という体裁になっているのだけれど、 「みんなが思っているプログラム」は、アルゴリズムがプログラムの中心であって、その良し悪しで評価されて、 一度書かれて完成されたらもう変更されないようなもの、という感じに思う。 これは現代の多くの初心者プログラマが誤って思ってしまう世界観では無いように思う。 どちらかというとアルゴリズムが中心になるようなプログラムは、今や多くの初心者プログラマにとっては高度な専門性の高い領域で、 最初に間違ってそれが普通と思う何かでは無いんじゃないか。 とりあえずwebのプログラムを入門しましょう、で、そういう誤りを持つ余地は無いように思う。
ドキュメントは変更を容易にする為にあるのでちゃんとある方が適応性が高い的な事を言っているが、 これは暗黙のうちに一度プログラムが完成するとしばらくはいじられず、 そのあとしばらくたっていじる必要性が出てきた時にドキュメントを見ながら直すと直しやすいですよね、 という世界観を前提としている気がする。 でも現代的な観点では、ドキュメントがいろいろ書かれてしまうとそのメンテが面倒で変更が大変になる事は良くある。 それは変更が、この時思っていたよりもさらに日常的なシチュエーションが増えてきているからじゃないか。 少なくともこの、ドキュメントがあるおかげで変更が簡単でいいですね、 というシチュエーションは、現代の多くのプログラマにとっての「普通の環境」とは程遠いように思う。 昔のメーカーのプログラムって感じだよなぁ。
良く出てくる例にコンパイラの開発があるが、コンパイラはユーザーもプログラマであるという点で、 ソフトウェア開発においてとても特殊な領域と思う。 この当時はコンパイラに限らず、コンピュータのユーザーはある程度特別な人だったのでこの例はそれなりに一般的だったのだろうなぁ、と推測は出来るけれど、 現代の多くのプログラウの典型的な話を代表しては居ないよなぁ。
良いプログラムとは何かという話で、 プログラムは不正確に早く動いても意味は無くて、正しく動く方が大切だ、という解説がある。 これ自体は当たり前の話だけれど、この説明が良い。
自動車の組み立てに必要な部品を調べるプログラムの話がある。 エアコンの有無でスペースが変わるのでリアシートの内装が変わる、みたいな制約条件があるので、 お互いの条件が複雑に絡み合っていて分岐が数千もあってテストもほとんど不可能で、 典型的な入力をしてもタイヤが8個とか出てくるような状況だった、と始まる。
それを予め定義されたテーブルとマッチングするだけのように変更したら２日くらいで動くものが出来た、 という感じに続く。
元の主張の、正しく動かないが巧妙で早いプログラムには意味が無い（何もしなくて良ければ誰でも実行時間は0に出来る）、 という主張それ自体は、さほど面白さも無いと思う。 けれどこの本のこの部分は読んでいてもなかなか楽しく、また結構印象的でもある。 自分は20年以上前に読んだのに今でも覚えているエピソードだった（この本だったかは覚えてなかったが）。
ここの説明が面白いのは、結構具体的なプログラムの話をする所にあると思う。 しかも細かくプログラムの話をしている訳では無い。聞き手がある程度自分の経験と照らし合わせて言っている事を推し量る必要がある感じの記述になっている。 しかもこの元のプログラムを開発していたプログラマのすごく人間的な（ダメな）反応が具体的な所が、 また印象深く感じさせている所に思う。
プログラムのエッセイでは、適度に具体的なプログラムの例は結構大切だよなぁ。
また、無駄な設定の細かさも面白さを増している気がする。入った時にはデスマになっている記述、 プロジェクトから少し離れて飛行機に乗っている時に思いついた、的な記述、 会社はこのプロジェクトを不可能だからと中止しようとしている所で慌てて戻ってプレゼンしたり反発にあったりする記述。 こういう小話が面白さを増している。 お話としてこういう要素を追加しておくのは大切なんだろうな。
適応性の所でプログラムは使われずに捨てられてしまうような事もあるが、 プロのプログラマーが開発したプログラムのほとんどは一定期間存続し、その間にプログラムが修正される、と言っている。 そして特定のアーキテクチャ向けにコンパイラを最適化した所、命令セットが追加されて対応が難しくなったというような例が出ている。
でもこの、一度つくったプログラムは基本的にはある程度長く使われて、CPUアーキテクチャの変更などに晒されるという前提はどのくらい正しいだろうか？ 例えば今Android向けに書いたアプリが、Androidの次の世代の何かに移植出来る必要性は、ほとんどのケースでは無いように思う。 それよりもずっと早く、多くのプログラムはディスコンになっている。
例えば自分が趣味で書いたアプリの半分くらいは、「作ってみたら思ったよりもいまいちだったので結局誰も使わなかった」として捨てられているように思う。 趣味なのでより捨てやすいという側面はあるけれど、仕事だってうまく行かないで捨てられているものは多い。 例えば仕事で書いた機械学習のレコメンドなどは、その次くらいには新世代のモデルが導入されて捨てられたと思う。 たぶん2年ちょっととかで書き直されている。 その間に大きな変更はたぶんされていない。
仕事で書いて、そのあと連綿と使われ続けたプログラムもいくつかはある。 けれどそちらが多数派か？と言われると、そうでは無いように思う。 作ってみて少し使われたがそのあといろいろな事情で捨てられたプログラムの方が多いんじゃないかなぁ。 そしてそれは失敗でも無い。 作って使ってみる事で得られるものがあり、それは次に活かされている事も多い。 だが、プログラムはやがて変更されるものなのでドキュメントとかコメントをたくさん書いておけ、みたいな主張は、 自分の過去の仕事を振り返るとあまり当たってないように思う。
CPUアーキテクチャに依存した最適化をしがちだが、すぐアーキテクチャは変わるよ、というのは、 いかにも黎明期の洞察だよなぁ。
パフォーマンスとかでプログラムの良し悪しは決められないぞ、こんなにそれ以外に考える事がある、と言って4つの項目を挙げている。
これらのどこにも、自分が重視している「プログラマ人生においてこれをやった！と思えるような社会に対するインパクト」とか、 「時代を分けるような競争に勝つかどうか」みたいな要素が入っていないのは、 プログラマというものに対する捉え方に大きな差があるようにも思う。 例えば現在自分がプログラムにおいて成功とか失敗を考えるのは、だいたいが40代のプログラマ目標に書いた事に沿ったものになるが、 そこには上記の4つはせいぜい2くらいしか入っていない（それもスケジュールというよりはtime to market的な何かだ）。 これはプログラマというものの変化という気もするが、一方で80年代のBill Gやジョブズだって自分と同じような価値観であったと思われるので、 別に時代という問題でも無く、ワインバーグの考えるプログラマの偏りという気もする。
章末にマネージャーに対する質問とプログラマに対する質問というのがあり、この中身はマネージャーが作るものをプログラマに伝えてプログラマがそれを作るかのような前提がある気がするが、これは現代においては多数派では無かろうし、 自分が重視するプログラムにおいて大切な事が入らない特殊な分野という気がする。 プログラムにおける様々なトレードオフを決めるのがマネージャーという前提になっているが、 昨今はその辺を非プログラマがやるのはむしろ例外だよなぁ。
「振り返って」のあとから足した項目に経済的要因について言及があるが、これの優先度もびっくりするほど低くて驚く。 プログラムにおいて経済的な成功はめちゃくちゃ重要だと思うんだが、それが良いプログラムの条件に入っていない。 一方で一切の金銭的な儲けを気にせずに行うプログラムもあるので、これが入らない場合もあると思う。 ただそれは上記の4つの条件にも全て言えるよな。 仕様にそっているかはユーザーにとって良いかよりは大切じゃない事の方が多かろう。 適応性は結局勝負に負けて撤退するなら必要では無い。 効率が必要でない事が多いのはすでに本書の時点でも言及されている。 ではここに経済的成功を含めない理由はあるのだろうか？
自分にとって良いプログラムは、やはり決戦において勝利するプログラムだよなぁ。
例えば上の4つの条件を順番に見ていくと、 正しく動いて使っていて良いと思える品質であるがゆえに競争に勝つ事はあるだろう。 勝負のタイミングでちゃんと市場に出せているがゆえに勝てる事もあるだろう。 変更が容易な事で重要なチャンスをつかめるという事もあるだろう。 効率がユーザーの心を掴む事で勝負に勝てる事もあるだろう。 それぞれが重要な要素たりえる場合はあると思う。
だがこの本はそういう大切さみたいなものは会社とかマネージャーが考えてそれに沿っているかどうかがプログラマの責務として重要であるという前提に立っている気がする。 だがそれでは、冴えない会社で冴えないマネージャーと仕事をしている場合は、プログラマとして良いけれど結果としてはしょぼい、ということも成立してしまう。 良いプログラムに、そうした条件が内側に無いのはおかしいんじゃないか。 プログラマが人生の重要な時間を使ってする仕事が、お前のプログラム人生においてそれで良いのか、みたいな視点が欠けているように思える。 それはプログラマにとって会社の成功やマネージャーの望み通りかよりもずっとずっと重要な事に思える。 それらが会社とかマネージャーの方向性と一致するのも大切とは思うけれど、それらが上に来る事は無かろう。
そういう点で、この本のイメージするプログラマは非常にサラリーマン的だよなぁ。 でも現代のプログラマにおいて、良いプログラムというのが例えばマーケットシェアを取れるプログラムとか、 そういう視点は必須だと思うし、それらのうちかなり多くの部分をプログラマが負っている、というのは、 そう珍しい少数派の考えという訳でも無い気はする。
効率や効果がカード読み取り式を前提としているが現代でも本質的には同じである、的な事が書いてあって、これは同意する部分としない部分がある。 現代においても通じる教訓は存在するが、 一方で時代の違いで通じないものや、この時代には重要ではなかったが現代では重要になった事も多くあるように思う。 やはり現代のプログラミングについて議論をしたいなら、現代の例の方が良いのでは無いか。
一方で読み物としては現代でも面白く読める。面白く読む為の文章という点では現代でも良いお手本になりうると思う。
プログラミングという活動をどう研究するかという話が始まるが、あまり関心が湧かない。 有意義な結果が得られるのかどうかが分からないのにやり方を議論しているからという気がする。 何を研究するかが不明なまま研究の手法を議論してもあまり面白くない。
プログラミングしているのを観察したり実験したりする事について語っているのだが、 こうした事の先に理解を深めてくれる何かがあるのだろうかね？
「プログラマーが平均で作業時間の3分の2を、１人での作業ではなくほかの人たちとの作業に費やしているとしたら（実際そうなのだが）」という記述があるのだが、自分の現状は9割以上を１人の作業に費やしている。 平均を見てプログラムという全体を語るのはあまり良いやり方では無いような気がする。
プログラムは同質な部分を見るよりも、多様な部分を見る方が実態に迫れるのでは無いか。
プログラミングの研究というのはまだまだ歴史も浅く、先の長い話のように思う。 一方で80年代と現代のプログラミングの違いは、この本を読む範囲でもかなりあるように思える。
科学的に研究をする意義というのは積み重ねていく事で他の方法では得られないような深い理解に到達出来るという事だと思うのだが、 こう変化する分野でもそれは正しいのだろうか？ 例えば単にプログラマがそれぞれ思う事を書き綴るよりも本当に深い理解に到達するのだろうか？
一方で2010年と2022年の違いは、そこまで大きく無いような気もする。 2010年くらいからの研究ならその先に積み重ねていけるのだろうか？ でも2010年くらいの頃は2005年くらいからあまり変化が無くなった的な事を言っていた気もするが、 今思うと2005年と今では結構違う気がする。
長期間積み重ねが必要な科学的手法というのと相性が悪い可能性もあるよなぁ。 実際80年代から40年間くらい人類はこの手の研究を積み重ねてきた訳だが、 何かそれらの研究が自分の仕事に役に立っているかというとあまり役に立っている事は思いつかない。 たまに面白い話やへーって話はあるのだけれど、何かただプログラマーとして日々を過ごす以上の理解に到達しているのかは怪しい気もする。
やはり学術的プロセスの有効性は良く分からないよなぁ。無いとも言えないがあるとも言えない。 なのでそれを検討すべきかも良く分からない。 実験はいろいろ行われたが、実際のプログラミングにそれほど有益な影響を与えているような気もしない。
やはりこの章は今の視点から考えると微妙だよなぁ、と思う。 こうした手法でやっていこうと当時思っていたんだろうな、とは思うし、実際やったんだろうが、 それほどうまく行かなかった試みの予定を長々と説明された文章を読んだだけという気がする。
上手く行かなかったという事について考えるのは有意義に思う。むしろそこについての考えを聞きたいよなぁ。 これが25年前の本である欠点か。
「誤りとエゴ」の所で、社会心理学によると、一般的な性格の特徴は以下の３つの次元について測定されて、 多くの場合どれかの次元に大きく偏るらしい、とある。
そしてプログラマは遊離型に大きく偏っているという話が続く。 これは昔のプログラマ像ではそういう印象もあるが、 現代だとどうだろう？ 例えば自分が思う大企業のプログラマは1の方が圧倒的に多いし、 自分など一発当てたいとか代表作を作りたいと言っているのは2がメインで3が混ざっている感じに思う。
現在のプログラマは遊離型が多くてそれが行き過ぎている、という気はあまりしないよなぁ。 自分の感覚では1が多すぎて良くないと思っているし、 一歩引いてみればこれらの偏りが大きな問題を生んでいる、と思う根拠は無いように思う。
20年前は遊離型タイプが結構多くてその社会性の低さはそれなりに問題にもなっていた気がするが、現在のプログラマはだいぶそういう感じでは無くなったよな。良くも悪くもエリートサラリーマンっぽくなった。
組織図的でないinformalなコミュニケーションが大切だ、という話の例が出ていて、それ自体は自分も結構同意する。 本当に大切だと言い切る証拠は無いけれど、少なくとも自分はそういうのが好きである。
だが、エレベーターガール的なオペレータが操作するエレベーターを高速式の自動エレベータに変えたらオペレータがついでにやってた事が無くなって非効率になった、という話は、うーんそれはどうかなぁ、と思ってしまう。 本当にそれに一人分の価値があるなら誰かをエレベータに配置すれば良い。 でも本当にそれが一人分の価値があるかは怪しい気がする。 実際現在、この本に書いてあるように誰がどの階にいるかとかを手軽に聞けるようにする為にエレベータに１人、人員を配置する、 という事をやっている組織は見かけないし、それが良いアイデアのようには全然聞こえない。
それまでの環境に最適化されている状態では、何を変えても一時的な非効率は生まれるだろう。 でもある程度の期間で本当に効率が落ちているかはある程度の期間を見てみないとわからない。 気づいていない良いものを無くしてしまう可能性はいつでもあるし、 大きなものは戻したりする事が良い事もあるだろうけれど、 新しいやり方に適応すればそっちの方が良い事も多いように思う。 少なくとも今と20年前の自分の仕事を比べて、大きく改善したとは思う。
エゴレスプログラミングは本書の25年後に振り返った内容よりもさらに進んでいて、割と一般に定着していると思う。 エゴレスプログラミングという名前では無くても、コードがプログラマの所有物でないケースの方が一般的になっているように思う。 プログラマは辞めるし、チームも移るし、そのあとにもソフトウェアは残る事は良く理解されているだろう。 レビューも一般的になっているし、周りに見せないように振る舞うプログラマは絶滅したと言って良さそう。
作業などは属人化してしまうのは現代でも良くある事で、問題は似ているけれど、属人化してしまう理由は誤りを見つけられたくないとかそういう話では無く、属人化させない為のコストが払えていないという場合の方が多いように思う。 そういう点では本書で述べられているようなプログラマ個人の考え方的な問題はだいぶ解決しているんじゃないか。
一方で、プログラムがプログラマの所有物であるようにした方が良いケースもあると思うが、 そういう視点がこの本には欠けているように思う。 オーナーシップを持つ利点だ。 コードベースが巨大になった時に、誰に聞いたらいいかわからないとか、 誰が決断すべきかわからないという問題はオーナーシップの設定で回避できる事も多いし、 自分がオーナーシップを持っていると思う方がより主体的に開発に取り組むという事もあるように思う。
そもそもにソフトウェアは企業の寿命よりも長い事もあるし、 企業を移動しても同じソフトウェアに携わる事も良く見られるようになった。 オープンソースにしてから辞めて退職後も関わる、というのは良くあるパターンだ。 プログラマ個人としてプログラマ人生において自分が何をなすかという事を考えた時に、 こうした形態のソフトウェアを持つかどうかというのはそれなりに大きな事と思うし、 それは企業の枠の中で仕様を満たすコードを書くという視点では評価出来ない、けれどとても重要な要素だろう。
現在の自分は、ほとんど他人は自分のコードを見ていない。単純に自分のコードと同じ所を触っている人が１人もいないからであり、 出来たら二人くらいでやりたいなと思っているので、他人に隠そうとしている訳では無い。 ただ現状はグループで開発するメリットは享受出来ていない。 こういうのは昨今では割と良くあるケースに思う。 特に零細で働くケースでは、自分の所を一緒に開発してくれる人が得られない方が普通で、 零細で働くという事を選んだ時点である程度はこうなる事は覚悟もしている。
チーム自体がもっとチーム開発的にお互いの仕事を交換しあうような形になる事も可能だと思うし、 自分としてはそうなっていてくれた方が嬉しいけれど、零細の仕事を受ける時点でそうでは無いだろうとは思っていた。 そして独自のプログラム言語を作るという仕事においては、１人のメリットも多くある。
チームで同じコードを触ってみんなで議論できる方がいいとは思うけれど、 そうでないならそうで無いでメリットの方を活かしてやってくしか無いよなぁ。
この本は大手の企業ばかりが想定になっていて、ベンチャーとかの立場があまり無いよな。 マネージャーとプログラマーの対立などを良く語るが、5人の会社でCTOなりトップがプログラマなりならそんな対立は無い。 そうしたベンチャーでのプログラムも今や典型的なプログラム環境の一つだよなぁ。
自分のやっている事と比較した時に、仕様の通りに動くというのを最低ラインとして考えるのは、あまり自分の仕事の現状と一致していない。 何を作るべきか分かっていない状態でものを作っているので、仕様がコードより先にある訳では無い。 むしろ仕様にたどり着く為にコードを書いているような部分はある。
そして現在の自分の仕事の成功と失敗は、作っている言語が広く使われるか全然使われないかで判断されるべき事で、 それ以外の指標にはあまり意味が無いように思う。 それは作るものだけで左右できる問題では無いのだけれど、 それでも作った独自言語が正解かどうかはそれでしか判断しようが無い。 バグが多くて品質が低いというのは重要な問題ではあるけれど、 まずそれを解決してから他の問題に取り組むべきというものでも無いように思う。
より表面的な事でも、リリースされてしまったあとに言語仕様は変えにくくなった所であまり言語仕様がよろしく無い、 という事が判明すれば、それは実装のバグの多さよりも被害は大きい。 そして自分のプログラム言語を作る時にはこの言語仕様を作るというのはまさに本体でもあり、 それは実装からのフィードバックを得て洗練されていくものなので、 仕様の通りに動くのが先にあるという問題では全く無い。
やはり全体的に、想定しているプログラミングの形態が狭い領域に限定されているように思うし、 それが現代ではあまり一般的では無い形態になってしまっているように思う。
目標をちゃんと共有してないと魅力的だが役に立たない小さなプロジェクトへと流れ勝ちである、 という話があって、チームがローダーの改良版を作りたがって、それは全然役に立たなかった上に結局使われなかった話がある。
これは失敗の例として挙げられているが、これがプログラマにとって失敗かどうかは分からないよな。 組織にとっては望ましくなかったのだろうが、プログラマとしては興味深い事をやって良い経験が積めたのなら悪くないよなぁ。 この本は成功というのを組織の視点に立って考えすぎな気がする。
たとえばWinFSの末期にメンバーがどんどんLINQのチームに移ってしまってWinFSが頓挫した、というのがある。 でもLINQは別にダメだった訳でもないし、WinFSの方が結果からみればよっぽど無駄だった。
ローダーもその会社にとって役に立ったかは知らないが、 そこで専門性を高めて次のローダーの仕事に移って大きな結果を出したプログラマもいるかもしれない。 一方で冴えない事をやって会社にとっては良くても個人としてプログラマのキャリアとして全然ダメな事もあるかもしれない。 そういう事をやらないようにプログラマはどうすべきか、という視点はあってもいいんじゃないか。
著者はコンサルとして組織から依頼される事が多いのでそういう前提に立っていると思うのだが、 プログラマーというものを考えるならもっとプログラマーから見た視点もあった方がいいよな。 組織がどうプログラマーを扱うべきかという事を書く本だというのだとしても、 もっと組織はどういう仕事をプログラマーに提供すべきなのか、みたいな視点でやはりそういう話は検討されるべきに思う。
ローダーの話はおいとくと、チームの目標をちゃんと話し合って合意する場はあった方がいいような気はするな。 そういう話をしないで仕事が進む事も結構あるよなぁ。
今の同僚とは割とそういう話が出来ているとは思っていて、勝利条件がはっきりしているのはいい方向に作用している気がする。 この本で述べられているような普通の会社員的な内容では無いけれど、 雇う側がそういう前提で雇っているのは今回自分が楽しく働けている理由の一つでもあると思う。
こういう所は時代が変わってもあんまり必要性は変わらないよなぁ。
チームのリーダーというのが上層部側である事が多いという話が出てくるが、 これは古い考えだよなぁ、と思う。 現在は開発組織において多くのソースコードについて責任を持つ類のLeadは珍しくなく、 これは会社の上層部とはだいぶ違う組織構造で動いているように思う。
Tech LeadとPeople Managementが違うというのは一般的な考えと思うが、この本ではTech Lead的な立場のリーダーシップというのがほとんど出てこない。
こういうのを見ると、ソフトウェア開発におけるリーダーというものについては随分と進歩したよなぁ。 昔は普通の会社組織の中にプログラマという異質な集団をどう入れ込むかという感じだったが、 昨今はプログラマ中心の会社とか珍しくも無い。 組織とプログラマの対立、みたいなのは、この本で描かれているようなのとはだいぶ形が変わったように思う。
なんか内容的にグループ、チームとあまり区別出来ていないような気がする。 チーム内ではなくチーム間の問題を扱っているという事なんだろうが、 これまでも会社組織とプログラマの対立的なものだったので、別にチーム内に閉じた話にはなっていなかったし。 実際上層部という名前でリーダーより上との関係は良く出ていた気がする。
悪い報告がなかなかなされなくて、ミーティングの終わりまで何も問題無いと進みながら最後にもう一度確認をとった所、 1つのチームが6週間遅れてると言ってきて、そうしたら他のチームも次々に6週間遅れると言い始めた、 というエピソードが紹介されているが、 こういうのはいかにも古い日本の大企業の悪い所的に紹介されそうなエピソードに見える。 このエピソードに限らず、いろいろな所で古い悪い日本の大企業の習慣のようなものが紹介されているように感じられる。
こういうのは日本特有の悪い所ではなく、単に35年前（本書は2011年に25周年記念と言って再販されているので35年前に書かれたものと思ってこう書く）の企業とはこういうものだった、というだけなのでは無いかなぁ、という気がしてきた。 実際、20年前に自分が読んだ時にはもうちょっと共感出来る部分が多かった気がする。 現代では日本企業という観点でも古すぎて全然共感できなくなっている。
別に日本かどうか関係なく単に古いという問題であるなら、 古い日本の大手企業が古い所を残しているというのは当然の事で何も面白い要素は無い事のように感じられるな。
前の章でも思ったが、この本ではキャリアとして前に進むのを「管理職のはしごを登る」という前提で話をする。 プログラマとしてキャリアを進めるという話が無い。 一方で現在では、少なくともシニアなプログラマとそうでないプログラマという区分はある気がする。 また、ある程度良い実績を積んできたプログラマとそうでないプログラマには結構な立場の違いがあるようにも思う。 これは35年前と現在で変わった所かもしれない。
一方で、プログラマがステップアップしていくのは、会社の中で偉くなっていく、というモデルとは微妙に違う気もする。 具体的には転職市場でどう見えるか、という立場が変わっていくものではなかろうか。
現在でもプログラマの実力が評価される、というのとは違うなにかで評価されているとは思う。というのは、プログラマの実力を評価するのはすごく難しいからだ。 ただ、それは社内のシステムとは別のなにかに思う。 US系企業で言えばそれはラダーで、 ラダーに関しては個々の会社にコントロールの余地はあまり無い。 ある社員を低く評価する事は出来るけれど、そうするとその社員が出ていくだけで、 結局は長期的には転職市場の中で見えるラダーに収斂している気がする。 社内で独自の評価システムを作る事は出来ても、 結局転職市場ではそれらはあまり考慮されずにラダーが与えられているように思う。
日本国内の転職市場だと企業をまたいだラダー的なものはUSの転職市場ほど強固には無いけれど、 やはりシニアかとかそういう区分はあるし、それは社内のどうこうとは独立しているように思う。 やった仕事の典型的な業界評価、みたいなので決まっているよな。
こういうキャリアの上下は、会社の中の組織図の上下とはあまり関係が無い。 そしてそれは現実にも反映されているように思う。 組織図として下に配属される人が組織図の上より立場が強い事は良くある。 特に自分のように業界経験が長くフリーランスとして組織に入る場合には、 むしろそういう場合ばかりに思う。 そうした上下は社内のシステムではなく、転職市場の需給で決まっているような気がする。
プログラマのキャリアというものがどういうものか明らかになった、というのはここ35年の大きな変化に思う。
この本をここまで読んでいて、競合との競争が一切出てこないし、ユーザーが獲得出来るかどうかも全然出てこない。 35年前には一般向けのプログラムというのはそんなに無かった（パソコン自体が一般に普及していなかっただろうし）という事なのだろうけれど、 この違いは結構大きい気がする。
プロジェクトの成功は会社の管理層が満足するかどうかみたいな前提があり、市場での成功が無い。 一方で現在の視点では、失敗プロジェクトの典型はリリースしたがさっぱり反応が無かった、みたいなサービスに思う。 こうした市場の反応というのはわからずやのマネージャーをどう騙すかという話とはだいぶ変わっている。 また、競合と比べてうまく行ったかどうか、というのも、やはりマネージャーを相手にどうこうするというのとはだいぶ違う話に思う。
こうした事情はここ10年では全く違いは無いと思う。15年前でもあまり違いは無い。20年前だと多少違いも出てくるかもしれないが。 その位には安定した話に思う。 現在の視点に立つと、黎明期の一時的な特殊な事を長々と話しているように感じられるな（実際はかなり長い事この本で書かれていた事は有効だっただろうからその感じられ方は正しくないだろうが）。
最後の振り返ってにもあるように、今日ではもっと遥かに多様になってしまった為、あまり有益な感じのしない話になっている。 多様であるという主張が正しくなくなったのではなく、この当時考えられていたよりも遥かに多様になった結果、 こうした類型化が有効で無くなってしまった、という事に思う。
バグを探すのと原因を特定するのと修正するのでどれかが得意という人がそれぞれ居るので協力するのがいいと書いてあるが、 前半と後半はイコールでは無いよなぁ。 作業を分けた時にそれぞれに得意不得意があっても、それでも１人でやる方が効率的な事は良くある。 実際フェーズを分けて分担するというのはウォーターフォールの衰退で大きく後退した所でもある。 現在は１人の人間が全フェーズを受け持つ方が一般的だろう。 テストは別の方がいいかもしれないが、少なくとも昔よりも専用のテストチームを持たない組織が増えたと思う。 それは結局分けて協業するのは別の問題を生んでいて、これが結構大きいからだと思う。
心理学研究としてなんとか作業を分けようとしている、と感じ取れる記述もあるが、 これが現在の視点から見るとこうした研究が実態から乖離して役に立たない理由になってしまっているようにも思う。 プログラミングという活動を理解するには分類をするよりも、ケーススタディみたいなのを積み重ねていく方がいいんじゃないか、 という気がする。
コーディングが調子悪い日に仕事をしない訳には行かないので複数の仕事を持っておいてその日のコンディションに応じて行う方がいいと書いてあるが、 自分は調子悪い時には仕事をしないようにしていて、これは非常に有効なのでフルタイム労働が良くないと思っている事でもある。 そういう訳には行かない、とワインバーグは言っているが、それは事実では無い。
現代におけるプログラミング作業の多様性には非常に多くの議論すべき事がある重要なトピックと思うが、 過去の話の延長というよりは全然別のなにかになりそう。
性格がプログラミングにどう影響するか、という話から、性格診断をプログラマの適性に使えるか、という話が出ている。
そこでは既にプログラマになった人の性格を調べて適性を判断しようという前提があるが、これは将来新しい種類のプログラマが求められるという可能性を無視している気がする。 けれとこの時期、その時点では明らかになってない種類のプログラマがきっとたくさん求められるようになる、というのは予想できた事ではないか。
実際、本書で調べていることもパンチカードというシステムに特化した部分が強いように思う。ターンアラウンドの長さは本当に様々で、この時点で特定の種類（しかももはや絶滅している）について調べる事に、現代の視点であまり価値があったとは思わない。
内容的にも、Linusはプログラマの適性はない、と言わんばかりの内容になってしまっていて、何か有効なフィルタリングを提供出来たとも思えない。 また本書の内容では、起業家もプログラマに向いてないという結論が出てしまいそうに見える。 そうした例だけに留まらず、通常の会社員のプログラマでも現代に求められている性質とこの本で必要とされる性質には随分と乖離があるように見える。
また、その問題点はプログラミングの心理学を研究するという問題点を浮き彫りにしているように思う。 何かを学問的に調べるのには長い時間がかかるが、その間に対象が陳腐化してしまうと、それを調べる意義は無い、という問題に思う。 例えば2010年にパンチカードでプログラミングをするのに高い能力を示す人間を選別出来るようになった所で、それはほとんど役には立たないだろう。
本書が全体的に問題と思うのはこの当時のプログラムの内容を細かく検討し過ぎている事にあると思う。 だから変化に弱い内容になりすぎている。 それはプログラミングということを理解しようとする時には致命的では無かろうか。 むしろプログラマに求められるのは、現時点では分からない変化に対応する事のように思える。 実際現代のソフトウェア企業は多様性を重視すると良く言っているが、それはまさにそういう理由によるよな。 本書のように今の性質を調べてそれに最適化するというのは正反対に思う。
将来に対してはどうか？というのは良く分からない。黎明期の頃に比べて安定化して長い期間の研究対象に適するものになった可能性はある。ただそうでない可能性もある。 少なくとも研究する正当性は自明では無い。
また本書でも述べられているように、既存のプログラマを調べてそれと同じ適性を持つものを選ぶのがどのくらい意味があるのかは分からない。 明らかに同じ人間でも向いた職場と向いてない職場は存在している。広く業界のプログラマを調べても、それと似ている事が適性があると言える気はあまりしない。 ましてや今後のプログラマに向いているかはますます怪しい。
成功者を調べる方がまだ意義はある気もする。 ただそれはサンプルが少なすぎるのであまり役に立たないかもしれない。 それはますますこうした学問的研究の対象として適切かを疑問に感じさせる所でもある。
性格の影響も向き不向きもあるのは疑いようは無いが、その事実を企業やプログラマが役に立てられる気はあまりしないな。
この章の内容はひどい。まず知能の話をほとんどしていない。知能テスト的なものの問題点を長々と書いている。 この当時良く行われていたテストらしいので、歴史の中で意味のなくなった章なのだろうな。
そしてプログラマに必要な資質についていろいろ語っているが、これも現在の視点から見るとひどい内容で、 例えばプログラマに幾何学はいらないと長々と書いているが、今グラフィックスの仕事をしている身からするとお前は何を言っているんだ、という感じだ。 全体的にいらないと言っているものも、代わりにいると言っているものもあまり説得力を感じず、 大した内容が無い。
知能とか測り方も良く分からないし関係あるかも分からない、で終わる事なら章にせずに8章の最後に一言そう書けばよかっただけでは…
10, 11章と飛行機の中で読んで特に感想もメモしてないが、あまり書くことも無かった気がする。ということで12章。
細かいところを実験的に確かめることで統一性がある種のケースで重要かもしれない、ということを調べたりするのだが、 それがいかにもFORTRANとか特有の話で、今から読むとこの手の手法の限界を感じさせる内容になっている。 言語によらない一般的な原則のような体裁を持っていながらその実は特定の言語の細かい事情の限定された条件での話しか出来ないので、 結局それが、例えばPythonとJavaのどちらが優れているかを考えるのには全く効果が無かったりする。 これならFORTRANだけに限定して改善案でも述べてる方がよっぽど意味があったんじゃないか。
一歩下がると、結局プログラムということについての研究に、こうした心理学的なやり方は向いていない、 ということを明らかにした、という意義はあると思う。 自然言語に比べれば変化が早いので、時間をかけてちょっとずつ積み重ねる手法はあまり有効では無い。
それよりはその時点でのケーススタディを積み重ねる方がプログラミングということを理解するのには有効なのでは無いか。 もっとFOTRANとPL/IとAPLの比較を具体的にやっていく方が意味はあった気がする。
なんにせよ、現代にこの章を読む意義はあまり無いな。本書の6割くらいは現代では読む意義は無い。 昔はこんなに違ったんだなぁ、と昔のおもしろ常識を見るようなつもりで読むのがちょうどいい。
13章はあまりにも古い内容過ぎて多少読み飛ばしたが、だいたい全部読み終わった。 この25周年記念版はUSでは1998年に刊行されて、日本語に訳されたのが2011年12月となっている。 日本の書籍としてはまぁまぁ最近の本だけどやけに古く見えるのは、US版が実際に古かったからだった。
まず、ここまで何どか書いてきたが、本書はほとんど2022年現在では役に立たない内容に思う。 本書の主題となる「心理学的な実験をプログラミングの理解のためにももっと行うべき」という主張が、 まったく時代のテストに耐えられていないため、本書の主張が全体的に的外れとなってしまっている。
だが、この手法が的外れである、ということは、割と学びの多いことでもあるように思う。 興味ある対象が興味深いままでいる期間が20年とか30年程度がせいぜいなので、 長期間かかるような科学的手法はあまり役に立たない、ということと思った。
また、内容が全然現在の役に立たないことから、昔のコンピューティングがどう違ったか、ということが感じられて、 青空文庫を読むことで明治時代の学生の生活が感じられて楽しい的な感じで、 かつてのコンピューティングがどういうものかを感じられて楽しい。 そういった、昔に思いを馳せて懐古するためにも、各時代でこうしたエピソードを残しておくのは意義があることなんじゃないか、と思った。
まとはずれなことを「XXすべきだ」と強く説教臭く言ってくることには鬱陶しさも感じるが、 気晴らしで読むエッセイとしてはそれなりの楽しさはあった。
なお、巻末の訳者やweb上のレビューなどの「現代にも通じる」的な主張はゾッとするものがある。 結局こうした古い話を見てそれが現代でも有効な部分を探してしまうと、そうしたバイアスが強すぎてかえって現代に必要なことを考えるのを邪魔してしまうのでは無いか。 それはこの本に限らず、古典全般に言える落とし穴だな、と思った。