プログラミングの心理学

著   ジェラルド・M. ワインバーグ
翻訳   木村 泉
翻訳   久野 靖
翻訳   角田 博保
翻訳   白浜 律雄
出版社/レーベル   毎日コミュニケーションズ
出版日  2005-02
★★★★★

ソフト開発に携わる全ての方に強く本書を薦める。いろいろなところで言及される古典です。出てくる技術は古いが、本質的な議論は現在でも的を得ている。豊富な実例とユーモアで飽きさせない。今回出版されたのは、「25周年記念版」。今までの原稿はそのままに、各章でワインバーグがコメントを書いている。ただ私には余計なことのように思われる。その記述の是非は読者が判断すればよいのである。それにもかかわらず、十分面白いので、エピソードのひとつと、エピローグを紹介します。

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

「閉会の前に、もう一度確認したい。」と彼はいった。「分担したところが今週中に終わらない可能性のある人はいますか。」
返事はなかったが、管理者はたっぷり六十秒間待ちつづけた。ついにチームリーダーの一人がかすかに、まるで気づかれたくないかのように手を動かした。だが管理者は見逃さなかった。「ジョージ、何か問題があるのかい。」
ジョージはもじもじしながらこういった。「ほんのちょっとですが・・・。」
「どのくらいほんのちょっとなの？」
「ちょっと遅れてるんです。」
「どのくらい？」
「ううむ、多分六週間。」
部屋中が大騒ぎになった。「六週間だって？」と全員が一斉に叫んだ。「みんなでシステムテストの準備をしているときに、六週間も遅れていながら、よくもそこでそうやって、会議の間中黙っていられたもんだ！」
管理者は他のチームリーダーたちを静まらせ、システムテスト部隊をホテルに待機させるための出費が実際に発生してしまう以前に、問題があることを認めたジョージの勇気をたたえた。しばらく話し合った後彼は、担当部分を四週間で完成させるようにジョージを説得し、システムテストのスケジュールを改訂した。そして、今度こそ閉会にしようというとき、もう一度何か問題はないか、と問いかけた。
「いやあ、あのう、」と別のチームリーダーが、言いにくそうに切り出した。「ジョージが四週間もらえるんだったら、ウチも欲しいんですがねえ。」
「ということは、君のところもできていないということ？」と管理者はたずねた。
「厳密に言えばですが・・・。」
「厳密に言えばどのくらい？」
「多分六週間だけど、でも四週間で何とかやってみますよ。」
こうして堰が切れてみれば、結局のところ六つのサブシステムは、全部スケジュール遅れを起こしている、ということがわかった。にもかかわらずもしジョージが、全員わかっていることを自認する口火を切らなかったとしたら、問題があろうなどとは露知らない、という形で会合が終わり、実りのないシステムテストが莫大な費用を費やして開始されるところだったのである。


第５部 エピローグ

人の頭脳は、いつもは容量のわずか１０パーセントしか働いていない。残りはオペレーティングシステムのオーバーヘッドだ。

この本に動かされるところのあった人々は、コンピュータのオペレーティングシステムにばかり気を使うのをやめて、彼が自分の中央処理装置、つまり彼自身の頭脳と一緒に持ち歩いているオペレーティングシステムに注意を向け始めるのだ。

コンサルタントの道具箱

ワインバーグの著作の中では、ベストだと思っている、「コンサルタントの秘密」の続編である。コンサルタントのための１６の道具（これらは物の名前がついているが全て抽象的なものである）と、それを補足する多くの法則からなっている。
例えば、正しいこと、そうでないことを見分ける能力を「知恵の箱」と呼んでいるが、その中には、「ケアリーのゴミ警報」という法則がある。それは「やる価値のないことは、きちんとやる価値もない。ゴミにのしをつけるな。」というものである。これらのワインバーグの経験から出た法則が、その法則の名前の元になった面白い逸話とともに紹介されている。
これらの道具は、文章にすると、自分でも使えそうな錯覚を抱くが、実際に使おうとすると、相当に難しいと思われる。それは人の頭とこころの使い方であるから。
コンサルタント以外の人々には、無用と思われるかもしれないが、本書はコンサルタントと依頼主との人間関係や自分の成長に焦点をあてているので、例えばコンサルタントをフリーランスや、SEに読み替えても十分に通じる。
法則ではないが、私が願う理想の姿を描いた次の文章は忘れられない。そもそもこれこそが、この本が書かれた理由だと思う。
「自分が尊重され、最高の自分を見せる機会のある適正な労働条件のもとで、自分の得意とする楽しい仕事をして、いつも忙しくしていよう。」
前著に比べ、内容が薄くなった感じを受けたことと、翻訳が木村泉さんに比べ、いまひとつでちょっとがっかりである。しかしこの本に投資するお金と時間は決して無駄にならないと思う。

他に役に立ちそうに思える法則が多数ある。

・新しく学ぶことがなくなったら、次へ移るときだ。（ダニーの決断のコツ）
・行動に挫折したら、情報を収集せよ。情報収集に挫折したら、眠れ。（ルグインの法則）
・(1)言葉、口調、ボディーランゲージを使って、心から感謝を示す。
(2)残念そうに、しかしはっきりと、言い訳せずにノーと言う。
(3)将来、別の関係を作るきっかけを示す。
（サティアの物柔らかな一蹴 ：依頼を断る際の方法）
・相手が奇妙な行動をとっていたら、たぶん奇妙なものに反応しているのだ。それはたぶん自分である。（パーソンの特異性原則）

