この記事を読むのにかかる時間： 約 7分
Jim Coplien 氏の認定スクラムマスタ研修に参加しました。
http://jp.agilergo.com/13
研修で行ったこと、感じたこと、自分のチームに戻ったらやりたいことをまとめました。
目次
心に留めておきたいこと
２日間の座学、ワークショップ、参加された方との会話を通して学んだ、心に留めておきたいことです。
- スクラムマスターがチームをリードする（指示し管理するのではない）
- スクラムマスターはチームのために尽くす
- 無駄なことは何か意識する。次のスプリントもまた同じ無駄なことをしないように
- スクラムで規定されていないことは、自分たちで考える。場・状況はそれぞれ違う
- スクラムマスターは時にはチームを突き放し、チームで問題を解決させる
- 失敗してもよい。失敗から学ぶことは多い。1スプリント失敗しても大したことはない
- チームの一番大きな障害は、多くの場合「人」である
- プロダクトオーナー、スクラムマスター、チームはもっと会話をして、考えていることを互いに知るべきである
抜けているかもしれません。思い出したら追加します。
座学
座学では、スクラムの理論、ルール、成果物、について学びました。
使われた資料や伝え方はJim氏のオリジナルでしたが、内容の本質は下記URLに書かれていることと同じだと思っています。
アジャイルソフトウェア開発宣言
http://agilemanifesto.org/iso/ja/
アジャイル宣言の背後にある原則
http://agilemanifesto.org/iso/ja/principles.html
スクラムガイド(日本語版PDFのリンクがあります)
http://www.scrum.org/scrumguides
上記３つのURLはみなさんご存知と思います。
私はこれを、定期的に何度も確認しようと思っています。いつ見ても、いろんな事を気付かされる資料です。
スクラムを始めたばかりの頃は、いつの間にかスクラムをやることが目的になっていたこともありました。
スクラムマスターの役割を担う方は、これを「スタート地点」としていつでも心に中に留めておき、チームやプロダクトオーナーがおかしな方向に向かいそうになったらそれを調整すべきではないでしょうか。
ワークショップ
ワークショップの内容は、予備知識なしで誰にでもできる面白いものでした。そして、気づきの多いものでした。下記のスクラムのプロセスを実体験できました。
- プロダクトバックログに対して計画を立て
- スプリントを行い
- 失敗し
- フィードバックを得て
- 反省し
- マネージャーが指示をして改善するのではなく、チームで改善する
状況が改善されていくのはすごく楽しかったです。自己組織化のポイントのひとつは、この「楽しさ」ではないかと思いました。
スクラムマスターがチームにどのように働きかけるか、ヒントも詰まっていました。Jim Coplien 氏が「もっとできるはずだ」とチームを鼓舞していたのを思い出します。
計画の時点でプロダクトオーナーと対面し、考えていることをお互いに確認することの重要性も実感しました。各自が勝手に解釈せずに、考えていることをもっと話し合うべきですね。
チームに戻って、スクラムマスターとしてやりたいこと
チームに戻って何をしたいか、忘れないようにメモしておきます。
スクラムマスターをやることを宣言する
まずはここからです。
私のチームではスクラムマスターの役割を明確に誰がやると定義していません。チームにも協力をお願いしようと思っています。
困っていることをリスト化する
「困っていることリスト」はすでにあり、壁に貼ってありますが、「可視化されていない困っていること」があると思っています。それを見える化したいです。
よいスクラムマスターは、妨害リストを100項目ほど持っているそうです。
チームの状況をよく見る
チームの状況を注意深く観察し、無駄がないか考えてみます。
また、作業に集中すると、しばしば周りが見えなくなります。プレッシャーを受けていればなおさらです。
チームがそうなっていたら、「とりあえず、おちつけ」と伝えたいです。
自分もパニックにならないように、常に冷静でいたいです。周りをよく見てくれる人がいると、こんなにも楽になることを忘れていました。
タイムボックスを守る
タイムボックスを切って、目的と違うことをダラダラやらないことをこれまで以上に意識したいです。
時間を切ってチームにプレッシャーをかけるのではなく、その時間内でできることを大切にしたいです。
プロダクトオーナーについて考える
私のチームのプロダクトオーナーに相当する方は、社外取引先のシステム担当の方です。スクラムについて、十分に理解していただいているか、やや疑問が残ります。
プロダクトバックログは、要件定義を行ったのち、チームが作成してプロダクトオーナーにレビューするという形になっています。
もしかしたら、社外の取引先の方を教育するより、社内に別途プロダクトオーナーを立てたほうがうまく回るのかもしれません。
これはとても難しい問題ですが、自分たちで何とかしなくてはいけませんね。
明るく元気に、まずは自分が楽しむ
チームの雰囲気をよくするために心がけようと思っています。Jim Coplien 氏の、人との接し方を見ていてそう思いました。とても魅力的なお方です。
自己組織化について思うこと
3.11の震災のとき、ディズニーランドではスタッフがマネージャーの指示なしに、自分の判断で動いたと聞きます。
自己組織化のポイントは下記ではないかと思います。
- チームで考えてよいことを知る
- 目的の共有
- 優先順位の共有
- 自分たちで状況を変える楽しさ
- そのようにして出来上がった成果物で喜ぶ誰かの顔
それでも、マネージャーの指示がないと動きたくない、という人もいます。スクラムに向かない人、組織、状況はあります。そのときどうするかは、スクラムマスターの腕の見せ所ではないでしょうか。
Great Scrum Masterになるには
Jim Coplien 氏が最後にこうおっしゃいました。
「Good Scrum Master は３つのチームを持つことができる。一方、Great Scrum Master は１つのチームを持つことができる。理由はみなさんで考えてみてください。」
今の私のレベルでは、理由はよく分かりません。自分の意見を持つことができたら、一緒に研修に参加した方と話してみたいです。
おわりに
いろいろな気づきを与えてくださった、講師、スタッフの皆様、参加者の皆様、そして研修に参加させてくれたチームに感謝申し上げます。
