はじめに

アジャイルソフトウェア開発やスクラムの教科書的な内容のまとめというよりは実際の体験談をベースに現在の自分が過去の自分にアドバイスするならというイメージでまとめています。もちろん当時のチームやメンバーの活動などを批判する意図も微塵もないです🙇‍♂️

私自身はスクラムやアジャイルの経験豊富なプロではないですし華々しい成功事例でもなくリアルなその辺にありそうなチームの実例として本記事の価値を置いてもらえればよいと思います。
ですので想定読者としては、他のチームの事例が気になるという方やこれからスクラムマスターとして活動していく方にとって、ひとつでも共感を与えられたり参考になったりすることがあれば幸いといった次第です。

すべてのチームに当てはまるものはないでしょうからぜひ批判的に読んでもらえるのが良いかと思います🙇‍♂️

なお本記事中では日本語訳された2020年版スクラムガイドから一部引用をしています。

自分たちにとってのアジャイル、スクラムとは何かをきちんと言語化して共有する

私たちのチームは元々ビジネスモデルの転換やウォーターフォール的開発プロセスからの脱却を目指して会社の中でも先行的に小規模にスタートしたチームになります。私も、当時はまだスクラムマスターではありませんでしたが、メンバーの一員でした。なのでその時のメンバーの間では目的意識もそれ以前の働き方の課題感も共有された状態で始まっていました。

チームの拡大に伴い以前までのウォーターフォール的開発プロセスを経験しない言わばアジャイルネイティブなメンバーの比率が増えていったときにこの章のタイトルにあるようなことをきちんと行うべきだったと思っています。つまり、元々は自分たちの体験をベースにした目的意識や課題感を暗黙の共有事項としてアジャイルやスクラムの根本のモチベーションにしていたところが、若い新しいメンバーと必ずしも共有されていなかった、あるいは共有したつもりになっていた（暗黙の部分により伝わらなかった）ということです。

チームの事情も会社・組織としての方針も時間に合わせて変化していきます。自分たちにとってのアジャイル、スクラムとは何なのかをチーム全員で考えるプロセスを期の変わり目や新人配属などのタイミングで都度やってみるのはどうでしょうか。

マネージャー兼 PO から早い段階で権限移譲をしておく

先述のような経緯で課 = スクラムチームという単位で始まったこともあり課長を PO において組織としての指揮系統と一致させることは自然に決まりましたし始めはやりやすくもあったのですが、少なくともチームの拡大に併せてチームをスケールさせる必要が生まれたタイミングで PO の権限をいずれかのやり方で移譲しておくべきだったと思います。

それよりもう少し後の話にはなりますが実際に私たちがとったのは PO チームのような形で PO（課長）のもとに一部権限を委譲されたメンバーを数名置くというものです（実際に置いたのは2名です）。諸事情あり意図しない形で課長（PO）がチームから外れることになったためとった引継ぎのための施策とも言えますが、終盤にはほとんどの PO 業務を委譲して業務を回すことができていたため早い段階でこうした取り組みをしても良かったと思っています。

なおスクラムガイドにおいてはプロダクトオーナーの説明として次のようにありますが、これは権限委譲や補佐のために PO チームを作るような仕組みを否定する記述ではないという解釈を私たちはしました。実際に PO チームというアイデアについては CSM 研修のを受講した際に講師からヒントをもらったものでもあります。

プロダクトオーナーは 1 ⼈の⼈間であり、委員会ではない。

プロダクトの設定をシンプルにしてみよう

課 = スクラムチームであり課長が PO を兼務していたこともあり私たちのスクラムチームではプロダクトを特定の一つの製品やサービスではなくある種抽象的な課としてのミッションそのものとして設定していました。その中にサービスの開発も含まれているような形です。

プロダクトとは価値を提供する⼿段である。プロダクトは、明確な境界、既知のステークホルダー、明確に定義されたユーザーや顧客を持っている。プロダクトは、サービスや物理的な製品である場合もあれば、より抽象的なものの場合もある。

スクラムガイドには上記のようにありますのでこういった例そのものはよくあるのかもしれませんし当時まったくうまくいかなかったというわけではないのですが、チームで振り返りを行った結果、メンバー各自がチームのプロダクトとして把握しておかなければならない技術領域や業務知識が広大になりそれらを網羅的にカバーできるメンバーも限られていたことで負担が集中してしまっていた（結果としてスキルトランスファーのための余裕も少なくなった）のではないかという意見もあがりました。

