「ピープルウエア」を読んだ
間違いを許さない雰囲気が社内にあると、担当者は守りに入り、失敗しそうなことには絶対に手を出さなくなる。部下が誤った判断をするのが心配で、開発手順をシステム化したり、厳格なメソドロジーを無理強いして、設計上の重大な決定をさせないと、部下はますます消極的になる。
・もっと長い時間働くようにプレッシャーをかける。
・製品開発を機械的なプロセスにする。
・製品の品質について妥協する（第４章で詳しく述べる）。
・手順を標準化する。
こうした方法は、仕事を面白味のない、やり甲斐のないものにする恐れがある。その結果、生産性を上げると退職率も上がる危険がある。このことは、退職という犠牲を払わないと、生産性を改善できないと言っているのではない。ただ、高い生産性を達成するには、退職も考えておく必要があるというだけである。さもなければ、「生産性の向上」を達成できても、キーマンの退職という取り返しのつかない痛手を受ける。
ミスを減らすため、誰でも作業ができるよう、再現性を上げるためなどの理由で手順をシステムス化することはあるがあらゆることを型にはめるのではなく個人の創造力に任せることも必要だ。
時間の細分化はチーム形成には良くないし、効率の妨げにもなる（読者にも思い当たることがあるだろう）。人が覚えていられる他人とのやり取りの流れには限りがある。４つの作業グループの仕事をしようとすれば、４倍の流れを頭の中でたどらなければならず、別の相手に調子を合わせるだけで時間が過ぎてしまう。
掛け持ちでプロジェクトを進めることがあるので、今後もそのような働き方をするならば（あまりしたくないが）このようなコストがかかることは覚えておきたい。
品質削減が最初に破壊するのは、長い間培ってきたチームの一体感だ。まやかしの製品を開発している開発者同士は、互いに視線を避けるようになる。共同で製品を完成させるという意識はないのだ。自分たちがやっていることをやめられるなら、救われた気持ちになると、全員が感じているのである。プロジェクトの終わりには、グループのメンバーと別れ、もっとよい仕事につくために全力を傾けるのだ。
チームとして炎上案件や納期重視のチームに参加したときに、いままでチームが培ったプロダクトの品質水準が狂う。そして、そのプロジェクトに長く携わることで、プライドを持って作ってきたものに対して興味が薄れる。
会社にも、仕事を区切る打ち上げという拍子木の音が必要である。会社にとっての打ち上げとは、仕事が成功裏に終わることであり、加えて、完成への過程でときどきすべてが目標通りであることを確認することだ（マイルストーンを達成したとか、重要な分納をきちんとしたことなど）。会社にどれほどの確認が必要かは、どれだけの金額がリスクにさらされるかにかかっている。企業の必要性から考えると、打ち上げは、４年間にわたる努力の末にやってくるので十分ということもある。問題は、働いている人たちが思っているほどには、会社は打ち上げが必要と考えていないことである。満足感を与える「拍子木の音」を４年間も全く鳴らさない仕事では、グループの人間が「この仕事が終わるまえに、オレは死んでしまうのではないか」と思って、次々と辞めていく。特にチームが一体となりかかったときには、頻繁な打ち上げが必要である。チームのメンバーたちには、共に成功し、それを喜ぶ癖をつけることが必要だ。これは、チームの勢いにはずみをつけるメカニズムの一つである。
チームで何かを達成した時はお互いがお互いを褒め合いたい。
意味のある会議の出席者は、利害関係者だけに限るべきであり、少なければ少ないほどよい。儀式的な会議の出席者は、まったく制限されない。主催者が出てほしいと思う人が出席すればよい。多ければ多いほど盛り上がる。会議の主催者の重要性が出席者の規模に反映するので、自然と大規模にしようという気持ちが働く。「オープンな組織」という空想は事態を悪化させる。
意思決定のためにたくさんの参加者が必要なMTGを設定することは、そもそもうまく権限委譲できていないできていないことの現れでもある。
まともなコーチなら、自分の仕事は、選手同士のやり取りを調整することではなく、選手が自分で調整することを学ぶように仕向けることだということがわかっているはずだ。
自ら調整するのではなく、個人自身で調整できるようにサポートすることが大切。
