スクラムマスターのフリーランスがつまずきやすい点と対策

フリーランスのスクラムマスターがつまずきやすいのは、募集名と実際の役割のずれ、チームに答えを出してしまうこと、チームの外にある妨げに届かないこと、技術の話への距離、成果が見えにくいまま更新を迎えることです。どれも、スクラムマスターの仕事が「目に見える成果物」ではなく「チームの状態の変化」で測られることから起きます。

対策の基本は、役割の範囲を契約と参画初期の取り決めで言葉にし、現場では変化を記録して共有することです。この記事では、契約・現場・技術・お金の順に、スクラムマスターならではの場面と対策を整理します。独立前の準備はスクラムマスターがフリーランスになるにはで扱っているので、ここでは「参画してから起きやすいこと」に絞ります。

契約でのつまずき

募集名はスクラムマスターでも、中身が進捗管理だった

スクラムマスターの募集でも、実際には進捗の取りまとめ、報告資料の作成、開発の一部まで求められる案件があります。参画後に気づくと、スクラムマスターとしての時間がとれず、チームを支える働きかけが後回しになります。

対策：契約前に「1週間の時間の使い方」を具体的に聞きます。イベントの運営、プロダクトオーナーの支援、他部署との調整、そのほかの作業がそれぞれどの程度かを確かめ、兼務がある場合は業務範囲として個別契約に書いてもらいましょう。参画後に頼まれごとが増えたときの考え方は業務範囲の変更の記事と追加の依頼を断るときで整理しています。

担当するチームが途中で増える

1チームの専任で入ったのに、隣のチームのスクラムマスターが抜けて兼ねることになる、という変化はよくあります。チームが二つになれば、イベントの数も関係者も倍近くになります。

対策：契約前に、担当チームが増える可能性と、そのときの稼働や報酬の扱いを確かめておきます。増えた場合は、そのまま引き受けるのではなく、範囲の変更として発注側と話し合う材料にしてください。

指揮命令の形が社員と変わらなくなる

スクラムでは発注側と受注側のメンバーが同じ会議とツールで動くため、境目があいまいになりがちです。プロダクトオーナーがバックログを説明すること自体は問題になりませんが、作業の手順や労働時間を発注側から直接指示される状態が続くと、準委任の契約と実態がずれます。

対策：誰に報告し、誰と業務の内容を相談するかを参画時に確かめます。IPAのアジャイル開発版モデル契約は、準委任契約を前提に、ユーザー企業がプロダクトオーナーを、ベンダー企業がスクラムマスターを選任する形を示しています（2020年3月公開、2026年9月更新）。実際の体制は案件ごとに違うため、自分がどちらの側に立つのかを言葉にしておくと、線引きがぶれにくくなります。考え方は偽装請負の記事をご覧ください。

現場でのつまずき

チームが迷うと、答えを出してしまう

経験のあるスクラムマスターほど、チームが議論で行き詰まったときに「こうすればよい」と言いたくなります。一度なら早く進みますが、続けるとチームは自分たちで決めなくなり、スクラムマスターがいないと動かないチームになります。

対策：答えを出す前に、問いを一つ挟む習慣をつけます。「何が分かれば決められそうか」「試すならどの小さな方法か」と聞き、決めるのはチームに任せます。期限が迫るなど、どうしても早く決める必要がある場面では、自分が提案していることを明示し、あとで振り返りの材料にしてください。

イベントを回すことが目的になる

イベントを時間どおりに開き、議事を進めることに力を使い、チームの状態が変わっていないことに気づかないまま数か月が過ぎることがあります。スクラムガイドはイベントを時間内で「前向きで生産的なもの」にすることを求めていますが、それはチームの有効性を高めるための手段です。

対策：月に一度、「参画したときと比べて、チームで変わったこと・変わっていないこと」を書き出します。変わっていない点が見つかったら、次のレトロスペクティブで扱う話題の候補にします。

プロダクトオーナーとの関係がこじれる

バックログの整え方に口を出しすぎると、プロダクトオーナーは自分の判断を軽く扱われたと感じます。逆に遠慮しすぎると、あいまいな項目のままスプリントが始まり、チームが困ります。

