nishida “とはいえ”シリーズは、スクラムに取り組む現場で起こる様々な「とはいえ」をピックアップし、それぞれどのようにアプローチしていけばいいのか、レッドジャーニーの経験豊富なアジャイルコーチがざっくばらんに語るシリーズです。
「スクラムガイドにはこう書いてあるし、ブログではこういう事例を見かけるんだけど、とはいえ…」と困ってしまったり、チームで対話しても道筋が見えてこない時、ここでのお話が何か一つでもヒントになれば幸いです。
第6回のテーマは「スクラムチーム」です。後編では、スクラムチーム内の役割と、うまくいかないときの対処法についてお話します。
前編はこちら
redjourney.jp
中村 洋 Yoh Nakamura
株式会社レッドジャーニー
CSP-SM(認定プロフェッショナルスクラムマスター)・CSPO(認定プロダクトオーナー)
様々な規模のSIerや事業会社でのアジャイル開発に取り組み、今に至る。現在まで主に事業会社を中心に40の組織、80のチームの支援をしてきた。「ええと思うなら、やったらよろしいやん」を口癖に、チームや組織が自分たちで”今よりいい感じになっていく”ように支援している。
※発表資料 「いい感じのチーム」へのジャーニー、チームの状況に合ったいろいろなタイプのスクラムマスターの見つけ方、アジャイルコーチが見てきた組織の壁とその越え方、など多数。
新井 剛 Takeshi Arai
株式会社レッドジャーニー 取締役COO
CSP(認定スクラムプロフェッショナル)、CSM(認定スクラムマスター)、CSPO(認定プロダクトオーナー)
プログラマー、プロダクトマネージャー、プロジェクトマネージャー、アプリケーション開発、ミドルエンジン開発、エンジニアリング部門長など様々な現場を経て、全社組織のカイゼンやエバンジェリストとして活躍。現在はDX支援、アジャイル推進支援、CoE支援、アジャイルコーチ、カイゼンファシリテーター、ワークショップ等で組織開発に従事。勉強会コミュニティ運営、イベント講演も多数あり。
Codezine Academy ScrumBootCamp Premium、機能するチームを作るためのカイゼン・ジャーニー、今からはじめるDX時代のアジャイル超入門 講師
著書「カイゼン・ジャーニー」、「ここはウォーターフォール市、アジャイル町」、「いちばんやさしいアジャイル開発の教本」、「WEB+DB PRESS Vol.111 見える化大作戦特集」
スクラムは、複雑なプロダクトを開発・提供・保守するためのフレームワークです。1990年代初頭、Ken Schwaber と Jeff Sutherland によって開発されました。
スクラムに取り組む際の拠り所となるのが、スクラムの定義やルールを示した「スクラムガイド」です。2010年に最初のバージョンが発表され、その後アップデートが加えられながら進化し続けています。
全18ページ（2020年版）という小さなガイドですが、目的や理論から実践まで分かりやすくまとめられており、スクラムの本質が理解できるようになっています。
「スクラムチーム」について、スクラムガイドにはこのように解説されています。
スクラムの基本単位は、スクラムチームという小さなチームである。スクラムチームは、スクラムマスター1人、プロダクトオーナー1人、複数人の開発者で構成される。スクラムチーム内には、サブチームや階層は存在しない。これは、一度にひとつの目的（プロダクトゴール）に集中している専門家が集まった単位である。
スクラムチームは機能横断型で、各スプリントで価値を生み出すために必要なすべてのスキルを備えている。また、自己管理型であり、誰が何を、いつ、どのように行うかをスクラムチーム内で決定する。
スクラムチームは、敏捷性を維持するための十分な小ささと、スプリント内で重要な作業を完了するための十分な大きさがあり、通常は10人以下である。一般的に小さなチームのほうがコミュニケーションがうまく、生産性が高いことがわかっている。スクラムチームが大きくなりすぎる場合は、同じプロダクトに専念した、複数のまとまりのあるスクラムチームに再編成することを検討する必要がある。したがって、同じプロダクトゴール、プロダクトバックログ、およびプロダクトオーナーを共有する必要がある。
スクラムチームは、ステークホルダーとのコラボレーション、検証、保守、運用、実験、研究開発など、プロダクトに関して必要となり得るすべての活動に責任を持つ。スクラムチームは、自分たちで作業を管理できるように組織によって構成され、その権限が与えられている。持続可能なペースでスプリントの作業を行うことにより、スクラムチームの集中と一貫性が向上する。
スクラムチーム全体が、スプリントごとに価値のある有用なインクリメントを作成する責任を持つ。スクラムはスクラムチームにおいて、開発者、プロダクトオーナー、スクラムマスターという3つの明確な責任を定義する。
出典：スクラムガイド
…とはいえ、実際の現場ではガイド通りには進みませんし、そもそも書かれていないような事態も多々起こります。そうした「とはいえ」に、どのようにアプローチしていけば良いでしょうか。
スプリントごとに価値のある有用なインクリメントを作成できる？
中村：
これができない理由としては、大体二つのパターンがある気がします。
一つは、スプリント初期のお互いがどんなスキルを持っているか分かっていない段階で、先が読めないというパターンです。どうコラボレーションしたらいいか分からないし、プロダクトバックログも落ち着いていなくて、どれくらいの大きさのチームになりそうかも分からない。
もう一つは、インクリメントを作成するための機能横断的なスキルがチームに備わっていないパターン。チーム外と連携しないといけないときですよね。
新井：
プロダクトオーナーが、プロダクトバックログをどれくらいの解像度をもって作れるかっていうところが、一因と言えるかもしれませんね。
中村：
プロダクトバックログに対して開発者たちがレディであるかどうかを、プロダクトオーナーがちゃんと判断できることが大事ですね。
開発者側が、スプリントでインクリメントに変換できる自信がないのに「できます」と忖度してしまったりすると、結果としてプロダクトオーナーも困ることになります。
新井：
忖度しちゃうっていうのは、どうして起こるんでしょうね。
中村：
「とはいえ、やらなくてはいけない」っていう状況があるんじゃないでしょうか。
プロダクトオーナーと開発者が、お互いの専門性を尊敬し合った上で「それは当たらないと思うよ」 「こっちの方がいいと思う」 「ちゃんとしよう」っていう風に、フラットに議論ができる関係を作らないと難しいですよね。
新井：
1週間スプリントで4日目くらいに無理だと言うよりは、スプリントプランニングの段階で無理なものは無理と明確に表明できるといいですね。
中村：
「やっぱり無理でした」なんて後から言われると、いつから無理だと思ってたんだろう？ と勘繰っちゃいますよね（笑）。
気づいた時点で言う方が、お互いにとっていいはずです。
開発者とプロダクトオーナーも、スクラムチームとステークホルダーも、誠実なコミュニケーションが大事です。
新井：
プランニングの時点で、レディじゃないのに無理をするっていうのは危険信号です。結局はお客様に何も価値が届かないという不利益・不都合も生じます。
Message from coaches
- プロダクトバックログに対して開発者たちがレディであるかどうかを、プロダクトオーナーがちゃんと判断できることが大事。
- 開発者は忖度せず、プランニング時点で無理なものは無理と明確に表明しよう。
- プロダクトオーナーと開発者、スクラムチームとステークホルダーが、お互いの専門性を尊敬し合った上でフラットに議論ができる関係性を作ることが大事。
- 誠実なコミュニケーションが取れる関係性を築こう。
人事異動で人の出入りが多すぎて、優秀な人材から抜けていき、自己管理型のチームになかなかなれない
中村：
これはつらいな…。
人が入れ替わること自体は防げないと思うんです。自分たちだけの話ではなくて、組織的な事情もありますから。
結局は、人が抜けても大丈夫なような体制を、ペアプロやモブプロで作っておくとか、抜けたあとにチームが変化に対応するだけの時間的余裕を持つことが大事かな。
新井：
変化に適応するための時間があるチームは、人の出入りによるインパクトがあったとしても、それを吸収できますよね。
並走期間がないと、チームはレジリエンス（柔軟性、しなやかさ）を失い、悪い方へ転がっていきます。
中村：
これは先日アジャイルコーチ同士で話したアイディアなんですが、人が抜けると分かったら、できるだけ早い段階でその人抜きのスプリントを回してみればいいんじゃないでしょうか。
その人が担っていた意外な役割や、その人が欠けることでチームに不足するスキルなんかが見えてきますから、抜ける前にペアプロやモブプロでスキルトランスファーしたり、必要ならドキュメントを書いてもらったり、手立てが取れます。
新井：
カバーできるうちに一旦やってみるのはいいですね。
中村：
ただ、人事異動の情報が直前まで出せない組織だと難しいですよね。
本人も決められた時期にならないと言えないということがありますし、チームはすごく困ると思います。
新井：
チーム内のインパクトを最小限に抑えたいという経営側の思惑と、現場側の求めるものが相反することってありますね。
私も経験があるので、経営側の思惑は分かります。モチベーションやパフォーマンスに影響するんじゃないかとか、いろんなことを経営側は考えるんですけど、「こちらを立てればあちらが立たず」になりがちです。
着地点としては、現場の混乱や業務が滞るのは避けたいというのはお互いの共通点だと思うので、杓子定規に会社の規定通り片付けるのではなく、人や状況に合わせて並行期間を考えられるといいですね。
中村：
経営側が従業員をプロフェッショナルとして信頼できるといいんだと思います。人事異動の情報を早めに伝えることで、それに対応するような動きを取ってくれるはずだと信じてほしいです。
Message from coaches
- 人の入れ替わり自体は防げない。人が抜けても大丈夫なように体制を作っておくことや、抜けたあとにチームが変化に対応できるだけの時間的余裕を持つことが大事。
- 人が抜けると分かったら、できるだけ早く、カバーできるうちにその人抜きのスプリントを回してみよう。
- 現場の混乱や業務が滞るのを避けたいのは、経営も現場も同じ。杓子定規にならず人や状況に合わせて並行期間を取れるのが理想。