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

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

2017/08/27

2017年再読。
ヤル気こそプロジェクト成功の鍵。人的資源は交換不能、オフィス環境と生産性、割り込みなしの時間、人材を揃える。この手の本で日本のソフトウエア産業には問題があると言われ続けて、変わらないと批判され続けて。

2017/05/02

●総論●

名著と名高く、開発手法や開発組織論の様々な本からも引用されている古典です。
どんな管理をすると開発の現場がダメになるか、実例を交えて楽しく書いた本です。

●本編の感想●

帯には「ソフト開発の現場で多くの熱い共感を呼んだ名著」と謳われていましたが、
個人的には、訳者のあとがきにある「日本人ではピンとこない人も多いだろう。」という洞察のほうが、しっくり来ました。

というのも、この本では主に、開発現場をダメにする　「管理者」を、皮肉たっぷりに糾弾していて、
その「管理者」は、開発者から仕事の楽しみを奪い、自主性を奪い、残業を命じて馬車馬のように働かせる存在なのです。

でも、私たちの身の回りを見渡して、そんな暴君のような　「管理者」がどこにいるか？と聞かれると、

・・・どうでしょう？

少なくとも、私の会社でそういうタイプの「管理者」に出会ったことはありません。

一方で、私が会社で一緒に仕事をしている人が、みんな楽しく、自主性をもって、残業もせず効率よく働いているかといえば、
そういう人もいるにはいますが、少数派です。

多くの人は、（最近は働き方改革とかで残業は減ってきているものの）
何だかつまらなそうに働いているなぁーと。

それはなぜか？と考えたとき、

理由のひとつとして考えられるのは、
働く人個人個人が、「仕事とはこういうもの（本来楽しいものじゃないし、言われたことはやらなきゃいけないし、残業は仕方ないし）」という「常識」という形で、
本書で糾弾されている「管理者」の考え方を内面化してしまっているからかもしれません。

それが本当だとしたら、まずは働く人一人ひとりの心に巣食う「常識　＝　”一般的”な、現場をだめにする管理者の考え方」を変えていくところ、もっと言えば、自覚するところからのスタートなのかな、と。

そういう読み方をするためにも、本書は役に立つと思います。

●続編の感想●

個人的には、続編の方が共感する内容が多かったです。

書かれた年代が新しいこともあると思いますが、
著者の洞察もより鋭く、深みを増している感じがしました。

以下に、心に残ったポイントを書き残しておきます。

・29章。　CMMIの組織レベルを上げようとすると、組織が挑戦的な目標に向かわなくなるという矛盾が指摘されていました。
　これは、CMMIそのものの問題というよりは、CMMIという「アセスメント」を「目的化」することの問題点なのかな、という気もしましたが、
　CMMIってすごいじゃんいいじゃんうちの会社も目指していこうよ！　と思っていた自分としては、少し立ち止まって考えるきっかけになりました。

・30章。　状況に変化をもたらすときに、「古い状況」から「新しい状況」に一足とびに行くことはあり得なくて、
　必ず、「古い状況」⇒「混乱」⇒「実践と統合」というフェーズを経て、その後で「新しい状況」が来るのだ、ということが、なんだか励みになりました。
　状況を変えようと思って頑張っても、すぐにうまくいかないことが多くて、そこで嫌になって「努力したけどだめだった」　と思うのは時期尚早で、
　それはうまくいかなかったんじゃなくて、「古い状況」から「混乱」のフェーズに進んだだけなんだということ。
　そこから、いかに「実践と統合」を経て、「新しい状況」をもたらせるかが勝負なんだということを、心に留めておきたいと思いました。

・33章。　人員の早期過剰について。
　他の章とずいぶん毛色が違う話だと思いましたが、「人月の神話」のみならず、ここでもこの話が出てくるとは。
　「プロジェクトのスタートアップ時は、少数精鋭で、じっくり検討する」ということを、いつか自分が関わるプロジェクトで試してみたいし、
　その「少数精鋭」に入れる自分になっていたいと思いました。

2018/11/25

