【読書感想文】ピープルウェア [第２版] - ホンモノのエンジニアになりたい

久しぶりに素晴らしい本に出会えたのでまとめます。１９８９年に初版が出版されたソフトウェア工学分野の古典ともいわれる本です。

純粋な感想文としてまとめようとも思ったのですが、素晴らしい内容が多かったので今回は概要とグサっと刺さった言葉をまとめます。純粋な感想文は気が向いたら書きます。

作者: トム・デマルコ,ティモシー・リスター,松原友夫,山浦恒央
出版社/メーカー: 日経BP社
発売日: 2001/11/26
メディア: 単行本
購入: 26人クリック: 339回
この商品を含むブログ (197件) を見る

概要

本書はタイトルの通り、「ヤル気こそプロジェクト成功の鍵」として”人”に焦点を当てて書かれています。著者はIT業界でコンサルをやっていたすごい人らしく、基本的にはIT業界の現場を対象としていますが、この本はIT業界以外の人も十分読める内容になっています。内容は人材活用、オフィス環境、人材の揃え方、生産性、仕事の楽しみ方、チーム殺しの方法（逆説的に良いチームの作り方）になっています。著者がコンサルテーションをやってきた経験や各種論文、インタビューから本質的な部分を抜き出す形でまとめられています。

グサっと刺さった言葉たち

グサっと来た文章、フレーズを抜粋してまとめます。まとめの都合上、間を省略している箇所があります。前後関係気になるよという方がいたら、それはもう買って読んでください。決して無駄な投資にはなりません。

プロジェクトが失敗した後で、その「検視」に立ち会ったとしよう。（こんなことは実際にはありえない。）

誰も失敗プロジェクトをマジマジと見たくはないですからね。ただ真剣に学ぶことを貫くなら避けては通れない道でもあります。たまにプロジェクトを振り返ってノウハウや失敗を共有する会が開かれることがあります。ただこの手の会合は大したことやってない人たちの自慢大会になったり、失敗プロジェクトの担当者を公開処刑するような、無益なものになりやすいです。

間違いを許さない雰囲気が社内にあると、担当者は消極的になり、失敗しそうなことには絶対手を出さなくなる。これに対する正反対のアプローチは大目に見ることだ。

うちの会社が正にこれですね。誰かがケツ拭いてくれる安心感がないと、失敗の可能性が高いチャレンジは出来ないです。そういう雰囲気作りをしないのに、「最近の若者はチャレンジしない」とか言っちゃいかんですよね。

プロジェクトの完成が1か月遅れても、この世が終わるわけではない。

実際その通りであることが殆どだと思います。日本のSIピラミッドでは顧客から開発者までの間で誰かがビビッて保身に走ると、「納期遅延は世界の終り」感が出て現場の人間が死ぬことになる。

熟練作業者が辞めた場合、補充にどのぐらいのコストがかかるかは誰にもわからない。

これは考えたこともなかったです。引き継ぎ等の実作業時間はもとより、辞める人が持つノウハウまでは引き継がれない事が多いため、それを埋めていく時間もかかる。その間は生産性が著しく下がるし、熟練作業者への教育投資も完全に無駄になる。

大抵の人は、自尊心を、自分の作った製品の品質と強く結びつける傾向がある。

確かに自分の作ったシステムが高品質で稼働して、その点を評価されると非常に嬉しいし仕事への満足感が生まれます。

組織の管理業務を行うには、時間はいくらあっても足りない。この傾向は会社の設立時に始まり毎年ひどくなる。成熟の頂点にある企業で働くのがあまり楽しくないのはこの理由による。

私は今の会社に入社して１０年ほどで、今まで合併を繰り返し業界でも中堅クラスの規模になりました。入社当時は皆生き生きと仕事をしていましたが、徐々に社内向けの業務が増えてきて、面白さの欠片も無いことに使う時間が増えてきたと感じていました。どこの国でも、どこの会社でも大した変わらないことなんですかね。

管理者の役割は、人を働かせることにあるのではなく、人を働く気にさせることである。

