ピープルウェア 第2版 の商品レビュー

トムデマルコ(著者),ティモシーリスター(著者),松原友夫(訳者),山浦恒央(訳者)

2014/03/30

初版が1987年に出ているにも関わらず、
何も変わっていないソフトウェア業界に驚いた。

内容としては、チームビルディングの重要性を説いているようである。また、仕事に取り組む上で、自身の仕事に集中可能なオフィス環境の整備についても言及されており、特に以下の文言に同感である。

"本当の意味での仕事は１人の時にできる"
"複数人数による仕事は、別の言い方をすると、次の仕事の準備、休憩、あるいは、暇つぶしなのだ"

2014/01/14

ソフトウェアでもなくハードウェアでもなく「ピープルウェア」。
古典的名著と言われている。

kindle版の第2版を買ったのだが、読み終わる前の2013年12月に第3版が出てる...
第3版では、「第3版では、時代の変化に対応し、以下の章が追加された。「リーダーシップについて話そう」、「他者とうまくやっていく」、「幼年期の終わり」、「リスクとダンスを」、「会議、ひとりごと、対話」、「E(悪い)メール」」という内容が追加されているそうだ。kindle版はまだ出ていないが、未購入ならもう少し待って第3版を買うべきだろう。

直接的にソフトウェア開発プロジェクトを管理しているわけではないが、発注元として多くのプロジェクトにかかわっているので、結構身につまされる。

「実際のところ、ソフトウェア開発上の問題の多くは、技術的というより社会学的なものである」という。よく、政治的問題が課題だと言われる。しかし、それは多くの場合は、「意思疎通の問題、要員の問題、管理者や顧客への幻滅、意欲の欠如、高い離職率」だという。つまり、これらはすべてはソフトウェア開発上の社会学の問題というべきであり、本書はそのための書籍だ。

構成は以下の通りになっている。

第I部「人材を活用する」
第II部「オフィス環境と生産性」
第III部「人材を揃える」
第IV部「生産性の高いチームを育てる」
第V部「きっとそこは楽しいところ」
第VI部「ピープルウェアの小さな続編」

第I部がメインだろう。品質についても深い洞察がある。価格と品質はトレードオフの関係にあるわけではない(日本のことを例に挙げている)、非合理かつ非現実的なスケジュールは、効率の低下を招く、プレッシャーをかけることが生産性を上げることにつながるわけではない、バグは罪ではなくバグを見つけたら褒めろ、早くやれと言うと仕事が雑になるだけ、品質目標は開発者が決めた方が品質が上がる、など。結局は、人のモティベーションが大事という話だ。第I部の最後の言葉「管理者の役割は、人を働かせることにあるのではなくて、人を働く気にさせることである」ということだ。

ソフトウェア管理における7つの錯覚、というのもありがちなので書き出しておこう。以下は全部、成り立たない。
・生産性を飛躍的に向上させる方法があるはずなのに、今までずっと見落としてきた
・他の管理者は2倍も3倍も成果を上げている。
・技術は日進月歩で、油断するとすぐ置いていかれる。
・プログラミング言語を変えれば、生産性は大幅に上がる。
・バックログが多いから、すぐにでも生産性を2倍にするひつようがある。
・何もかも自動化してしまおう。そうすれば、ソフトウェア開発者がいらなくなるのではないか?

第II部では、インタラプションによる非効率性に注目しており、集中できるオフィスの効率化にも言及している。電話による中断がどれほど生産性を落としているかを述べっているが、現在だと電子メールの方が大きな問題だろう。電子メールの方がマシだと言うことだが。とにかく、オフィスの環境はケチってはいけない、というのが著者の主張だ。

そして、チーム。「チーム編成の目的は、目標の達成ではなく、目標に向かって一体になることである」ということは覚えておいて損はない。そして、それはリーダーの仕事なのだ。「管理における究極の罪は、人の時間を浪費することだ」というのも。

第VI部は、この第2版で追加された章で、「チーム殺しの７つの秘訣」というものを整理している。あえて書くべきほどのものだと著者が判断したものだから覚えておこう。

自己防衛的な管理
官僚主義・・・ペーパーワーク
作業場所の分散
時間の分析
品質低減製品・・・短納期→低品質のものを出荷する
サバを読んだ納期
チーム解体の方針

2013/12/07

内容は読む価値ありなんだけど、
ちょっと表現が回りくどかったりした印象
管理者となった時に読み返したい本

2013/10/26

