CSMトレーニングを受けて、atama plusの開発やスクラムマスターについて改めて考えた話
こんにちは。atama plusでスクラムマスターをしている松村です。
今年の2月に、Scrum AllianceのCertified Scrum Master（通称CSM）のトレーニングを受けました。
受講後に社内のスクラムマスターにCSMの学びをシェアし、atama plusの開発やスクラムマスターの役割について再考しましたので、今回はその内容をまとめます。
Certified Scrum Masterとは？
Scrum Allianceが提供するスクラムマスター向けのトレーニングであり、受講後は「認定スクラムマスター」という資格を取得することができます。ちなみに、Scrum.orgやScrum Incも資格認定トレーニングを提供しています。
今回私が本トレーニングに参加した理由は、atama plusでスクラムマスターとして1年近く活動し、ある程度業務に慣れてきたので、スクラムマスターとしての役割やスクラムの考え方について一度整理したいと考えたためです。
研修は、平日5日間の13:00-19:00にオンラインで開催されました。講師は、スクラムトレーナーとして有名なえばっきーこと江端一将さん、受講者は私を含め32人でした。
社内の自分以外のスクラムマスターは、すでにCSMを受講済みではありましたが、トレーニング内容の整理や、特に印象に残ったことを共有することで、スクラムマスター間での理解を深めました。
今回は、その際に共有した内容を、テーマ毎に紹介したいと思います。
スクラムは「現状可視化のフレームワーク」
一般的にスクラムというと「=アジャイル(開発)」「既定の打ち合わせ集や開発プラクティス集」「導入すれば開発が速くなるもの」といったイメージを持たれることが多いと思います。
しかし本来スクラムとは、「チームの開発活動や能力の現状を可視化するためのフレームワーク」です。受講したトレーニングの中では、以下のような説明がされていました。
「適応によって目的と現状のギャップが埋まらないのはプレイヤーの能力。
それもスクラムであり、つまりスクラムは改善を保証するものではない。」
atama plusでも、スクラムはあくまで現状可視化のフレームワークであり、スクラム自体に改善や最高のプラクティスを求めるのは誤りだ、と考えています。
可視化された課題に対してプラクティスの導入等をチームで行うのが正しいスクラムの使い方ですが、日々の活動を続けていると、「スクラムだからxxx（プラクティス）をやらないといけない」と、スクラムとプラクティスを混同し、時にプラクティスを行うことが目的化してしまうことがあります。
活動の基底としているスクラムはあくまで「活動や状態の可視化」を目的にしているということを念頭に、チームの状態や課題に応じてプラクティスは臨機応変に適応する必要があると、改めて認識を揃えました。
スクラムでの中長期の開発計画の立て方
スクラムないしアジャイルは、「計画を立てず、都度決める」「長期のプロジェクトに不向き」と捉えられることがありますが、実際には異なります。
チームの活動がある程度予測できることが前提となりますが、数ヶ月かかる開発計画を立てることや事業戦略上必要なリリース日を設定することがスクラムでも可能です。具体的には、スプリント毎にリスクの高いものから開発し、検証した結果を元に、残りの開発順やそもそも本当に開発すべきかをスプリント毎に再計画・再検討します。
トレーニングでも、スクラムでの中長期の計画の立て方について解説がありました。プロジェクト的に期限やスコープがおよそ定められているものに対しての計画の立て方についての解説がされていて、特に「スクラムは計画に対して厳格」という点が強調されていたのが印象深かったです。
atama plusでは創業以来スクラムでの開発を行ってきていますが、「いまってウォーターフォールっぽくなってない？」と話があがることや、スプリント毎の再計画がうまく行われないこともあります。スクラムマスターとして、再計画を促すようにチームに提言をしたり、普段から「変化を伴わないウォータフォールチックな開発」のデメリットについて正しく理解し、チームに浸透させる必要性を、スクラムマスター同士で再認識しました。
完成の定義を拡張することは不可能...？
完成の定義とは、プロダクトの品質基準を満たすインクリメントの状態を⽰した正式な記述
トレーニング受講前は、インクリメントの完成の基準を示す「完成の定義」は、チームの守備範囲を広げ、リリースを早めることを目的に拡張していくという考え方が一般的だと捉えていました。
トレーニングの中でも「完成の定義の取り扱い」について触れられていましたので、私自身うまく理解できたか不安ですがその内容を書いてみます。
私の理解では、「”完成の定義”として設定されず、一度でもundoneとして取り扱った項目は、すでにundoneとしてプロダクトに入り込んでいるため、それ以降も”完成の定義”として設定することはできない」、つまり「完成の定義を拡大していくことは不可能」と説明されていました。
これまで、完成の定義の拡大を目指すことが当然と考えていたため、この内容を聞いたときは、価値観をひっくり返されたような気持ちとなり非常に驚きました。
それでは、これまでの考え方と何が異なるのでしょう。トレーニング受講後も疑問として私の中に残ったため、トレーニング後に再考し、atama plus社内のスクラムマスター間で議論しながら以下の整理をしました。
(1) 改めてスクラムガイドを読んでみると、「完成の定義」とはプロダクトの品質基準を示すものである。
(2) プロダクト品質基準を満たせた状態であれば、スプリント外で担保していたundoneをdoneにしていくことは可能。
ただし、講師の見解としては、スプリント内で完了できず負債を溜め込んだ時点で、その後Undoneワークを行っても解消を証明できないため、プロダクト品質基準となり得ない。そのため、最初のDone項目のみがプロダクト品質基準になるといった説明でした。
※一方、Scrum Allianceウェブページの記載ではリリース基準からスプリント基準に拡大するのは可能とのこと。
The DoD changes over time. Organizational support and the team’s ability to remove impediments may enable the inclusion of additional activities into the DoD for features or sprints.
(3) 実施すべき項目として最初から考慮できていない項目は、プロダクト内にUndoneとして入り込んでいるため、完成の定義に入れることはできない。
もしそのような新規で毎スプリント取り組みたい項目ができた場合、完成の定義とは別の概念（あくまでそのプロダクトバックログアイテム単位での品質基準）として設定する必要がある。
その上で、自分達が取りうる選択肢をまとめると
「チームの能力を高め、Deliverのスパンを短くするために、これまでUndoneワークとして品質を担保できているものをDoneに移行していくことは推奨する」
一方で、「完成の定義の項目を増やしてもプロダクト内にはその基準について担保できていない部分が存在するため、プロダクト品質とはなり得ない」ということを理解し、「理想的には開発の最初期からそのような部分プロダクトに取り込まないよう、担保したい項目に注意を払うべき」という整理になりました。
中央集権型組織の中のスクラムチーム
atama plusの状況とは異なるため、普段の開発に活かせるテーマではなかったですが、中央集権型組織におけるスクラムチームの活動についての話も興味深かったので紹介します。
ここでいう中央集権型組織とは、トップダウンの命令や指示・管理が強い組織のことを指します。また、対象的な組織として「チーム中心型組織」が存在し、自律的に活動する組織を指します。
スクラムはチーム中心型組織であるものの、そのチームが所属する会社自体は中央集権型組織である可能性があります。その場合、会社の管理下にスクラムチームが置かれ、会社由来のプロセスに対応するため、リリースに時間を要するケースが発生します。
例えば、ある会社のリリースにて、会社が定める審査基準と、月次の審査会を突破しなければならないケースを考えます。この場合、スクラムチームはスプリント毎にリリース準備ができているものの、月次の審査会がボトルネックとなり、高い頻度でのリリースをできなくなります。
こういった場合には、「審査基準を満たす完成の定義を設定し、完成の基準を守ればチームがリリースを判断できる」ように、組織に対してスクラムマスターが働きかける必要があるとトレーニングでは説明されていました。
中央集権型組織では、会社側の基準に合わせて活動することが多いようにも見えますが、スクラムでの定義をうまく活用することで、組織全体とすり合わせを図るというのは、チーム中心型組織のメリットを取り崩さずに組織と向き合うための良い手段であり、それを成功させられるかはスクラムマスターの腕の見せどころだなと感じました。
スクラムマスターの責任範囲
スクラムマスターは名前がそれっぽいので「スクラムの全責任を負う」と捉えられてしまうことがありますが、スクラムの定義上、どの責任もスクラムマスターが1番の責任者となることはありません。
トレーニングの中でも「スクラムマスターはどの場面でも2,3番目に責任を負う。1番目になることはない。」と説明がありました。それに対して参加者からは「開発者やデザイナーと平等に思われないのでは？」といった質問があがり、講師からは「それでも、スクラムマスターは価値を出し認められていくしかない」といった回答がされていました。
スクラムマスターが1番に責任を負うことはない、という内容は知識として知ってはいたのですが、改めてトレーニングを受けた後に考えてみました。
中長期的な価値の責任を負うのがスクラムマスターの役割ですが、組織の力学を考えると、「平等に思われるために何か価値を出さないと」という焦りが発生するのではと考えています。
スクラムマスターという役割の定義上、中長期といったロングスパンで物事を捉えられ、周囲や組織の期待値調整を行った上で、地道に価値をだすことが必要ですので、その役割を全うするのは難しいことだと改めて感じました。
atama plusでのスクラムマスターとは...？
atama plusでは以前より「チームの成果の最大化」を担う役割としてスクラムマスターを設置しています。
スクラムのフレームワークによる開発はしているものの、事業のフェーズを考慮すると、どのタイミングでチームの能力を最大化したらよいか考えるのはとても難しいです。
例えば、チームを3年後に最高のチームに仕上げるために、「スキル習得に大きな時間を取り、開発すべきものを開発しない」という選択肢をいまのatama plusは取れないと思っています。
（もちろんこれは極論で、スキルを伸ばしながら開発することも当然できると考えています。個人的には、短期的な成果にフォーカスして、チームの成長を促さないという選択肢は取りたくないと考えています）
トレーニングにて「スクラムは疲れるし、超イケてる世界的なスクラム先進企業でも、スクラムを使ったり使わなかったりしている」という事例を聞いて、非常に納得しました。（今回これを聞けただけでもトレーニングに参加してよかったと思えます。）
atama plusもスクラムマスターという名前で職種を置いていますが、実際にはスクラムをやっている状態とそうでない状態が時期により異なると捉えています。そこの難しさに直面することがこれまで多かったので、今回のトレーニングであくまでスクラムは1つの選択肢であり、その上でスクラムを選ぶ意義について、理解することができました。
ちなみに、atata plusのスクラムマスターは以下のような形で定義を行い、開発チームや会社全体との期待値調整を行っています。
最後に
CSMのトレーニングはそれ単体でも非常に学びが多く、またスクラムマスターとして1年近く活動した上で参加したことにより、より良い学びを得たような気がしています。
普段考えている「チームや開発活動、会社のフェーズ、atama plusのスクラムマスターの活動目的」について整理する良い機会となり、さらに社内のスクラムマスターと議論をすることで、改めて自分たちの活動目的についてすり合わせを行うこともできました。
We are Hiring
atama plusはチームで働くことやチーム活動を改善することに重きを置いている会社です。スクラムで働くことに興味がある方だけでなく、チームで開発して、良いプロダクトを作りたいという気持ちのある方と一緒に働きたいと考えています！
スクラムマスターもエンジニアもQAもデザイナーもプロダクトオーナーも他職種も積極的に募集しておりますので、是非興味を持っていただけると嬉しいです！