ピープルウエア 第2版

様々な所で参照されている古典です。副題はPRODUCTIVE　PROJECTS　AND　TEAMSで、ソフトウエア開発におけるプロジェクト、チームのあり方です。現代では少し古くなったところもありますが、デマルコとリスターの着目点は完全に正しいと思います。デマルコの名前だけで無条件に買ってしまう信頼できる著者の一人です。第2版で8章が追加されました。

・デマルコが開発者としてシャロン・ワインバーグが管理するプロジェクトで仕事をしていたころ。彼はある日病床から足を引き摺ってオフィスへ行き、不安定なシステムを立て直そうとしていた。シャロンは、コンソールの前で倒れそうになったデマルコを見つけ支えてくれた。やがてスープを持って戻ってきて、彼にに飲ませ、元気付けた後で、彼は彼女に、どうしてこんなことまでしてくれるのか、と尋ねたところ、「トム、これが管理というものよ」…つまり管理者の役割は､人を働かせることにあるのではなく、人を働く気にさせることである。
・残業の本当の目的は、品質向上のためである。昼間はオフィスが騒々しく仕事に没頭できないなどの理由で。
・生産性と無縁な要因（プログラミング・コンテストによる結果から）① プログラミング言語② 経験年数③ 残存バグ数（つまり、生産性の高い人が低い人よりバグが多い或いは少ないことはない）④ 年収
・誰も書かなかった生産性要因…「誰とチームを組んでいるか」
・プログラミングコンテストの結果､生産性、作業速度ともに優れた上位のグループの作業環境は、オフィスは静かで､個人の空間が保護され、無駄な割り込みも無く、その他あらゆる点で下位グループよりも恵まれていた。（各参加者は、通常の就業時間内に自分の作業場所で競技を行う）
・チーム殺し、7つの秘訣① 仕事がうまく行かないことを部下のせいにする② 官僚主義③ 作業場所の分散④ 時間の分断：人を同時に２つ以上のプロジェクトに割り当てる⑤ 品質低減製品：短期間での出荷⑥ さばを読んだ納期⑦ 人々を次々とチームから引き剥がす

・チーム殺し再考-チーム内の競争は、コーチングを難しく、あるいは不可能にする。チームの中の競争を助長する管理者のいかなる行動も、チーム殺しと見なされる。例えば○年俸制あるいは業績レビュー○目標による管理（MBO)○顕著な業績に対して特定の作業者を賞賛すること等。
・CMM批判-CMMはローリスクの安全な行動へと仕向け、それゆえプロジェクトは利益の少ないものとなる。最も実行する価値のあるプロジェクトは、あなた方のプロセスレベルを下げるようなプロジェクトである。
・人々は変化を嫌う。変化は、失敗が認めらられる場合にのみ成功のチャンスがある。
・学習センターが存在する最も確率の高い場所は、中間管理者の間にある空白の中である。（組織図の箱の外の空白である）
・究極の管理上の罪とは人々の時間を浪費させることである。例えば定例会議が単なるセレモニーになるように。
・コミュニティに対する必要性は、人間のファームウエアに組み込まれた何かである。

ソフトウェア職人気質

従来のソフトウエア工学を補完するものとしてソフトウエア職人気質(Software Craftsmanship)を提唱している。全面的に賛成というわけではないが、ソフトウエア工学に対する問題点の提起は、うなずくところが多い。ソフトウエア工学の問題点すべてがソフトウエア職人気質のメタファで解決できるとは思えないが、ソフトウエア工学で捉えそこなっている、優秀な個人に依存するするプロジェクトを見るにつけ、双方を両立させる方法はないものかと悩みは尽きない。

・ソフトウェア工学はもともと200人以上の大規模チームの開発のための手法であり、小規模開発に適用すると数々の問題を起こす。
・ソフトウェア工学は個人が技術を磨くことに関しては何も述べていない。
・ソフトウェア工学は全ての問題を、人を投入することで解決しようとする。
・ソフトウエア工学は「体系的」かつ「規則化」された「定量的アプローチ」が唯一可能なアプローチであると仮定していて、人々が新たな方法を考える妨げになっている。
・体系的・定量的プロセスがあったとしても、ひときわ優れた開発者の存在がプロジェクトの成否を握っており、そのような開発者を生み出せる育成方法に注目しなければならない。
・プロジェクトの遅れは過度のプレッシャーによって引き起こされるが、これはソフトウェア工学メタファによって生み出されたものである。なにかに時間がかかりすぎている場合、作業員をより熱心に、より長く働かせるだけで良いのです。この考えをソフトウェア開発に持ち込もうとするのは間違っている。
・測定できるものは、パフォーマンスを向上させることとは無関係である。パフォーマンス向上を目指して精神活動について話す場合、事例証拠を用いるしか方法がない。ソフトウェア工学が危険なのは、事例証拠の価値を重要視していないからである。