9月20日から3日間、株式会社アトラクタ主催の認定スクラムマスター研修を受講しました。
実践的な内容で、開発を進めていくうえでのリアルな悩みに響くものでした。単に資格を取得するための研修ではなく、スクラムを実践するうえでの壁を突破するヒントやエネルギーをもらえたと思います。
この研修を経験して考えたことを中心に、個人的な感想をまとめてみます。
より一般的に「研修で学んだこと」を知りたい方は、一緒に参加した同僚の記事をおすすめします。
私はスクラムマスターを目指すべきか？
私は、とあるスクラムチームのプロダクトオーナーを務めています。チームが発足してから3ヶ月が経過し、徐々にスクラムに慣れつつあります。しかし、チームのスクラムマスターはあと3ヶ月でチームを去る予定であり、まだ代わりとなるメンバーを見つけられていません。チームの人数も多くなく、すぐに開発者の中から次のスクラムマスターを立てるのは困難そうです。
スクラムマスターが居なくなった後、このチームは、どうしていけばいいのでしょう。
たとえば、私の代わりとなるプロダクトオーナーを見つけて、私はスクラムマスターに役割を交代してみることを想像してみます。認定スクラムマスター研修を受けたため、きっと私はスクラムマスターがやるべきことを理解できているでしょう。
しかし、もしかしたら「プロダクトオーナーとしての情熱が邪魔をする」のではないか？という心配があります。
私の手元にあったSCRUM BOOT CAMP THE BOOKには、このように書かれていました。
プロダクトオーナーであれば、自分たちがつくっていくものがどうすれば少しでも良くなるかを熱心に考えてくれる人だ。近くに「もっとこうしたら良くなるのに」といつも口にしているような人はいないだろうか？実はそういう人が適任なんだ。その人なら実現したいことの明確なイメージを持っているだろうし、どっちの仕様がいいかといった判断も迅速にやってくれる。
私はチームの担当領域に関して、このような熱意を備えている自信があります。しかし、もしかしたら実現したいことのイメージが強固すぎるかもしれません。「どっちの仕様がいいか」という意見を持ちすぎており、プロダクトオーナーとしてのふるまいが抜けきらないかもしれません。
私にはスクラムマスターの資質があるか？
仮にプロダクトオーナーとしてのふるまいが抜け、スクラムマスターとしての役割に専念できたとします。しかし、私はスクラムマスターに向いているのでしょうか。
「スクラムマスターに向いている人」を検索してみると、個人のキャラクターに言及しているようなものも多かったです。いつもニコニコしており、いつでも相談したいと思えるような、一人の人間としての魅力は、私にあるのでしょうか？
実は、私たちのチームはスクラムではない・・・
正直に白状すると、実は私たちのチームはスクラムであるとは言えません。それは、スクラムの肝である毎スプリントのスプリントレビューを実施していないからです。つまり、スクラムの要素を取り入れているアジャイルに過ぎません。
毎スプリントのスプリントレビューを実施していない理由は、私たちのチームの特徴にあります。私たちのチームのミッションは、Developer Productivity Engineering(DPE)です。お客様はご近所のチームであり、私たち自身もそれらのチームで働いた経験があります。このため、フィードバックを常に得やすく、現時点においてはつくるものの不確実性が高くありません。私たち自身も作成物を利用することがあるため、私たち自身もステークホルダーであるとも言えるかもしれません。
また、忙しいほかの開発チームに対して、頻繁にスプリントレビューに招待するのも遠慮がありました。
しかし、インクリメントに関するデモは、重要な「検査」です。予期していなかったことに気づく可能性は大いにありえます。このため、まずはチーム内を中心とした少数向けだけでもいいので、実験としてスプリントレビューをやってみるのもいいかもしれない、と思い始めました。
というよりも、この研修を経験して、「スプリントレビューをやってみたい！」という気持ちが芽生えました。
「撤退」の重要性
アジャイルの価値は「少数のプロダクトに社運を賭けるような大きなギャンブルをせずに済むこと」という説明が強く響きました。アジャイルの価値をマネジメント向けに説明するのに苦労しているシーンを見かけることがありますが、これはお金の話に変換できている、シンプルで良い説明だと感じました。
ビジネスのライフサイクルが短期化し、既存ビジネスが縮小していく現在、多数の取り組みを素早く回して、ポテンシャルのあるものを見極めていく必要があります。そのためには、素早い投資判断をし、素早く実行し、素早く撤退し、うまくいけば素早く追加投資をすることが求められています。
成果を上げなかった取り組みからは撤退する必要があります。撤退しないと人を薄く広く分散しなければいけなくなるからです。このため、素早く撤退するというのが非常に重要です。
その判断のキーは「価値」ですが、価値は提供元のチームや組織が決めるものではありません。顧客やユーザーが決めます。
しかし、ウォーターフォールって、それを実現できるんでしたっけ？ウォーターフォールで結果が判明するのは、大きな投資金額を賭けた後になるのでは？と。
逆に言うと、「撤退」を決断し実行するための環境を揃えられていないのであれば、それはアジャイルの価値を出せていないのではないかと感じました。（ウォーターフォールで開発したほうがマシ？）
「不要な機能」を消す重要性
不要な機能を消すことに関して、下記のパワーワードが炸裂しました。私はパワーワードに弱いです。
ソフトウェアが肥大化すると、本当に大事なことに集中できなくなります。不要な機能を削除していくためには、削除するためのプロダクトバックログアイテムを用意する必要があります。
プロダクトオーナーは、たくさん機能を作りたがります。実は、開発者も同じで、複雑なものをいっぱい作りたがります。それに対して、スクラムマスターは「ちょっと待って！一気にそんなにたくさん作らなくていいから、それよりも、早く動くものを見せてフィードバックをもらおうぜ」と、アジャイルの価値を理解してもらう役割であるとのことでした。
個人的に不要な機能を消したり、利用されなくなったサポート環境を減らすなどの取り組みは進めてきました。しかし、組織全体にその価値を伝え、スピードを上げていくことに対しては、まだまだ課題を感じています。
取り組みを力強く後押ししてくれる説明でした。また、成熟したソフトウェアが林立しているこの時代、どこの組織においても似たような課題はあるのだとも感じました。
最後に
研修の中では「スクラムマスターの目的は、単に良いチームではなく、ハイパフォーマンスのチームを作ることです。スクラムマスター1人分のコストなんて安いものです。」(引用: SCRUMMASTER THE BOOK)という言葉が紹介されました。
・・・はい、難しそうです。大変そうです。
しかし、スクラムマスターは一人孤独に戦うわけではありません。チームメンバーと一緒になって、チーム全体で課題に取り組むことができます。今回、誘い合って一緒に研修を受けることにした別のチームの仲間だったり、スクラムマスターやメンバーが集まったコミュニティもあります。もしかすると、チームメンバーと一緒に課題に取り組み、協力者を増やしていき、大きなことを成し遂げる旅を最も楽しめる役割なのかもしれません。
よし、やっていくぞ！