ピープルウエア雑感

新しい会社が本格始動する前にこの本を読んでおいて本当に良かった。

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

最近時間に余裕ができたので色んな本を読んでたんだけど本書を読んでおいて本当に良かったと思う。

管理とは何かから始まってオフィスの改善や生産性についての話など、「人材」に纏わるデマルコ氏なりの考察を知ることができて良かった。

まずは冒頭の一文。この一文にピープルウエアの全てが表されているといっても過言ではない（大げさ過ぎか^^;）

管理者の大部分は、人を交換可能な部分と扱う特有の失敗をしがちだ

本書を読み進めれば読み進めるほど前職のことを思い出す。
ピープルウエアにおける駄目なケースにぴったし当てはまってしまってなんだか憂鬱な気分になる。

各章のタイトルは以下の通り

• 一章　人材を活用する。
• 二章　オフィス環境と生産性
• 三章　人材を揃える
• 四章　生産性の高いチームを育てる
• 五章　きっとそこは楽しいところ
• 六章　ピープルウエアの小さな続編（第2版で追加）

僕自身本書を読んでいてギクっとするお話がいくつも出てきた。
たとえば、

間違いを許さない雰囲気が社内にあると、担当者は消極的になり、失敗しそうなことには絶対に手を出さなくなる。部下が誤った判断をするのが心配で、開発手順をシステム化したり、厳格な作業規定を無理強いして、設計上の重大な決定をさせないと、部下はますます消極的になる。

僕は品質管理部として厳格なソースレビューや過度なテスト手順などを行ってきた。
「間違いを許さない雰囲気」を作り出していたとは思わないけど結果としては皆がそう感じていたのかもしれない。
現にこの一文にある通り、開発手順もシステム化したし、厳格な作業手順も作ったし、設計上の重大な決定をさせていなかったように思う。
いや、決して意図的にそうしてたわけじゃないけど、結果としてそうなってしまっていたんだろうな。そうだとすると本当に申し訳ない気持ちになる。

残業に関してもいつくかの見解があって、

残業は全力疾走だ。残りのエネルギーを振り絞り、マラソンのゴール前数百メートルを全力疾走するのは、それなりに意味がある。しかし、最初の1キロメートルでこれをやれば、単に時間を無駄にするだけだ。

たくさん残業をさせるのは生産性を下げるやり方だ。ほどんどの場合、余計に働いた時間よりも、マイナスの副作用で消える時間の方が多い。

人は、期限通りに仕事をするために多くの残業をするのではなく、仕事が期限通りできそうもないことがわかったときに、非難から身を守るためにそれをやるのだそうだ。

まさにこの通りだと思った。
残業に関しては「やる時間を増やせば、成果も増えるに決まってる」という会社の方針があったのでどうにもならなかった。
でも実際は成果が増えるどころか減っていく一方で、そうなると会社としては「時間を増やしてるのに成果が増えないのは個人の能力が低いから」という結論に至ってしまい、
そうすると今度は社員は成果を上げるために、

犠牲にできる唯一のものは品質である。そこで、極端な時間のプレッシャーをかけ続けると、部下は品質を犠牲にしはじめる。（中略）好んでやっているのではないが、他に選択肢がないのだ。

という最悪な結果になってしまう。
この「好んでやっているのではないが、他に選択肢がないのだ。」という部分には涙が出るよね。
で、そうしてあげた成果を人月に合わせて計算するので、

実際には80時間、90時間働かせて仕上げた成果を、40時間で割り、1時間あたりの生産性とする。 これを生産性と呼ぶのは詐欺に等しい

こういう結果になってしまう。

本来、生産性とは、1時間当たり、どれだけ多く作れるか、ということであるべきなのに、現実には、1時間あたりの賃金から、どれだけ多くを絞り取れるか、という意味にゆがめられることが多い。

会社がそういう考えで行動していたとは思いたくはないけど、ずっとそういう状況に置かれるとそう思ってしまいたくなる。怖い。

