アジャイルコーチのフリーランス案件で求められるスキルと経験

アジャイルコーチの案件で見られるのは、複数の進め方を理解して組織に合わせる力、組織の中で仕事が止まる場所を見立てる力、コーチングとファシリテーション、経営層や他部署に働きかける力、技術的な実践への理解です。どれも1つのチームの中だけで完結しない点が、スクラムマスターに求められるスキルとの違いです。

ただし、すべてを最初からそろえている人は多くありません。案件では、支援の範囲がチームか、複数チームか、組織全体かによって、重く見られるスキルが変わります。この記事では、分野ごとのスキルと、経験の段階ごとに求められる水準を整理します。1つのチームを支えるスキルはスクラムマスターのスキルの記事で扱っています。

案件で求められるスキルの分野

1. 進め方の原理を理解し、組織に合わせる力

アジャイルソフトウェア開発宣言の4つの価値（プロセスやツールよりも個人と対話を、など）と、その背後にある原則を、自分の言葉で説明できることが土台です。そのうえで、スクラム、カンバン、XP（エクストリーム・プログラミング）など、複数の進め方の考え方を知り、組織の状況に合わせて選んだり組み合わせたりする力が問われます。

IPA（情報処理推進機構）の「アジャイル開発の進め方」は、唯一の正しいアジャイル開発はなく、実際のプロジェクトや組織に適したやり方を取捨選択し、カスタマイズすることが必要だと書いています。一方で、同じIPAの「アジャイルプロジェクト実践ガイドブック」は、スクラムであればスクラムガイドで定義されたイベントや役割を網羅して始めるべきだとし、原理原則以外は変わってよいとしています。変えてよいところと崩してはいけないところを見分ける力が、コーチの判断の中心になります。

複数のチームで1つのプロダクトを作る場合の考え方も押さえておきたい分野です。スクラムガイドは、チームが大きくなりすぎたら、同じプロダクトゴール・プロダクトバックログ・プロダクトオーナーを共有する複数のスクラムチームに分けることを検討するよう書いています。大規模向けの枠組みは、案件の組織で使われているものを中心に理解しておくと会話がかみ合います。

2. 組織を見立てる力

チームの外で仕事が止まる場所を見つける力です。たとえば次のような点を観察し、関係者と共有できる形にまとめます。

• 依頼から提供までの流れのうち、待ち時間が長い工程
• チーム間の依存関係と、調整にかかっている手間
• 予算の付け方、承認の流れ、評価の仕組みが、短い周期の進め方と合っているか
• プロダクトオーナーに判断の権限が実際に渡っているか

IPAの冊子「組織を幸せにする組織アジャイル5つの原則」は、複数のアジャイルプロジェクトがうまく連携できていない、企業活動とアジャイルチームがかみ合っていないといった問題意識から作られたものです。方向性、協働、敬意、成長、事業の5つの観点が示されており、組織の状態を見立てるときの手がかりになります。

3. コーチング・ファシリテーション・教える力

相手に答えを渡すのではなく、問いかけで考えを引き出すコーチング、多くの関係者が集まる場で合意をつくるファシリテーション、基本を短い時間で伝える研修やワークショップの力です。コーチの場合は、相手がチームのメンバーだけでなく、スクラムマスター、プロダクトオーナー、部門の責任者に広がります。相手の役割に合わせて、話の抽象度を変えられるかが見られます。

4. 経営層・他部署に働きかける力

アジャイルな進め方を広げると、品質保証、調達、人事、経理などの手続きとぶつかる場面が出てきます。それぞれの部署の立場と言葉を理解し、何を変えれば双方が困らないかを一緒に探る力が必要です。経営層に対しては、進め方の説明よりも、事業にとって何が変わるかを短く伝える力が求められます。

5. 技術的な実践への理解

IPAの「アジャイル開発の進め方」は、アジャイル開発の大原則として「人間中心」と「技術の尊重」を挙げています。コーチ自身がコードを書くとは限りませんが、テスト自動化、継続的インテグレーション、リファクタリングなどが、短い周期で価値を届けるうえでなぜ必要かを説明できると、チームと経営層の両方から信頼を得やすくなります。

6. 契約と体制への理解

発注側と開発を担う会社が分かれている現場では、契約の形が進め方に影響します。準委任契約で進めることが多いこと、発注側から受注側の担当者へ直接指示を出すと偽装請負と判断されるおそれがあることなどを理解し、体制づくりの段階で注意を促せると、発注側の安心につながります。

IPAは「情報システム・モデル取引・契約書（アジャイル開発版）」を公開しており、ユーザー企業がプロダクトオーナーを、ベンダー企業がスクラムマスターを選ぶ体制を想定しています（2026年10月時点）。こうしたひな形の考え方を知っておくと、発注側と受注側の役割分担を整理する場面で、具体的な話ができます。

経験の段階ごとに求められる水準

同じスキルでも、支援の範囲によって求められる水準が違います。次の表は、案件の型と照らし合わせて自分の位置を確かめるための目安です。

チーム横断の段階では、スクラムマスターとしての実践の深さがそのまま生きます。部門・組織の段階に進むほど、開発の外の人と話す経験の比重が高くなります。今の経験がどの列に近いかを確かめ、次の列の経験を1つずつ増やしていくと、応募できる案件の幅が広がります。独立の進め方はアジャイルコーチがフリーランスになるにはで解説しています。

スキルを面談で示す方法

スキルは、名前を並べるより、場面とセットで話すほうが伝わります。分野ごとに、次のような形で1つずつ用意しておきます。

1. 見立て：何を観察して、どこが止まっていると判断したか
2. 打ち手：誰と、どんな場をつくり、何を変えたか
3. 変化：支援の前と後で、何が違ったか（数字にできるものは伏せられる範囲で）
4. 引き継ぎ：誰に何を渡し、その後どうなったか

面談でよく聞かれる質問全般は業務委託の面談でよく聞かれる質問にまとめています。スキルシートへの落とし込み方はアジャイルコーチのスキルシートの記事をご覧ください。

よくある質問

アジャイルコーチとスクラムマスターのスキルはどう違いますか？

土台は重なりますが、使う相手と範囲が違います。スクラムマスターは主に1つのスクラムチームと、その周りの関係者を支えます。アジャイルコーチの案件では、複数のチーム、部門、経営層、開発以外の部署まで相手が広がるため、組織の見立てと、他部署への働きかけの比重が高くなります。

大規模アジャイルの枠組みの経験は必須ですか？

必須とは限りません。案件の組織がすでに特定の枠組みを使っている場合は、その経験が評価されやすくなります。一方で、枠組みを導入すること自体より、複数のチームの連携が実際に良くなったかが見られます。名前のついた枠組みの経験がなくても、複数チームの計画や依存関係を整えた経験があれば、具体的に話しましょう。

開発経験がなくてもアジャイルコーチの案件に入れますか？

入れる案件はありますが、技術的な実践の意味を説明できることは求められやすくなります。テスト自動化や継続的インテグレーションが、なぜ短い周期の進め方に必要かを、チームと経営層の両方に説明できるようにしておくと、開発経験が少なくても信頼を得やすくなります。