納期もコストも品質も全部守れと言われて、残業代なしの状態で深夜まで働かせる。
その結果、プロジェクトからどんどん人が離脱する。
いったいなぜ、こんなことが起こるのだろうか？
・・・この疑問に1987年に答えてくれた本があったようです。
今更ながら気づいた名著『ピープルウエア』です。
『ピープルウエア』とは？
本書はソフトウェア開発の現場で共感を生みまくった名著中の名著です。
本書が名著たらしめている点は何か？
それは、ソフトウェア開発を難しくする要因が「技術的なもの」ではなく「社会学的なもの」だと特定した点。
エンジニアの技術力ではなく、1人ひとりの尊重・オフィス環境づくり・チームの結束力などが、プロジェクトを左右する主要因だそうです。
本書は、主に以下の6つの視点で、ソフトウェア開発のポイントを語っています。
- 一人一人の人格の尊重
- 頭を使う人間にふさわしいオフィス
- 人材の選び方・育て方
- 結束したチームがもたらす効果
- 仕事は楽しくあるべきもの
- 仕事を生み出す組織づくり
中でも「チームがもたらす効果」の話を読み、目から鱗が落ちました。
チームを殺す7つの方法
まず学びが深かったのが「チームを殺す7つの方法」について。
本書では、チームを崩壊させてしまう方法として、以下の7つが紹介されていました。
- 守りのマネジメント
「部下を信頼しないこと」「マネジャーによる技術的な干渉」は守りのマネジメント - 官僚主義
頭を使わない機械的なペーパーワークは、官僚主義を促進する。この作業を任された部下は、自分が信頼されていないと思ってしまう - 作業場所の分散
作業場所を分散させると、日常会話がなくなり、チームの文化がいつまで経っても形成されない - 時間の細分化
4つの作業グループの仕事をしようとすれば、4倍の流れを頭の中でたどらねばならない。頭のスイッチを切り替えるたびに、労力が奪われる - 製品の品質削減
「安くて早く納品する代わりに、品質を下げること」に合意すると、開発者の自負や喜びが傷つけられる - はったりの納期
「はったりの納期＝わざと厳しくて不可能な納期」を繰り設定すると、部下は設定された納期を疑うようになる - チーム解体の方針
プロジェクト解散と共にチームを解体してしまうと、せっかく形成されたチームの結束がリセットされる
この7つの共通点は、いずれも「マネジャーが無意識のうちにやってしまっている点」。
誰も「部下を信頼したくない。ぎちぎちに管理したい」なんて思って、マネジメントの向き合っているわけではない。
しかし、「部下が失敗して、自分が責められたらどうしよう」「クライアントから急げ！安くしろ！と言われたから、しょうがない」という思いから、上記のような7つの行動をとってしまう。
誰も「チームをぶっ〇ろしてやろう」と思ってやってるわけではないわけです。
では、どうすればよいのか？
チームの化学反応を促す6つのポイント
そこで本書は、チームの化学反応を起こす6つのポイントを教えてくれます。
自分の理解のために、私なりの言葉で書くと・・・
- 品質至上主義
「完全な製品だけを求める」態度を取れば、チームが一つにまとまりやすい - 満足感を与える打ち上げ
仕事をいくつかのマイルストーンに分ける
マイルストーンの達成ごとに打ち上げし、次のステップに向かうエネルギーを与える - エリート感覚の醸成
「自分たちは他チームとは違う」と思ってもらえると帰属意識が高まる - チームに異分子を混ぜることの奨励
異質な人を混ぜると「自分も組織の型にハマる必要はないんだ」と安心できる - 成功しているチームの保護・維持
結束できているチームを、簡単に解散させてはいけない。新たなプロジェクトが始まっても、今のチームのままで担う選択肢を持っておくと、スタートダッシュしやすい - 戦術ではなく戦略の提供
目的は提示するが、手段はメンバーに一任
→各メンバーが、自分が力を発揮できる分野で自発的にリーダーシップをとってくれる
いずれも納得感しかありません。
例えば「品質至上主義」について。
ここ数年は社内のデータ見える化をリードする立場にいますが、「品質を犠牲に、納期を優先する」ことは絶対に避けています。
「いやいや、社内のIT活用だからでしょ」と言われそうですが、このスタンスはコンサル時代でクライアントワークをしていたころから一貫させています。
短期的に品質を捨てて納期やコストを優先したとしても、
・システムの使い勝手が悪く、業務が思ったより減らない
・バグが多発し、修正に時間を取られる
とかで、結局、中長期的に見れば、品質を犠牲にしたせいで納期とコストが余計にかかってしまう。
だから、よっぽどのことがない限り、品質を無駄にしてはいけません。
ただ、私も1回だけ品質を犠牲にしたことがあります。
AシステムからBシステムに乗り換えるプロジェクトに参画したときなんですが。
20XX年12月31日までにBシステムに完全に切り替えないと、Aシステムのライセンス料が2億円かかってしまう。
・・・こんなシチュエーションでした。
このプロジェクトのときは、とにかく納期がマスト要件でした。
もともと半年で行うはずだったプロジェクトが、諸々の事情で3ヶ月着手が遅れてしまい。
そのタイミングで私がプロジェクトにアサインされました。
「あと3ヶ月でシステムを切り替え終わらないと、2億円のライセンス料がかかる」
・・・このシチュエーションで品質を優先するのは不可能に近いものでした。
上長に「プロジェクトの目的は何ですか？」と聞いても、「納期通りにシステムを切り替え終わること」という回答しか返ってこず。
このプロジェクトに関わる人と会話を交わすと「何のためのプロジェクトなんだろうね」という声が散見される。
結果的に納期通りにプロジェクトを終えられたものの、これを機に数名が退職をする。
決してヘルシーなプロジェクトとは言えませんでした。
このプロジェクト以降、「品質至上主義」は私の基本スタンスとなりました。
そして「納期・コスト至上主義」の仕事は全部断るようになりました。
そのプロジェクトから7年がたち、改めてこの本と出会えたことに運命を感じました。
忙殺されがちなシステム開発を健康かつ文化的に乗り越える術が、この本には記されています。
