プロジェクト・マネジャーが知るべき97のこと/さあ、プラクティスを投げ捨てよう
うまくいっているチームがやっていて、ほかのチームがやっていないことは何でしょう？
うまくいっているチームは定期的に自分たちのプラクティスに疑問を持ち、ムダなものを排除しようとします。ソフトウェアだけでなくプロセスも容赦なくリファクタリングするのです。
“Il semble que la perfection soit atteinte non quand il n'y a plus rien ? ajouter,mais quand il n'y a plus rien ? retrancher.” このフランス語の文章はアントワーヌ・ド・サン＝テグジュペリから引用したもので「完璧であるということは、付け加えるべきものがなくなったときではなく、取り去るべきものがなくなったときである」という意味です。
どうしてチームはこの原則を適用しないのでしょう？
どうしてしばらくすると、最終製品の価値がどんどんやせ細っていき、プロセスや副産物がどんどんふくれ上がっていくのでしょう？
どうしてコードの行数が増えているのに、ソフトウェアの有用な機能はどんどん失われていくのでしょう？
以下に、ソフトウェア開発プロセスにおける「亀裂」を示す指標を挙げます。
- コードの行数やムダな機能という観点から、ソフトウェアが膨張する。
- ソフトウェアを開発するチームがどんどん大きくなる。
- プロセスがどんどん杓子定規で独断的で、融通の利かないものになる。
- チームが「計画倒れ（death by planning）」のミーティングを体験する。
- ドキュメントやサポートすべき生成物の量が指数的に増える。
- 顧客テストグループから、新たなバグが絶えず殺到する。
チームリーダーはプロセスやチェック、監査を増やしてしまいがちです。プロセスをもっと厳格にすることで、問題が解決すると思い込んでいるのです。私の経験から言って、これはプロセスの問題ではありません。プロセスをさらに増やすことは、チームが問題の根本原因を認識することを、さらに難しくしているだけなのです。
どうしてほとんどのチームは、チームにとって役に立たないプロセスを投げ捨てることを怖がっているのでしょう？
どうしてチームは、使い捨てのプラクティスを追加していくのではなく、思いつく限りの多数のプラクティスから始めようとするのでしょう？
そもそもこれは、そのプロセスを使っている理由をチームが本当は理解していない印なのかもしれません。あるいは、ソフトウェア開発プロセスを十分理解していない人が、高圧的にチームに方法論を強いているのかもしれません。いずれにせよ、プロジェクトは「砂上の楼閣」になって、今にもくずれて無用なコードの山になるおそれがあります。真の理由を理解せずに何かを変更しようとすると、プロジェクトは価値を高めることなく膨張していき、結局使えないものになるのです。
私が思うに、すぐれたプロジェクト・マネジャーはチームがうまく機能しているか、健康状態を把握すべきです。プロジェクト・マネジャーは一歩後ろに下がって、チームに課せられたプロセスが、動作するソフトウェアのスループットにどんな影響を及ぼしているのか、評価するべきです。
聡明なプロジェクト・マネジャーであれば、チームに依頼される可能性のあるアクティビティから取捨選択して、プロジェクトの成功に不可欠なものだけを維持すべきです。過去のプロジェクトから受け継がれたプラクティスを一掃することで、チームの生産性とスループットは短期間で大きく改善するはずです。
「過ぎたるは及ばざるがごとし」というのは、プロセスに関する非常に重要な哲学なのです。
この作品はクリエイティブ・コモンズ 表示 3.0 アメリカ合衆国ライセンスのもとに利用を許諾されています。
あなたは以下の条件に従う場合に限り、自由に
- 共有 – 本作品を複製、頒布、展示、実演できます。
- 再構成 – 二次的著作物を作成できます。
あなたの従うべき条件は以下の通りです。
- 表示 – あなたは適切なクレジットを表示し、ライセンスへのリンクを提供し、変更があったらその旨を示さなければなりません。これらは合理的であればどのような方法で行っても構いませんが、許諾者があなたやあなたの利用行為を支持していると示唆するような方法は除きます。
