どのスケーリングモデルにも柔軟に対応します！

SAFeは規範的なフレームワークで、複数の構成（Essential、Large Solution、Portfolio、Full）を備え、Release Train Engineer、Solution Architect、Product Managementといった新しい役割を追加します。LeSSは意図的に最小限で、標準的なScrumの役割を維持し、1人のProduct Ownerと1つのProduct Backlogを用い、プロセスではなくチームを増やすことでスケールします。規制の厳しいエンタープライズ環境ではSAFeを、余分なセレモニーを避けたい単一プロダクトの組織ではLeSSをお選びください。

関連はあるものの結合度の低い作業に2〜9チームで取り組んでいて、依存関係や障害を洗い出す定期的な同期があれば十分な場合は、Scrum of Scrumsが適しています。人数が50名前後を超える、単一のプロダクトを共有する、複数チームでカデンスに基づくプランニングが必要になる、といった段階に入ればScrum of Scrumsでは手狭であり、SAFe、LeSS、またはTribeモデルの検討をおすすめします。

Spotifyモデルは、自律的なSquad（少人数のクロスファンクショナルチーム）を軸に仕事を編成し、それらをTribe（同じプロダクト領域を担当するSquadの集まり）にまとめます。ChapterはSquadをまたいで同じスキルを持つ人をつなぎ、GuildはTribeを越えた関心コミュニティです。規範的なフレームワークではなく構造上のパターンであり、多くの組織はそのまま採用するのではなく大きくアレンジして取り入れています。

4つの観点でモデルを見極めてください。規模（チーム数と人数）、プロダクトの結合度（単一プロダクトか、独立した複数プロダクトか）、規制環境（コンプライアンス要件が重い環境ではSAFeの構造が向いています）、そして既存の文化（自律性を重んじる文化は重厚なフレームワークを嫌います）です。まずはScrum of ScrumsやLeSSのように軽く始め、調整コストがデリバリーを上回ったときにだけ構造を足していきましょう。

はい。成熟した組織の多くは最終的にハイブリッドに行き着きます。よくあるパターンは、カデンスと予算配分にはプログラム／ポートフォリオレベルでSAFeを用い、Agile Release Train内のチームレベルの自律性はTribeとSquadで担い、各チーム内ではScrumまたはKanbanを使うというものです。リスクは一貫性の欠如です。1つのモデルを背骨として選び、他のモデルからは偶然ではなく意図的に取り入れてください。

JiraはチームレベルのScrumとKanbanには十分対応していますが、Agile Release Train、PI Planning、チーム間の依存関係、Solution Trainといったプログラムレベルの概念をネイティブに扱うことはできません。Kendisはその隙間を埋めます。JiraおよびAzure DevOpsと双方向に同期したうえで、リアルタイムのProgram Board、依存関係マップ、Solutionレベルビューを上に重ねて提供します。

Kendisはフレームワーク非依存です。標準テンプレートで、SAFe（Program、Solution、Portfolioの各ボード）、LeSS（全プロダクトチームを1つのボードに集約）、Scrum of Scrums（Scrum of Scrum of Scrumsへ自動拡張するMeta Scrumボード）、Spotify Tribeモデル（Tribeに整合したSquadとOKRのロールアップ）をカバーします。独自のスケーリングモデルを運用している企業向けに、ボード、レイアウト、KPIを完全にカスタムで構築することもできます。

アウトプットよりもアウトカムを追跡してください。PIの予測可能性（コミットした目標に対する達成状況）、チーム間の依存関係の解消率、コミットから本番までのリードタイム、リリースに紐づくビジネスKPI（NPS、リリースあたりの売上、顧客のアクティベーション）などです。ストーリーポイントのスループットはチームレベルのシグナルとしては有用ですが、大規模な組織の主要指標にすべきではありません。

3〜5チームの小規模な組織であれば、3〜6か月で導入できます。数百チームを抱える大企業では、安定稼働に至るまで通常12〜24か月を要し、その後も継続的な進化が必要です。技術的な展開は簡単な部分で、時間の大半はリーダーシップの整合、役割の明確化、そして文化の変革に費やされます。