はじめに

受託スクラムでPO/SM/DEVのチームを作るときに考えるポイントをまとめました。
有名なアジャイルコーチの意見
自分の体験談
今回はPO編

SMは誰がやるんか問題

アジャイルコーチの考え

以下はそのまま抜粋。

スクラムマスターはチーム全体を冷静に観察できる人、言いにくいことでも言える人、みんなの役にたつことが好きな人が向いています。
技術スキルはあるに越したことはないですが、常に絶対に必要とは限りません。
スクラムの実現に責任を負うのでスクラムについての知識は必要です。

個人的な解釈を含んだサマリ

自社の組織的課題を解決する必要性があるなら、自社の人間の方が解決が進む。
マネージャーが行う場合、以前の関係性を維持しがちになりやすく、「役割名が変わっただけ」になってしまう場合がある。
技術力がある人はSMをやるよりもDEVをやってもらった方が開発が進むケースは多い。

いずれもケースバイケースなので、「こうしろ」というものでは無いです。

おまけ

以下のようなものを参考に理解を深めるのもありだと思います。

もうちょっと体系立った定義が見たい場合

SMという役割で特徴的だと感じる部分や誤解が多いなと感じる部分

サーバントリーダーシップ

個人的にSMという役割で最も特徴的だと感じるのは「サーバントリーダーシップ」です。
これ本当に難しい。
「リーダーシップ」って名前に入ってるけどどちらかというと「コーチング」みたいな要素の方が大きいと思っています。

極論としてはSMは以下だと解釈しています。

チームの方針に対して決定権を持たない。（SMが判断した内容を理由にチームの方向性が決まってはいけない）
チームメンバーが決断できるように成長させることが責任。（成長してもらうために個人個人にちゃんと向き合う必要がある。）
チームがアプローチできない組織課題に対してアプローチする役割。（SMだけでやる必要はないけど、チームの成長が終わったら次は組織改善。）

ファシリテーション

スクラムイベントに慣れないうちは、イベントのファシリテーションをやったほうが、メンバーの理解も早いと思います。
メンバーが理解したらファシリテーションもメンバーに引き継ぐべきで、オブザーバーくらいのポジションに早めに移行すべきだと思っています。
難しい議論や揉め事などは、第三者的な立ち位置としてスクラムマスターがファシリテーションをやるケースもあるかもしれませんが、毎回やるのはチームの成長に悪影響だと思っています。

実際の例（自分の体験談）

専任スクラムマスター

各チームに専任スクラムマスターがいる形。

一番の理想系。顧客側からすると「開発しない人」に見えてしまうので、そこの説得が難しい。
反対してる顧客を説得できたことはない。
「あぁスクラムだよね、各チームに一人スクラムマスターが必要だね。」くらいの顧客の場合だけ実現できてる。

複数チーム兼任スクラムマスター

スクラムマスターが複数のチームを見ている状態。

多少の反対でも、「スクラムってそういうもんなんで」のゴリ押しでギリ通せる。
スクラム慣れてないメンバーが多い場合、すごく大変。スクラムマスター側としてはできればやめてほしい体制。

ある程度現場メンバーがスクラムに慣れてきたら複数チーム見るのはできなくはない。
とはいえ、その場合は組織課題にアプローチする余力を食い潰しているだけなので、なんとも言えない。

DEV兼任スクラムマスター

スクラムマスターが各チームに居るが、DEVの役割と兼任している状態。

チーム内のことに対して決定権を持つことになるので、スクラムマスターとして言ってるのか、DEVとして言っているのか分かりづらくなりやすい。
結果として、「各チームの開発リーダー」的な役割と認識されてしまいやすい。（旧来と大差ない感じ）

現場メンバーの成長を待てない時は、一時的にこの形式で走るのはありだと思ってる。
というか、受託開発だと成長を待てない状況が多い（顧客側が納得しない）。難しいね。

自社スクラムマスター

他社から派遣してもらったことはなくて、今のところ自社メンバーにやってもらうことしかない。（全員CSM研修を受講済み）
社内に適任がいない場合は、他社から派遣してもらうのは悪くない手だと思う。特に初めてのスクラムとかは外部から呼んだ方が良いと思う。

アジャイルコーチ/社外研修

流石にSMはスクラムのこと全く知らないとちょっときついので、そこは抑えておくべき。
CSMなどの資格取得を推奨します。

また、教科書的な知識を得たとしても、目の前の現実問題を解決するには応用力や経験値が必要になってきます。
応用力や経験値が足りない場合は、アジャイルコーチや外部のスクラムマスターを積極的に活用すべきだと思います。

従来の役割との違い（私見）

あくまで実体験ベースでの差異なので、他の現場から見た時と比べると間違ってる場合はあるかと思います。

開発リーダーとの比較

同じであって欲しいところ

メンバーの成長を支援する。

違い

SMはチームのやることに対して決定権がない。（その決定が本当にまずいならちゃんと意見は伝えてあげるべき）
SMはチームの代表者・代弁者ではない。（SMに意見を求める状況はおかしい）
SMはチームの成長によって役割が変わっていく。（最初はチームを支援するが、組織改善などに徐々に移っていく）

難しさ

チームの成長が顧客にとってメリットになりにくい。
- さまざまな事情で開発メンバーが同じ現場に居続けることは少ない（多くの場合新しい技術/スキルを身につけると転職しがち）
- 同じ会社なら居続けてもらうために待遇を上げるなどのアプローチがすぐにできるが、受発注関係だと難しい。（発注側が単価を上げても、本人の給料が変わらないケースは多い）
基本的に、顧客は「チームの成長を通してプロダクトを開発して欲しい」わけではなく「単にプロダクトを開発してほしい」という要求の方が強い
- 結果として、短期的な成果を求められやすく、開発リーダー的な動きを求められやすい。
- チームの成長の先のメリットを伝えたくても、前述の通り顧客のメリットにはなりにくいため、説得材料が少ない。

まとめ

常に「理想と現実の狭間」に悶え苦しみ続けるポジション

SMは役割としてスクラムの知識が求められるため、理想像を理解していることが多いです。
一方で、現実はそんな甘くはなくて、さまざまな組織的課題や業界構造の都合から発生する問題ばかりです。
そんな現実と折り合いをつけながら、「今の現場としての次の一歩」を常に考え続ける必要があります。

理想だけ声高に叫ぶスクラムマスターはぶっちゃけ邪魔です。
苦しんでるスクラムマスターだけが、役に立つスクラムマスターです。

アンチパターンは踏み抜くもの

PO編でも言いましたが、受託アジャイルをするのであればアンチパターンは必ず踏みます。なるべく避けるべきですが、踏まざる得ないものは、周りの理解を得た上で対策を立てた上で踏み抜いていきましょう。

地雷原の先にしか受託アジャイルの未来はないです。
後続の受託アジャイルが少しでもやりやすくなるように、地雷を踏み荒らしていくのだ！という気持ちで進みましょう。

いきなり理想的なアジャイルを目指すのではなく、「今よりちょっとスクラムに近い状況」を一つずつ実現していくのが良いと思います。
ステークホルダーが乗り気なら、ガッツリ進むのもありです。

次回予告

次はDEV編。やっぱりちょっと求められる性質は違うように感じてる。