「プログラミングの心理学」を読む

概要: 「プログラミングの心理学」は、 ジェラルド M. ワインバーグ (Gerald M. Weinberg) による本である。 オリジナルは 1971年に刊行され、25周年記念版が 1998年に発行された。 日本語訳もある。 著者のワインバーグは著名なコンサルタント・教師であり、 学術的な研究でも業績をあげている。 1971年当時のプログラマはメインフレームのソフトウェア開発が主な業務で、 おもな使用言語は FORTRAN や COBOL、PL/I などであった。 ちなみに、PC はまだ存在しなかった。 このような時代に書かれたにもかかわらず、 この本が推奨するのは XP 的な手法であり、こんにち 「バランスドチーム」「心理的安全性」と呼ばれているものが なぜ重要かが実例とともに説明されている。

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

4章. プログラミングをする集団

人々が集まってプログラミングをすると、 必然的になんらかの組織が発生する。

公式な組織・非公式な組織

会社などで定義された「公式な」組織だけではなく、 自然発生的に生まれた「非公式な」組織の場合もある。
非公式な組織の多くは、人々のニーズと「物理的に近い場所にいる」ことによって発生する。
非公式な組織の存在を無視したり、それを強制的に消そうとすると 何らかのツケが回ってくる。

• かつてコンピュータは専用のセンターに1台だけ存在していた。
• 井戸端会議による情報共有「FORTRAN? 何だそりゃ?」
• 自販機の回りにたむろす学生の集団

間違いとエゴ

多くのプログラマは他人から離れて作業することを好むが、 一方で彼らは自分の成果物に執着しがちである。
コードを「所有する」ことの害悪は、それが自分自身 (エゴ) の 延長であると考えがちなことである。
こうなると、自分のコードの間違いを「自分の欠陥」ととらえることになり、 間違いを間違いと認めにくい風潮が生まれる。

「エゴレスプログラミング」

プログラマのエゴの問題を直接是正しようとしても難しい。 むしろ有効なのは、プログラマのいる文化および価値観を変えることである。
プログラマの成果が集団に帰属し、個人には帰属しない というチームでは、コードはつねに全員で改良すべき共有物という 考え方が生まれ、バグの発見が促進される。
このようなチームは仕事に対するメンバーの満足度が高く、 あまり人が離れない。
また、たとえ誰かがいなくなったとしても、 チーム全員が同じ知識を共有しているので、あまり深刻な問題にならない。

エゴレスな環境を作る・保持するには

「伝説のチーム」…チーム全員で仕事を共有し、つねに結果を出すチーム。
このようなチームは存在するが、 残念ならがまだあまり一般的ではない。
周囲からは「何か秘訣があるに違いない」と思われている。
伝統的な考え方をもつ組織をこのようなチームにつくり変えることは難しく、 このようなチームをゼロから構築するほうが簡単である。
いったんこのようにしてできあがったチームは、 全体で環境を移動することもありうる。

5章. 開発チーム

「プログラミング集団」が組織化されると、開発チームになる。 開発チームは、(個人では達成できない) ある共通した目的を達成するために作られる。

プログラムの構造とチームの構造

伝統的な (エゴレスでない) 組織では、 プログラムの構造とチームの構造は似かよってくることが多い。

def main():
    x = input()
    y = process(x)
    output(y)

• main部門
  • input部門
  • process部門
  • output部門

この場合、以下のことが起こる:

• main部門が input部門、process部門、output部門の進捗を「監督する」ことが多い。
• process部門は板挟みになることが多い。

チームの目標設定

「見せかけの合意」は危険である:

• 入出力ルーチンを自前で実装したプログラマ。
• バグを放置してリリースを強要されたプログラマ (cf. チャレンジャー号爆発事故)。

プログラマは「何をするのか」だけでなく「なぜするのか」を知りたがる。
上層部から細かい部分まで指定されると士気が低下する (自分達はただの「コーダー」)。
目標が明確でないと、メンバーは瑣末な点にこだわるようになる (パーキンソンの凡俗法則)。

• 瑣末な議論は、より根の深い問題「誰がボスなのか」の兆候であることが多い。

管理的なチームと民主的なチーム

プログラマの仕事に対する満足度を左右する要素は 4つある:

1. 物質的・金銭的な見返り。
2. 仕事のやりがい。
3. 労働環境。
4. 上司・監督者の質。

このうち環境によって大きく差があるのは 4. である。

• 管理的なチームでは、上から「任命された」人物がリーダーになることが多く、 プログラマをまとめるのに苦労する。
• 民主的なチームでは、状況に応じて異なった人物がチームを導く。
• 民主的なチームは、メンバー全員が他のメンバーの仕事を把握しているので、 メンバーの損失にも対処しやすい。
• しかし人嫌いのプログラマは民主的なチームは適応しにくく、 むしろ管理的なチームを好むかもしれない。

チームの危機

チームメンバーの役割は大きく次の 2つに分けられる:

1. チームの目的を達成する (タスク指向)
2. チームそのものを持続させる (メンテナンス指向)

どちらも重要な業務である。 古い組織では、「タスク指向」の業務は父親的、 「メンテナンス指向」の業務は「お母さん的」な仕事とされ、 実際に女性がついていることが多かった。

6章. ソフトウェアプロジェクト

いくつものチームが集まり大きな組織を構成すると「プロジェクト」になる。

変化を通じての安定性

ソフトウェアプロジェクトでは、人はつねに入れ替わる。
しかし「プロジェクト」は人の任期を超えて存続する。
他に移りたがっているプログラマを金銭的またはその他の報酬で引き止めようとしても、 たいていは無駄である。
「チームに『かけがえのないプログラマ』がいたら、一刻も早くそいつを追い出せ」

進捗見積りの難しさ

小さなチームですら進捗の正確な評価は難しいのに、 大きなプロジェクトではなおさら大変になる。
大きなプロジェクトでは「測定」よりも「報告」が優先される。
各階層の管理職は極端な報告を避け、平均に寄せるために 全体として進捗報告はほとんど現実を反映しなくなる。
そして同調圧力がある (アッシュの同調実験)。

• 「ちょっと遅れているんです」「どれくらい?」「うーんと、6週間」

プロジェクトの構造

いくつかのチームが異なった専門的なタスクを与えられることはよくある。
しかし、チームの役割に「優劣」がつけられていると、各チームがスムーズに協調することは難しい。
(たとえばエンジンのバルブはシリンダーより「偉い」わけではないし、 クランクシャフトもバルブより「偉い」わけではない)
階層的な管理は、各メンバーが交換可能であるような業務でのみうまくいく。 ソフトウェア開発はそうではない。

偏見にまつわる問題

階層的な組織の問題はほかにもある。
階層の差が大きいと、上層の管理職は現場のプログラマの仕事をほとんど理解できない。
そのため、仕事の成果そのものではなく、「成果のようなもの」を基準に評価することになる。
プロジェクトは水平に管理するのではなく、垂直に管理したほうが望ましい。
大規模プロジェクトの失敗の原因のほとんどは、管理の失敗である。