『プログラミングの心理学』をコツコツと読み進める試み その4
昨日の続き。
『第2部 社会活動としてのプログラミング』
『第2部 「 社会活動としてのプログラミング」へのコメント』について
プログラマの集団をさらに四半世紀にわたって行ってきた観察の結果として、私は「チーム」に関する右の定義を変更した。 いまならば、こういいたい。「プログラミングチームとは、共同して働くことによってよりよい製品を作り出そうとしているプログラマたちの集団のことである。」 すなわち、チームをチームであらしてめている特性は、メンバーの一人では作り上げることのできない（または、効率よく作り上げることができない）製品を共同して作り上げる、そのやり方にある。
人さえ集まればよいのではなく、「よりよいものを作ろう」という思いがあるかどうか。 日本の大手SIerが海外のIT企業に勝てないのはこのあたりにあるように思える。
『第4章 プログラミンググループ』について
『公式的組織と非公式的組織』
組織図は、管理者たちにとってお気に入りのおもちゃである。だが、プログラマ同士のやりとり、もし組織図にあるような細い直線に限定されていたとすれば、プログラミングの仕事は片付きはしない。
プロジェクトがうまくいかない時に、組織図をいじる、すなわちチームリーダーの交代、配置転換で何とかしようという不毛な試みの例は いくらでもある。これに五月雨式の増員が加わると目も当てられない。
困った時に相談できる相手が社内外にいるかどうかはかなり重要な要素だと思う。同期入社組でこっそりチャットで相談したりとか、いろいろしたもの。
管理職のリーダーシップに問題がある場合、影の権力者が育つことは稀ではないと思う。 また、大手SIerにいたころ、設備管理担当の派遣社員さんを中心にお困りごと相談所みたいなものが形成されていたりした。
『物理的環境と社会的組織』
プログラマの溜まり場の有用性。計算機センターの古き良き時代。
若者の溜まり場としては、大学の研究室も本来は有益だったんだろうか。私の所属したところは電子材料の研究室だった上、グループ別の関連性が低かったりで全然有益ではなかった。装置のトラブルの場合を別にして。
『エラーとエゴ』
たいていのプログラマは、もし聞かれれば、他人から妨害される恐れのない場所で一人で働くのが好きだ、と答えるのではないか。
……というような考えこそ、プログラミングをよりよくしていく上でわれわれが出会う、恐らくもっとも打ち破りにくい障壁にほかならない。 まず第一に、もしこれがプログラマという職業に対する一般的イメージであるのなら、人は一人で働くのが好きか、他人と共同で働くのが好きかによって、この職業に就きたいと持ったり、就くまいと思ったりするであろう。
社交的な方のほうが知名度相応に実力があるような感じはしている。というか、非社交的なタイプは実力があっても目立ちにくいのか。 伸び代は意欲的で社交的なタイプが大きいのは認めるけれども、社交的なだけではダメだと思う。
現在プログラミングの職についている人々の大多数が「孤立的」な方向に傾いていることは疑問の余地がない。 それは個人的な選択にもよるし、プログラマを雇う側の採用方針がそういう人を見つけよう、という方向性を持っていることにもよる。 そしてこれはかなりの程度まで、よい選択といえる。 というのはプログラミングの仕事のかなりの部分は、「孤独で創造的」だからである。
少なからず偏見の匂いがする。
とにかく彼らは人々からは孤立する一方で、作ったプログラムには執着する。
意外にそうでもないと思う。というか、人によるのでは。
プログラマは、勝手にやらせておくと、自分のプログラムの出力にまぎれもない、ほかの人なら瞬時に気づくような誤りがあっても、それを無視してしまうものなのだ。
認知不調和とバグ。人は自分の書いたプログラムのバグを認めたがらない。
これはこれで正しいと思うが、バグを認めたがらないだけでらいい。スケジュールがタイトな場合、巧妙なバグの隠蔽工作を眼にしたことがある。
締め切りを守れないことによる上司からの評価の低下、あるいは過度の労働をさけるために、納期をサボりの口実のする実例を随分と目にしたものだ。
『エゴレス方式』
対等な立場の人間による「相互レビュー」の重要性について。
自分の書いたプログラムに対する、レビューを自分への攻撃と捉えてしまうと機能しない。
もしプログラマにとってプログラミングに向かない日というものが実在しているのだとすれば（そしてそれを裏付ける証拠はいくつか挙がっているのだが）、そういう日に書いたプログラムは虫取りに飛び抜けて多い試行回数を必要とすることになるだろう。
残業時間に書いたプログラムに飛び抜けてバグが多いことだけは個人的な信念のもと、強調しておきます。 というか、最高の開発手法は、「定時で帰る」だと思う。（この本の"虫取り"というのはバグ（＝不具合）を修正すること、要するにデバッグのこと）。
よくあるソフトウェア開発の現場で起こる問題の一つは、特定のプログラムについて、理解している人が一人しかいないという問題。 いわゆるトラック係数、ハネムーン係数が小さいということ。
これに対する一つの方策として本書で言う所の「エゴレス方式（相互レビュー方式）が有効だと著者は述べている。事実、そうだと思う。
プログラムを読む、ということについて著者らが信じていることがもし正しいとすれば、その人は、自ずとよりよいプログラマになっていくのだ。
耳が痛いですね。簡潔なプログラムを読むと感動すると同時に勉強になるのは事実です。最近それが全然できていないですが。
『プログラミング環境の構築と維持』
社会的な意味でのプログラミング環境。
我々人間は、周囲の人々はこう行動しているのだと自分が思う所に従って行動するものだから、現に活動しているプログラミンググループは、新しいメンバーをそのグループの哲学に合うような型にはめていく傾向を持つことになる。
どうせならいい方向に型にはめられたいですよね。
とりわけ彼らは、個々人の才能を相互に尊敬し、共通の目標に向かって協力する、という考えに基づくログラミンググループが一体なぜ円滑に機能し散るのか、理解できなくて途方に暮れる。 むしろ彼らは、人々は金のために脅迫のもとで働くものだと思っている。 彼ら自身がそうだからだ。
これは極めて考えさせられる。というか、どういう発想の人間のもとで働くか、という問題。少なくとも私は、体育会系の人間の下では働きたくない。
『第4章 「プログラミンググループ」へのコメント』についての読書メモ
多くのソフトウェア管理者は、いまなおおもに出荷可能製品に基づいて評価されており、出荷可能製品を作り出す能力を持ったチームを作り上げたことや、チームが出荷する製品の品質によっては評価されていない。
これはすごい指摘。日本のSIerのミドルウェアがひどい理由を簡潔に説明している。それだけでなく、たいていの大手日本企業がひどい製品を出荷する理由を極めて簡潔に説明している。
本の内容の普遍性に圧倒されている所ですが、今日はここまで。
