スクラムマスターのORSC®（システムコーチング® ）活用方法
Koki Shimizu
Scrum Alliance® Certified Team Coach℠ (CTC℠)
目次
スクラムマスターのORSC®（システムコーチング®）の活用方法 6
POと開発者（開発チーム）が受発注関係(POだけ疎外感を感じてるケースもあり) 16
POに逆らえない（開発チームとPOが対等な関係性ではない） 17
チーム内に不透明な役割があり、チーム内の特定の誰かがいつもカバーしてくれて成り立っていて、不満が見え隠れしている 20
ある特定の強烈なメンバーがいて、チームや組織の心理的安全性が保たれない 21
皆様、こんにちは。
アジャイルコーチ、清水弘毅です。
スクラムマスターのスキルセットは非常に多岐に渡り、人生に「道」を与えてくれるような感じさえ覚える今日このごろです。
最近、スクラムマスターやアジャイルコーチの方が、ORSC®（システムコーチング®）を学ばれているのを見て、とてもうれしく思います。
私も今(2022/5現在)まさにORSC®の認定プロフェッショナルコースの終盤に差し掛かっているところです。
ここまで進めてきて、 ORSC®の智慧は、スクラムマスターには確実に役に立つと確信しました。私なりに考える優れたスクラムマスター・アジャイルコーチへの「道」の過程にORSC®は是非とも取り入れたいと考えています。
本記事では、スクラムマスターのORSC®（システムコーチング®）の活用方法を詳細な視点でお届けします。皆様の自己啓発の一助になれば幸いです。
スクラムマスターは、場の目的によって、コーチング、ティーチング、ファシリテーティングを使い分ける必要があります。これはチームの状況やスキルレベルによって変わってくるので、一概に区分けがしづらいのが難しいところです。大まかに以下のような「図 1 チームの特性とスクラムマスターの行動」で見ていただけるといいかなと思います。スプリントプランニングやリファインメントなど、アジェンダがおおよそ決まり、慣れてくるに従ってチームで実践できるものは、チームに任せていきます。
図 1 チームの特性とスクラムマスターの行動
では、具体的にどのような場面で、どのようにORSC®が活用できそうか、私の経験も交えてお伝えします。
スクラムでは、スクラムガイドで４つのイベントが定義されていますが、私はそれにほぼ必須だと思われる「プロダクトバックログリファインメント」を加えます。
それぞれのスクラムイベントの「場のデザイン」、「スクラムマスターのスタンス」、「ORSC®の利用可能なツール」をまとめてみました。
プロダクトバックログリファインメントは、プロダクトバックログを追加・更新・削除・明確化・分割等を行う場です。少なくとも直近２〜３スプリントのバックログアイテムの明確化を行います。加えて、中長期計画を共有・確認する場です。中長期計画を見据えないと、チームが「木を見て森を見ず」の状態になります。スプリント期間中の5〜15%の時間を取ります。特にスクラム開始前や、はじめてから２〜３スプリントはプロダクトバックログが明確ではないため、多くの時間を取ります。時間を徐々に少なくしてもいいでしょう。２週間スプリントだと３〜４時間欲しいとこれまでの経験から思います。参加者は、PO・開発者・SMです。
スプリントプランニングは、多くの場合２部構成に分かれます。スプリントプランニングⅠは、スプリントゴールの明確化と、これからはじまるスプリントでどのPBIを選択するかを開発者とPOで合意します。プロダクトバックログは優先順位で既に並んでいるはずのため、プランニングⅠはそこまで時間はかかりません。30分〜１時間程度かと思います。参加者はPO・開発者・SMになります。スプリントプランニングⅡは、選択したPBIをどう実現するか検討します。PBIの実現手段をタスクに分解し、スプリントバックログを作成します。「Doneの定義」を参照しながら、開発者はタスク分解をします。プランニングⅡは２週間スプリントの場合、６〜７時間ほどかかります。開発者はソースコードを見たり、どのように実現するか設計を議論・検討しながらすすめるため、時間がかかるのです。プランニングⅡの参加者は、開発者、（開発者に必要とされれば）SMで、POはすぐに連絡が取れる状態であれば良いと思います。開発者がタスク分解をすすめる過程で、疑問点がでてくることがあるため、すぐQ&Aができると良いです。
デイリースクラムは、プランニング時に作成したスプリントバックログを前にして、開発者がこのスプリントの計画を検査・適応する場です。スプリントバックログで立てた計画から乖離がある場合は、どのように是正するのか検討します。また、スプリントをすすめるにあたって課題や困っていることがあれば共有します。15分以内と定められています。15分以上の議論が必要な場合は、必要な人だけ集まって別会を計画します。
プロダクトオーナー（または開発者）からステークホルダーへ最新のインクリメントをお披露目する場です。真摯にプロダクトに対するフィードバックを受けます。フィードバック内容をプロダクトバックログにそのまま載せることもあります。現状を見据えて、未来をどうするかを語る場でもあります。予算や残り期間、リリース日、どの機能がいつごろリリースできそうかなど、現実的な話も出てきます。参加者は、PO・開発者・SM・ステークホルダーです。２週間スプリントであれば２時間ほど取ります。プロダクトバックログリファインメントを明確にイベントに含めていない場合は、このイベントに、バックログリファインメントを含めることもあります。
いずれもステークホルダーやスクラムチームと前もって合意の上でツールを利用することをおすすめします。
スプリントでの働き方や生産性、品質、スクラムの原則（透明性・検査・適応）についてチームでふりかえりを行う場です。例えばスプリントバックログの計画予実が良かったのか、タスクを実行する際に、躓いたポイントはなかったのかなどをふりかえり、次のスプリントへの最低１アクションを出します。２週間スプリントであれば１時間３０分〜２時間は取ります。参加者は開発者・PO・（必要とされれば）SMです。スプリントレビューはプロダクトに対するフィードバックですが、スプリントレトスペクティブは、プロセスに対するフィードバックです。よって、プロダクトに対する改善はこの場では行いませんので注意してください。
いずれもスクラムチームとその場で合意の上でツールを利用することをおすすめします。
これまでは、スクラムのイベントにフォーカスしてORSC®の活用箇所をみてきましたが、スクラムイベント外でもチームで仕事をしている以上、関係性に関する様々なことが起こります。これまで私が経験してきたことで、今振り返るとシステムコーチング®が有用だったようなケースを挙げてみます。
スクラム開始前のチームビルディングはとても重要な時間です。キックオフと題してメンバーを集めることもあると思います。よくある光景は、POからの一方的なプレゼンテーション。Q&Aはありますが、ワクワク感は芽生えませんよね。私は最低限チーム名を決めることをゴールとしています。チーム名は、チームのアイデンティティになり、帰属意識を芽生えさせます。ただ単にチーム名を決めてくださいといっても良い名前付ができません。その場しのぎのなんとなくの名前になりやすいです。チームの意図的な協働関係を築き、どんな雰囲気や文化を創っていきたいかをチーム全員で考えるDTAや、自分たちが集まった目的、何をなぜ達成したいのかをディスカッションし、その後に、「ではそのようなチームにふさわしいチーム名は何でしょうか？」とチームに問います。
私の場合は、３時間ほどいただき、チームの見立てに合わせてチームビルディングの中にシステムコーチング®のツールを差し込みます。逆に、システムコーチング®のツールだけでは実施したことはありません。よくやるのは、アイスブレイク的な自己紹介、DTA、インフォーマルコンステレーション、開発者にインタビューアになってもらいPOに対する「9Whys」（人数が多い場合はフィッシュボウル形式もおすすめです）役割の明確化と役割の期待値（ドラッカー風エクササイズの個人ではなく役割毎バージョン）等です。インフォーマルコンステレーション[6]は、その場に集まったメンバが、いきなり「アジャイル」や「スクラム」に放り込まれ不満が見え隠れするときに活用します。アジャイルサムライに記載のある、インセプションデッキのような便利なテンプレートもありますが、単にあれをシリアルに埋めるのはおすすめしません。スクラムマスターは、この場をより効果的に楽しく、誰もが自分の思いを吐き出せ、そして同じチームにいるのだ、一つのチームになったんだと思わせるようなファシリテーションをすると良いと思います。
ORSC®のツールを利用するときはシステムコーチの帽子を被ります。遊び心の中にも、本気・コミットメントが見え隠れするようなスタンスで、チームからの信頼を得ることが可能な場です。
日本の伝統的な大企業だと、以下のような構造が多いと思います。
この構造はソフトウェア開発においてはかなり致命的です。これまでのビジネス上の慣習により、「POから要件が下りてきて開発者が開発する」となると、POはPOで、「要件を決めたらあとよろしく。お金払ってるでしょ」開発者は開発者で、「要件に書いてあることだけをやります」と言ったマインドセットで仕事にとりかかることになります。「文化は構造に従う」[8]とも言われます。この構造が悪しき根源なのですが、いきなり構造を変えるのは現実的ではありませんので、まずは心の持ちようを変えてみることからはじめてみます。
これは受発注よりも厄介かも知れません。よくあるパターンは、POに役職がついているケース。特にPOが社長など、かなり強い権限を持っているときに見られるケースです。スクラムマスターもPOにフラットな関係性を維持できないケースがままあります。このケースの場合に起こりうる現象は、
などと言ったものです。
このケースは、レトロなどの場で不満は聞けると思いますが、ちゃんと時間を取り、腰を据えてPOと開発者間の壁を取り除かなければなりません。よって、レトロ以外に時間を計画し、複数回に渡ってシステムコーチング®を実施すると良いと思います。（システムコーチング®を実施する）スクラムマスターにもかなりのストレスがかかると思いますし、システムコーチの帽子を被りきれないかも知れません。もし予算的に可能であれば、部外者に頼むのも選択肢の一つです。これは逃げではありません。立派な決断の一つです。
それでももし、システムコーチング®をスクラムマスターの方がトライするとなった場合、その勇気は素晴らしいと思います。とことんシステムコーチになりきってください。部外者のように振る舞うのです。完全な中立者であり、その場で起きていることが全てです。また、本来システムに関係する全員を呼びたいところですが、人数が多すぎる場合は、代表者のみを呼ぶことも検討します。全員呼ぶ際には、コーコーチ（２人１組コーチ）も検討します。
誰かが何かを話すと沈黙が訪れたり、変なフォローをし合ったり、非難や無視が見られたりといったその場にいると胃が締め付けられるようなそんなコミュニケーションを取るチームもまれにあります。スクラムを実施している方たちは大半が（精神的にも）大人なので、目に見える非難は少ないのですが、目に見えないからこそ厄介であったりします。そのような兆候を感じとったら、スクラムマスターはシステムコーチング®を活用できます。
スプリントレトロスペクティブの場を利用しても良い題材かと思いますが、１回でチームが劇的によくなることはないので、複数回実施します。そのため、レトロの時間を毎回取ってしまうのは厳しいかも知れません。チームの状況・状態にあわせてプランニング時にシステムコーチング®の時間を計画してもいいでしょう。
真面目すぎると、活気が戻るものも戻らなくなるので、適度な遊び心をもって望んでいただきたいです。
１つのスクラムチームだけで、顧客に価値が届けられるなら、それはとても素晴らしいことです。しかし、現実はそうでもありません。様々な部署やステークホルダーとの協調の上、顧客に価値を届けられるのです。スクラムは透明性を謳い、少なくともスプリントレビューにはステークホルダーは呼びますよね。周りからは、「あいつらわいわい何やってんだ」「なんか楽しそうだなぁ」「品質は大丈夫なのか」と穿った見方をされることも少なくありません。このようなケースの場合、スクラムマスターは他チーム、他部署、ステークホルダーとスクラムチームの間にある「壁」を取り除くことを求められます。
これはスクラムでなくてもよくある話だと思います。システムコーチング®ではまさにこの「役割」に焦点をあてたコーチングを提供してくれます。
実力は非常にあり、アイディアも豊富なのですが、ときに全く空気を読まない、怒鳴り散らす、公の場で他メンバーを罵る（いじめ）、長文のDMを休日平日関係なく大量に送りつけてくる、などの場に遭遇したことがあります。チーム内でもランクがついてしまい、他メンバーと対等に話ができなくなるほどの強烈な方は、ときどきいらっしゃいます。スクラムではイベントが多いので、自然とそのようなメンバーと一緒に集まる場が多くなります。露出が多くなるので、そのような場に出くわす確率も高くなります。さすがに手を挙げ始めたら（暴力）その場で止めたほうがいいと思いますが、手はあげず、言葉の暴力だけの場合、（かつ巧妙に言葉の暴力まではいかないのだけど、全体の雰囲気が非常に悪くなるような言い方、声の大きさのケースもあります）そのような場合、スクラムマスターは一人で解決しようとせず、上司や他マネジメント、社長、人事と相談しましょう。もちろん、システムコーチング®のツールも場合によっては有効だと思います。とくに何もないのに怒鳴り散らすような場合は論外で、コーチング云々ではありません。パワハラです。すぐに人事と相談しましょう。仕事をしている訳なので、おそらく背後に大きな不満や不安があるのだと思います。それを聞いてくれる人がいない、他のメンバーがわかってくれない、そこがポイントだと思います。
なぜモチベーションが低いのか考えるところから始めます。色々な理由があると思います。これまで見てきたなかだと、アジャイルやスクラムを上から言われてただやろうとしているケース。内発的動機ではないケースです。あとは、何のために仕事をしているのか、誰のために、どう役に立っているのかが不透明なケースです。このケースの場合は、システムコーチング®は非常に役に立ちます。
システムコーチング®で技術スキルを向上させるのは不可能だと思います。技術スキルを上げるためのモチベーションの明確化や、システムがどうなりたいのかを明らかにするのは可能です。技術レベルが高い方をつれて、リチーミングを検討してもいいと思いますが、システムコーチング®の領域ではありません。
ここまで読んできて、各シチュエーションにおけるORSC®の活用可能なツールはわかったけど、具体的にどうやればいいの？と思われたかもしれません。はい、私からはORSC®を教えたり、お伝えしたりすることはできませんので、是非、ORSC®の研修を受けて頂ければと思います。以下からたどれます。
https://crrglobaljapan.com/courseschedule/
個人的には実践プロフェッショナルまで受けてやっとシステムコーチング®チョットデキルぐらいかなと思うので、是非ORSCC目指していただきたいと思います。日本にORSCC認定のスクラムマスターが増えますように。そこからボトムアップで日本の社会が全体的に変わっていくことを期待しています。
[1] 出典 CRR Global Japan ORSC®プログラム
[2] https://liberatingstructures.com/
[3] 出典 CRR Global Japan ORSC®プログラム
[4] 出典 アーノルド・ミンデル博士 プロセスワーク
[5] 出典 CRR Global Japan ORSC®プログラム、アーノルド・ミンデル博士 プロセスワーク
[6] 出典 CRR Global Japan ORSC®プログラム
[7] 出典 CRR Global Japan ORSC®プログラム、アーノルド・ミンデル博士 プロセスワーク
[9] 出典 CRR Global Japan ORSC®プログラム、アーノルド・ミンデル博士 プロセスワーク
[10] 出典 CRR Global Japan ORSC®プログラム、アーノルド・ミンデル博士 プロセスワーク
[11] 出典 CRR Global Japan ORSC®プログラム
[12] 出典 CRR Global Japan ORSC®プログラム、アーノルド・ミンデル博士 プロセスワーク
[13] 出典 CRR Global Japan ORSC®プログラム
[14] 出典 CRR Global Japan ORSC®プログラム
[15] 出典 CRR Global Japan ORSC®プログラム
[16] 出典 CRR Global Japan ORSC®プログラム
