トム・デマルコ／ティモシー・リスター『ピープルウェア』日経ＢＰ、2001年11月
- 作者: トム・デマルコ,ティモシー・リスター,松原友夫,山浦恒央
- 出版社/メーカー: 日経BP社
- 発売日: 2001/11/26
- メディア: 単行本
- 購入: 26人 クリック: 339回
- この商品を含むブログ (197件) を見る
- 現在、仕事でソフトウェアの開発プロジェクトを抱えており、手戻りなく開発を行うための手法を知りたい
- 以前読んだことがある本だが、改めて内容を確認したい
○第一部「人材を活用する」
- 大きなプロジェクトほど失敗（中止、延期、使われない）する確率が高い。これら失敗したプロジェクトを調査したところ、その圧倒的多数の失敗原因は、技術的問題以外の部分にあることが分かった。この本では、トラブルの原因の多くを占めている「人に関する問題」をテーマとしたものである。
- 管理者のほとんどは、そのプロジェクトに関する技術面より「人」に気を配っていると思いこんでいるが、実際には技術者が解決すべき難問を自分で解こうとしている、つまり技術面に傾注していることが多い。作業を管理するのでなく、作業そのものをやっているのだ。
- 管理者は、会社に入ってから「どのように仕事を行うか」は教えられたが、「どのように仕事を管理すべきか」は教えられていない。なぜ管理者が技術的問題に時間を割こうとするのかというと、それはその方が「自分にとって解決しやすい」問題だからに過ぎない。
- ソフトウェアの開発作業は、工場におけるチーズバーガーの生産（流れ作業による大量生産）とは性質が異なる。エラーの極小化、エラーへの厳罰、スムーズな流れ、人間の取り替え、マニュアル化、など大量生産の現場で行われ、効果をあげているこうした手法をソフトウェア開発現場で適用することは逆の効果をもたらす。
- 頭脳労働者が時々ミスを犯すのは極めて自然なことであり、ある面では真面目に取り組んでいる証拠でもある。しかし、ミスすることを聖書でいう「罪」と同じように考えている人がいる。
- 根本的欠陥を有する設計は、細かな手直しをして使おうとするよりも、思い切りよく捨てて一から作り直した方が結局はうまくいく。
- 管理には、スペイン流の管理（資源の量は決まっており、どこから奪ってくるかの問題だとするもの）とイギリス流の管理（技術進歩により、パイ自体を大きくしようとするもの）がある。ソフトウェアの管理者の態度としては後者が望ましいが、スペイン流の管理（際限ない残業＝タダ働きで解決しようとする）をしている者が多い。実行不可能な納期を押し付けるほど多くの労力を引き出せると考えているのである。
- 納期を短くすればするほど犠牲になるのは品質である。品質とコストは比例関係にあるとよく言われるが、一般に製品の質が高い日本では、品質を高めることでコストを低減させるという考え方が広く受け入れられている。また、ヒューレット・パッカード社は、市場が要求する以上の品質を供給するということで有名である。同社は、仕事への満足度も高く、離職率は低い。また、日立ソフトウェアエンジニアリングと富士通では、十分な品質基準に達していないと考えられた製品の出荷を拒否する権限がプロジェクトチームに与えられている。
- パーキンソンの法則「与えられた仕事をするのに時間はいくらあっても余ることがない」ということを信じ、仕事を支配する唯一の真理と考えている管理者は多い。しかし、パーキンソンの法則は公理というより皮肉なのであって、この言葉から、技術者に徹底的に仕事をさせること自体おかしいことである。
- 「シャロンは、優れた管理者の本質をよく知り抜いていた。つまり、管理者の役割は、人を働かせることにあるのではなくて、人を働く気にさせることである。」（41ページ）
- 従業員のやる気を失わせる原因としてもっとも大きいのはオフィス環境（空間、備品、その他もろもろ）である。
- プログラマーは論理的に物事を考える知的な作業者である。しかし、さまざまな騒音・雑音がその作業を妨げていることが多い。
- 単独で作業をする場合、プログラマーは心理学者（チクセントミハイ）のいうフロー状態になっていることが理想だ。スイッチを入れたり切ったりする状態ではフロー状態にならない。
- 電話に対しては厳しい態度で臨む必要がある。電子メールを効果的に活用すべきだろう。
- 音楽を効果的に使うことで騒音をかき消すという方法もある。音楽を聴く部分と思考する部分は異なるため、作業の能率に悪影響を与えることはない。
- なぜ人は会社を辞めるのか。それには以下の理由が考えられる。
- １．腰かけメンタリティー：この仕事を長く続けようという雰囲気を同僚が醸し出さない。
- ２：使い捨てにされる予感：管理者が従業員を交換できる部品くらいにしか考えていない。
- ３．会社への忠誠なんて馬鹿馬鹿しいという意識
- 会社の移転はもっともらしい理由を付けて行われるが、とりわけ共働きの女性の家族に与える影響を考えると愚かな行為であり、貴重な人材の流出を招いてしまう。
- 自分がこれまで携わった仕事の中で、特に楽しかった経験を思い起こしてほしい。すぐに思いつくのは「挑戦」がそこにあったということであろう。
- チームは結束することではじめて成功する。そして結束したチームは「目標」を共有化しているのが特徴である。しかし、目標の共有化は自然にできることではない。
- 結束したチームの特徴としては、
- １．アイデンティティ感覚
- ２．選ばれたものとしての意識
- ３．生産物共有意識
- があり、明らかな楽しさがある。
- 混乱が生じたとき、管理者はそれを取り除くことに気を配る。しかし、混乱を小さな包みに入れて部下に渡すのも一つの方法である。
- 小さな混乱の導入としてプログラミングコンテスト、研修・旅行などが考えられるが、ちょっとしたブレーンストーミングも効果的である。
- コーチングは重要な要素であり、チーム内が相互にうまくいくことにつながる。
- チームを殺すことにつながりかねない要素として以下のものがある。
- １．年次の給与または功績の見直し
- ２．目標管理
- ３．特定の従業員の表彰
- ４．功績と結びついた表彰、賞、ボーナス
- ５．あらゆる形態の成果の評価
- 組織が学習するためにはたんに経験を積み重ねるだけでは不十分である。企業の姿勢が経験から学ぶ姿勢に変化したとき、はじめて経験は学習となる。そして、組織の学習能力は、組織がどの程度人を引きとめられるかで決まる。
以前、「知るを楽しむ」というＮＨＫの番組で、楽天の野村監督が、ヤクルトでは成功し、阪神で失敗した原因について、阪神という球団の特殊性に加え、自らのＩＤ野球を、プリントの配布で伝えようとした＝手抜きだったと言っていたことを思い出す。ヤクルトではホワイトボードを使い、選手にも考えさせながら取り組んでいた。伝えるという行為は丁寧さがないとうまく行かないという好例かと思われる。目標の共有化に関しても同じだろうと思われる。
本書は、主としてシステム開発担当者の業務能率に与える、オフィス環境やチームワーク等の社会学的要因を、著者の経験をふまえて分析した書である。とくに「生産的な仕事」はどうすればできるのかという視点を中心においてポイントを２点抽出してみた。
○ 読んだポイント１
―オフィスの作業環境が“仕事そのもの”に与える影響―
「プログラミングコンテストの結果、生産性、作業速度ともに優れた上位４分の１グループの作業環境は、下位４分の１とは根本的に異なることが分かった。上位グループのオフィスは静かで、個人の空間、プライバシーが保護され、無駄な割り込みもなく、その他あらゆる点で下位グループよりも恵まれていた。・・・（中略）部下であるプログラマーが通常の就業時間内に仕事に打ち込めない以上、オフィスの環境改善は管理者の責任であり、使命である。「プログラムは夜作られる」という文を睨みつけて、じっと考え込んでいても話は進まない。・・・（中略）通常の就業時間内に仕事ができないなんて、全く馬鹿げた話である。もうそろそろ、このことを真面目に考えてもよいころだ。」（p.61〜62）
〔コメント〕
よくある話なのが、いつもはそれほど仕事が進まないのに、たまに休日出勤し、静かな環境で取り組むと俄然進んだりすることがあること。例の「ホーソン実験」における作業では環境は重視すべき項目とはなっていなかったが、考えをまとめ、形にするというプロセスは、ここでいっている望ましいオフィス環境を必要とするのだろうと思われた。それは以下の部分でも論述されている。
○ 読んだポイント２
―生産的な仕事をするためには―
「単独で作業をする場合、プログラマーは心理学者のいうフロー状態になっていることが理想だ。これは、一つのことに没頭し、ほとんど瞑想状態になることである。・・・（中略）製造業での設計、開発、書類作成等では、必要不可欠であり、「調子に乗る」ことが非常に大切である。フロー状態になってはじめて仕事がうまく運ぶ。・・・（中略）騒々しいオフィスではフロー状態になることは、不可能に近い。」（p.79〜80）
〔コメント〕
最近、茂木健三郎氏の脳の機能をめぐる著作でも、例えばモーツァルトの作曲活動に見られるような人間の創造的・生産的な活動は、一種のフロー状態から生み出されることが論じられている。自分を取り巻く環境では、「人を詰め込む場でなく、生産的な活動を行うための場としてのオフィス」という考え方がどれだけ今まであったのだろうと思わざるを得ない。具体的には、企画業務を中心におく職場、システム開発業務を中心におく職場など、創造的な活動を行うための職場のレイアウトは本来違っていて然るべきではないかと思われる。
