iOSエンジニアが認定スクラムマスター研修を受けてスクラムマスターをやってみた話

 こんにちはKINTOテクノロジーズの小山です。モバイルアプリの開発・運用に携わっています。担当はiOSです。
前回はiOS開発に特化した記事（Combineを使ってMVVMを実現した話）を書かせてもらいましたが、今回はその開発現場で取り入れているアジャイル開発の内容です。
以前から私の携わっているモバイルアプリ開発ではアジャイル開発を取り入れており、スクラムを使って運用しています。今回、スクラムマスターをやってみないかとの話をいただきましたので、その経過を紹介したいと思います。
※この記事は「アジャイル」をテーマにした一連の連載記事となります。
私たちは「組織としてアジャイルな状態」になっていくために、
さまざまな課題や困難に立ち向かってきました。
時には失敗もありましたが、それでも着実に成長を続けています。
この連載記事では、そんな私たちの実際の取り組みをご紹介していきたいと思います。
 なぜスクラムマスター研修を受けたのか以前からスクラムを使った開発には携わっていましたが、いずれも開発者の立場での参画でした。スクラムマスターとしての立ち回りはやったことがなかったため不安に感じていたところ、スクラムマスター研修なるものが存在するとの情報を得て受講に至りました。

今回は株式会社アトラクタさんが主催している認定スクラムマスター研修というものを受講しました。
 それまでの開発チーム私の所属している開発チームについて紹介したいと思います。
 体制・役割プロダクトオーナー
チームリーダー
バックエンド開発チーム
フロントエンド開発チーム
iOS開発チーム ←今ここ
Android開発チーム

QA
デザイナー
モバイルアプリの開発現場ではこのようにフロントエンドの開発チームが2チームに分かれることがままあります。

今回私がスクラムマスターを実施するということで、以下のようになる想定でした。
プロダクトオーナー
バックエンド開発チーム
スクラムマスター（チームリーダー）

フロントエンド開発チーム
スクラムマスター ←ここ半分
iOS開発チーム ←ここ半分
Android開発チーム

QA
デザイナー
元々チームリーダーはバックエンド開発寄りの立場にいたため、そちらのスクラムマスターを担当し、フロントエンド側を私が担当する想定でした。

…今思えば奇妙な構成を考えていたと感じますが、当時の私は気づけず、気づいていたとしても自信を持って意見できる状態ではありませんでした。
 既存のチーム開発における課題もちろんそれまでもアジャイル開発を進めていたため、スクラムを利用する上での疑問点や課題が多くありました。
開発メンバーが10人を超えてしまっているがどうすれば良いか
各種スプリントイベントをバックエンドとフロントエンドで分けて実施しているが問題ないのか
スクラムへの理解度がメンバーによってばらつきがある
等々…
これらが解決できればと思い研修に臨みました。
 いざ、受講！ 研修概要スクラムマスター研修は3日間のカリキュラムとなっており、毎日13時〜18時の間オンラインで実施されました。その後任意のタイミングで試験を受けることができ、合格するとScrum Allianceが発行するCertified ScrumMaster（認定スクラムマスター）の資格を取得することができます。
3日間の内訳はざっくり以下の通りでした。
1日目：アジャイルとスクラムについての座学
2日目：スクラムの実践
3日目：スクラムマスターの座学と実践
アジャイルやスクラムについては書籍やWebなどから学ぶことができますが、それらを遥かに凌ぐわかりやすさで座学が進められました。忘れかけていた原則やマインドを学び直した上で、疑問点は常に講師の方に聞くことができ、実践形式で知識を定着させることができました。とても有意義な時間でした。
 研修を受けて変わったこととにかく、
自信がついた
これに尽きます。
スクラムマスターをやる上で絶対に必要なのがスクラムについて指導をすることです。

それまでの学びでは「こういうことが本には書いてあるけど実際こうだしな」と自分でも疑問を解消しきれずにいました。原理原則は知っていても自信を持ってチームメンバーに広めることができずにいました。
研修を受けることで少なくとも自分が思っている疑問点は全て解消でき、スクラムの書籍も出しているような著名な講師の方に教えてもらったという絶対的な安心感が自信に繋がりました。また認定スクラムマスターの資格も手に入れることができたためこれも自信の裏付けとなりました。
 受講後、やってみた プロダクトオーナーの理解を得る私のチームでは研修の中でアンチパターンと呼ばれる手法をいくつも取っていることが判明しました。そこでまずプロダクトオーナーにアンチパターンがあること、なぜアンチパターンなのか、を説明しました。
