アジャイルはマイクロマネジメント

作者 Vikas Hazrati , 翻訳者 徳武 聡 投稿日 2009年11月12日

セクション

プロセス/プラクティス

トピック

Agile in the Enterprise ,

Agile ,

マネジメント

原文(投稿日：2009/11/10)へのリンク

マイクロマネジメントは通常、あまり良い意味で使われない。このマネジメント方法は、マネージャが部下や社員の近くで仕事について細部まで指示する方法だ。普通、アジャイル開発とマイクロマネジメントは正反対の手法と考えられがちだが、表面上の違い以上に強く関連している。

Mike Cohn氏が指摘しているのは、アジャイルは実はマイクロマネジメントだ、という暗い秘密についてだ。氏は、すべてのアジャイルプラクティスはマイクロマネジメントをサポートしている、と説明している。曰く、

• デイリースクラムはチームのメンバの日々の仕事を細かく管理することであり、各人が自分のやる予定のことを確実に実施するようにする方法です。

• 継続的統合が導入されるのは開発者がビルドに失敗した時にすぐにわかるようにするためです。

• ペアプログラミングはプログラマが集中力を失わずに、実績を粉飾することなく、自信が楽しいと思うことだけをすることを禁じて、きちんと仕事をやり遂げるようにするための手段です。

この考えを補強するように、Artem Marchenko氏は次のように付け加えている。

アジャイルを強烈なマイクロマネジメントと見なす人はとてもたくさんいます。開発者は日毎に自分の作業を報告しなければならない。マネジメントは鼻をいじりながら報告のすべてに目を通して、２週間から４週間ごとに報告書と一緒にデモも見たいと思う。また、丁寧に考えて良い設計するために2、３ヶ月費やす必要がある問題も抱えている。どうでしょうか。マイクロマネジメントみたいでしょう。

ではマイクロマネジメントを実施しているのは誰か。

結果的には、チームだ。チームが自分たちのためにマイクロマネジメントを実践する。チームが毎日の作業を日単位で細かく管理し、マネージャはリリース物をイテレーション単位で細かく管理する。チームが毎日の作業について議論することは、チームや組織全体の利益について詳細に管理しようするのと同じことだ。

しかし、チームのメンバ自身が、細かく指示を与えられていることを感じ取る場合もある。

スクラムマスターがチームの進捗具合に力を注ぎすぎている場合がそうだ。たとえば、スクラムマスターがチームの周りをうろついて残課題についてや難儀な工数見積もりについて要求することは、この場合に該当するだろう。また、チームのメンバが、何もかもが透明になることで隠しておきたい技術不足や弱点が明らかになってしまうのを恐れている場合もある。その他には、

• マネージャが頻繁に質問をすることで、定期的に情報を新しくしておきたいと思っていて、チームのメンバは状態を報告するために長ったらしいレポートを提出しメールを送り、会議に出席しなければならない場合。
• マネージャが自分がわかりもしない技術の細部についてチームのメンバと議論しようとする場合。
• マネージャが思いつきでチームのメンバのやっていることを変え、作業の流れを壊してしまう場合。

伝統的なソフトウエア開発からアジャイルな手法へと転換をはかっている組織では、概してこのようなマイクロマネジメントが行われている。Jurgen Appelo氏が言うように、

チームが一緒になって意思決定をするのを快く思わないマネージャもいます。そういうマネージャは、自分抜きで意思決定が行われた場合に発生する作業に対して、制御を失ってしまうと感じるようです。マネージャは、意思決定というものは拘束力がなければならない、そうでないと無秩序になってしまう、と考えています。しかし、それと全く同じ無秩序が宇宙全体を構成しているのですから、一概に悪だとは言い切れません。

マイクロマネージャは自分が“責任者”であり、“制御者”ではないことを理解しなければならない。チームを“制御し抱え込む”ような試みは、大概失敗する。全く逆の結果を生んでしまうこともある。

このように、アジャイルとはマイクロマネジメントなのだが、実践するのがチームであるという点に両者の違いがあると言えるだろう。マイクロマネジメントの実践はマネージャからチームへと委譲されるべきなのだ。そして委譲されたチームが、プロジェクトとチーム自体の利益のために毎日の基本的な作業を進めるためマイクロマネジメントを実践する。

• 次へ >