■
https://sites.google.com/a/scrumplop.org/published-patterns/product-organization-pattern-language/scrummaster を訳してみた。精読するために訳したので、どっかに正式の日本語版があったらごめんなさい。
ScrumMaster スクラムマスター
スクラムチームは自己組織化する。重要な役割や責任をチーム内に落とし込むのも自己組織化のプロセスの一部だ。
自己組織化したチームが自分自身を客観的に観察するのは難しい。そのために、改善や、問題発見、ときによってはベロシティと品質を維持するのにも苦労することがある。
プロジェクトはトップダウンで遂行するのが伝統的だが、うまくいっているとは言えない。知性的で想像力ある個人でチームを構成するなら、自分たち自身のやりかたで組織化する必要がある。自己組織化したチームはスクラムのコアを成す。いっぽう自己組織化にも問題がある。中でも、リーダーや監督の不在が問題である。チームが「正直」でありつづけるよう働きかける人物が必要なのだ。またチームには公式の「顔」も欠かせない。チームと話したいが誰と話したらいいかわからないときは「顔」の人と話すことになる。チームのスポークスパーソンとして定まった担当者がほしいときもある。ここで述べたような機能が欠けていると、チームは失敗してしまう。
ところが平等主義が行き渡ったチームではそうした機能をうまく実現できない。1人の人を決めるのは、平等主義に反してしまうからだ。不自然に感じるし、立候補するのもためらわれることが多い。これはコミットメントや問題意識が足らないためではない。平等主義的自己組織化チームの自然な反応なのだ。
Therefore:
スクラムマスターと呼ばれる人を1人定め、チームがスクラムプロセスを効果的に遂行し、かつ継続的に改善を続ける手助けをしてもらう。スクラムマスターはチームの中にいながら、チームの「上から」客観的にチームを見る。スクラムマスターの責務は、チームがより効果的になる手助けをすることだ。
スクラムマスターの選定からチームの自己組織化が始まることが多い。
スクラムマスターの役割はチームの他のメンバーとわずかばかり異なる。リーダーシップ、励行(encouragement)、規律、保護、コミュニケーションといった要素がスクラムマスターには必要となる。しかしそのような要素をメンバーはみな苦手に感じたり、そもそもできないかもしれない。
役割が少々異なっているとは言え、全員がスクラムマスターのことをチームの一員と見なさなくてはいけない。なによりもチームメンバーであり、そのうえでスクラムマスターなのだ。スクラムマスターが「上から」チームを見てるからと言って、メンバー同士のオープンな助け合いの関係に変化があってはならない。スクラムマスターとその他のメンバーは、お互いを同等と考えなくてはならない。
チームがスクラムマスターを選定するのが理想だ。そうでない場合でも、スクラムマスターはチームを支えることに喜びを感じなくてはならない。
チームを支えてよりよくするのがスクラムマスターの最大の責務であることを忘れてはいけない。多くのチームにおいて、スクラムマスターは朝会などのミーティングで司会をするところが目立つので、それだけやっていればいいと思われがちである。スクラムマスターもチーム全体も、もっと広範かつ重要な責務のことを意識しなくてはならない。
Producer Roles パターンで Coplien と Harrison が説明しているように、典型的にはチームメンバーは「プロデューサー」(組織のROIに直接貢献する)と「サポーター」(プロデューサーの仕事を助ける)に分けられる。スクラムマスターは完璧なサポーターだ。すなわち、スクラムマスターがやることはすべて、他のチーム全員がよりよくなるためなのである。そのための方法はたくさんあり、特に重要なものをサブパターンで紹介する。
スクラムマスターはチームから外界に対する「顔」となることがある。これはスクラムマスターがチームにとってコミュニケーションパスになるという意味ではない。むしろ、チームメンバーは必要に応じて自由に頻繁に外界とコミュニケーションをとるべきだ。ときには1人の決まった人が望ましい場合がある(いつもそうしないよう注意！)。また、チームを望ましくない妨害から守るためにスクラムマスターが立ち上がることもある(Firewallを参照)。
スクラムマスターはどこからやってくるのだろうか？ 理想的にはチームの中から選ぶのがよい。だがチームに希望者や、適任者がいないこともあるだろう。その場合はもちろん外部から連れてくればよい。だが信頼の絆(Community of Trust)に注意せよ。信頼関係を気づかなくてはならない。マネージャーがスクラムマスターを決め手はならない。候補をマネージャーが選んでもよいが、最終的にスクラムマスターとして受け入れるかはチームが判断する。経験の浅いチームには経験豊富なスクラムマスターがいたほうがよい(他のパターンも参照)。
よいスクラムマスターはそのへんに生えてきたりしない。育てなければならない。スクラムマスターとなる人材にあったほうがよいスキルがいくつかある。
- なにより第一に、スクラムマスターになりたいという気持ちが大切だ。開発者に必要なスキルとは大きく異なるため、そもそもやりたいと思わないメンバーが多い。
- スクラムプロセスのリーダーとして、スクラムについて熟知していなくてはならない。
- 対人スキル、コミュニケーションスキルは必須。
- スクラムマスターは数多くの細かい問題を扱えなくてはならない。
- データを分析し結論を導く能力。たとえば、ベロシティに関するデータを集め、分析して、チームがベロシティを向上できる方法を探すのはスクラムマスターの役目だ。
- チームメンバーとして、開発しているものを理解するだけの技術知識が必要だ。
ここで挙げたスキルは従来のプロジェクトマネジメントで使うものとよく似ている。だが従来のプロジェクトマネージャーをスクラムマスターにするのは危険が伴う。経験あるプロジェクトマネージャーは、従来のやり方に戻ってしまうかも知れず、それではスクラムとはほど遠くなってしまう。
スクラムマスターが開発の作業もしていいだろうか？ そうしたいと感じることは多い。とりわけ、スクラムマスターの仕事だけでは時間が余ってしまうように思えるとそうなるだろう。だが、避けるべき理由がいくつかある。
- 開発が慌ただしくなってくると、50%だけ開発するつもりだったものがたちまち90%になってしまう。そうなるとスクラムマスターは開発作業と朝会の司会以外なにもできなくなる。スクラムマスターの利点がすべてなくなってしまうのだ。
- それほど重要ではないかもしれないが、品質と改善が「ひたすらコードを書く」よりずっと重要であるというメッセージが薄れてしまう。
Examples:
- セミナーやミーティングで、参加者がグループに分かれてディスカッションし、結論を報告することがある。グループに分かれたときは居心地が悪く、誰かリードしてくれないかと思う。そのうち誰かがリーダーとなる(グループで選ぶこともある)。報告もたいていの場合リーダーがする。「同等のリーダー」が見つかるまでの居心地の悪さを思い出してみよう。
- 大学の組織で一般的なのは、代表を選挙で選び、代表になった者は一定期間でまたもとの職務に戻るやり方だ。
- スクラムチームでは、スクラムマスターはミーティングの司会をするだけでなく、必要なミーティングを開催するのも仕事だ。開発者は得てしてミーティングよりコーディングを選んでしまう。
- 一般的にはスクラムマスターがプロジェクトのデータを集めてスクラムボードを更新し、チームの Visible Status を提供する(下記の鏡の剣士パターンを参照)
スクラムマスターが決まったら、以下のパターンが役に立つ。スクラムマスターは以下のすべてのサブパターンを知っておくべきだ。サブパターンはスクラムマスターが果たす役割の主要部分をカバーしている。
- 触媒: スクラムに欠かせない大量のコラボレーションを発現させる。
- スクラムマスターはチームに完了の定義(Definition Of Done)を守らせる完了マスターとなる。
- 牧羊犬: チームが常にプロセスを守るよう支える。監視して、ズレを補正する。
- スクラムマスターは鏡の剣士となり、チームの行動を投影してみせる。チームは自分自身の長所と弱点に気づく。
- コーチ: チームに改善を促し、改善のためのアドバイスを与える。
- チアリーダー: チームを元気づけ、ポジティブなフィードバックをする。
- ファイヤウォール: 不必要な外部の影響からチームを保護する。
- スクラムマスターはプロダクトオーナートレーナーとして、プロダクトオーナーがより上手になるのを手伝う。
時と場合に応じて使える作戦もいくつか挙げる。
- ニワトリに変身 (目を合わせない)
- ビートルズを朝会に
- おやつ神社
- Four Minute Mile
その他の提案されたパターン:
- 悪魔の代理人
- チェンジエージェント
