発注者側スクラムマスターが支援しやすいこと、しにくいこと

Cover Image for 発注者側スクラムマスターが支援しやすいこと、しにくいこと
monotalkのプロフィール画像
monotalk

現在、スクラムチームで発注側の立場で受発注混合スクラムチームのスクラムマスターをやっていますが、スクラムチームを支援しやすいポイントと、支援しにくいポイントがあるなと感じるので、それぞれ自分なりに整理したくなったのでまとめておきます。

スクラムチームの状況について

ステークホルダーを含めた体制図

ステークホルダーを含めた体制図の説明

役割 所属 説明
PO 発注側 スクラムチームの外での役割は、PdMです。
開発者 (デザイナー) 発注側 Figmaでデザインをしたり、ユーザーインタビューの業務を担当しています。POの支援として、PBIの分割、作成も支援しています。
開発者 (エンジニア) 受注側 -
スクラムマスター 発注側 スクラムチームの外での役割は、Tech Leadです。
管理監督者 (ステークホルダー) 受注側 開発者の管理監督者がスクラムチームの外に存在します。
Lead PdM (ステークホルダー) 発注側 プロダクトの事業責任者となるLead PdMがスクラムチームの外に存在します。

スクラムチームに支援がしやすいこと

スクラムマスターが発注側だと、当たり前ですが発注側への支援がしやすいというのがポイントしてあるのかなと思います。

POと開発者間のファシリテーションはしやすい気がする

スクラムマスターが発注サイドなので、開発者がPOに対して言いにくいことを言いやすいようにファシリテーションをするのはやりやすいのかなと感じています。

POのレポートラインのステークホルダーへの働きかけがしやすい気がする

スクラムマスターが発注サイドなので、スクラムチームを取り巻く環境へのアプローチも受注サイドにスクラムマスターが存在する場合に比べるとしやすいのかなと感じています。

以前、アジャイルコーチの方と話した時に「発注者が組織上どのポジションにいるか？は意識しています」 とおっしゃっていたのを思い出しました。 ※発注者の配下の組織は変えやすいが、発注者の権限が及ばない範囲を変えるのは難しいという文脈。 受注サイドでスクラムマスター｜アジャイルコーチになる方は、このあたりは意識されているのかなと思いました。

スクラムチームを支援しにくいこと

端的に準委任契約の関係から発生する指示系統の問題などに起因して起こるものかなと考えています。

開発プロセスへの支援がしにくい

以下の2点が原因で、開発状況の情報の入手が断片的になっていてスクラムマスターとしては観察がしにくいです。

  • 発注側、受注側で作業の拠点が分かれている。
  • 利用しているチャットツールが異なり、開発者（エンジニア）間のコミュニケーションが把握できない。

現状はスクラムイベントとバックログリファインメントの時間、タスクボードのデータを元に観察をしていますが、それだけだと開発プロセス関連のデータが不足している気がしています。

開発者（エンジニア）個人への直接的な支援がしにくい

スクラムマスターと開発者（エンジニア）間に受発注の関係があるので、「〇〇しませんか？」という提案的なフィードバックが、指示に聞こえやすいのかなと考えています。
今は受注側の管理監督者に依頼して開発者（エンジニア）個人へのフィードバックをするようにしています。

PBIの「なぜ（Why）」への興味を高める支援がしにくい

スクラムマスターとしては、開発者（エンジニア）がPBIの「なぜ（Why）」への興味が薄いように感じています。これは、現状のチームにあまりスクラムの教育の時間をとっていないというのも原因な気がしますが、受発注という構造的な問題もあり、支援がしにくいのかなと考えています。

スクラムチームに支援しにくいことに対して何ができそうか？

NotebookLMに以下のページのドキュメントを読み込ませて、支援しにくいポイントに対してアドバイスをもらいました。

アドバイスの結果の全文は以下のgistに記載しています。

個人的に今後のアクションアイテムとして設定しても良いかなと思ったものを列挙します。

コミュニケーションチャンネルの統合

契約上は問題がなさそうで観察データの入手という観点でコミュニケーションチャンネルを統合しても良さそうにも思いました。
ただ、チャンネル統合により開発者の心理的安全性が失われる可能性もあり、それなりに慎重なチャンネル設計は必要になるかと思いました。
以下は、NotebookLMのアドバイスの抜粋です。

  • 共有ツールの利用は法的リスクではない： 厚生労働省の最新の疑義応答集（第3集）では、発注者と受注者がチャットツールやプロジェクト管理ツールを共有し、全員が参加して情報を共有・助言・提案を行うことは、実態として対等な関係の下で受注側が自律的に判断している限り、直ちに偽装請負とは判断されないと明記されています,。

前提を整え、言い方を考えた上での提案をする

提案であれば指示にはあたらないので、スクラムマスターの役割としての提案は問題がなさそうには思いました。ただ、提案が指示と受け取られないように、前提ルールの説明、発注側のスクラムマスターとしての提案の伝え方を考える必要はあると思いました。
スクラムチームでスクラムガイドを読むなどで前提知識を整えるのが、まず先に感じました。
※スプリント0では、ざっくり説明のみでスクラムのプロセスに慣れたからインプットした方が良さそうに感じてはいた。

  • 実施責任者を通すべき事項の限定： モデル契約（第3条）では、業務の遂行や労務管理に関する「指示・要請・依頼」は実施責任者を介することが定められています,。
    しかし、これには議論があり、現場レベルの「提案・助言」まで全て実施責任者を通すことはアジャイルの実態にそぐわないという視点もあります,。

POから「なぜ（Why）」を提示してもらう

NotebookLMから以下のアドバイスがあり、開発者に提案していくよりもまず、POに状況を説明して丁寧な説明をお願いするのが筋が良さそうに思いました。
チームの状況によりアプローチが変わりそうですが、わたしが関わるスクラムチームだと以下の問題があり、POからのプロダクトゴールの提示とともに、PBIの説明をより深く行ってもらうことが必要と感じています。

  • プロダクトゴールが曖昧。
  • スプリントゴールが曖昧、もしくは設定されない。
  • • POには「ビジョン提示」の義務がある：
    モデル契約（第4条第3項）において、プロダクトオーナー（PO）は**「スクラムチームに対してプロダクトのビジョンや意義を示し、価値を最大化するよう努める」**義務を負うと明記されています,。
    開発者が「なぜ」に関心を持てないのは、POがこの契約上の義務（役割）を十分に果たせていない、あるいはその熱量が伝わっていないためかもしれません。

まとめ

記事を書いて思ったことをまとめます。

  • 発注側のスクラムマスターのふるまいについては、モデル契約に直接的に書かれていない。ただ、間接的には多くのヒントが記載されている。NotebookLMがすごい。
  • スクラムマスターは基本的に提案・コーチング・支援でのふるまいになるので、受注・発注どちらに立てても良さそう。
    • 入手しやすいデータ、チーム外への支援のしやすさについては変わりそう。
      • スクラムマスターのLevel 1役割は受注側のスクラムマスターが担う、Level2以降の役割は発注側のスクラムマスターが担う。とかが良さそう。

以上です。

コメント