「ピープルウェア(第2版) ヤル気こそプロジェクト成功の鍵」- 「第1部 人材を活用する」を読んで
最初に勤めた会社で、エンジニアリング研修の指導者が推薦していた
トム・デマルコの著書を空いた時間で読んでみることに。
なるべくの速読を目指しつつ、
振り返り用のメモとして残します。
なぜピープルウェア(Peopleware)を選んだか
人と一緒に働くのが好きなものの、少しブランクが空いてしまったので
なんとなく、そういった記憶の喚起に効きそうな一冊を選択。
枝葉なのですが、このいかにもっぽい副題は日本独自なのですね。
原副題は Productive Projects and Teams とシンプル。
お客さんの手に取ってもらいやすくするっていう意味では、日本の副題はマーケティング戦略として正しいのか。
第1部: 人材を活用する の論点と著者の意見
要約:「互いに尊重し、協調し合い、十分に会話をすることで、高品質/高生産性を目指すことのススメ」
第1章: 今日もどこかでトラブルが
問題意識の喚起
- 執筆当時の1980年頃、20%前後のプロジェクトが失敗に終わるという現状。
- プロジェクトの失敗は、技術面でなく社会学的な原因に由来するところが大きい。
- しかし、管理者はその「社会学的」な課題の解決に取り組めていないという現状の提示。
- 管理者のそういった態度の原因は、単に技術的な課題が解決しやすい明快な問題であるため。
・現在は、こういった書籍の影響も積み重なったからなのか、管理者も一定成長している。
第2章: チーズバーガーの生産販売マニュアル
頭脳労働者の扱い方の基本
- 頭脳労働者と工場労働者は別物。
- 工場労働者の場合は、決められたルールの中でミスなく最大効率で労働することが資源の最大活用になるが、
頭脳労働者の場合は、 Try&Errorありき、自発性が認められる環境で労働することが資源の最大活用になる。 - 人員は部品のように替えが効くものではない。
- ユニークな人材(触媒)交流による化学反応の有意性。
- エンジニアやアーティストなど、スキルを武器に生きている人間の採用こそ、
静的能力(レジュメに書けるスキル)でなく、実際にチームに馴染めるかを意識するべき。(社会学的な課題に直結) - 頭を使う仕事の重要性は、リスクが大きくなるほど増大する。
スッと入ってきた言葉:
「人は誰しも仕事に愛着を持っている。管理者は、むしろ働きすぎないように、時折、気を配らなければならない。」
・人材交流や採用については、チーム加入後に実際に触媒反応を起こさせることに至っていないケースを多く見かける。
・本当は経験があるのに言わない、本当は興味があるのに言わない、などもったいないケースが多い。
・基本的な頭脳労働者への態度については賛成だが、
年俸制度などの賃金体系と合わせて考えないと労働効率については一概には論ずることができないと思う。
・プロジェクトが実現するべきことは必ずあるので、その中でいかに自由度を高め、その自由を謳歌してもらうかが重要。
・別途、本当に現場のプログラミングが他の労働よりも過酷な頭脳労働なのか、とは思う。例えば弁護士などと比べて。
第3章: ウィーンは君を待っている
搾取されない労働のあり方
- あなた自身も"犠牲"と思ってしまうほどに、人生のバランスを崩す必要は無いし、
あなたの部下にも当然それを強いるべきで無い、という思想。 - 残業は、同等の無業時間を要するという考え方。
- 仕事中毒者は、どこかで我に返った時、社内で配置換えを望むこともなく、退職する。本当の意味での教育コスト管理(生産性)の話題。
- 生産性向上への取り組み(標準化や機械化)が、退職率を向上させる可能性がある。(※1)
| 地域 | 価値に関する思想 |
|---|---|
| スペイン流 | 地球上の価値の総量は一定(ゼロサム)なので搾取することで強者になれる |
| イギリス流 | 価値は才能と技術で生み出すもの |
・請負開発では、大体初期契約時点で大枠の開発費などは決定しているので、スペイン流に陥りがち。
・どうにか、納得と安心を届けつつ開発費用を動的に計上できるようにするか、もしくは、高い精度でいかに見積もるかが大事。
・仕事中毒者=能力者の可能性も高いので、ふとした時に、容易に他に移動する。
※1の示唆は、他の人に野暮な仕事を任せて自分が自由に活動するための対価なので、これを払えないエンジニアは個人的には結構NG。単体テスト書きたくない人とほぼ一緒。
第4章: 品質第一 時間さえ許せば
高品質は労働者も製品もユーザも幸せにする
- オフィスにおける感情の主な構成要因は、自尊心。
- 大抵の人は製品の量でなく、質で自尊心を満たす。
- 極端な時間的プレッシャーは、品質劣化につながる。期待する品質を短時間で得ることはできない。
- 開発者にとっての最低品質は、その人の過去最高品質とイコール。
- ユーザにとっての品質の方が、よほど開発者が望む品質よりも低い。
- 高品質が高生産性/低コスト化をもたらす。
- 品質に対して予算を組み、相応の覚悟を決める。
- 出荷拒否権限。日立や富士通で採用されているリリースルール。
・著者曰く、「高品質が高生産性をもたらす」らしく、日本がその例として挙がっているが、
日本のそれは「職人気質/本物指向」と「規律/(死ぬほどの)真面目さ」といった国民性が為せる業であって、例として不適切。
・品質向上が、どれだけコスト抑制や生産性向上に影響するか、計量・明示できると方針が定めやすい。
・顧客の手にものを届けることを楽しみにできるだけの、意義を参画者と共有することが重要。
第5章: パーキンソンの法則の改定
現場目線の目標設定がもたらす高生産性
- パーキンソンの法則: 「労働者はあるだけ時間を使ってしまう」は間違っている。
労働者も、作ったものが早く顧客の手に届くことを期待するため、その分、熱心に仕事をする。
労働が期待通りでない場合、例えば、力不足感、自身の無さ、同僚とのコミュニケーションロス等が要因として考えられる。 - 目標設定者と生産性の関係について、生産性は、優れたものから以下の順となる。
目標なし > システムアナリスト > プログラマー > プログラマー+管理者 > 管理者 - 組織の管理業務は、時間がいくらあっても足りない。
・参画者が熱量をもっていることが前提となっているが、その点の温度合わせが難しいところではある。
・熱を感じさせ、巻き込むのが管理者の仕事。とはいえ、熱で労働を強いるのでなく、知的好奇心を刺激するようなスパイスを与える形で。
・目標設定は、少なくともエンジニアや第三者を交えて行うべき。
・管理業務は、全般的にシステム化を図るべき。
・ここで言う「生産」されたものが、果たして「ユーザが享受した価値」なのか、「ソースコードの量」なのかが気になる。
第6章: ガンによく効く?「ラエトライル」
堅実な改善が功を奏す
- 生産性は飛躍的に向上しない。
- 実際の製造工程全体は壮大であるため、その内の開発工程のみをN倍速にするテクニックを用いても、全体としてはやはり相応の時間を要する。
- 技術の進歩はめまぐるしいが、年間で生産性の向上は3~5%程度。自動車産業より少しましな程度。
- プログラミング言語の変化で生産性が大幅に変わることはない。
- 機能やプロジェクトの取捨は、収益ベースで行い、バックログ/やりたいことに流されないようにする。
- プレッシャーは薬よりも毒になる。
- 管理者は、人を働かせるのでなく、働く気にさせるもの。
・実際のものを扱うこともなく、仕入れも無いにも関わらず、自動車産業と同程度の進化速度なのは、産業としてだらしなさすぎる。
・逆に言えば、もっと改善の余地がある。
・人を働く気にさせるもの。は気にしてやってたけど、改めて大事なんだろうなと思った。
