古典的名著『ピープルウェア』から学ぶ、人間中心のチームマネジメントの真髄

ソフトウェア開発上の問題の多くは、社会学からのアプローチが必要

実際のところ、ソフトウェア開発上の問題の多くは、技術的というより社会学的なものである。

ソフトウェア開発には多くの「ヒト・モノ・カネ」が投入されますが、失敗に終わるケースが後を立ちません。著者の調査によると、25人年を投入したプロジェクトのうち25%が完成に至らなかったといいます。なぜ、ソフトウェア開発は上手くいかないことが多いのでしょうか？

一般的に、マネージャーはプロジェクトの失敗の理由を設計手法や開発技法などの「技術的」な要因であると捉えがちです。しかし、著者が失敗したプロジェクトにアンケートをとったところ、本当の問題は「技術的」なものではなく「社会学的」なものであることがわかりました。なお、社会学のここでの定義は、人間に関する領域とします。

ほとんどのマネージャーにとって、複雑極まりない「人間」に関する問題を解決することよりも、ある技術に関する問題を解決する方が簡単でしょう。そのため、失敗の原因が「人間」にあると認めることを躊躇います。

とはいえ、開発プロジェクトの「人間」に関する問題に取り組んで成果を残しているマネージャーも少なからずいます。彼らに共通することは「人間を働かせる」のではなく「働く気にさせる」ことに長けていることです。

知的労働で成果を出すには「フロー」状態になれる環境が必要

プログラマーの能力差が10倍であることは理解できるが、企業自体の生産性にも10倍の開きがある

一般的に、プログラマーの能力差に大きな開きがあるということはよく知られています。ただそれは、個人差として納得感を持ち受け入れられています。しかし、企業の生産性に顕著な差があるとしたら、それは個人差では片付けられないもっと根本的な問題がありそうです。著者は、そのような差を生んでいる要因の一つが「オフィス環境」にあるのではないかと指摘しています。

オフィスは、企業によってそれぞれ大きく異なりますが、知的労働にふさわしい環境を提供できているものはどのくらいあるでしょうか？著者は、開発や執筆などの知的労働をおこなうためには、心理学でいうところの「フロー」状態になる必要があると主張しています。

「フロー」状態とは、一つのことに没頭して集中力が高まっている状態のことです。「フロー」状態に入るためには、15分ほど精神集中をする過程が必要といわれています。この過程では、騒音や中断に非常に敏感になるため、オフィスの騒音が激しかったり、電話などによって作業を中断されると、「フロー」状態になることができません。

その中でも、電話の呼び出しが多いと問題は深刻になります。一度の通話時間が5分だとしても、一日に10回電話がかかってきたら、「フロー」状態になれない時間が200分も生まれてしまいます。これでは、生産性をあげることなどできるはずもありません。これに対処するため、本当に集中したい時は近くのカフェやレストランに行き仕事をするなどの策を講じざるを得なくなります。

オフィスの騒音をかき消すためにBGMを流すというお手軽な対応で済まそうとすることもありますが、音楽を聴きながらの作業は創造性を低下させるという研究もあり、あまりいい策ではありません。ですので、知的労働者の生産性を向上させたいのなら、彼らが仕事に集中して「フロー」状態になれるようなオフィス環境を用意することが、バックオフィスの役目となります。

チーム殺し

著者は、チーム形成を妨げ、プロジェクトを崩壊させる、確実な方策を「チーム殺し」と名付け、紹介しています。

1. 守りのマネジメント

マネージャーは、一度そのメンバーで仕事をすると決めたのであれば、部下に自主性を与えて信じることが求められます。部下を信用せず、ミスを恐れるあまりに自分がすべての仕事をチェックしていては、チームが機能不全になることは明らかです。

2. 官僚主義

頭を使わないドキュメント作成の仕事は、開発プロジェクトの仕事の中でも大きな比率を占めるようになっています。マネージャーは、部下がチームの目標に対して貢献できているという実感を与えなくはならないので、このようなつまらない仕事を部下に押し付けることは、彼らのモチベーションを低下させます。

3. 作業場所の分散

日頃密接に連絡を交わすメンバーを物理的にバラバラにしてはなりません。その場合、隣に座るのはまったく関係のない人になり、彼が発する騒音は集中の妨げにもなります。これが同じチームのメンバー同士なら、集中するタイミングも似てくるので、「フロー」状態が中断される可能性は低くなります。また、日常的に会話を交わすことで、連帯感を持たせることも可能になります。

4. 時間の分断

一人の人間が複数のプロジェクトに並行して所属することは避けなければなりません。この時間の分断は、チームの結束力を低下させます。そのため、メンバー一人が集中して取り組むことができるのは一つのことだけという原則を徹底して、チーム内の相互作用を促進する必要があります。

