1. はじめに
求人広告システムの刷新を兼ねた基盤システム開発プロジェクトにて、スクラムマスター（SM）としてチームビルディングを始めてから8ヶ月が経ちました。
このプロジェクトは、客先メンバーを含めた混合チームでのスタートという、あまり多くはない座組みでした。それでも、チームビルディング・チームの成熟度向上、安定したベロシティの提供を継続できているため、このタイミングで一度ノウハウを整理しておきたいと思います。
以前、Scrum Inc. 認定スクラムマスター（RSM）研修を受講しましたが、そこで学んだ理論（3本の柱、スウォーミング、キャパシティを加味したベロシティ計算など）が、実際の現場でどう活きたか・どこでうまくいかなかったかを軸に、これからチームビルディングをする方の参考になるようまとめます。特に今回は、混合チームならではの摩擦とその吸収の仕方、そしてプロダクトオーナー（PO）・ドメインエキスパート（DE）との協働を厚めに書いています。
スプリント0から9月の客先メンバー増員までの8ヶ月間と、10月以降の複数チーム化に向けた展望
2. スクラムチームの座組みについて
- チーム構成: 客先メンバー2名+1名（9月ジョイン）/社内メンバー2名+1名（4月ジョイン）
- プロジェクト性質: 求人広告システムの刷新を兼ねた基盤システム開発、準委任契約
- 客先メンバーの役割: 開発メンバーとして参加。職能を社内メンバーと分けなかったことが良い結果につながった
- ツールスタック: チケット管理はBacklog、チャットはSlack、MTGはGoogle Meet、ドキュメントは原則GitHub
先方企業（PO・DE）と、客先開発メンバー・SM・社内開発メンバーからなるスクラムチームの関係
社内で完結するチームと違い、意思決定の主体が複数の会社にまたがる状態からのスタートでした。特に「客先メンバーを開発者として、機能横断的なチームの一員として迎え入れる」という設計が、後述する多くの工夫の土台になっています。
3. チームビルディング初期（0→1）
スプリント0での取り組み
スプリント0では、このプロジェクトでのスクラムの回し方を定義したハンドブックを作成し、チームに共有しました。客先メンバーを含む混合チームでは、「スクラムとは何か」の前提知識にばらつきがあるため、最初にチーム独自の運用ルールを言語化して揃えておくことが重要でした。
客先メンバーへのアジャイルの浸透方法
理屈から説明するのではなく、スクラムイベントをとにかく回すことを優先しました。デイリースクラム、スプリントレビュー、レトロスペクティブといったイベントを実践の中で体験してもらうことで、自然と「アジャイルの考え方」が浸透していきました。
最初にぶつかった壁
立ち上げから1〜2ヶ月で一番苦労したのは、チームが仲良くなっていく感覚、チーム力が出ている感覚がなかなか得られなかったことでした。プロセスは回っていても、チームとしての一体感が伴わない期間があり、ここが最初の関門でした。
この時期に試してうまくいかなかったのが、常時Discordを接続しっぱなしにして、疑問があればすぐボイスで聞けるという環境づくりでした。2日ほど運用しましたが、ほとんど会話が生まれず中止しました。「いつでも聞ける場」を用意するだけでは、心理的なハードルは下がらないという学びでした。
その後、疑問解消の手段は段階的に変化していきました。
- まずはデイリースクラムという定時の場で疑問を解消するサイクルから開始
- 定時の場のあと、Slackでの都度の質問が増えてきた
- 現在は、担当者同士がそれぞれカレンダーに対面での打ち合わせ時間を設定し、疑問点の解消や資料の読み合わせをセッティングできる状態まで発展
この変化を後押ししたのは、チームで隔週開催している趣味の雑談会や技術座談会など、業務外で顔を合わせる機会を増やす施策だったと感じています。また、打ち合わせではインセプションデッキで決めた通りカメラONを推奨してくれているメンバーが多く、毎朝顔が見える状態を保っていたことも、心理的安全性が徐々に確保されていった要因の一つだと考えています。
「いつでも聞ける環境」を仕組みとして先に作るのではなく、定時の場→非同期→対面と、負荷の低い手段から段階的に信頼関係を積み上げていく方が、混合チームでは現実的だったという実感があります。
4. 混合チームならではの壁と、その吸収の仕方
理論だけではカバーできない、客先メンバーと社内メンバーが混在するからこそ生じた摩擦とその工夫をまとめます。
稼働時間の違いをデイリースクラムの時刻で吸収する
客先メンバーの稼働時間は9-18時、社内メンバーは10-19時でした。ただし社内側はもともとフレックス勤務で、9-18時で働くメンバーもいたため、デイリースクラムの開催時刻を10時に設定することで、稼働時間の違いをイベント運用のレベルで自然に吸収しました。ルールで縛るのではなく、全員が無理なく揃えられる時間帯を見つけるという発想です。
準委任契約である以上、契約時間を超えた稼働が発生しないよう管理する責任もSMにあります。この点は、スプリントゴールを「昨日の天気（前回までの実績ベロシティ）」を参考に無理のない範囲で設定することで、そもそも契約時間内で達成可能な計画にするという形で担保しました。目標を張りすぎないこと自体が、長時間労働のリスク管理にもなっています。
システムアクセス権限のリードタイム
IdP（Auth0）やCRM（HubSpot）など先方システムへのアクセス権限は、PO が社内 IT 決裁に近い役割を兼ねていたこともあり、基本的には都度相談する形で進められました。ただし稟議のスピードが速い会社ではなかったため、権限付与の稟議が下りるまでの間は社内の検証環境を代用したり、モックを作成して開発を進めることで、権限待ちが開発のブロック要因にならないよう工夫していました。「権限が下りてから着手する」のではなく、「権限が下りるまでに進められる形を作っておく」という考え方です。
客先メンバーの評価とキャリアケア
客先メンバーの人事評価・1on1は、先方のマネージャーが別途実施していました。ただし、チーム立ち上げ直後の時期に限っては、SMからも客先メンバーに対して1on1を実施しています。立ち上げ期の不安や違和感を早期にキャッチする目的でのケアは有効だったと感じています。
メンバー交代リスクへの備え
契約更新のタイミングでメンバーが抜けるリスクについて、現時点で明確な引き継ぎの仕組みは用意していません。ただし、特定のPBIが特定の個人に属人化しない運用（後続のPBIの切り方の工夫や、大きめのPBIでの全員MTGなど）を積み重ねてきたため、誰か一人が抜けても大きなリスクにはならないだろうという想定を持っています。仕組みとして引き継ぎ手順を用意するのではなく、日々の運用自体が属人化を防ぐ形になっているという状態です。
スキル・知識差によるタスクの偏りと、PBIの切り方での解消
立ち上げ当初は、社内メンバーになじみのないHubSpotなどのツールに関するタスクと、技術レベルの高い社内メンバー向けのタスクとで、「客先向けタスク」「社内向けタスク」という暗黙の分断が生まれてしまっていました。
これに対しては、PBIの切り方を工夫し、AI コーディング支援ツール（本プロジェクトでは Cursor）の利用を前提にすることで、誰が着手しても対応可能な粒度にするという改善を行いました。結果として、客先・社内の区別なく、その時点で優先度が一番高いタスクから全員が着手できる状態を作れました。単にモチベーションや意識づけで解決しようとするのではなく、PBIという「作業の単位」自体を設計し直したことがポイントだったと思います。
情報格差の中身と埋め方
情報格差は双方向に存在していました。
- HubSpotの知識、Auth0の権限は客先メンバーの方が多く持っていた
- 開発スキル（技術力）は社内メンバーの方が高かった
どちらか一方が「教える側」「教わる側」に固定されるのではなく、領域ごとに得意なメンバーが自然と入れ替わる構造だったことが、上下関係を生まずに済んだ理由だと感じています。
客先メンバーが「開発者」として振る舞うことへのケア
客先メンバーを開発者として扱うと、逆に先方社内から浮いてしまったり、板挟みになったりするリスクがありました。この点については、もともとスクラム導入を望んでいたPO自身がスクラムへの理解が深く、先方社内側のケアをうまくしてくれていたことに助けられました。チーム内の設計だけでなく、チームの外（先方組織）との接続部分をPOが担ってくれていたことが、混合チームが機能した大きな要因の一つです。
5. 成熟期（ベロシティの向上）
ベロシティ計測による予測可能性は数ヶ月である程度安定していました。大きな転機になったのは4月の社内メンバー追加で、これを機にストーリーポイント（SP）の絶対量が増加し、より安定度が増しました。
1月末〜9月上旬の累積消化SP。4月以降に角度が増している
レトロスペクティブで効果があった工夫
「人間が行うレビュー負荷が重すぎる」というProblemがレトロスペクティブで挙がったことをきっかけに、コーディング・レビュー支援用のスキル（本プロジェクトではCursor）を整えるPBIにつなげました。結果としてレビュー負荷の低減という具体的な成果が出ています。これは、レトロスペクティブが単なる感想共有で終わらず、改善アクションとしてバックログに反映された良い例です。
Swarming（スウォーミング）の運用実態
研修で学んだ理論をそのまま持ち込みましたが、正直なところ、教科書通りにはうまくいきませんでした。
- スウォーミング（担当者を割り付けずチーム全員で優先度の高いPBIに向かう動き）は、ほぼ機能しませんでした
- 代わりに、SP20以上の大きなPBIについては着手タイミングで全員MTGを実施するというルールに落とし込み、「個人の視点だけで進まないようにする」というスウォーミング本来の狙いを別の形で担保しました
理論の「型」がそのまま機能しなくても、その型が守ろうとしていた本質（視野の偏りを防ぐこと）さえ押さえられれば、現場に合わせた代替策で十分に効果が出せるという学びでした。
6. PO・DEとの協働
先方・自社の混合チームでは、PO・DEとの関係の質がそのままチームの成果に直結します。ここは特に手応えがあった部分なので、少し詳しく書きます。
体制と頻度
- PO-SM間で毎週1時間、その週に起きたことやお互いの相談ごとを共有する時間を必ず確保
- DEとは別途、現行ビジネスの課題背景を共有する時間を確保できるようになった
良かったコミュニケーションの工夫
PO-SMの週次定例は、議題がそれほど多くない週でも実施することを崩しませんでした。結果として、議題ベースの話だけでなく、お互いの人となりや社内での立ち位置といった、雑談レベルの情報まで自然と共有し合える関係になり、これがチーム全体の透明性の向上につながったと感じています。「議題があるから話す」のではなく「話す時間があるから議題以外のことも共有できる」という順序が良かったのだと思います。
POが先方所属であることの難しさ
意外と難しさはあまり感じませんでした。プロジェクト当初は「変わった人だな」という印象もありましたが、思考の進め方が自分とかなり近く、その観点では逆に進めやすい相手でした。PO個人のタイプに助けられた面も大きいですが、週次で継続的にコミュニケーションを取り続けたこと自体が、所属の壁を意識させない関係性につながったとも言えます。
7. 失敗談とそこからの軌道修正
理論通りにやってもうまくいかなかった代表例が、バックログリファインメントです。
研修で学んだ通り、PO・DEとの間で受入条件の共通認識を持つ場としてリファインメントを設けていましたが、実際には質問すべきこと自体が場で出てこず、その状態で着手した結果、開発が進む中で背景や細かい仕様の理解が追いつかなくなるケースが多々発生しました。
これに対しては、事前に共有されるEPIC（大きな要求単位）について、リファインメント前にチームで読み合わせを行い、疑問点をあらかじめリストアップしておくという運用に変更しました。これにより、リファインメントの場での質問の質が明確に上がりました。
「質問してください」と場を用意するだけでは機能しない、というのはプロセスから入ったスクラムにおいてよくあるケースなのかもしれないと思いました。
8. 今のチームの状態
一言で表すと、「仲良くやれている」状態です。
特に印象的なのは、社内メンバー同士で「あの発言は嫌だった」「実はこういう意図だった」といった、踏み込んだ相互フィードバックができるようになっていることです。これは初期の「チーム力が出ている感じがしない」状態から見ると、大きな変化だと感じています。
9. スクラムを導入する前に満たしておきたい条件
ここまでは自分たちのケースの振り返りでしたが、最後に、これからスクラムを取り入れようと考えている方に向けて、必要条件を提示しておきます。
スクラムの経験は必須ではない
スクラムの「型」をなぞった経験があっても、結局はチームやプロジェクトの実情に沿ったやり方を都度模索していくことになるため、経験がそのまま活きるとは限りません。実際、自分自身も「チームの立ち上げ」は未経験の状態からのスタートでした。経験がないことを理由にスクラム導入を諦める必要はないと思います。
スクラムの知識はSMに必須
経験は必須ではありませんが、知識は必須です。SMを担う人は、ジェフ・サザーランド氏の著書『スクラム 仕事が４倍速くなる“世界標準”のチーム戦術』を読んでおくことを強く勧めます。個人的には数ある学習方法の中でもこの本が一番ためになりました。加えて、知識を体系的に確認する意味でも、Scrum Inc.のRSM試験のような認定資格の取得をお勧めします。これは継続的にSMを担っていく人に限った話ではなく、単発のプロジェクトで一度だけSMを担う場合でも、個人的には受けた方がよいと考えています。
スクラムへの理解はPOに必須
最も重要なのはPOのスクラムへの理解です。受託・準委任の場合、PO本人でなくとも、先方で調整力のある立場の人がスクラムを理解していることが必須条件になります。特に、ベロシティや自己組織化したチームの重要性を理解し、「納期ありきの開発の進め方」に固執しない考え方を持っていることが欠かせません。
とはいえ、あらかじめこの理解が備わっているPOに出会えるケースはかなり稀だと思います。理解が浅い、あるいはゼロの状態から始まる場合は、本を読んでもらいながら、初期にスクラムの勉強会的な場を定期的に開催するのが現実的です。スプリント0で実施するハンドブックの読み合わせ会にも、当然POに参加してもらいます。
なお、事前の見極め方としては、経歴や経験年数を聞くよりも、「スクラムの原理原則として大切なことは何か」を直接聞いてみるのが判断材料になります。
改善しようとする心意気は全員に必要
スクラムイベントを型通り繰り返すこと自体は簡単ですが、それだけでは継続的な改善にはつながりません。SMだけが改善を主導するのではなく、チームメンバー全員が常にプロセスを改善しようとする心意気を持ち、提案を出せる状態が必須です。
この心意気は、チームビルディングの過程で育てるものというより、メンバー選出の時点で見るべき資質だと考えています。実際、社内メンバーはスクラムの経験こそなかったものの、この心意気は最初から持っていました。メンバーを選ぶ基準は「スクラムの経験があるかどうか」ではなく、「改善しようとする心意気があるかどうか」に置くべきだと思います。
4つの条件が一つも揃っていない場合
もしPOの理解も、チームの心意気も、何も揃っていない状態でスクラム導入の相談が来たらどうするか。その場合は、スクラム経験者にSMコーチとしてプロジェクトに入ってもらい、コーチングをしながらスクラムを回していくべきだと考えています。それが叶わないのであれば、無理に引き受けない方が妥当な判断だと思います。
これらは「揃っていないと始められない」というより、始める前にどこまで揃っているかを自覚し、足りない部分をどう補うかまで見積もっておくべき条件として捉えるのが実用的です。
10. これからチームビルディングする人へ
8ヶ月を振り返って伝えたいのは、次の4点です。
- 契約・稼働の違いは、ルールではなくイベント設計で吸収する
稼働時間の違いをそのまま制約として扱うのではなく、デイリースクラムの時刻設定のように「全員が無理なく揃えられる接点」を運用側で作ることで、契約体系の壁は意外と目立たなくできます。 -
スキル差・知識差による分断は、意識づけではなくPBIの設計で解消する
「客先向けタスク」「社内向けタスク」という分断は、精神論では解けません。PBIの粒度や前提（AIサポートを織り込むなど）を見直すことで、誰でも優先度の高いタスクに着手できる状態を作る方が現実的です。 -
型は最初に揃える、ただし型に固執しない
スプリント0でハンドブックを作り運用ルールを揃えることは有効です。一方で、スウォーミングのように教科書通りに機能しない場合は、その型が守ろうとしている本質（視点の偏りを防ぐ、透明性を保つなど）を別の手段で担保できないかを考える方が現実的です。 -
PO・DEとは、議題のない時間を持つ
議題ベースの報告・相談だけでなく、定期的に「話すこと自体」を目的にした時間を持つことで、雑談レベルの情報共有が生まれ、結果としてチーム全体の透明性が上がります。所属会社が違うことの壁は、継続的な接点の積み重ねで薄れていきます。
客先メンバーを含む混合チームという特殊な座組みだからこそ得られた学びも多くありました。同じような座組みでこれからチームビルディングに臨む方の参考になれば幸いです。
11. 今後の展望: 複数チーム体制へ（Phase2）
10月からは新たにフロントエンドチームを立ち上げ、複数チーム運用を試験的に開始しました。そして来年1月からはPhase2として、フロントエンドチームとの本格的な複数チーム開発をスタートする計画です。
これまでは単一のスクラムチームの中でのチームビルディングでしたが、今後はチーム間の連携・スケーリングという新しい課題に向き合うことになります。混合チームで培った「型に固執せず本質を代替策で担保する」「議題のない時間を持ち透明性を上げる」といった学びが、複数チーム体制でもどこまで通用するのか、あるいは何を変える必要があるのか。このあたりは実際に運用してみてから、改めて別記事でまとめたいと思います。
簡単30秒