Blog

スクラムにおける管理職の役割の変化

 2009/12/17
このエントリーをはてなブックマークに追加

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

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

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

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