対策：参画初期に、プロダクトオーナーと「どこまで手伝ってほしいか」を話し合います。バックログの項目を一緒に見直す時間を定期的にとるなど、支え方を合意しておくと、介入の加減を誤りにくくなります。

チームの外の妨げに届かない

チームが抱える妨げの多くは、承認の待ち時間、他部署への依存、環境の不足など、チームの外にあります。外部の立場では社内の人のつながりがないため、どこに相談すれば動くのかが分からず、妨げが放置されがちです。

対策：妨げの一覧をつくり、「チームで解けるもの」と「チームの外の誰かに動いてもらう必要があるもの」に分けます。後者は、発注側の担当者に誰が決められる人かを尋ね、影響（止まった日数、遅れた項目）を添えて相談します。一度に全部を動かそうとせず、影響の大きいものから一つずつ扱います。

技術でのつまずき

開発の話についていけない

完成の定義、テストの自動化、リリースの手順などの話題が分からないと、チームが何に困っているのかを見立てられません。開発者からの信頼も得にくくなります。

対策：コードを書ける必要はありませんが、チームのリリースまでの流れを一度、開発者に説明してもらい、図にしておきます。完成の定義に何が含まれていて、何が含まれていないかを把握しておくと、品質の問題が起きたときに話の筋を追えます。

技術の判断を引き受けてしまう

逆に、開発の経験があるスクラムマスターは、設計や技術の選択に意見を言いすぎることがあります。作業の進め方は開発者が決めるもので、スクラムマスターが判断すると役割があいまいになります。

対策：技術の話では、自分は判断する立場ではないことを前提に、論点の整理や、必要な人を議論に呼ぶことに徹します。意見を求められたときは、一人のメンバーの意見として伝えます。

お金でのつまずき

成果が見えにくいまま更新を迎える

スクラムマスターの成果は数字にしにくく、何も記録していないと、更新の時期に「いなくても回るのでは」と見られることがあります。

対策：毎月、チームの変化を短くまとめて発注側の担当者と共有します。数字にできるものは数字で、できないものは具体的な場面で書きます。記録は、次の案件のスキルシートの材料にもなります。

チームが自走した時点で契約が終わる

外部のスクラムマスターがうまく働くほど、社内で引き継げる状態に近づきます。成果の結果として契約が終わることがあり、次の案件の準備が遅れると空白が生まれます。

対策：参画時に、契約の見込みの期間と、引き継ぎのゴールを発注側と話しておきます。終わりが見えてきたら、早めに次の相談を始めましょう。フリーランス法では、6か月以上の業務委託を解除・不更新とする場合、少なくとも30日前までの予告が必要です（2026年10月時点、公正取引委員会の特設サイトによる）。契約期間の考え方は契約期間の記事で整理しています。

イベントの延長や時間外の対応が精算されない

複数のタイムゾーンにまたがるチームや、リリース前の振り返りの延長などで、稼働が契約の時間を超えることがあります。精算の幅や超過の扱いを確かめていないと、そのまま持ち出しになります。精算の仕組みは精算幅の記事をご覧ください。

よくある質問

参画してから、聞いていた役割と違うと気づきました。どうすればよいですか？

まず、契約書や個別契約に書かれた業務範囲と、現場で求められている作業を書き出して比べます。そのうえで、紹介を受けたエージェントや発注側の担当者に、ずれている点を具体的に伝えて相談してください。参画初期のうちに話すほど、調整の余地が残りやすくなります。

チームが自分たちで決めようとしません。どうすればよいですか？

すぐに決める場をつくるより、小さな決めごとから任せていくのが現実的です。振り返りで試す改善を一つだけチームに選んでもらい、次のスプリントで結果を一緒に見ます。初月の進め方はスクラムマスターの参画初月にやることで整理しています。

スクラムマスターの成果を発注側にどう伝えればよいですか？

参画したときのチームの状態と、今の状態を並べて伝えるのが基本です。振り返りの改善が実際に試された回数、妨げで止まった日数の変化、プロダクトオーナーとの準備の進み方など、チームで記録できるものを選びます。スキルシートへの書き方はスクラムマスターのスキルシートの記事をご覧ください。