本書を読んで一番グサっと来た言葉でした。よく管理職やリーダー研修なんかで「部下のモチベーション管理」と言われたりします。モチベーション管理というと、なんかこう、そこまでやんなきゃいけないの？感があって納得できなかったんですが、働く気にさせるという言葉は何か刺さりました。

まともな仕事をするには、朝早くオフィスに来るか、夜遅くまで残っているか、あるいは会社の喧騒を避けて一日中自宅にこもるしかない。

（劣悪なオフィス環境や割り込みの仕事が入ることで）部下であるプログラマーが通常の就業時間内に仕事に打ち込めない以上、オフィスの環境改善は管理者の責任であり使命である。通常の就業時間内に仕事が出来ないなんて全く馬鹿げた話である。

あーこれ正にその通りです。設計とか計算とか頭を使う作業中に人が来たり、電話が来たりするともう最悪なんですよね。国内のIT企業で作業効率を上げるための取り組みとしてこれは大いにアリだと思います。

（採用面接の場で）応募者に過去の仕事について聞くのはよいが、見せてほしいというのはよくない、といった不文律がある。だが、要求すれば応募者はほとんど例外なく喜んでサンプルを持参する。

これは私が勤めているようなSIerではなかなか難しいですね。今の採用面接が良くないのは昔から変わっていないと聞きます。本当に技術力の高い人なら作ったものを見てもらうのが一番早いと考えると思いますが、SIerに応募するような人間は外に見せれるものなんか一つも無いのが標準仕様。秘密保持契約で持ち出し禁止になっているという面と、見せれるほどのものなんて持ってないという両面で。

複数の結束したチームに同時に身をおくことはできない。固く結束したチーム内の相互作用は排他的である。時間を分断されたらチームは結束しない。

あっちの仕事したり、こっちの仕事したりとしている人がチームメンバーに心から認められるということは確かに無い気がします。大変な時も大変じゃない時も同じ時間を過ごして、特に深夜まで皆で残ってなんとかしようと頑張る中で強い結びつきができると経験上思います。

管理者にとっての最大の成功は「管理」などないかのように、チームがなごやかに一致団結して働いているときである。最良の上司とは、管理されていることを部下に気付かせずに、そんなやり方を繰り返しやれる人である。目に見える管理は囚人相手にすればよい。

リーダーシップが必要なチームは、チームとしてうまく機能していない。最も優れたチームでは、各人が力を発揮できる分野で、時に応じてリーダーシップを発揮する。誰も恒久的なリーダーではない。恒久的なリーダーはやがて仲間として扱われなくなり、メンバーとの相互作用は崩壊する。

うまく回っているチームは言われずとも周りがフォローをしたり、先読みして事前に皆でトラブル回避に舵を傾けたりしています。安心して身を任せられ、自分に出来ることを全力で頑張るのが良いチーム。

チームはプライドをもってプロ意識の標準を自ら設定し守ろうとする。チームメンバーのすべては、仕事の質がその組織にとって重要であることを理解しているが、チーム自体は他と差別化するために更に高い目標を設定する。他と差別化する要因がなければグループはただのグループであって真のチームとはいえない。

寄せ集めの人たちが本当にチームみたく振る舞うようになる時ってどんな時だろうと考えました。本書のように高い品質を皆で目指すような共通の目的がある時に真のチームになるのだと思います。なにも品質である必要もないと思います。世の中に無い素晴らしい何かを作り出そうと一致団結したときや、非常に難しい要件を実現しようとメンバー全員で前向きに取り組んでいるときなんかもそう。

本当に有効な会議は出席者全員が一つの問題を一緒に討議する必要がある場合に開く。ミーティングの目的は、コンセンサスにたどり着くことだ。

これは本当に当たり前のことなんだけど、全然できてないなと思う所です。皆で集まっても議論せずに個々の状況報告をするような会議。報告を受ける側は効率的ですが、報告する側は自分の報告の時間以外は無駄な時間になります。この手の会議は役職の高い老害層に多いです。古いやり方を考えなしに踏襲し、権威を示したいと思っている人たちです。で、そういう人たちが「当社は生産性を上げることがホニャララで～」とか言っているわけです。って書いてたらむかついてきたのでこの辺でやめておきます。