一気に全てを変えることは難しいのでわかりやすいところから変えていこうとなり、私のチームでは「バックログの運用方法」から変えることを検討していくことになりました。
 チームメンバーに研修の展開アジャイル開発ではチーム全体で同じ意識を持つ必要があります。これがアジャイルを進める上でのとても重要なことだと私は思います。「バックログの運用方法」から変えるにしても、まずは意識を統一させることが必要でした。
そのために、受講後の週で内部展開用の資料を新たに作成し集合研修を行いました。まさに自信がついたからこそできた行動でした。



チームメンバーからは「アンチパターンを実施してしまっていたことがわかった」という声や、「研修受講後すぐに展開してくれるのが嬉しい！」といった反応をいただけました。正直なところ資料の作成と研修展開はかなり大変でしたが、やってよかったです。
 改善内容の実践「バックログの運用方法」の改善にあたり、現状の課題点とあるべき姿を説明し、次のバックログリファインメントから取り入れていきました。ここまでを研修受講後から1週間というスピードで実施しました。研修受講したてのホットな状態でここまでやり切れたのは、理解のあるプロダクトオーナーと開発メンバーのおかげでした。

 体制はどうなった？研修内容のチームへのフィードバックは滞りなく完了したのですが、ここで問題が発生してしまいました。
なんとチームリーダーが急遽育休に入るということでした。
当社は育休制度（もちろん男性も）がありますし、育児を応援したい気持ちはチーム全体としてありましたので、気持ちよく送り出すことにはなったのですが、どうやらこのビッグ（メンバー数が）プロジェクトを私がスクラムマスターとしてサポートする必要がありそうです。ひええ。

ということで再構成された体制が以下の通りです。
プロダクトオーナー
スクラムマスター ←ここ半分
バックエンド開発チーム
フロントエンド開発チーム
iOS開発チーム ←ここ半分
Android開発チーム

QA
デザイナー
前述の
…今思えば奇妙な構成を考えていたと感じますが、
の記載については、そもそもチーム内にスクラムマスターは1名で十分なためです。主にバックエンドをフォローするスクラムマスター、主にフロントエンドをフォローするスクラムマスター、といった分け方は本来の役割を期待されているようには見えません。名ばかりのスクラムマスターで、チームリーダーのような役割になってしまいそうな懸念があります。
また、元々実施していたチーム分け（バックエンド/フロントエンド）ではどうしてもチーム間でのやり取りが発生し、結局ブリッジとなる役割のメンバーが必要になってくる課題がありました。かつそのブリッジメンバーの負担が非常に大きくなってしまう傾向があったので、このタイミングで1チームにまとめられたことは今後のこと（後述）を考えるとむしろ好手であったと私は考えています。
 これからやっていきたいこと当面の目標としては、上記の改善を皮切りにどんどん開発チームをアップデートしていくことです。上手にスクラムが回るようになってきたら、今度はフィーチャーチームに分割するといったことにもトライをしていきたいと考えています。こうすることで当初考えていたチームの課題を全て解決することができます。
また長期的には社内にいるスクラムマスターと協力して、スクラムを使ったアジャイル開発を広めていけたらと考えています。うまく走り出すところまでサポートしたら、またさらに別のチームをサポートし、そうしてスクラムがもっと広まればより良いプロダクトの開発に貢献できるはずです。
 終わりに以上、スクラムマスター研修の体験記でした。とにかくメリットだらけですので、もし読んでいる方の中にスクラムがなかなかうまくいかないと悩んでいる方がいれば、受講を検討してみてはいかがでしょうか。受講料が少々お高めなので個人では受けづらいですが、会社に費用を負担してもらうために会社・上長を説得できる要素は十二分にあると思います。
個人的にスクラムを使ったアジャイル開発の最大のポイントは「チームごとにプラクティスが違う」というところだと思います。他社のプラクティスが必ずしも自社に適用できるとは限りません。いろいろなやり方を模索していくのは難しいけれど実は一番楽しいポイントかもしれませんね。