Scrum 管理職の役割の変化

 2009/12/17

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

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

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

サイト内検索


著作

寄稿

Latest post: