ピープルウェア第二版―ヤル気こそプロジェクト成功の鍵
「システムエンジニア、デザイナーなどいわゆるクリエイターと
言われる職種の人たちをチームとして機能させる」
これは今の私のテーマなのですが、一般的なチームビルディングの
書籍にはこういった特殊な？技能を持ったプロフェッショナルを
どのように扱うか、そしてどうしたら楽しいと思えるビジョンとなって
気持ちを一つにできるのかが欠けています。
この欠落していると思える2大テーマの前者はこの書籍、
後半についてはまた他の書籍で補完したので別の機会に紹介します。
さて、この本ですが、大元は89年に出したピープルウェアの第一版。
これに99年にⅥ章を追加することにより第二版としてます。
言いたいことは第一版でほぼ書かれており、ソフトウェアエンジニアリング
でエンジニアをどういう組織にするべきかということについて
バイブルともいえる内容です。
第二版で追加したⅥ章は自動翻訳を使ったのではないかというくらい
何が言いたいのかよくわからない内容になってますが、最後の最後は
きちんと翻訳したらしく、何とか本の体裁にはなっています。
せっかくの名著がちょっと台無しですね。
まず人材の考え方について説明しています。大事なポイントは
・ソフトウェア開発上の問題の多くは技術上のものではなく社会学的なもの
・スペイン流管理（地上にあるすべてのリソースは限られているので
その中でいかに搾り取るかに重点を置く）では人は動かない
・人生というものを考えて人を管理している人は少ない
・エンドユーザの要求をはるかに超えた品質管理こそ生産性を上げる方法
・「与えられた仕事をするのに余る時間は全くない」というパーキンソンの法則
はエンジニアには当てはまらない
→つまり納期でプレッシャーをかければやりきるであろうという考え方は
通用しない
・ラエトレイル（杏から取れるというがんの治療薬だが効果は？というもの）
に引っかかる管理者は多いが、管理の本質は「働かせる」ではなく「働く気にさせる」
ことである
次に労働環境について。
・プログラマのような知的労働者が日中に割り込みを入れてしまうことで生産性を
下げていることはさけるべき（静かな環境なら1日でできることが日中のけたたましさで
2，3日に伸びてしまうことへの懸念）
・パーソナルスペースの拡充など広くて静かな環境を用意することによりプログラムの
質は格段に向上する
３つめは人材について。
・原則は３つ
人材を揃える
人々に満足感を与え、やめないようにする
人々を束縛から解放する
・企業エントロピー（平準）は組織内では常に増加する
→誤ったプロフェッショナルの定義により、没個性の集団と化す
→管理者はこのエントロピーと戦い、部下の育成によりプロジェクトを活性化すべし
・オーディション（すなわち採用時にはテストしろということ）の必要性
・ここ（職場）にいるのが楽しいと思わせるようにすべし
→退職ほど無駄なコストはない
・作業既定の類は業務がある程度、軌道に乗った時点で後付けで作ればよい
（研修、ツール、レビューといった手法を用いる）→最初から型にはめるな
生産性の高いチームについては
・「挑戦」できる目標を共有し、一緒になって努力するようにする
・「目標」に会社の利益を混同してはいけない
・チーム編成の目的は目標の達成ではなく、目標に向かって一体になること
・結果として目標を達成できれば、より結束力が高まる
・結束力の高いチームの特徴は
退職率の低さ
アイデンティティ感覚（選ばれた自負）
生産物共有意識（自分たちが作ったという愛着）
・チーム殺しとなる法則
自己防衛的な管理
官僚主義
作業場所の分散
時間の分断
品質低減製品
さばを読んだ納期
チーム解体の方針
・裃を脱ぎ、部下を信頼して仕事を任せるようにすること。部下の自尊心にも
配慮すべし。そうすることが最善を尽くさせる方法である。
・場所を隔離してプロジェクトを進める「スカンクワーク」は能率を高める
（会社にとってのデメリットもあるが、管理者はこれと闘う必要あり）
・健全な会社にするための６つの手法
品質至上主義
満足感を与える打ち上げを用意する
エリート感覚を醸成する
チームに異分子を混ぜることを奨励
成功チームを解散させないで保護する
戦略でなく戦術を与える
・管理者はルール上同僚とはなれず、上からの指示や管理上の手続きをメンバーから
取り除く役割を果たす
・リーダーはメンバーの誰もがやるということで、恒久的なリーダーは不要
・チームは階層構造ではなくネットワーク構造で
５つめは仕事は楽しくあるべきということでそのためのいくつかのTipsを紹介しています。
・試行プロジェクト
新しくてまだ効果が実証されていない技術を試す機会
・プログラミングコンテスト
あるテーマにそってプログラミングを行い、各個人の実力を比較するというものだが
結果は公表せず、本人のみに伝え、業務上の評価にしないという形をとることで
楽しくなるんだとか
・ブレーンストーミング
なるべく多くのアイデアを出させることが目的
・実戦さながらの訓練
・教育、旅行、学会、お祭り、そして冒険体験
大体こんな内容で非常に参考になるところも多かったです。初版から20年以上も
経つというのに似たような失敗や誤った考え方というのはどこでも変わらないのですね。
99年の第2版（日本語訳は2001年）で追記されたところで参考になる個所があったので
そこを紹介しつつ本書評を締めます。
「満足のいくコミュニティつくりに成功した組織は人を引き付ける」
派閥と言われようが成功体験をしたチームの結束は必ず波及すると思います。
人はやめないし、いいものを作ろうというスパイラルも生まれる。
私自身がこの仕組みを理解していなくて迷惑をかけた人は数知れません。
それだけの仕事に耐えうる人を選抜しているということに自信を持ちながら
自らもマネージャーとして成長していきたいですね。
言われる職種の人たちをチームとして機能させる」
これは今の私のテーマなのですが、一般的なチームビルディングの
書籍にはこういった特殊な？技能を持ったプロフェッショナルを
どのように扱うか、そしてどうしたら楽しいと思えるビジョンとなって
気持ちを一つにできるのかが欠けています。
この欠落していると思える2大テーマの前者はこの書籍、
後半についてはまた他の書籍で補完したので別の機会に紹介します。
- ピープルウエア 第2版 － ヤル気こそプロジェクト成功の鍵/トム・デマルコ
- ￥2,310
- Amazon.co.jp
さて、この本ですが、大元は89年に出したピープルウェアの第一版。
これに99年にⅥ章を追加することにより第二版としてます。
言いたいことは第一版でほぼ書かれており、ソフトウェアエンジニアリング
でエンジニアをどういう組織にするべきかということについて
バイブルともいえる内容です。
第二版で追加したⅥ章は自動翻訳を使ったのではないかというくらい
何が言いたいのかよくわからない内容になってますが、最後の最後は
きちんと翻訳したらしく、何とか本の体裁にはなっています。
せっかくの名著がちょっと台無しですね。
まず人材の考え方について説明しています。大事なポイントは
・ソフトウェア開発上の問題の多くは技術上のものではなく社会学的なもの
・スペイン流管理（地上にあるすべてのリソースは限られているので
その中でいかに搾り取るかに重点を置く）では人は動かない
・人生というものを考えて人を管理している人は少ない
・エンドユーザの要求をはるかに超えた品質管理こそ生産性を上げる方法
・「与えられた仕事をするのに余る時間は全くない」というパーキンソンの法則
はエンジニアには当てはまらない
→つまり納期でプレッシャーをかければやりきるであろうという考え方は
通用しない
・ラエトレイル（杏から取れるというがんの治療薬だが効果は？というもの）
に引っかかる管理者は多いが、管理の本質は「働かせる」ではなく「働く気にさせる」
ことである
次に労働環境について。
・プログラマのような知的労働者が日中に割り込みを入れてしまうことで生産性を
下げていることはさけるべき（静かな環境なら1日でできることが日中のけたたましさで
2，3日に伸びてしまうことへの懸念）
・パーソナルスペースの拡充など広くて静かな環境を用意することによりプログラムの
質は格段に向上する
３つめは人材について。
・原則は３つ
人材を揃える
人々に満足感を与え、やめないようにする
人々を束縛から解放する
・企業エントロピー（平準）は組織内では常に増加する
→誤ったプロフェッショナルの定義により、没個性の集団と化す
→管理者はこのエントロピーと戦い、部下の育成によりプロジェクトを活性化すべし
・オーディション（すなわち採用時にはテストしろということ）の必要性
・ここ（職場）にいるのが楽しいと思わせるようにすべし
→退職ほど無駄なコストはない
・作業既定の類は業務がある程度、軌道に乗った時点で後付けで作ればよい
（研修、ツール、レビューといった手法を用いる）→最初から型にはめるな
生産性の高いチームについては
・「挑戦」できる目標を共有し、一緒になって努力するようにする
・「目標」に会社の利益を混同してはいけない
・チーム編成の目的は目標の達成ではなく、目標に向かって一体になること
・結果として目標を達成できれば、より結束力が高まる
・結束力の高いチームの特徴は
退職率の低さ
アイデンティティ感覚（選ばれた自負）
生産物共有意識（自分たちが作ったという愛着）
・チーム殺しとなる法則
自己防衛的な管理
官僚主義
作業場所の分散
時間の分断
品質低減製品
さばを読んだ納期
チーム解体の方針
・裃を脱ぎ、部下を信頼して仕事を任せるようにすること。部下の自尊心にも
配慮すべし。そうすることが最善を尽くさせる方法である。
・場所を隔離してプロジェクトを進める「スカンクワーク」は能率を高める
（会社にとってのデメリットもあるが、管理者はこれと闘う必要あり）
・健全な会社にするための６つの手法
品質至上主義
満足感を与える打ち上げを用意する
エリート感覚を醸成する
チームに異分子を混ぜることを奨励
成功チームを解散させないで保護する
戦略でなく戦術を与える
・管理者はルール上同僚とはなれず、上からの指示や管理上の手続きをメンバーから
取り除く役割を果たす
・リーダーはメンバーの誰もがやるということで、恒久的なリーダーは不要
・チームは階層構造ではなくネットワーク構造で
５つめは仕事は楽しくあるべきということでそのためのいくつかのTipsを紹介しています。
・試行プロジェクト
新しくてまだ効果が実証されていない技術を試す機会
・プログラミングコンテスト
あるテーマにそってプログラミングを行い、各個人の実力を比較するというものだが
結果は公表せず、本人のみに伝え、業務上の評価にしないという形をとることで
楽しくなるんだとか
・ブレーンストーミング
なるべく多くのアイデアを出させることが目的
・実戦さながらの訓練
・教育、旅行、学会、お祭り、そして冒険体験
大体こんな内容で非常に参考になるところも多かったです。初版から20年以上も
経つというのに似たような失敗や誤った考え方というのはどこでも変わらないのですね。
99年の第2版（日本語訳は2001年）で追記されたところで参考になる個所があったので
そこを紹介しつつ本書評を締めます。
「満足のいくコミュニティつくりに成功した組織は人を引き付ける」
派閥と言われようが成功体験をしたチームの結束は必ず波及すると思います。
人はやめないし、いいものを作ろうというスパイラルも生まれる。
私自身がこの仕組みを理解していなくて迷惑をかけた人は数知れません。
それだけの仕事に耐えうる人を選抜しているということに自信を持ちながら
自らもマネージャーとして成長していきたいですね。