BT

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

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース スクラムマスターがブロッカーとなるのは、守るべきパターンか、それとも避けたほうが良さそうか?

スクラムマスターがブロッカーとなるのは、守るべきパターンか、それとも避けたほうが良さそうか?

ブックマーク

さて、あなたは開発チームの一員で、そのチームではアジャイルを採用しているか、その方向に向かおうとしている。あなたはおそらく、スクラムか、その他のアジャイル手法のいずれか、あるいは独自に組み合わせたものを考えているだろう。もしアジャイルを小さく始める(source)のだとしたら、おそらくあなたは組織の体質に逆らって仕事をしているのだろう。チームをアジャイルではない世界から守る役割の人がいなければならない、と聞いたことがあるかもしれない。あるいは、まったく正反対のことを聞いたかもしれない-これはチームが機能不全に陥ったサインであり、われわれ対彼らという対立や局所的な最適化へと至らせるものである、と。どちらなのだろうか?あなたはスクラムマスターあるいは同等の役割をどのように遂行するべきなのだろうか?

2003年の初めに、Scott Ambler氏は障害を取り除く、という記事(source)で次のように書いている。

理想の世界では、あなたは正しいことをしたいと思っています。最適な方法であなたのステークホルダの要求にこたえるソフトウェア(source)を作り出すのです。あなたはステークホルダと親しく仕事ができ、適当と思うものはどんなものでも作成でき、価値を高めないものを作ることを強制されず、そしてプロジェクトのライフサイクルの間のしかるべき時期にそういったことができるはずです。あなたは適切な時点で適切な人物に近づく必要があり、そして他の人の「手伝い」を自由に断ることができるはずです。言い換えれば、あなたは自分自身の運命をコントロールしているはずです。

OK、もう笑うのはやめて下さい。

Scottはそれから現実に目を向け、チームがどのようにして最適ではない条件と折り合いをつけていくかを提案している。

それでは、もっとアジャイルなやり方を進めていくには、他の人たちが-教育をしたりコミュニケーションをとった後でさえも-柔軟性に欠けていたら、どうしますか?その答えは簡単-彼らをブロックするのです。アメリカンフットボールチームでは、とても大きな男達が前線にいます。彼らの唯一の役割は、相手チームのメンバがクォーターバックにタックル(してあなたのチームが前進するのを妨げようと)するのを防ぐことです。ソフトウェアの開発でも、ブロッカーは同じように働きます。チームの開発者の進捗を遅らせないように、もっと物理的ではないやり方で、他のチームの人たちを止めるのです。

ブロッカーは官僚的な人達から要求されたドキュメントを作成し、彼らとのミーティングに出席し、プロジェクトチームが実際にこうした他のグループと一緒に作業をしているように見えるように体裁を整えます。この妥協のプロセスによって、官僚的な人たちの妨害は開発者から遠ざけられ、なすべき仕事ができるようになります。官僚的な人達は、あなたのチームを「手伝った」のだと主張することもあるでしょうし、したがって彼らはその存在を正当化することができるのです。
InfoQでは先ごろ、Scottにインタビューをしてこの手のブロックがはらむ危険について話を聞いた。

InfoQ: ブロックすることは良いことですか?悪いことですか?

Scott: はい。

以前書いたように、最後の選択肢でなければなりません。あなたは、あなたが使っている技術について教育する努力をしなければなりませんし、彼らが何を成し遂げようとしているのかを知ろうとしなければなりません。何度も集まって話すだけで、多くの問題が解決されるのです。それでも上手くいかない時はブロックする必要があると思うでしょう。これは不幸なことですが、あなたの成功を可能にする唯一の戦略なのです。

InfoQ: スクラムマスターがブロッカーになるべきなのでしょうか?

Scott: これはチームの誰にでもできることです。順番で担当する役割かもしれませんが、多くの場合は最も経験豊富な人物/コーチがこの役割を担います。

InfoQ: このことはわれわれ対彼らという考え方を生まないでしょうか?この考え方が上手くいくはずのアジャイルの採用をいつも妨げる、という意見には賛同しますか?

Scott: はい、これには相当なリスクがありますし、おそらく良いことではないでしょう。私達は、それぞれのグループが成し遂げようとしているものを理解するために、一丸となって取り組む必要があります。私が思うのは、多くのアジャイルの開発者達は、「悪しき官僚主義」にまつわる一部のレトリックに騙されているということです。なぜなら、彼らはもっと大きな状況を本当に理解していないことがしばしばあるからです。アジャイルの進展は開発者に素晴らしい規律をもたらすために、多くのよいことを行いました。しかしその他の点では、一部の偏見や、あまり経験のない開発者には見えていないものを悪化させました。

InfoQ: それでは、これに代わるものは何でしょうか?その価値を増し、別のやり方をしている他の人たちに対応していくためには、チームはどのようにしてアジャイルの採用に取り掛かるべきなのでしょうか?

Scott:  他のグループの目的が何であるのかを知ることです。あなたがアジャイルのやり方でそうした目的に向かって進んでいることを示すことが出来れば、たいてい前に進むことができます。彼らはあなたに意味のあることをしてほしいと頼んでいるのだと言うことに、たぶん気がつくでしょう。

ブロッカーの問題をとりあげるのはこれが初めてではなく、既に議論されてきた。これは繰り返されている問題であり、我々もすでにInfoQで取り上げている(参考記事・英語)


このように、あなたがアジャイルでは無い環境でアジャイルを採用しようとしていたら、おそらくブロッカーが必要だろう。-しかし、慎重に行って欲しい。われわれ対彼らという状態にならないか注意が必要である。アジャイルではない人たちに耳を傾けるのだ。-彼らもまた、素晴らしい仕事をして組織の役に立つために、ベストをつくしているのだから。

原文はこちらです:http://www.infoq.com/news/2008/02/blocker-pattern-or-smell

この記事に星をつける

おすすめ度
スタイル

BT