ピープルウエアを読んでの感想

デッドラインを読んでもいまいちピンと来なかったので補足として『ピープルウエア 第2版 － ヤル気こそプロジェクト成功の鍵』を読んでみた。



デッドラインは小説仕立てで読みやすいのは良かったけれど、たまに得心のいかない法則が出てくるときもあり「？」となる場合があったけれど、ピープルウェアはデッドラインと同じような素材を扱いながらも違う視点から切り出してあるのでデッドラインで学んだ法則の理解を補強するのに役立った。それに各章ごとに内容にそった小話的な実話がちょこちょこ挿入されているので読んでいて飽きない工夫がされているのも良かった。

全6部構成で各部それぞれ下記のようなことが学べる。

第1部　管理するとは
やってはいけない管理方法がわかる。

第2部　オフィス環境を整えることの重要性
思考を電話などによって頻繁に中断されることがいかに頭脳労働にたいして悪影響かがわかる。
オフィスのレイアウト周りの話なんかはあまり興味がないけれど、オフィス移転を考えているような人には良い参考になると思う。

第3部　人材をそろえる、維持する方法
人材をそろえる効果的な方法や退職に伴うコストなどが解説されている。
下記の企業側からみた退職のコストの考え方は意識したことも無かったので目からうろこで面白かった。
--------------
退職のコスト＝４～５月分の人件費
内訳：人材紹介会社への報酬、人事部門の費用、プロジェクトになれるための教育コスト（本人が学ぶ分とその他の教える人達の分）などなど
--------------

第4部　生産性の高いチームを作る方法
チームの効果を高める方法について、良い方法、悪い方法が解説されている。
要はやる気ということで、それをどのように高めるかというお話。

第5部　仕事を楽しくするには～
とくに感想なし。

第6部
１～５部それぞれの小さな続編。

デッドラインを読んでの感想

手を動かすほうが好きなので管理とかにはあんまり興味がないのだけれど、後学のために『デッドライン―ソフト開発を成功に導く101の法則』を読んだので感想とか内容の覚書とか。



技術系の本は読むけれど、こういうノウハウ系の本はあまり手にとったことがなかった私にとってこの本の内容は「ものすごくためになった！」とか「明日から即実践しよう！」とかそういう感動系のたぐいではなく、「あぁ管理ってこういうものなんだ、へー」という感じに曖昧模糊としていたものの理解を助けてくれたり、「あぁこういう問題が起こりえてそういうときはこういう風に対処すれば良いのね」という先駆者の知恵を授けてくれた。

内容は小説仕立てで、各章の最後にその章で主人公が学んだことを法則として小説のなかから抜き出してまとめてくれるので、さくさくと読んでいけてあっという間に読み終わる。そのままにしてしまうと脳みそからすぐ抜け落ちてしまうことは確実なので、101個の法則のなかから気にいった法則を下記にまとめておいた（結構な数になったけど）。法則だけ読んでも意味不明なところが多々あると感じるかもしれないけれど小説を通して読めば前後の文脈があるので理解できる。

基本

• 適材適所
• 士気を高める
• Teamの結束を強め維持する
• 変更はプロジェクト成功のために必要不可欠である
• 人は安全が保証されないと変更を受け入れない
• リスクをさけるとそれに伴う利益も逃がす
• どれほど強く脅しても最初に割り当てた時間が足りなければ仕事は完成しない
• 管理は、心、腹、魂、鼻でやるもの。心で指揮をとり、自分の腹（直感）を信じ、組織に魂をふきこみ、くだらないものをかぎ分ける鼻
• 戦闘が始まるときには管理者のほんとうの仕事はすでに終わっている

採用

• 採用には心、魂、腹、鼻すべてを使う（腹が大部分）
• 一人でやろうとするな。二つの腹には一つの腹の2倍以上の力がある
• 新しく採用した人材は、能力実証済みレベルのプロジェクトを任せ目標を拡大するのは次回以降とする
• 意見をもとめよ。優れた人材は優れた人材を知っている可能性が高い
• 話すよりも聞け

生産性

• 短期的に生産性を高める方法などない。生産性は長期的な投資によって向上する
• 短期的な効果を約束するものはいんちきである可能性が高い

リスク管理

• リスクを管理してプロジェクトを管理せよ
• プロジェクトごとにリスク調査の方法を確立して継続せよ
• 最終的な望まざる結果だけでなく、日常のリスクに注意せよ
• それぞれのリスクの実現する確率と予想コストを評価せよ
• リスクが現実になる前の初期の兆候を予測せよ
• 悪い話が上層部に伝わりやすい経路を作っておくこと（匿名メールなど）

人材管理

• 成功を最大化するより失敗を抑えることによって全体的な成績を高めることができる
• 失敗した作業は早く打ち切る勇気をもつ
• チームの結束については既存のチームを探して利用したほうが楽だったりする
• 結束力のあるチームはばらさずに維持する（本人たちが望めば）。そうすると後継者たちが困らない
• 新しい仕事を引き受ける意欲のある結束の固いチームはプロジェクトの成果の一つとみなす
• プロジェクト初期に無駄にする一日も末期に無駄にする一日も等しく打撃になる
• 一日をむだにする方法はいくらでもあるが、一日を取り戻す方法はひとつもない

開発プロセスのモデリングとシミュレーション

• 仕事を完成させるプロセスに関する直感をモデル化する
• 仲間と対話しつつプロセスの進行に関する考えを伝えたり修正したりするためにモデルを使う
• モデルを使って結果をシミュレートする
• 実際の結果と照らし合わせてモデルを調整する

理想と現実

