本記事は広告（アフィリエイト）を含みます。掲載するエージェントは編集部が厳選した提携先です。
この記事の結論
即答
アジャイル経験は「担当した役割・スプリント運用・改善できた数字」の3点を案件ごとに1セットで書くと伝わります。
「アジャイルでずっとやってきたのに、職務経歴書にすると急に薄く見える…」。そんな相談を、私は取材のたびに受けます。スクラムは日々の動きが細かいぶん、文章にすると「チームで開発しました」で終わりがちなんです。
伝わる人は、やっていることが同じでも書き方が違います。担当した役割（開発者かスクラムマスターか）、スプリントでの具体的な動き、そして改善できた数字。この3点を案件ごとにワンセットで並べるだけで、読み手の解像度が変わります。職務経歴書はそもそも最初に流し読みされることが多い書類です（doda 職務経歴書の書き方）。だからこそ、まずは1案件、3行だけ書き直してみてください。この記事では、アジャイルの職務経歴書の書き方を、役割の示し方・数値化・そのまま使える例文の順で一緒に整理していきます。書類づくりの全体像はIT転職の流れをロードマップで確認すると迷いが減ります。
アジャイル・スクラム経験は職務経歴書のどこに書く？
即答
「職務要約」で開発手法に触れ、各案件の「担当工程・役割」欄でスクラムの動きを具体化します。
書く場所を間違えると、せっかくの経験が埋もれます。私も最初は、アジャイル経験を自己PRの最後にひとまとめで書いていました。でも採用担当が知りたいのは「どの案件で、どう関わったか」です。
おすすめは2か所に分けることです。まず職務要約の冒頭で「スクラム開発5年」のように手法と年数を一言。次に案件ごとの担当工程欄で、スプリントの長さやチーム規模、自分の役割を具体的に書く。こうすると、流し読みでも「アジャイル慣れしている人だ」と伝わります。アジャイル開発を採用する企業は年々増えていて（IPA DX白書）、手法そのものより「その中で何をしたか」が見られています。
ここで一つ気づいたんですけど、手法名を並べるだけの人がほんとうに多いです。「スクラム/カンバン/XP」と書いてあっても、何をしたのかは伝わりません。手法名は名刺がわり、中身は案件欄で見せる。役割分担を意識すると、同じ情報量でも印象が変わります。
スクラムでの「役割」はどう書けば伝わる？
即答
「開発者・スクラムマスター・PO補佐」など立場を明示し、その立場でやった行動を動詞で書きます。
「チームで」と書くと、自分が何をしたのかが消えます。ここがいちばんもったいないところ。スクラムは協働が前提だからこそ、自分の輪郭を意識して書く必要があります。
立場を先に置くのがコツです。開発者なら「バックエンド開発者として、スプリントごとに5〜8ポイントを担当」。スクラムマスターなら「デイリースクラムとレトロスペクティブの進行を担当し、チーム5名の妨害要因を除去」。役割名のあとに、その立場でやった行動を動詞で続ける。これだけで「再現できる人」に見えます。
兼務だった場合は、割合で書くと正直で伝わりやすいです。「開発7割・スクラムマスター3割」のように。私が見てきた中では、盛らずに割合を書いた人のほうが、面接で深掘りされても崩れませんでした。等身大のほうが、結局いちばん強いです。
スプリントの実績はどうやって数値化する？
即答
ベロシティ・リードタイム・障害率・参加人数など、前後の変化を数字で書くと実績になります。
「数字なんて出せる成果がない」とよく言われます。私も同じことを思っていました。でもスクラムは、実は数字の宝庫なんです。毎スプリント回しているなら、変化の前後が必ずどこかに残っています。
使いやすいのは、ベロシティの安定、リリースのリードタイム、レビュー指摘の数、デプロイ頻度あたりです。たとえば「リリースまでのリードタイムを平均10日から6日へ短縮」「レトロで決めた改善で、手戻りを月8件から3件へ」のように、ビフォーアフターで書く。絶対値が出せないときは「約4割短縮」と割合でもかまいません。
大事なのは、数字に「なぜ動いたか」を一言添えることです。数字だけだと運に見えますが、「CIを整えてテスト時間を短縮した結果」と添えると、再現性が伝わります。最初に数字を出すのは少し怖いですが、面接で深掘りされたとき、自分の言葉で語れる数字ほど強い味方になります。
アジャイル経験はどんな手順で書く？例文も知りたい
即答
「役割→担当工程→開発環境→数字の成果」の順に1〜2文ずつ並べると、そのまま職務経歴書に使えます。
型が決まると、書くハードルがぐっと下がります。まずは下の5手順で骨組みを作り、それから言葉を整えるのが近道です。
下の記入見本は、スクラム開発者の職務経歴書を1枚にまとめたものです。冒頭の職務要約で手法と年数、案件欄で役割と数字、という流れを目で確認してみてください。
例文も置いておきます。開発者ならこんな形です。「自社SaaSの開発チーム（5名）にバックエンド開発者として参画。2週間スプリントで要件詳細化から実装・運用までを担当。GoとAWSを用い、リリースのリードタイムを平均10日から6日へ短縮。」
スクラムマスター寄りならこうです。「チーム6名のスクラムマスターとして、デイリー・レビュー・レトロの進行を担当。妨害要因の可視化と優先度調整により、スプリントの計画達成率を6割から9割前後へ改善。」役割・工程・環境・数字、この順番を崩さないのがスクラム経験のアピールのコツです。まずは1案件だけ、この型に流し込んでみてください。
アジャイル経験でやりがちなNGな書き方は？
即答
手法名の羅列・「チームで開発」止まり・ツール名だけ、の3つが埋もれる典型パターンです。
頑張って書いたのに刺さらない人には、共通点があります。私が添削で何度も見てきたのは、次の3つです。
- 手法名だけ並べて中身がない
- 「チームで開発しました」で主語が消える
- JIRA・GitHubなどツール名だけで成果がない
どれも「やったこと」は書いてあるのに、「何が良くなったか」が抜けています。華やかに見せる必要はありません。NGを1つずつ「役割＋数字」に置き換えるだけで、拍子抜けするくらい読みやすくなります。
もし自分の書類がこのパターンに当てはまっていそうなら、第三者の目を借りるのが近道です。IT・Web・ゲーム領域に特化した転職エージェントのギークリー（Geekly）は、エンジニアの職務経歴書を数多く見ています。アジャイル経験を職務経歴書でアピールする際の見せ方を案件単位で相談できるので、自分だと気づけない「埋もれポイント」を拾ってもらえます。
提出前に何をチェックすればいい？
即答
役割が立場名で書けているか・各案件に数字が1つあるか・理由が添えてあるか、を出す前に確認します。
提出ボタンを押す前に、30秒だけ見直す時間をとってください。ここで直せると、面接での説明もぐっと楽になります。最後に見るのは、難しい項目ではありません。
この4つを満たしていれば、読み手は「再現できる人」として受け取りやすくなります。逆に1つでも欠けると、せっかくの経験が伝わりきりません。完璧を目指すより、欠けている1項目を埋めるほうが結果に直結します。
よくある質問
Q. アジャイル経験はスクラムマスターでなくても書ける？
A. 書けます。開発者としてスプリントで担当したポイント数や、レビュー・改善の動きを書けば十分に伝わります。立場を明示することが大切です。
Q. 数字が出せないアジャイル経験はどう書く？
A. 絶対値が難しければ割合や頻度で代用します。「手戻りを約4割削減」「デプロイを週1回から日次へ」のように、前後の変化で表すと実績として読めます。
Q. 複数案件で同じスクラム経験がある場合は全部書く？
A. 直近5年を中心に、役割や規模が違う案件を選んで書きます。同じ内容の繰り返しは1つにまとめ、技術や規模の幅が伝わる構成にすると読みやすくなります。
次のアクション
IT転職は順番に進めると迷いが減ります。全体像の確認と、自分の市場価値の把握から始めてみてください。
次に読む
この記事と近いテーマの記事です。続けて読むと理解が深まります。
守秘義務・NDAで案件名が書けないエンジニアの職務経歴書の書き方：プロジェクトを抽象化して実績を伝える
守秘義務やNDAで案件名が書けないエンジニア向けに、職務経歴書で実績を抽象化して伝える方法を解説。業界・規模・役割・工程・使用技術・数字の成果に置き換える手順と記入見本、やりがちなNGまでミナが実例で紹介します。
職務経歴書の「活かせる経験・知識・技術」欄の書き方：ミドルエンジニアが応募先ごとに刺す要約と例文
職務経歴書の「活かせる経験・知識・技術」欄で手が止まるミドルエンジニア向けに、役割・工程・技術・数字成果の4要素と、応募先ごとに書き分ける5ステップ、SaaSバックエンド求人を想定した記入見本・例文まで、ミナがやさしく解説します。
40代ITエンジニアの職務経歴書の書き方：年齢を強みに変える経験の絞り込みと項目設計【テンプレ付き】
40代エンジニアの職務経歴書は、書きすぎが最大の落とし穴。直近5年への絞り込み、判断と数字の見せ方、項目設計、やりがちなNGの直し方を、記入見本テンプレ付きで編集者ミナが解説します。