転職会議事業部でITエンジニアをしている@ishitan-livです。
早くも2024年が半年過ぎようとしていますね。
会社によっては上半期評価の時期だったりするので、何故かブログが乱立してるような気がしますがきっと気の所為ですね。
というわけで、前回はスクラムマスター研修で得た知見について書きましたが、今回は多くのチームが抱えていそうな問題を改善するためのヒントになればと思い、考えを共有します。
この記事にかかれていること3行まとめ
- 人数多めなチームはスクラム運営が大変で、問題がたくさん出てきて全て解決は出来なかったよ
- スクラムマスター研修を受講したことでこれらの問題点に対する解決案をもらったよ
- 現在はうまく回っているよ
あくまで「転職会議におけるスクラムイベントを取り入れたチーム運営の考え方」として捉えていただけると助かります。 それを頭の片隅に入れてこんなやり方もあるんだなぁ〜と気楽に読んでいただければ。
現在のチームの問題点
スクラムに関わる人数が多すぎた
前提として昨年度時点でのチーム編成
昨年度までの私が所属していたチーム編成は以下のようになっていました。
PO(プロダクトオーナー)1名、PdM(プロダクトマネージャー)3名、SM(スクラムマスター)1名、エンジニア4名(私含めて)、ステークホルダー複数名。
この人数の多さがデメリットとなっていました。
コミュニケーションコストが大幅に増えた
- 見解・意思統一(意見の収束)に時間がかかる
- 何か突発で決めたい要件が出た際に、メンバーの予定を抑えるのに時間がかかる
- 議論中に複数名に意見を求めるとイベント時間が足りなくなりがち
異なる性質のプロダクト領域を複数名が担当していた
全員が1つのプロダクトゴールに向かえていなかった
転職会議ではPdMごとに関わっているプロダクト、持っている目標などが全く異なっており、対応するプロダクト領域が多岐にわたっていました。 しかし、チームの意思を統一しきれないまま進んでしまい、結果として開発者含めて全員が同じプロダクトゴールへ向かうことが出来ずに危ういバランスで活動がされていました。
実際にとある月までにリリース予定だったものが数ヶ月遅れてしまった経緯もあります。 この時はどの価値を最優先で届けるかを明確にし、約2ヶ月はそこに注力するようにした背景もあります。それくらいチームのプロダクトゴールは大事です。
以下はスクラムガイドよりプロダクトゴールについての記載です。 2020年版から追加された新規項目です。
ひとつのチームがひとつのプロダクトに集中する これはチーム内で分断が発⽣し、PO と開発チームの関係が「プロキシ」や「我々と彼ら」とい った問題につながることを排除するためである。存在するのは、PO、SM、開発者の3つの異なる責任を持ち、同じ⽬的を共有するひとつの「スクラムチーム」だけである。
[スクラムガイド2020] スクラムチームより抜粋
今までのチームはアンチパターンでしたね。 やりたいことが多くあること自体は良いのですが、ゴールが明確になっていないために「私の順番がないがしろにされている」と感じるメンバーもいたように感じます。 PO、開発者ともに何が最優先で何を目指すのか曖昧のまま進めてしまったことは反省点でした。
適切なスプリントゴールを決められていなかった
スクラムでは1スプリントに対して1ゴールであるべきです。 その点で、複数のゴールが設定されてしまった時点で破綻していたと言えます。
- 施策数(PBI)が多く、スプリントに対して詰め込みすぎた
- リファインメントしきれなかった分を追加で別ミーティングするので開発時間が取れない
- POが施策の優先度をつけにくい
更に開発者側のコストとして以下のような問題があがっていました。
- 全く領域の異なる開発要件が多く、開発者の対応範囲が広すぎる
- 開発者が複数施策を行き来するので思考のスイッチングコストがかかる
PBIを詰め込みすぎた
差し込み対応が入るたびにスプリントゴールがずれていった
toB向けの案件の場合は期限付きが多いです。（主にパートナー企業側の都合で） また、差し込みタスクも頻繁にあったため、スクラムで決めたスプリントゴールと相性が良くなかったように思えます。
よくあるのが、◯◯の仕様について教えて欲しいとか、◯◯ってどうなってる？とか調査依頼がよくきます。また、調査結果後に連携企業からの要望で期限付きで差し込み対応が入ったりもします。
全てのシステムについて把握してるわけではないので、当然頭を切り替えて調査の時間が必要になるので開発のリズムが崩れます。
プロダクトに直接紐づかない大事な課題に取り組めなかった
- メインの施策以外に技術的なチャレンジが出来なかった
- 技術的負債改善をする時間が取れなかった
エンジニアとしてはメインのプロダクト開発・改善以外にも、技術的負債の改善や新しい技術の投入などを考えていきたいところですが、スプリントに詰め込まれたPBIがパンパンで、かつ、差し込み対応もある状況ですと物理的な時間として課題に取り込む時間は取れない状況が続きました。
その結果、追加開発や改善がしにくいプロダクトが生まれている状況でした。
スクラムマスター研修で講師からもらった解決案
これだけの問題点が、昨年度のレトロスペクティブではあがりました。この問題点をチーム全員が認識できたのはとてもよかったのですが、具体的な解決策が打ち出せていませんでした。
ちょうど、スクラムマスター研修への参加の話をいただき受講したところ、解決策のヒントが得られました。
スクラムに関わる人数が多すぎた件について
ではどうすればよかったのか？ あくまで理想論になりますが、スクラムマスター研修では以下のように講師の方からアドバイスを受けています。 スクラムガイドにも似たことが書かれておりますし、一部は実際に改善に向けて動いていることにもなります。
解決案：まずは10人以下にチームをわけることを考える
スクラムチームは、敏捷性を維持するための⼗分な⼩ささと、スプリント内で重要な作業を完 了するための⼗分な⼤きさがあり、通常は 10 ⼈以下である。⼀般的に⼩さなチームのほうがコミュニケーションがうまく、⽣産性が⾼いことがわかっている。スクラムチームが⼤きくなり すぎる場合は、同じプロダクトに専念した、複数のまとまりのあるスクラムチームに再編成す ることを検討する必要がある。したがって、同じプロダクトゴール、プロダクトバックログ、 およびプロダクトオーナーを共有する必要がある。 [スクラムガイド2020] スクラムチームより抜粋
たまたま複数のPdMがいる場合はチームをわけるか、そのままでいくならプロダクトの最終目標として、提供する価値観意識を統一する。開発の担当領域もこの時点で精査します。これにより、「施策として異なる性質のプロダクト領域が混ざっていることについて」の問題点も同時に解消されます。
※ちなみに前提で紹介した今年からの新チームは、人数と開発担当領域を絞ったことで開発しやすい状態となっております。
異なる性質のプロダクト領域を複数名が担当していた件について
前提として複数のPdMが同一チームにいること自体は全く問題ないです。 あくまで顧客への価値提供をするために、どのように達成するのかへの合意形成が大事という話。
以下はスクラムガイドより引用。
プロダクトゴールは、プロダクトの将来の状態を表している。それがスクラムチームの計画の ターゲットになる。プロダクトゴールはプロダクトバックログに含まれる。プロダクトバック ログの残りの部分は、プロダクトゴールを達成する「何か（what）」を定義するものである。 プロダクトとは価値を提供する⼿段である。プロダクトは、明確な境界、既知のステーク ホルダー、明確に定義されたユーザーや顧客を持っている。プロダクトは、サービスや物 理的な製品である場合もあれば、より抽象的なものの場合もある。 プロダクトゴールは、スクラムチームの⻑期的な⽬標である。次の⽬標に移る前に、スクラム チームはひとつの⽬標を達成（または放棄）しなければならない。
[スクラムガイド2020] 確約（コミットメント）：プロダクトゴールより抜粋
解決案：全員の目指す方向性と認識をすり合わせ統一させる
これもスクラムガイド引用どおりですが、プロダクトバックログの最終的な優先度決めはPO判断となります。ただ、今回のケースでは判断材料として何を基準にするのかという点が難しいかと思います。 各々の担当領域が異なるPdMがあげてくる施策の価値が異なるため、チームとしてどこを優先していくのか認識を揃えておく必要があるというだけのことです。
スクラムはコミュニケーションツールであるといわれているのは的を射ていますね。 この認識のすりあわせにより、優先度が落とされたと考えて落ち込んだり、自分が蔑ろにされたと憤ることもないかと思います。
PBIを詰め込みすぎていた件について
では、よくある急に差し込んでやって欲しいタスクが割り込んできたらどうするのか？また期限が元々決まっているPBIをどうするのかについてですが以下となります。
プロダクトゴールを達成するために必要なすべての作業は、スプリント内で行われる。 スプリントでは、 l スプリントゴールの達成を危険にさらすような変更はしない。 スプリントによって、プロダクトゴールに対する進捗の検査と適応が少なくとも 1 か⽉ごとに 確実になり、予測可能性が⾼まる。
[スクラムガイド2020] スプリントより抜粋
解決案1：そもそもスクラムについての認識がずれているので揃える
「スクラムにおいて急ぎのタスクというのはない。あくまで価値とそれに伴う開発の順序があるだけ」
という認識を揃えないことにはスクラムをもちいたアジャイル開発の意味がないです。
その場合、どのように対応するのか講師の方に聞いたことをあげてみます。
スクラムチームと納期とベロシティの関係
「スクラムにおいて急ぎのタスクというのはない。あくまで価値とそれに伴う開発の順序があるだけ」
再度書きました。大事なことなので。
とはいっても、現実問題としてビジネスサイドから要望はあがってくるし、会社の経営層からは売上あげろと言われて詰められる…そんな世知辛いことも多いでしょう。 ではスクラムチームで出来ることはなんだろうと考えると、以下が落としどころなのかなと考えています。
解決案2：納期前提としてそれに合うように開発すべきではない
もう動き出してしまったプロジェクトはしょうがないのですが、今後のケースについてです。
- 取引先との納期期限がビジネスサイドから決まった状態で来る場合、それは契約を進める時点で交渉するべきです
- ◯◯日までにXXの機能なら提供出来ますといった交渉をしましょう
- つまり、なんでも0,1で受けてこないようにします
- 期限を決める段階では、開発者やPOがこの時点で関わっていないとまずいです
開発するプロダクトが自社のみでなく、他社と連携したり納品する場合は一気に完成品を提出する約束をするのではなく、あくまで全体像を把握したうえで、小分けのリリース、もしくは価値の提供を交渉するようにします。 これはスクラムマスターの仕事というより、POやビジネスサイドの仕事の範疇ですが、具体的な機能面についてはエンジニアでないと見積もりは出来ないので提案材料の手助けはしたいところです。
解決案3：スプリントでの不確定要素をあらかじめ積んでおく
でも今回のスプリントではどこまで対応出来そうですか？って聞かれますよね。 その場合、スクラム期間内に完了できる作業量をストーリーポイントで考えて、最終的なベロシティを算出すると思いますが、そこでひと手間いれます。
例えば、私の場合は差し込みタスクとして事業部に対するIT統制の仕事があります。 これは依頼内容によりますが、おおよそ2日〜3日はかかるタスクなので、2週間スプリントでみると20％ほど使うコストになります。 依頼がくる時期がわかっているのであれば、その個人タスクになりそうなものをPBI化して、スクラムチーム全員が把握出来る状態にし、スプリントバックログに入れておきます。
優先度については基本的には ”POが並び替えたPBI > 個人PBI” ですが、スプリント内に達成すれば良いだけなのでタスクとして視覚化されスプリントに乗っていることが大事です。
ベロシティによるスプリント達成度を決めた後に、依頼があったからと急遽追加で別のタスクなんて対応する時間が取れないのですから、あらかじめ積んでおくことが大事です。
結果として依頼がなければ、プロダクトバックログから新しいPBIを取っていけばよいだけですしね。
解決案4：投資の重要性を説明し、スプリントにあらかじめ積む
上記の不確定要素を積んでおくに近いですが、ちょっと注意が必要です。 何故なら、プロダクトの未来に対しておこなうものとなり、主語がエンジニアからの意見になりがちで、ビジネスサイドやPdMなどには理解してもらえないケースが多いからです。 相互理解のために必ず背景を説明し、自分たちの組織課題として認識してもらう必要があります。
幸いなことに転職会議では、エンジニアチームのGLが他職種のリーダーや、事業部全体にこの投資の重要性を説明してくださっているので、今年からは毎スプリントごとに積む努力をするようになりました。 まずはこの根回しと理解から始まり、その上でスプリントに施策とは別のPBIを20％程度積むようにしています。
参考までにちょうど私の上司が書いた記事を載せておきます。
ちなみにこう書くと、なんでもかんでも毎回スプリントに載せるべきでは？と考えがちですが、そこもまた注意が必要で、あくまでチームのプロダクトバックログの優先度決定権をもつのはPOです。 毎回スプリントに必ず乗せる義務はないので、そこは勘違いしないようにしていきたいです。
※余談
空いた時間で好きに色々吸収していくのが開発者なので、タスクを積みすぎずそういった時間を用意するのはスクラムマスター研修で参加していた他の会社事例でも有効だったという結果をもらっています。
小規模なチームになってどうなったのか
現在のチーム編成
なお、現在の転職会議では大きく分けて3チームに分かれてプロダクト開発をしております。
- Aチーム（toC向けの既存メインプロダクト開発・施策）
- Bチーム（toB/toC向けの新規プロダクト開発・施策）
- Cチーム（toB向けの求人/応募送客などの連携開発・施策）
今年から私がスクラムマスターをしているのはCチームです。
PO1名、PdM1名(+補助1名)、SM1名(私)、エンジニア2名(私含めて)、ステークホルダー複数名といったチーム構成です。
チームとしては少し小規模ですがスクラムをする上では程よいメンバー人数です。 レトロスペクティブにて、チームメンバーからも以前に比べて気軽に相談しやすい、意思決定しやすいと良いフィードバックをいただいております。
また開発者側の担当プロダクト領域もかなり絞られて、集中して開発できる状態となっております。差し込みは多いチームではありますが、それを想定してのスプリントプランニングとゴールを決めています。
今回は主に大きくなりすぎたチーム編成の問題点とその解決案や、プロダクトバックログ、スプリントバックログへのPBIの積み方などについて言及してみました。 本当はスクラムイベントについても勘違いしやすい、やってしまいがちな行動を書く予定でしたが長くなるのでまた次回にしたいと思います。
スクラムイベントをもちいたチーム運営は組織によって合う合わないが明確に出ますので、独りよがりではなく、みんなが納得して気持ちよくチームに所属し、施策提案や開発出来るようにコミュニケーションをとっていきたいですね。
では！