[人材を活用]
ソフトウェア開発上の問題点の多くは、技術的というよりも社会学的なものである。

早くヤレとせかせれば、雑な仕事をするだけで、質の高い仕事はしない

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

品質はタダである。但し、品質に対して喜んで金を出す人だけに対して

組織の管理業務を行うには、時間はいくらあっても足りない

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

[オフィスの環境と生産性]
誰とチームを組んでいるかで、生産性は変わる

能率の良い仕事をするには、広くて静かな場所が必要

本当の意味での仕事は、一人の時に出来る

[人材を揃える]
ずっと勤め続けることが期待されているという感覚を、会社側は従業員に持たせることが大事

生涯教育プログラムの充実

[生産性の高いチームを育てる]
チーム編成の目的は、目標の達成ではなく、目標に向かって一体になることである

結束の強いチームの特徴
・退職率の低さ
・強固なアイデンティティ感覚
・選ばれし者としての感覚
・生産物共有意識
・明らかな楽しさ

チーム殺し
・自己防衛的な管理
・官僚主義
・作業場所の分散
・品質低減製品
・さばを読んだ納期
・チーム解体の方針

チーム形成の不思議な作用
・品質至上主義を作り出す
・満足感を与える打ち上げをたくさん用意する
・エリート感覚を醸成する
・チームに異分子を混ぜることを奨励する
・成功チームを解散させないで保護する
・戦術ではなく戦略を与える

[きっとそこは楽しいところ]
進歩こそ重要
・試行プロジェクト
・プログラミングコンテスト
・ブレーンストーミング
・実戦さながらの訓練
・教育、旅行、学会、お祭り、そして冒険体験

[ピープルウエアの小さな続編]
続、チーム殺し
・動機づけのためのアクセサリー
・大量の残業

続続、チーム殺し
・年次の給与または功績の見直し
・目標管理
・大きな功績を成し遂げた表彰、賞、ボーナス
・あらゆる形態の成果の評価

変化のチーム内競争は何も良いことを生まない
スポーツの例ではなく、音楽のアンサンブルのイメージが良いチーム

変化への基本的な反応は、論理的なものでなく情緒的なものである

古い方法を決してけなしてはいけない、むしろ古い方法を変化を助ける方法として讃える必要がある

2017/04/14

プログラマが成果を出すために、精神はどうあるべきか。
その精神を保つためにはどういった環境がベストなのか、が書いてある。
実験した内容や数値が書いてあるため、説得力が高く自分のモチベーションを維持するために
どういうコミュニケーションが必要なのか改めて考えさせられました。
内容が濃く、全部飲み込むのに時間がかかりましたので、再読したい一冊となります。

2016/06/26

プログラマを、どうマネジメントするべきかという古典。電話やキュービクルの話など、多少時代を感じさせる部分もあるが、基本は人間のことなので、古典といってもあまり変わらない。ただ、先日、社内の別の開発部門と話をしたときに、ソフトウエアは一人でないと開発できない、複数人での開発などありえない、とチーム開発を全否定されたときには、びっくりした。この人たちはどの世界線を生きているのだろう？？

2016/02/28

IT業界では有名な本。だと思う。

プロジェクトは、技術的な問題と社会学的なものがあると認識することを掲げており、ホーソン効果を取り上げて、プロジェクトが成功する秘訣は、働く環境というよりもやる気・意欲であると説いている。

そして、やる気を出させるためには、こういうことが必要だよって。
例えば、プロジェクトチームを結束させる人。こういう人がいれば、プロジェクトは成功に近づく。確かに、チームを盛り上げる人がいるのといないのでは、猪突猛進かお葬式かの違いがある。こういう人って2人分の価値があるとも言っている。
ほかにも管理者の役割に言及しており、部下を働く気にさせることが仕事と説いているし、また、生産性を向上させるには、フロー状態をいかに作るかがポイントと言っている。（ちなみに、フローに至るには15分以上の集中過程が必要。うーん、電話とかで作業を中断されると集中力切れるもんな）さらに、利益を目標にすると、やる気を失うよって。
あとは、目標なしの方が生産性が最も高いんだって。これだと、人は与えれた時間を消費するまで時間を使い切るというパーキンソンの法則には疑問が残るよねって。たしかに、インバスケット方式のほうが生産性が高い気がする。

