マイペースなRailsおじさん

Ruby、Ruby on Rails、オブジェクト指向設計を主なテーマとして扱います。だんだん大きくなっていくRuby on Rails製プロダクトのメンテナンス性を損なわない方法を考えたり考えなかったりしている人のブログです。

Peoplewareを読んだ

Tom Demarco & Timothy ListerのPeoplewareを読んだ。いまいち理解できていない部分が多いので、ここに書いて整理する。

要旨

ソフトウェア開発における課題の大半は技術的な問題ではなく社会学的なものである、という主張を核に、ソフトウェア開発のマネジメントがどうあるべきかを説いた本。

作業者が効率よく作業するために必要なことが説明される。具体的には、他人に邪魔されず集中すること、自発的に期限を設定できること、品質を高く保つ権限をもつことなどである。 また、チームとして動く場合に結束力を上げるためには、共通意識やコミュニティの醸成が不可欠であることを示している。

それらを実現するためには、どのようなマネジメントや環境の整備が必要なのか、著者の経験と外部の文献の調査結果を説明している。

1 人材を活用する

  • 開発における問題の殆どは「人に関する問題」である
  • 本来持っている能力(静的側面)と、チームに入ってから発揮できる能力(動的側面)は違う
  • 頭を使う仕事では、手を動かさずじっくり考えることが重要
  • 残業をすると、その分次の日のパフォーマンスが落ちる
  • 品質を上げるとコストは下がる。が、品質を上げる権限を得ることは難しい
  • 目標は無いほうが成果が出る
  • マネジメントでするべきことは、部下のやる気を出させること

2 オフィス環境と生産性

  • オフィスの品質は生産性と品質に悪影響を与える
  • 残業の理由は、「量をこなすため」ではなく「品質を上げるため」
  • プログラマーの生産性は、一緒に働くプログラマーとほぼ同じになる
  • 一人で集中して誰にも邪魔されずに作業する時間が必要
  • 良いアイディアは無音の空間で生まれる
  • 同じチームの3,4人を一つの部屋に入れると、必要なときにコミュニケーションし、同時にフローに入れる
  • オフィスに快適な環境が無いなら、外に借りてもいい

3. 人材を揃える

  • 社内の標準に収まっているかどうかを気にしない
  • リーダーシップとは、全員に最大の価値を与えるような仕事を自ら仕事を引き受けたときに生まれる
  • 採用プロセスでは、できるだけ実際の能力がわかるような成果を見せてもらう
  • 人間的な能力も見たほうがいい
  • 人がやめたときのコストは大きい

4. 生産性の高いチームを育てる

  • チームに仕事をさせるのではなく、一体感をもたせる

5. 肥沃な土壌

  • リスクを考えるときに、自分が責任を全うできなかった場合も考える
  • 会議は儀式になりやすい
  • 組織の学習能力は、どれだけ人を引き止めておけるかで決まる

6. きっとそこは楽しいところ

感想

プログラマーの成果は、かけた時間ではなく、誰にも邪魔されずに連続して集中できた時間で決まる、という主張がはっきり述べられていたのが印象的だった。これはすぐに仕事に活かせそう。全体的に、マネジメント担当者に向けて書かれているので、自分の仕事のポジション的にすぐに役立てられそうな話題は少ないように感じた。

個々の話題について、あまり具体的な解決策が示されているように感じなかった。なので、それで結局どうすればその課題は解決できるの?という疑問が解決されないまま話が進んでいくように感じた。

基本的な原理は示したので、あなたが考えてくださいねという投げかけなのだと思う。

出版から30年近く経っているので、とても目新しい考え方を目にするということは少なかった。これは、後続の本や開発プロセスに、この本が影響を与えているからだろう。この本の功績を物語っていると考えるべきだろう。