スクラムマスターのスキルシートの書き方｜面談で評価される実績の見せ方

スクラムマスターのスキルシートは、イベントの運営を並べるより、「どんな状態のチームに、何を働きかけ、どう変わったか」を先に読ませるのが基本です。1チームごとに「立場・チームの構成・参画時の状態・働きかけ・変化」をそろえて書くと、読み手はそのチームで何をしてくれるかを想像しやすくなります。

「スクラムマスターとしてデイリースクラム、スプリントプランニング、レトロスペクティブを運営」と書くだけでは、どのスクラムマスターにも当てはまってしまいます。この記事では、スクラムマスターのシートに固有の書き方を、架空の例を使って紹介します。全体の構成や基本の型はフリーランスのスキルシートの書き方をご覧ください。

スクラムマスターのシートはどう読まれるか

シートを読むのは、発注元の開発部門の責任者や、プロダクトオーナー、すでにいるスクラムマスターであることが多く、読み手自身がスクラムを知っています。そのため、用語が正しいかよりも、次のような点を読み取ろうとします。

• 専任だったか、PMや開発と兼務だったか
• チームはどんな状態で、自分が入って何が変わったか
• チームの外にある妨げに、どこまで働きかけたか
• プロダクトオーナーや関係者を、どう支えたか

スクラムガイドは、スクラムマスターの責任を「スクラムチームの有効性」としています。シートでも、チームがより有効に動けるようになった変化を示すことが中心になります。求められるスキルの全体像はスクラムマスターのスキルの記事で整理しています。

要約欄は「得意な場面」を3行で

要約欄では、経歴を年代順に並べるより、自分がどんな場面に強いスクラムマスターかを先に書きます。チームの段階、扱った規模、プロダクトの領域の3つで表すと伝わりやすくなります。

架空の例：

• Webサービスの開発チームで、スクラムの導入から定着までスクラムマスターを担当
• 停滞していたチームに途中から入り、振り返りの改善が実行される状態に立て直した経験あり
• 3チームが同じプロダクトを開発する体制で、チーム間の依存の整理と合同レビューの運営を担当

応募する案件で求められる場面に近い行を一番上に置き、案件ごとに並べ替えます。

チーム欄に入れる項目

スクラムマスターの経歴は、プロジェクトより「チーム」を単位にすると書きやすくなります。

記入例（架空）

期間：（例）約1年。チームの立ち上げから参画
プロダクトの概要：（例）小売業向け 会員アプリの開発
立場：発注元の社内チームに、外部のスクラムマスターとして参画。専任
チームの構成：開発者6名、プロダクトオーナー1名（事業部門と兼務）
スプリント：2週間。スクラムガイドのイベントをすべて実施
参画時の状態：スプリントゴールが毎回達成できず、レビューに関係者がほとんど来ない
主な働きかけ：プランニングで取り込む量をチームと見直し、バックログの項目を小さく分ける手法をPOに提案。レビューの日程を事業部門の会議に合わせて組み直した
変化：スプリントゴールを達成できるスプリントが増え、レビューで関係者から直接意見が出るようになった

これは項目の埋め方を示すための架空の例です。実際の経験に置き換えて書いてください。

「主な働きかけ」の書き方

働きかけの欄は、次の3点を意識すると、スクラムマスターらしさが伝わります。

1. 主語を分ける：自分がしたことと、チームが決めたことを分けて書く。「チームと決め直した」「POに提案した」のように、関わり方が分かる動詞を使う
2. 見立てを添える：なぜその手を選んだのかを短く入れる。「取り込む量が多すぎると考え」など
3. チームの外も書く：他部署への説明や承認の流れの見直しなど、チームの外の妨げに働きかけたことがあれば書く

「チームに指示して改善させた」のような書き方は、スクラムマスターの立場と合わず、読み手に違和感を与えます。

数字の扱い

数字は、変化を伝える助けになりますが、扱い方に注意が要ります。

• ベロシティ：見積もりの基準はチームごとに違うため、ほかのチームと比べる数字としては使いにくい。書くなら、同じチームの中での変化として、補足をつけて書く
• スプリントゴールの達成：「達成できるスプリントが増えた」のように、傾向として書くと誤解が少ない
• 人数と期間：チームの人数、チームの数、スプリントの長さ、参画期間は数字で書く

守秘義務の範囲を超える数字や、発注元の業績に関わる数字は書かないようにします。伏せ方はスキルシートの守秘義務の記事で解説しています。

関わり方が特殊なときの書き方

複数チームを担当していた

チームごとに欄を分けるか、全体を1つの欄にまとめて、チーム間の連携で自分がしたことを書きます。同じプロダクトを複数のチームで開発する場合、スクラムガイドは、チームが同じプロダクトゴール、プロダクトバックログ、プロダクトオーナーを共有するとしています。その中でどこを担ったかを書くと伝わります。

開発者や別の役割からスクラムマスターに移った

同じチームの中で役割が変わった場合は、期間を分けて書きます。移った後の働きかけを中心に書き、それ以前の経験は、開発の理解を示す材料として短く添えます。

資格欄の書き方

資格欄には、認定の正式名称、実施団体、取得年月を書きます。Scrum AllianceのCSMは2年ごとの更新が必要とされているため（2026年10月時点の公式ページによる）、有効期限も添えておくと読み手が確かめやすくなります。資格の位置づけや更新の詳細はスクラムの認定資格の記事をご覧ください。

提出前に見直したいこと

書き終えたら、次の点を見直してから提出しましょう。

1. 要約欄の1行目が、応募する案件で求められる場面に合っているか
2. どのチームの欄にも、参画時の状態と変化が対になって書かれているか
3. 「指示した」「管理した」など、スクラムマスターの立場と合わない言葉が残っていないか
4. 専任か兼務か、兼務なら比重が分かるか
5. 社名、サービス名、発注元の業績に関わる数字が残っていないか
6. 資格の有効期限が切れていないか

面談では、シートに書いた働きかけを1つ選び、「状態→見立て→働きかけ→変化」の順で2〜3分で話せるようにしておくと、質問に答えやすくなります。

よくある質問

スクラムマスターの経験が1チームしかありませんが、どう書けばよいですか？

1チームでも、参画時の状態、働きかけ、変化を段階に分けて書けば、十分に読み応えのある欄になります。時期ごとに課題が変わった場合は、「立ち上げ期」「停滞期」「定着期」のように区切って書くと、経験の厚みが伝わります。

うまくいかなかったチームのことも書くべきですか？

書いてかまいません。うまくいかなかった理由をどう見立て、何を試したか、そこから何を学んだかを書けば、経験として受け止められます。面談で聞かれたときに、他者のせいにせず話せるよう準備しておきましょう。

使ったツールはどこまで書けばよいですか？

ボードの管理やオンラインのホワイトボードなど、チームの運営に使ったツールを簡潔に書けば足ります。ツールの名前より、それを使ってチームの状態をどう見える形にしたかのほうが評価につながります。