• 病んだ政治＝政治的な理由からくるむちゃくちゃな要求（機能はそのままで納期を半分にしろなど）
• いつでもクビをかける覚悟が必要である
• それでも病んだ政治の影響を受けないとは限らない
• 病んだ政治はもっとも健全な組織にも出現する可能性がある

プロジェクトの数量化

• すべての製品のサイズを測定せよ
• 単位は気にするな。客観的な尺度ができるまで主観的な単位を使えばよい
• 手に入るすべての基本要素（ソフトウェアの数量化可能な特徴）をもとに合成尺度を作成する
  －この法則のトレンドライン周りの話はピンとこなかった（最近の開発にはあてはまらない気がする）

プロセスとプロセス改良

• 優れたプロセスとプロセスを絶えず改良することは立派な目標である。それらはまたごく自然な目標でもある。すぐれた技術労働者は指示があろうとなかろうとそれらに焦点をあてる
• 形式的なプロセス改良プログラムには時間と金がかかる。一つのプロセス改良プログラムのためにプロジェクトが後退することもありうる。生産性の向上が実現したとしても、そのプログラムを受け入れたプロジェクトでプロセス改良のために費やされた時間を相殺できる可能性は低い（次以降に効力を発揮する）
• プロセスは注意深く選んだひとつの手順改良によってその変更に投資した時間と金に報いるだけの利益を期待できることがある
• プロジェクトの期間中に二つ以上の手順改良に順応することは現実には期待できない
• 標準的なプロセスの危険な点は人々が懸命な省略を行う機会を失わせることである。とくに、人員過剰のプロジェクトの場合、標準的なプロセスによって全員に行き渡るだけの仕事が発生するなら（役にたとうがたつまいが）、標準的なプロセスが厳密に守られてしまう

設計とデバッグの関係

• デバッグの時間を大幅に減らさなければ、プロジェクトの成績を通常より大幅に高める方法はない
• 優れたプロジェクトはデバッグに費やす時間の割合がはるかに低い
• 優れたプロジェクトは設計に費やす時間の割合がはるかに高い

プレッシャーの効果

• プレッシャーをかけても思考は速くならない
• 残業時間を増やすのは生産性を落とす方法である
• 一時的なプレッシャーや残業は人々の焦点を定めその仕事が重要であるという認識を高めるには有効な方法かもしれないが、プレッシャーをかけすぎるとかならず失敗する

いかれる管理者

• 管理者の怒りと侮辱は伝染する。上の管理者が怒鳴ると下の管理者も同様の行動をとるようになる（虐待された子供が自分の子供を虐待するようなもの）
• 管理者が部下を侮辱してだれかの業績がよくなるという証拠はあるの？
• 管理者が部下を刺激するのに侮辱を使うことは部下ではなく管理者の能力不足のしるしである

あいまいな仕様書

• 仕様書があいまいなのはシステムの利害関係者の間で対立が解決されていないしるしである
• 入出力の完全なリストのない仕様書は見込みなしである。使用を明確にする最初の一歩にもならない

対立

• 開発に複数の当事者がかかわっている限り、利害の対立は避けられない
• システムの構築と導入の事業にはとくに対立が多い
• システム開発組織のほとんどは対立解決能力に乏しい
• 対立は尊重すべきである
• 全員の勝利条件を尊重することをあらかじめ宣言しておく。あらゆるレベルで勝利条件を引き出すようにする
• 交渉は難しいが、仲裁は簡単だ
• 勝利条件が相容れないか、または部分的に相容れない場合でも関係者が対立解決のために仲裁に移行するようにあらかじめ準備しておく
• われわれは味方同士である。敵は問題そのものだ
• 触媒のような人格というものがある。そのような人はチームがまとまって結束し、なおかつ健全性と生産性を維持できるようにすることでプロジェクトに貢献する。触媒の役割は重要で貴重である
• 仲裁は触媒の役割の特殊なケースである。仲裁はわざうかな投資で学習できる
• 「あなたたちの仲裁をさせてもらえますか」というささやかな儀式の開始が対立解決の本質的な第一歩になることがある

スタッフの人数

• 初期に人数が多すぎるとプロジェクトは重要な設計作業を省略せざるをえない（全員に仕事を与えるため）。設計が完成する前に大勢に仕事を割り当てると、人や作業グループの間のインタフェースを最小化できない
• このため相互依存性が高まり、会議が増え、やり直しがふえ、フラストレーションがたまる
• 理想の人数配分はプロジェクト期間の大部分を少人数のコアチームで行い、プロジェクトの終盤（最後の６ぶんの１ぐらい）に人数を大幅に増やすというものである

プロジェクトの社会学

• 会議は重要ではない人物が出席しなくても心配のないように小さくする必要がある。欠席者が安心するための最も簡単な方法は、議事予定表を発行しそれに厳密に従うことである
• 罵倒などの怒りから人々を守るために手を打つ
• 怒りは恐怖である。部下に対して罵倒などの怒りの行動をとる管理者は、ほとんどの場合、怖いからそうしているのである（失敗するのではないか、期待に背くのではないか、などなど）
• 怒りが恐怖であることをすべての人が理解すれば、その人が怒っているのは怖がっているからだと周りの人間は理解でき、周りの人間の悩みは軽減できるだろう

病んだ政治

• 病んだ政治を下から治療することはできない。むだな努力で時間を浪費したり、自分の立場を危険にさらす必要はない
• 問題が自然に解決するか、行動するチャンスが来るのを待つしかない場合もある

倹約精神

• 倹約精神とは、失敗した企業の中でその失敗の責任者が作った公式である