5. 製品の品質削減

顧客はしばしば納期が早くなるなら、品質がそれほど良くなくてもよいという判断を下します。これは一見問題が無いように思えますが、部下のヤル気を下げる要因になります。なぜなら、部下は自分が生み出すことができる品質以下の製品を提出させられることで、自尊心が傷ついてしまうからです。部下は、自分の製品の品質を高めることに誇りを持っていることを忘れてはなりません。

6. はったりの納期

はったりの納期は、最初の一回しかその意味を持ちません。当然、一度は騙されてしまった部下に再びはったりの納期を告げても、部下の生産性を上げることには繋がらないのです。これは、マネージャーに対する不信感を強めるだけです。ただし、厳しすぎる納期はモチベーション低下に繋がりますが、頑張れば達成できるかもしれない納期は生産性の向上をもたらすことがあるため、納期を告げること自体は間違いではありません。

7. チーム解体の方針

企業によっては、一度解散したチームメンバーをそれぞれ別のところに配置する決まりを設けているところもあるといいます。チームが本当に結束することは、メンバーにとって素晴らしい経験であり、たびたび訪れることでもありません。そのため、チームメンバーを別々に散らせるという方針は、意図が不明確であり反発を招きます。

チームの化学反応を促進する

著者は、チームのメンバー同士が相互に作用してプラスの化学反応を起こすためにできることを紹介しています。

1. 品質至上主義を作り出す

「品質至上主義」の文化をチームに根付かせることができれば、チームの結束は固まり大きな成果を生み出します。短期的な視点でみれば「品質至上主義」は必ずしも利益に結びつくわけではありませんが、長い目で見れば必ず割りに合う結果を生み出すでしょう。

2. 満足感を与える打ち上げをたくさん用意する

人間は誰でも自分が正しいことに進んでいることを確認して、安心感を得たいと考えています。そのため、打ち上げを頻繁におこなうことはメンバーの心に満足感を与えます。マネージャーは、チームが共に成功し、それを喜ぶ癖をつけることを手伝わなくてはなりません。具体的には、仕事を適度に細分化することで、それぞれの仕事が一区切りし易くすることができます。

3. エリート感覚を醸成する

チームがエリート意識を持つことは一見すると問題であるかのように思えますが、自分たちは他のチームとは違うというアイデンティティーを保持することで、チームに対する帰属意識を高めることができます。マネージャーは、マネジメントしにくいことを嘆くかもしれませんが、チームの生産性を高めるという観点から見ればプラスです。

4. チームに異分子を混ぜることを奨励する

ほとんどの場合において、チームには異質な人が混ざっている方が効果的です。その人がいることで、「組織の型にはまってなくてもいい」という安心感をメンバーに与えることができます。

5. 成功しているチームを守り、維持する

成功しているチームがいたら、別のプロジェクトをそのチームがそのまま担当する選択肢を提供することが重要です。そうすることで、プロジェクトはスタートに弾みをつけることができます。

6. 戦術ではなく戦略を与える

マネージャーは、チームに上からあれこれ指示をすることは避けなければいけません。これは、マネージャーが司令塔のような役割を担うべきと考えている人にとっては衝撃的ですが、マネージャーはチームの一員にはなれないのです。あくまでもマネジメントや手続きにおける障害を取り除いて、チームが快適な環境で仕事ができることをサポートすることが懸命です。

小さな混乱の建設的な再導入

「混乱」がなくなったら、もっと楽しく生きていけるのだろうか？そんなことにでもなれば、退屈で、涙が出るほどだろう

現代社会は、世の中に存在する「混乱」を凄まじい速度で「秩序」あるものに変えていっています。そして、この「混乱」を「秩序」に変えるという経験は貴重で、マネージャーだけが堪能するべきではありません。チームのメンバーにもその機会を提供することが重要です。

著者は「小さな混乱の建設的な再導入」の方法としていくつかの手法をあげています。

パイロットプロジェクト

パイロットプロジェクトは、新しくてまだ効果が実証されていない技術を試す機会です。短期的にはチームの生産性は落ちますが、長期的にみると全体の生産性は上がる傾向があります。また、新しい変わった方法への取り組みは、チームのモチベーション向上にもつながります。

プログラミングコンテスト

プログラミングコンテストは、開発者が自分のスキルのレベルを確かめたり、自社の長所や短所を客観視できる機会を提供する点において非常に効果的な取り組みです。ただし、運営側は競技を開催するには相当のコストがかかることを認識しておかなくてはなりません。

ブレーンストーミング

これは、量より質を求めて参加者にアイディアをどんどん出してもらう手法であり、一般的にもよく知られています。重要なことは、アイディアの評価は必ず後でおこなうというルールを徹底することです。これにより、面白い発想が生まれることも多くあります。