BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース スクラムマスタはチームの障害をどう扱うべきか

スクラムマスタはチームの障害をどう扱うべきか

ブックマーク

原文(投稿日:2013/05/16)へのリンク

スクラムでは,チームの作業がブロックされた場合の問題対処行動について議論をする時,障害(Impediment) という用語を使用する。障害に対処する上で重要なのは,スクラムマスタとチーム間の相互期待と協力関係である。対処の方法はさまざまだ。何人かのスクラムマスタの例を見てみよう。

Gunther Verheyen氏は impediments (and where to find them) と題したブログ記事で,障害に対するスクラムマスタの役割について持論を展開している。スクラムの紹介に始まるその記事では,スクラムマスタは障害の解消を期待される存在ではあるが,それは障害の発見にも責任を負うという意味ではない,と説明されている。

(...) [スクラムマスタは 'インペディメント・ハンタ' であるべきだというのは,] スクラムマスタが積極的に障害を見つけ出して追跡し,取り除かなければならないと言っているのです。(...) 果たしてこれは,チームの自己組織化や透明性と両立できるのでしょうか?

問題の所在を明確化して,それを障害として取り上げる役目は,チームメンバに期待されるものだ。スクラムマスタが問題を "ハント" する必要はない。

障害を積極的に探して('ハント'して)取り除くというのは,問題が問題になる前に解決する,ということです。(...). 問題を事前に解決するというのは,チームの自己組織能力を信用していないことに他なりません。問題を事前に解決するというのは,チームに対する透過性を阻害するという意味で,学習と改善の機会を損なうものです。問題を事前に解決するというのは,時間とエネルギの浪費でしかありません。スクラムマスタの介在がなくても,チーム自身が何らかの方法でそれを解決して,彼らに対するブロックに転じることを阻止することは可能だからです。

スクラムマスタの役割はチームがブロックされるのを防ぐことだ,と氏は言う。

問題が障害に転じるのは,それが自己組織のエコステムでは対処できないものである場合に限られます。(...) 定義上,スクラムで問題が障害になるのは,(開発)チームの権限ではブロックを解除できない場合のみです。

スクラムマスタに対して氏は,チームの自己組織量を向上させるようにアドバイスする。

チーム自らの問題解決を支援するにはどうすればよいかを考えて,ツールやトレーニング,これを実行する方法への洞察を提供するようにしてください。

Alec Hardy氏のブログ記事 got an impediment? Great! には,スクラムマスタがチームと共に障害に対処するための方法が説明されている。氏は最初に,第1ステップの説明をする。

多くの場合,障害を取り除くことが最大の課題なのではありません – 最初の段階で,人々に障害を本当に認識してもらうことなのです。

障害を可視化し,議論と解決のできる文化を創り上げることが重要だ,と氏は説明する。

チームメンバがインペディメントを報告したら,スクラムマスタはこう言うべきです。"すごいぞ!よく報告してくれた。みんなに伝えられるから,対策も打てるよ。" 障害を気軽に議論できるチームは,すぐに絨毯の下に隠そうとしたり,CYA(隠ぺい)モードになって逃げだしたりするチームに比べれば,はるかに先を行っているのです。

should the scrum master remove impediments? というブログ記事でJames Scrimshire氏は,スクラムマスタとしての自分がどのように障害に取り組んでいるかを説明している。

今はスクラムチームのコーチングの一環として,障害が見つかったときには,チーム自身で取り除く方法を見いだすのを支援するようにしています。チームがそれを自分たちのものとして受け入れるならば,あるいは彼らの方法で障害を取り除くために必要なスキルやツール,リレーションシップ,あるいはその他のものを特定する上で有効ならば,私の方から何らかの提案をすることもあります。

彼らの抱える障害の数が多い(多すぎる)ときはどうすればよいだろう? Marcello Scacchetti氏は a scrum master is keeping a list of open impediments (...) という長い題のブログ記事で,そのような場合のアクションをいくつか提案している。

障害とその影響についてマネージメントに警告を上げておけば,可能なソリューションを決定して,手遅れになる前にそれを実行できるようになるでしょう。

開発チームと現在の障害について話をするのも,根本的な原因の発見に繋がるかも知れません。障害リストが絶えず増え続けている場合には,プロジェクトにとって致命的な問題が突然発生する,その前兆である可能性があります。

優先順位を付けた障害リストを開発チームや関係各所に公開しておけば,可能な限り早期解決するのに役立つかも知れません。

読者諸氏の組織のスクラムマスタは,チームの障害に対してどのように対処しているだろう?

この記事に星をつける

おすすめ度
スタイル

BT