さらに現在では、開発リソースがこれまで以上に確保できるようになり組織の戦略として複数のサービスを同時に開発していくことが求められるようになったことに伴い、それぞれのサービスをプロダクトに持つチームがそれぞれ個別の PO とプロダクトバックログのもとで動いているような形をとっています（前章で PO の権限移譲について話した通り現在は複数の PO がいる状態です）。一方で課という従来のマネジメントのための構造は残っているため完全にそれぞれのチームを独立させるのではなく様々な形で連動させたり全体感を持たせるための仕組みやバランスを現在は模索しているというところです。（※ちなみに本記事のチームという表現についてはここの文章以外については基本的には課全体としてのチームを指しています）

LeSS などのスケーリング手法を採用する必要があるかどうか考えてみる

この章の内容は LeSS を批判する意図ではなく自分たちのチームが実際に行った判断についての評価ということをあらかじめ記しておきます。

スクラムチームのサイズ、スケーリングについてはスクラムガイドでは次のように記述されています。実際にチームが大きくなるにつれこうしたスケーリングの必要性は感じられていたので私たちもさっそく LeSS を導入して運用を始めました。

スクラムチームは、敏捷性を維持するための⼗分な⼩ささと、スプリント内で重要な作業を完了するための⼗分な⼤きさがあり、通常は 10 ⼈以下である。⼀般的に⼩さなチームのほうがコミュニケーションがうまく、⽣産性が⾼いことがわかっている。スクラムチームが⼤きくなりすぎる場合は、同じプロダクトに専念した、複数のまとまりのあるスクラムチームに再編成することを検討する必要がある。したがって、同じプロダクトゴール、プロダクトバックログ、およびプロダクトオーナーを共有する必要がある。

この章で言いたいことは私たちのチームではまずは（あるいは同時に）前章までに述べたような PO の権限移譲についての話やプロダクトの設定についての話をするべきだったのかなと今は思っているということです。結果的に現在は前章で述べたように LeSS ではなく複数のスクラムチームを作ることでスケーリングをしています。（LeSS 自体は当時チームのスケーリングをするうえで役に立ちましたし A-CSM の研修においてもコーチをはじめとして LeSS を推奨する声が一定数あったこともあり良いフレームワークだと思っています）

チームが大きくなったといえ10数名のチームであったため LeSS としては最小構成も最小構成だと思います。もう少しチームのサイズが大きかったとしたらより効果的だったかもしれませんが当時の時点で自分たちのチーム事情や性質に合わせたやり方をもう少し検討しても良かったのかなと思います。

チームメンバー全員が CSM を取得しているチームって結構すごい説

これは良かったことだと思います。実際にこのことについて CSM, A-CSM 研修や RSGT などで社外の方とお話をする機会が結構あったのですがその時に結構驚かれることが多かったと記憶があります。

元々は未経験の少人数のメンバーが手探りで始めたこともあり基礎の習得を目的として CSM 研修の受講及び認定資格の取得を目指したものです。その後チームの拡大があっても継続して、現在のチームメンバーは全体で15名以上の規模ですがその全員が CSM を取得しています。これはどちらかというと会社としてそこまでの投資をできるということがすごいということであり有難いことであるということは理解しています。

スクラムチームにアサインする前段階でこうした知識習得を行うことでスクラムに対してのチームのベースアップを目的とした取り組みだったのですが、今後はそうした目的でのスクラムに対する学習やトレーニングについてはチーム内で SM が主導し行うようにしようと考えています。本来 SM に期待される役割そのものでもありますし、CSM 研修に関しても実際に業務を経験し具体的な目的意識や課題感を持った状態で受講してみるのも良いのではないかというフィードバックもチームからあがったためです。またチーム内に私以外の SM が爆誕したこともあり継続的な活動としてこうしたトレーニングについて考えられるようになったということもあります。

まとめ

これまで自分達の活動に関してこうした形でアウトプットしてこなかったのですが改めて考えも整理されますし再発見もあったりしました。
スクラムは検査と適応が重要だと言っています。それらを引き起こすようにフレームワークとして設計されていると思いますし私たちは日々スプリントを回しながら様々な検査と適応をしていますが、もう一段階俯瞰してみて自分たちにとってスクラムってなんだっけ、アジャイルってなんだっけということを振り返る（検査と適応する）のが大事なのかなとこれまでの経験を通じて感じています。

特に「自分たちにとってのアジャイル、スクラムとは何かをきちんと言語化して共有する」で感じたことはアジャイルが組織文化や哲学的なものであるというような話を体感して理解できたということでもあると思っています。組織文化のレベルまで昇華できていたらこういった悩みも自然と解消されるのではないかなと（アジャイル以前からそういったことはしていたわけですしできていたわけです）。逆にこういった課題感が表出してきたということはまだどこかで「うまくスクラムをやろうとしている」ということなのかなと自己分析したりしました。

基本的には備忘録というか過去の振り返りではあるので勢いで書いた部分もありますがこれがチームメンバーや将来の自分、たまたまこれを読んだ誰かに何らかの形で役に立てばいいなと思います。