最後に知ってよかったのは、「健全で誰もが満足するコミュニティつくりに関する学問」は政治学なんだって。
政治学勉強しよかな。

2015/05/26

実際のところ、ソフトウェア開発上の問題の多くは、技術的というより社会学的なものである。管理者の役割は、人を働かせることではなくて、人を働く気にさせることである。従業員をヤル気を起こして仕事をさせるには、まず、ヤル気を失わせる原因を理解することが重要である。
ヤル気を失わせる原因の最たるものが、オフィス環境である。オフィスには、電話、電話、電話、割り込みといった、集中力を途切れさせるものが多く、一度集中力が途切れると、元に戻るまでに時間がかかり、生産性を悪化させている。よいオフィス環境を整えることを、まず初めに実施する。
次に、人材という点では、①人材を揃える、②満足感を与え辞めないようにする、③束縛から解放する、といったことが重要であり、環境を整えることにより、満足度が高く、すぐには辞めない人材を揃えていく。
オフィス環境が整い、人材が揃ったら、生産性の高いチームに育て上げ、楽しく仕事ができるようにしていく、というように段階を踏んでいく。

2015/02/11

2015/02/11 22:12

デッドラインのような小説風ではなく、普通の解説書だった。

後半の第3部からが本番かなと感じた。

チームのメンバーの状況などどうしても知りたくなってしまうので、ついマイクロマネジメントっぽくなってしまうのだけど、今後はやめるようにしようと思う。
それから、チームのメタファとしてスポーツを用いるのは良くないという点も参考にしたい。

改善活動についても色々と参考になった。

一度読んだだけでは、消化しきれてないと思うし、第3版が出ているので、改めて読んでみたい。

2014/08/13

ソフトウェア開発における問題は技術的なものではなく常に人的なものである、との視点から、プロジェクトマネジメントで往々にして見られる問題点を指摘し、適宜その解決策を提案する本。

この手の本は往々にして、当たり前の抽象的訓示を、何か意義深いことを述べている体を取り繕うだけの勿体ぶった文体で、延々語るだけである。

然るに本書は、初版が87年発行であるにも関わらず、現在においても大いに共感を持って受け止められるであろう諸問題と、これらに対する新規性に富む提言を、古くはあるものの説得力を持つ数値と合わせて、多く掲載している。

例えば、計画において見積もりの正確性がシステムアナリスト>プログラマ>管理者、となることが、実験によって得られた数値によって示される。これは、当該作業に責任を持つ者に見積もらせると、自身の能力をアピールしなければならないプレッシャーや見栄のために、楽天的な計画を立ててしまうことを示唆している。ここから示される見積もり精度向上策は、作業の実施責任を負っていない者に見積もりを立てさせることであるが、これは一般の慣行に反するものである。

また例えば、チームに所属しているメンバーが、自分たちは特別な存在であるとして、一種の排他性や傲慢さを持つことは一般には忌避されるが、これはそのチームが構成要員の承認欲求を満たしていることの裏返しである。すなわち、彼らがハッスルするための必要条件であり、これをマネージャーが正しい方向で発散させれば大きな力になることが示される。

以上のような、示唆に富む問題提起や解決策がふんだんに散りばめられた本書は、あらゆる分野の管理職にとって、自身の在り方を再考する上で、非常に有益。☆４つ。

2014/05/15

20140515
翻訳が読みにくかったけど、いくつかの気付きがあった。
割り込みの影響が、いかに無駄な時間を産んでいるか。フロー状態に達するまで15分、１時間に４回中断されたらまるまる無駄になる計算。
デスクの配置も、広い大部屋で騒音を受けるのではなく、数名で一部屋が良い。また、机も個々に配置することで快適な環境になるらしい。日本の一般的な会社では程遠い。
プロジェクトの半分は少数精鋭で設計し、残り半分は人数をかけてコーディングする。