スクラムにおけるマネージャーの役割の変化

みなさんこんにちは。@ryuzeeです。

Yahoo Groupのスクラム開発のメーリングリストでPete Deemer氏が投稿した記事から気になるところを抜粋して意訳にてご紹介します。

原文は、Manager 2.0: The Role of the Manager in Scrumを参照してください。 12ページくらいなので気軽に読めると思います。

スクラムを導入すると、マネージャーの役割が完全に無くなってしまうのではないか、という懸念に早い段階で気付く
スクラムには3つの役割しか規定されておらず、その他の人は、彼ら（スクラムの登場人物）をサポートするか、彼らの邪魔にならないようにしろ、くらいのことしか言及していない
従来のマネージャーは、「コマンドコントロール」というモデルに基づいていて、部下に何をすべきかを指示し、確実に、その指示にしたがって部下が作業するようにしていた
しかしソフトウェア開発が複雑で変化の激しいものとなってきている今では、マネージャーが全ての詳細を把握して、的確な指示を部下に出すことは難しくなってきている
またコマンドコントロール型のモデルだと、部下は単に指示に従うだけのモデルであり、それゆえに仕事全体に対して責任を持たないようになりがちだ（仕事全体はうまくいかなくても、「私は自分に与えられた仕事は完了したよ」というレベルでの責任しか持たなくなってしまう）
スクラムではその点では、「自己組織化されたチーム」というアプローチをしている
自己組織化されたチームで仕事をできるようにするためには、外部からのマイクロマネジメントを止める必要がある
通常チームは指示があればそれにしたがってしまうものであるため、外部からの指示がなくならない限り、チームは自己組織化したチームにはならない
マネージャーが答えを与えてしまうのは簡単だが、そうせずに、チームに考えさせて、チームに責任を持って対応してもらうようにすべきだ
マネージャーはスクラムにおいては、チームが学習し、成長し、達成するためのメンターであり、伝道師である。これがManager1.0からManager2.0への移行である
この新しいマネジメントモデルを定着させるためには、組織はマネージャーの役割とマネージャーへ期待することについて再定義を行う必要がある
一方でマネージャーをスクラムマスターにする、という選択肢もあるのだが、これはあまり良くないと思われる。というのもコマンドコントロール型のモデルを壊すのは難しく、やはりチームがマネージャーの方を向いて仕事しがちであるからだ。従来型の指示パターンを単にスクラムの中に移植した、ということになってしまうと、自己組織化されたチームから本来得られるであろうメリットはたぶん実現できない
マネージャーの役割の再定義の方法として、一旦マネージャーが持っている役割を全て付箋に書きだしてみて、それを「スクラムにとって好ましいか」「スクラムと競合する/もしくはスクラムでは必要ない」の2つに分けて配置してみる。その上で後者の役割を全て捨てて、残った役割をマネージャーの役割として、再定義すれば良い