あなたの会社のスクラムマスターは、実のところ何を見ているのか
Ubie Discovery でスクラムマスターをしているはたけです。
普段は主にグローバルチームのUI/UXデザインを担当しているのですが、デザイナーとしての帽子と以外にもう一つ、スクラムマスターとしての帽子をかぶる場面も多いです。実際に現職での直近3年間で、かれこれ10チームほど様々なスクラムチームの支援やスクラムの実践を重ねてきました。
スクラムマスターとスクラムセレモニーマスター
あなたは「スクラムマスター」と聞いてまず何を想起するでしょうか？
スクラムマスターは、「スクラムガイドで定義されたスクラムが適切な形で実践されるよう支援すること」を主たる責務としています。
なので練度の高いチーム/組織においてもはやスクラムマスターは不要ですし、「だめなスクラムマスターであれば、いないほうがいい」とまで言われるゆえんもそこにあります。
もしあなたが「スクラムセレモニーの予定を調整してくれる人、Jira をいいかんじにしてくれる人だな」くらいに捉えているのであれば、おそらくあなたのチームのスクラムマスターは十分な役割を果たしていません。
それはただの「スクラムセレモニーマスター」かもしれません。
いいプロダクトはいいチームからしか生まれない。では、どうやって？
Ubie Discovery はここ3年で1桁台から100人を超えるまで社員が増えました。
医療機関向け事業であるAI問診ユビーは病院向けからはじまりクリニック向けもはじまり、生活者向け事業であるAI受診相談ユビーは昨年のリリースから1年で200万MAUを超え、医療アクセスを支える社会インフラとなりつつあります。
それぞれの体験はつながりはじめ、事業の複雑度は加速しています。
いうならば数ヶ月前まで自転車を漕いでいたはずなのに、今は自転車から自動車に跳び乗る思いの加速度です。
全社OKRも1ヶ月で書き換わり、それに伴って今日とあるチームにいたメンバーが明日は違うチームで活動する、というのが当たり前の環境です。
そのような状況下、素早く目的に向かって走り出すことのできる、走り続けることのできるチームを組成できることは、もはや必須といっても過言ではありません。
いいプロダクトはいいチームからしか生まれない。
では、そのようなチームはどうやったらつくれるのか？
それも再現性をもって。
スクラムマスターは、開発チーム/PO/組織を支援する
スクラムガイドのたった18ページ (日本語版。2020年) の中には、スクラムマスターが支援する対象は「開発チーム」「プロダクトオーナー（以下、PO）」「組織」の3つであると明記されています。
これは数年に一度の改訂を経てもなお変わらない基本的な役割です。
では、Ubie Discovery の場合はどうでしょうか？
「開発チーム」はエンジニアはもちろん、医師やデザイナー、事業開発のメンバーもいわゆる「2枚のピザ」を囲んでいます。前述の通りOKRの進捗状況に応じて四半期末を待たず柔軟にチーム組成が変わるため、スクラムマスターたちはその迅速な立ち上げを支援しています。
「PO」は、エンジニア・事業開発・デザイナー・医師など様々なバックグラウンドのメンバーが「役割」として担います。こちらも、本人の will、得意領域を踏まえて頻繁に入れ替わるため、今日POになった人が明日からすぐにプロダクト/事業のROI最大化に注力できるようスクラムマスターたちは支援する必要があります。
Ubie Discovery のカルチャーガイドにも明記されている通り、私たちはスクラムを組織全体で導入・実践しています。プロダクト開発に携わるチーム/メンバーだけがスクラムをやっているではありません。たとえば前職まではあまりスクラムに馴染みがなかった事業開発・医師・デザイナーのメンバーであっても、スクラム三本柱である「透明性・検査・適応」を共通言語として理解/実践できるよう、スクラムマスターたちが支援しています。
スクラムマスターは、フェーズごと支援対象の力点がかわる
組織やチームはある種の生き物であり、それらの成長・変化に伴ってスクラムマスターが支援する対象の力点も変わります。
もしあなたがスクラムマスターなら、次の図をみたことがあるかもしれません。これは組織の成長フェーズとスクラムマスターの支援の力点がどのように推移するかを示したプラクティスの一つです。
様々な局面を経験してきた今でこそ腹落ちしているつもりですが、これをはじめて見た頃は、この図が意図するところが正直よくわかっていませんでした。
事業やチームの立ち上げ期には、やはり「開発チーム（=組織）」「PO」への支援活動が主軸になります。組織拡大にしたがってより大きな「組織」全体でのスクラムのプラクティス実践が効力を発揮するようになります（LeSS においては技術的プラクティスの重要性にも言及がありますが、今回は割愛します）。
言ってしまえば至極当たり前のことでしかありません。
大事なのは、いまのチームや組織がおかれている状況を観察して、いまどこの支援に力点をおくべきかを理解し実践することです。力点は常に移り変わるもので、それに自覚的であり続けるのは、ちょっとした心がけではありますが大きな変化をもたらします。
「スクラムがしんどい！」を乗り越えて
スクラムマスターとしてのこれまでの経験で1つ、忘れられない出来事があります。
数年前、同じチームで熱心に取り組んでいたとあるPOが、ある日突然「スクラムがしんどい！」と言い始めたのです。
チームが真の意味で「自己管理」できるよう、スクラムマスターであった自分が十分に支援できておらず、そのしわ寄せ・帰結としてPOが荷重負荷で悲鳴をあげていたのでした。
多くの場合、開発チームへの働きかけと、POへの働きかけは相互作用があります。
ただ、当時はこの当たり前の機序・つながりがよくわかっていませんでした。
スクラムガイドでも言及されている通り、スクラムではチームの「自己管理」を大切にしています。
Ubie での経験から、真に「自己管理」されたチームは、まだそうでないチームに比べて、たとえば次のような特徴があると考えています。
・OKR/スプリントゴールとのアラインメントを図ること。それらの実現は、最終的にはPOが担うものの、見立て等が不明瞭であればそれさえもチームが自発的に問い直すこと。
・常に検証目的に立ち返り、有効かつ有用なPBIを産み出しつづけること。
・スプリント直後の振り返りで出た課題は、次の週のその場までには解決されていること。
チームが自己管理されているからこそ、POはPBIの実現について開発チームに背中を預けつつROIの意思決定に注力できるし、POがそこに注力できるからこそ、スクラムチームとしてより早くより適切な価値を顧客に届けることができます。
スクラムマスターは、「パクりやすさ」で組織文化を育てる
フレームワークとしてのスクラムの良さは、たった18ページのスクラムガイドの中に原理原則が詰まっていることです。
スクラムガイドには「how はこうすべき」とほとんど書かれていませんし、かつてあった記述も近年は取り除かれる傾向にあります。
多くのスクラムマスターが「組織」の支援に目を向けたときにまず気づくのは、おそらくその軽量さ・パクりパクられやすさです。
それこそ、スクラムが個別のチームではなく組織全体の文化として定着する上で本当に重要なミーム (遺伝子) といえます。
"Attempting to change an organization’s culture is a folly, it always fails. Peoples’ behavior (the culture) is a product of the system; when you change the system peoples’ behavior changes." (John Seddon)
「組織の文化を変えようとするのは愚の骨頂で、必ず失敗します。人々の行動（文化）はシステムの産物であり、システムを変えれば人々の行動も変わるのです。 (ジョン・セドン, 拙訳)」
これを読んでいるあなたは、おそらくなんらかの形でスクラムに触れているはずです。
もしあなたのチームにスクラムマスターがいたら、ぜひ訊いてみてください。「スクラムってシンプルなんですか？」と。
スクラムはおそらくあなたが思っている以上にシンプルで、いいプラクティスほどパクりやすいものです (血肉にするのは大変ですが...)。
もしとても重厚長大な何かを想像しているなら、それはたぶんスクラムではありません。
もしスクラムがムダだな、ミーティング増やしたくないなと感じるのであれば、スクラムがリーン思考に立脚していることを見過ごしています。
スクラムガイドをもう一度、声に出して読みましょう。スクラムマスターに訊いてみましょう。
スクラムマスターは、個別化と汎化で「組織」を支援する
繰り返しになりますが、スクラムは原理原則がシンプルです。
だからこそその個別化と汎化を組織的に繰り返し、ナレッジ資産を育てることが組織戦略上重要になります。
これは決して放っておいて実現するものでは決してなく、スクラムマスターの支援対象が「組織」であるとスクラムガイドに明記されている理由の一つでもあります。
少し具体的な例に触れます。
Ubie Discovery は2021年夏現在100人を超えたくらいですが、かつてに比べても多様なバックグラウンドのメンバーが増えてきました。
組織内では15あまりの大小さまざまなチームが組成されていますが、自分を含む若干名のスクラムマスターが片手間でスクラムの支援をするだけでは組織の基盤としては脆く、その課題意識から最近はスクラムの導入・実践を組織設計にビルトインするためのプロジェクトチームが組成されています。
個別チームのハンズオン、特にビジネスバックグラウンドが多いチームにおいてはラーニング/アンラーニングに苦戦するケースが比較的多いので、厚めのハンズオンを行っています。一概にフレームワークだけをおしつけるのではなく、よくあるピットフォールにも意識が向くよう促しつつ、常に透明性・検査・適応に立ち返ることを促しています。
同時に、個別のハンズオンからの知見抽出 (汎化) と組織全体へのナレッジ資産化も行っています。
「チームとしての成熟度」「個人としての習熟度」などを切り口に、最低限の学習のラダーをつくり組織のオンボーディングプロセスに埋め込むことを行っています。
スクラムマスターは、「見えていないものは何か」を見ようとする
多くの場合、顕在化している課題を解決するのは優秀な人が集まったら簡単にできます。
一方、何が見えていないかに自覚的であることは、本当に難しいことです。
個人やチーム、組織、会社、業界など、様々なレベルでのバイアスが存在しているはずで、結局のところそれらはいくつかのものを比較し差異を知覚することしか気づくことができません。
だからこそ、スクラムを単一チームではなく複数チーム/組織全体で取り組み、その共通点相違点から学ぶことを促す価値があります。
We are hiring!
ここまでスクラムマスターがいったい何を考え何を支援しているのか、について触れてきました。
Ubie Discovery の例にも触れていますが、ある部分の経験はあなたの会社のスクラムの取り組みと重なっているかもしれませんし、ある部分は Ubie 固有のものかもしれません。
普段自分はデザイナーの帽子をかぶって活動することが多いですが、だいたいいつも10-30%程度は上で述べたようなことを考えつつスクラムマスターの帽子をかぶっています。
根底にあるのは、「いいプロダクトはいいチームやいい組織からしか生まれない」という信念です。
チームや組織がのコンディションがいまいちなまま、素晴らしいプロダクトをつくって顧客に価値を届けられますか？少なくとも自分は経験がありません。だから自分はスクラムマスターをやっています。
よく設計されたシステムについて、使い手がその存在意識することはほとんどありません。同様に、スクラムのコンセプト自体は極めてよく設計されているので、組織のある種のOSとして十分「透明に」役割を果たすことができるはずです。
スクラムが空気のように当たり前なレベルまで組織運営にビルトインされている状態を目指す、単に「開発」のフレームワークとしてでなくカルチャーレベルまで昇華するというのは生半可なことでないですが、それなりにやりがいがあるものです。
Ubie Discovery ではスクラムマスターとしての求人はないものの、エンジニア・事業開発・医師・デザイナーが皆一丸となってスクラムに取り組んでいます。
スクラムが当たり前になった2021年現在、「なぜスクラムか？」ではなく「スクラムで、いったい顧客に何の価値が届けられるか」に興味がある方は、ぜひ近くの Ubie Discovery メンバーに声をかけてみてください。きっとエキサイティングな話をしてくれるはずです。
