読書メモ:『ピープルウエア第3版』第 Ⅰ 部「人材を活用する」
このメモについて
- これは要約
これは本文の引用
これは本文の独立した太字テキストの引用(本書のメッセージに関わる部分)
→ これは私が本書から読み取ったメッセージ
第Ⅰ部 人材を活用する(p.1)
第Ⅰ部では、人や人の扱いについて、今までと全く違った考え方を述べる。これには、交換不能という人的資源の性質に適応する方法も含む。
第1章 今日もどこかでトラブルが(pp.2-5)
- 簡単なプロジェクトが失敗する理由は技術的な問題として片付けられない
- この本では、人に関する問題をテーマとする
実際のところ、ソフトウエア開発上の問題の多くは、技術的というより社会学的なものである。
- 技術より人に気を配っているマネージャーは滅多にいないのは「ハイテクの幻影」のせい
……多少なりとも最新技術に関係している人は、自分はハイテクビジネスの旗手だと錯覚している。……本当にハイテクビジネスに身を置いているのは、ハイテクの領域で、基本的な発明発見を成し遂げた研究者だけだ。それ以外の人は、他人の研究成果を応用しているに過ぎない。
ソフトウエアは、多数のチームやプロジェクト、固く結束した作業グループで開発するので、ハイテクビジネスではなく人間関係ビジネスに携わっているといえる。プロジェクトの成功は関係者の緊密な対人関係によって生まれ、失敗は疎遠な対人関係の結果である。
- → マネージャーの仕事は人間関係を扱うこと
第2章 チーズバーガーの生産販売マニュアル(pp.6-12)
- チーズバーガー工場式のマネジメントはソフトウェア開発になじまない
- 工場式では失敗を許さないが、「知的労働者が時々ミスを犯すのは極めて自然で、仕事を真面目にやっている証拠である。」
頭を使う仕事では、頭を調子良く働かさなければならない。担当者をあれこれとせき立てて、働かせることはできても、創造的で、工夫に富み、思慮深い仕事はさせられない。
- 人を知るマネージャーは、担当者一人ひとりのユニークな個性がプロジェクトを活発にすることを知っている
- プロジェクトは打ち切られるか終了するまでは安定しない動的側面に神経を使うべきであり、プログラマーは「静的な能力」よりも「グループ全体にうまくなじむか」を重視すべき
- 「触媒」の役割を果たす人は、不安定なプロジェクトを安定させる
- 超人的な力が必要な仕事こそ、手を動かすよりもチームビルディングに時間を割くことが重要になる
- ヘラクレス的=超人的という意味
第3章 ウィーンはきみを待っている(pp.13-20)
-
二つの価値観
- スペイン流:「地球上には一定量の価値しかないので、豊かになる道は大地や民衆から、いかに富を絞り取るか」
- イギリス流:「価値は、発明の才能と技術で創造するもの」
- スペイン流は、残業代のつかない人にタダ働きさせて生産性を上げようとする(本来は時間をかけた分だけ小さくなっていく)
-
人生は短い(ビリー・ジョエルも「VIENNA」で歌っている)
- 残業時間を埋め合わせる「無業」の時間で生気を取り戻せる人はまだいい
- それができないとワーカホリックに陥って大切なものを失い、黙って辞めていく
-
マネージャーはワーカホリックをどう扱うべきか?
- スペイン流マネジメントはワーカホリックになった部下を失う
- 「本当の意味での生産性」というテーマに発展する問題
-
生産性と退職(離職)
- 生産性を上げる典型的な方法は、退職率を上げるリスクを伴う
- それを認識しなければ、キーマンの退職という痛手を受ける
- 生産性は利益をコストで割ったものと定義すべきであり、そのコストには「退職者の補充に費やした余計な費用を含むべき」。
早くヤレとせかされれば、雑な仕事をするだけで、質の高い仕事はしない。
仕事を早くするためには、製品の品質と仕事の満足感を犠牲にせざるを得ない。
第4章 品質第一……時間さえ許せば(pp.21-26)
- 自尊心と品質
- プログラマーの自尊心は、製品の品質(量ではなく質)と結びついている
- プログラマーの自尊心を満足させる最低水準=今までに達した最高水準であり、マーケットが金を出す水準よりもずっと高い
- たしかに品質の低さを気にしないユーザーはマーケットにいるが、かれらはプログラマーの品質基準を満たすさいの足かせになる
- 品質が低くてもを気にしないユーザーに合わせていると、品質の低い製品を買わないユーザーを失い、市場浸透力が低下する
開発者でなく、買手に品質基準を決めさせることを「品質第一主義からの逃避」と呼ぶ。……長い目で見れば、市場に品質を合わせると、コストが増える。
- 「品質第一主義からの逃避」からの教訓
エンドユーザーの要求をはるかに超えた品質水準は、生産性を上げる一つの手段である。
価格と品質はトレードオフの関係にあるという考えは、日本には存在しない。
反対に、高品質がコスト低減をもたらすという考えが広く受け入れられている。
[1][Tajima and Matsubara 1984] p.40
品質はタダである。ただし、品質に対して喜んで金を出す人だけに対して。
[2][Crosby 1979]
- ヒューレット・パッカード社のエンジニアは、市場よりも遥かに高水準の品質を供給するという企業文化を負っていることを認識している
- 日立ソフトウェアエンジニアリング(現日立ソリューションズ)と一部の富士通の部門では、製品出荷拒否権限をプロジェクトチームが持ち、品質を守っている
→ 品質のイニシアチブを良い意味で顧客に握らせないことが、品質を守り、生産性を高める上で肝要
-
Tajima and Matsubara, 1984.:Tajima, D., and T. Matsubara. "Inside the Japanese Software Industry." Computer, Vol.17(March 1984). ↩︎
-
Crosby, 1979.:Crosby, Philip B. Quality Is Free: The Art of Making Quality Certain, New York: Harper & Row, 1970. 邦訳 小林宏治監訳、『クオリティ・マネジメント――よい品質をタダで手にいれる法』、日本能率協会、1980年 ↩︎
第5章 パーキンソンの法則の改訂(pp.27-32)
パーキンソンの法則は、ほぼ確実にあなたの部下にはあてはまらない。
-
パーキンソンの法則
- パーキンソンの法則:「仕事は与えられた時間に見合うところまで膨張する」
- 科学法則ではなく、時間を決めたら仕事がそれまでに必ず終わるわけじゃないよ、という皮肉(なので、膨張というよりは伸縮というのが和訳として適切ではないか?)
- パーキンソンの法則を信じるマネージャーは、部下に仕事を完成させるためには無茶な納期設定が必要だと思い込んでいる
- よいチームを作ろうとして部下をパーキンソン流に扱うと、プログラマーの意欲を挫いて逆効果になる
-
ニューサウスウェールズ大学の実験
- 目標値設定のやり方によって生産性がどのように影響を受けるのかの調査
- 仮説:開発者(プログラマー)は自分で立てた目標値を達成するために懸命に努力する
- 結果:仮説通り(表 5.1)
- 表 5.2 のシステムアナリストのデータが仮説に従わないのは、かれらが誤った目標値を設定しないプロだから
- 表 5.3:上司が日程的なプレッシャーを少しもかけなかったプロジェクトは最高の生産性を示した
- いつもハッパをかけるマネージャーはマネージャー自身に問題がある
表 5.1 目標値設定者による生産性の違い(結果の一部)
目標値設定者 | 平均の生産性 | プロジェクト数 |
---|---|---|
プログラマー | 8.0 | 19 |
マネージャー | 6.6 | 23 |
プログラマーとマネージャー | 7.8 | 16 |
表 5.2 目標値設定者による生産性の違い(結果の一部)
目標値設定者 | 平均の生産性 | プロジェクト数 |
---|---|---|
プログラマー | 8.0 | 19 |
マネージャー | 6.6 | 23 |
プログラマーとマネージャー | 7.8 | 16 |
システムアナリスト | 9.5 | 21 |
表 5.3 目標値設定者による生産性の違い(結果の一部)
目標値設定者 | 平均の生産性 | プロジェクト数 |
---|---|---|
プログラマー | 8.0 | 19 |
マネージャー | 6.6 | 23 |
プログラマーとマネージャー | 7.8 | 16 |
システムアナリスト | 9.5 | 21 |
目標なし | 12.0 | 24 |
- パーキンソンの法則を手直しするとこうなる(※皮肉)
会社のルーチンワークは、就業時間に見合うところまで膨張する傾向がある。
- こうなると会社の問題。第Ⅱ部で再び取り上げる。
第6章 ガンによく効く?「ラエトライル」(pp.33-38)
- ラエトライル
- ラエトライル:アンズの種から採れる液体で、病気に効く証拠が無いのに法外な値段で売られている
- 筆者は生産性を向上するために企業文化の改善が重要だと考えているが、難しい
- マネージャーが技術的ラエトライルのカモになっているうちは、健全な企業文化を作る努力をしない
マネージャーが陥りやすい7つの錯覚と反論
1. 生産性を飛躍的に向上させる方法があるはずなのに、今までずっと見落としてきた
反論:そんな基本的なものを見逃すほど馬鹿じゃない
2. 他のマネージャーは2倍も3倍も成果を上げている
反論:気にするな、ソフトウエア開発はやることが一杯あることには変わりがない
3. 技術は日進月歩で、油断するとすぐ置いていかれる
反論:コンピューターは進歩したが、ソフトウエア開発は従来のまま(ハイテクの幻影)
4. プログラミング言語を変えれば、生産性は大幅に上がる
反論:コーディング工程にしか影響を与えないし、5%は上昇するかもしれないが、それ以上にはならない
5. バックログが多いから、すぐにでも生産性を2倍にする必要がある
バックログ=積み残し作業のこと
参考:バックログとは|「分かりそう」で「分からない」でも「分かった」気になれるIT用語辞典
反論:プロジェクト完成時のコストが当初予算を上回るのは常識。
6. 何もかも自動化してしまおう。そうすれば、ソフトウエア開発者がいらなくなるのではないか?
反論:ハイテクの幻影の一つで、ソフトウエア開発者の仕事は人と人とのコミュニケーションであり、自動化できるはずがない
7. 部下に大きなプレッシャーをかければ、もっと働くようになる
反論:やる気を無くすだけ
- さんざん否定的なことを並べたが、マネージャーは何をすればいいのか?
- 人を働かせるのではなく、人を働く気にさせること
第 Ⅰ 部
- 第1章:ソフトウエア開発で起こる問題は技術じゃなくて人の問題だから、マネージャーの仕事は人間関係を扱うことだよ
- 第2章:体を動かす仕事の工場式マネジメントは、頭を動かすソフトウエア開発の仕事のマネジメントに役に立たないよ
- 第3章:スペイン流マネジメントはワーカホリックになった社員を失わせて生産性を下げるよ
- 第4章:無茶な納期を設定するスペイン流マネジメントは品質を下げるよ/品質管理のイニシアチブを市場や顧客に取らせるかどうかは品質に影響するよ
- 第5章:マネージャーの仕事は納期設定じゃなくて、適切なタイミングで部下にハッパをかけることだよ
- 第6章:生産性を上げるというのは、人を働かせることではなく人を働く気にさせることだよ
まとめ:
- マネージャーの仕事はプログラマーを働く気にさせるのが仕事
- そこに注目すれば、ソフトウエア開発のマネジメントが適切かどうかがわかる