両著者は、ソフトウェア開発などのプロジェクト管理のコンサルタントである。プロジェクトを進める際に問題となる事柄、その原因、対策が、著者のコンサルティング経験に基づいて書かれている。

問題として言及している点は多岐にわたり、仕事をする環境から、一緒に仕事をする仲間とよいチームを作り上げることの重要さ、いかにプロジェクトを進めていくかなど他にもある。

管理職はどうあるべきか、どうやってプロジェクトを成功に導くか。本に書かれてあることがすべて正しいとも思わなかったが、参考にするべき点はたくさんあった。特に印象に残っているのは、

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

・人（部下なり同僚なり）を信頼すること

である。管理者でなくともこれは重要なことであると思う。仕事はふつう誰かと一緒にするものだ。その人たちをヤル気にさせ、信頼することは非常に大切で、みんなでいい仕事をするためには不可欠であると思う。

仲間といい仕事をするためにどうするか、そのやり方を考えさせてくれる本だと思う。

2013/06/30

ピープルウエア 第2版 － ヤル気こそプロジェクト成功の鍵
トム・デマルコ ティモシー・リスター著

数年ぶりに読み返してみました。
ソフトウェア開発の名著です。技術進歩が速いソフトウェア業界において、２０年以上前に第１版、第２版も１０年以上前に出版されているが、今でも読み継がれているのは、それを作る「人」に焦点を当てているからだと思います。

今では、モティベーションマネージメントという言葉が聞かれるようになってきていますが、この本に書かれていることは、モティベーションマネージメントそのものだと思います。

ソフト開発に関わるすべての方に読んで欲しいですが、特に、ソフトウェアチームの管理者、プロジェクトリーダーには、一読すると勇気づけられます。

「管理者の役割は、人を働かせることにあるのではなくて、人を働く気にさせることである。」
「知識労働者の典型的なチームがさまざまなスキルを持っていて、そのほんの一部をボスがマスターしているだけだ。」
「活動中の固く結束したチームを観察すると、仲間同士のコーチングという、ごく当たり前の健康的な行為が常に行われていることを目にするだろう」

2013/01/10

30年近く前に出た本だが、これに書いてあることを実践できている会社は少ないと思う。人類は進歩していないなぁと思わざるを得ない。

個人的なヒットは2つ。

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

・人間は秩序が大事だが、それだけでは進歩しないので、小さな混乱の建設的導入

2013/01/09

名著。

仕事してる人なら絶対読んだほうがいい！と思えるほどです。

人のヤル気はいったいどこから来るのだろ？なんて思ってる人にもオススメです。

2012/12/09

社員旅行の移動でまとめ読み。手をつけずに数年寝てた本です。

ソフトウェア(コンピュータのプログラムとか)のプロジェクトに関する本です。
といっても、大切なこととして「オフィスの環境」とか「人を集める」とか、人間に関する話がたくさん書いてあります。結構昔の本になるが、最新の本だと思って読んでも違和感がないような内容でした。

「ビジネス書は新しいものがたくさん出てくるけど、人間に関する話は数年では簡単に変わらない」という気づきがあり、読めたことに満足しました

2012/08/03

開発者が読んでもそれほど役に立たない本。「あー、うちのプロジェクト（会社）も同じだなー」ぐらいの感想しか持てない。どのみち、実践できるほど決定権を持ってないし、開発者は、美しいコードを書くための本や、設計手法の本など、自分の普段の業務に活かせる（または近い）本を読んだほうがよい。
この本は、プロジェクトや会社の方針を決定できるような立場の人が読む本。

おおざっぱに、各部の対象者を列挙してみる。
・第I部：プロジェクト管理者、部下を持つ役職者、経営層
・第II部：経営層
・第III部：部下を持つ役職者、経営層
・第IV部：プロジェクト管理者、部下を持つ役職者
・第V部：うーん、わからん。まとめみたいな感じ
・第VI部：プロジェクト管理者、部下を持つ役職者

出版されてからかれこれ25年経過しているわけだが、今でも良くない点について当てはまることが多いってことは、結局、企業は何も変わっていないんだなあと思った。ということは、これから先も企業は変わることはないのだろう。

2012/04/30

ソフトウェア開発やソフトウェアテストという仕事は、人（とチームワーク）が命です。「人」を題材としているので1987年初版（すでに20年！）のこの本は今でも色あせることはありません。

『HAYST入門』の著者の一人である仙石太郎が野中郁次郎先生の指導を受けながら進めているナレッジ・ワークプレイス改革も「活力ある個」と「ダイナミックな場」をキーコンセプトとしている点で本書の延長線上にある活動ということができると思います。