ホンモノのエンジニアになりたい

ITやビジネス、テクノロジーの話を中心とした雑記ブログです。

【読書感想文】ピープルウェア [第2版]

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

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

純粋な感想文は気が向いたら書きます。

 

ピープルウエア 第2版 ? ヤル気こそプロジェクト成功の鍵

ピープルウエア 第2版 ? ヤル気こそプロジェクト成功の鍵

 

 

概要

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

 

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

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

 

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

読んでみて確かに検視には立ち会ったことがないと気づきました。誰も失敗プロジェクトをマジマジと見たくはないですからね。ただ真剣に学ぶことを貫くなら避けては通れない道でもあります。私は通ったことはありませんが(笑

 

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

うちの会社が正にこれですね。大目に見るとか、誰かがケツ拭いてくれるという安心感がないと失敗の可能性が高いチャレンジは出来ないです。

 

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

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

 

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

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

 

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

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

 

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

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

 

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

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

 

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

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

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

 

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

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

 

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

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

 

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

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

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

 

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

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

 

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

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

 

終わりに

素晴らしい本だった。うまくまとめられないので書いていませんが、人の事やチームの事以外に、オフィス環境をまとめている章もあって、少し冗長に感じる部分はありますが、現代の環境に照らしても十分過ぎるレベルで通用する内容でした。

また読んでいる中で、この分野(人とかチームとか環境とか)は本当に成長していないんだなぁってことが見て取れました。30年前の本なのに古さを感じないんですからね。

私はこの本が何かの媒体で紹介されているのを見ていて、たまたま古本屋で見つけたので購入して読んでみました。ただこんなに良い本なのに社会人になって10年の間で人から聞いたことは一度もありませんでした。それも毎日SEと仕事をしているのにも関わらずです。色々と残念です。

Amazonやネットでの評価も高いですし、このエントリを見てくれた方にはぜひ読んでほしいなと思いました。

 

おわり。