開発者でなく、買手に品質基準を決めさせることを「品質第一主義からの逃避」と呼ぶ。顧客の要求通りの品質を提供するのは、開発者の反発と作業効率への影響を無視すれば、一見もっともらしく思える。 しかし、長い目では、市場ベースの低い品質要求は、余計なコストがかかる。そこで次の教訓が得られる。

これは前職でも同じようなことがあった。
品質を維持しようと思ったらそれなりに人月がかかる。でも顧客は多少品質はいいから早く作ってくれという。
じゃあ顧客にあわせて品質を落として開発しようという流れがあった。
僕はわざと品質を落としてまで早く作るというのが、なんだか自分自身のプログラムに対する冒涜のように感じられ、モチベーションがだだ下がりしそうだから嫌だったんで反対した。
でも結局は安い外注に仕事を回して低品質のコンテンツを素早く開発するという結果になっちゃったけども。
そしてデマルコ氏の教訓、

エンドユーザーの要求をはるかに超えた品質水準は、生産性を上げる一つの手段である。

本当にそうなるかは今の僕にはわからないけどこの一文は心に留めておこう。

次にオフィス環境についての話が色々とあってこれもなかなか頷くところがあった。

こうした雑用が上の人間にだけ影響し、プログラマーは何も気にせず仕事に打ち込めるのなら、それほど大した問題ではない。しかし、実際はその逆なので、事態は極めて深刻である。プログラマーは、毎日会社でのイライラと毎度毎度の割り込みで、精神、肉体ともに疲労状態にある。丸一日が何の意味もなく過ぎていき、一体どこまで作業が終わったのか誰にもわからない。

割り込みの後、以前の状態に頭を戻す作業が何度も続くと、プログラマーは、イライラがたまる。マネージャーがこの問題を認識することは、まずない。この状態のエンジニアは、全部自分が悪いと思い込んでしまうためだ。

前職は、無駄な会議、電話、内線、メールなど割り込みのオンパレードでまともに仕事のできる環境ではなかった。
僕自身はなるべくそういう割り込みに巻き込まれないようにうまくやりくりしていたんだけど、他の人は割り込みだらけで見ていてかわいそうだった。

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

うひ！これは僕もよくやりました。やっぱり昼間は割り込みだらけで仕事にならない。
朝とか夜は本当に気持ちよくプログラムできる。

さばを読んだ納期に関しても思うところがあった。

さば読み納期は絶対であると考えるかぎり仕事に対する意欲は間違いなくなえてしまう。はじめる前から、仕事は決して成功しないと決まったようなものだ。プログラマーへのメッセージは明白だ。管理者はパーキンソン流のロボットであり、部下の気持ちを尊重したり、一人ひとりのことを考えてやる気はないのだ。管理者は、脅迫しないと部下は、何一つ仕事をしないと信じているのだ。

これは凄く耳が痛かった。
決して「管理者は、脅迫しないと部下は、何一つ仕事をしないと信じているのだ」などとは思っていない。
でも部下からすると結局は同じことなんだろうな。

本書に関してまだまだいいたいことはあるけど長くなりすぎなんでこの辺で終わりにします。

会社が本格始動する前に本書を読んでおいて良かったといいましたが、本当はもっと早くに読んでおけば良かったという気持ちも少しあったりします。
前の会社の時に本書を読んでいればもう少し違った未来があったかもしれません。

もし前の会社の同僚でココを見てる人がいたら是非本書を読んでみてください。とってもオススメです。そして会社を変えるために何か行動してみてもいいんじゃないでしょうか。（僕にはできなかったけども・・・）

僕は僕で新しい会社のために本書のノウハウを多いに参考にします。

あ、そうそう。デマルコ氏の著書で「デッドライン」というのもあります。

スゴ本の中の人曰く、こっちもかなりの良書らしいので僕も今度読んでみようかなと思ってます。