KPTとは？意味・進め方・例をわかりやすく解説【図解・テンプレ付】

KPTとは、Keep（続けること）・Problem（問題）・Try（次に試すこと）の3つの枠で振り返りを整理するフレームワークのこと。

ホワイトボードや付箋さえあればその日から始められ、チームの「やりっぱなし」を次の改善につなげられます。

アジャイル開発の現場で広まり、今では営業・人事・バックオフィスなど職種を問わず使われています。

一方で、「やってはいるが何も変わらない」「反省会になって空気が重い」という声も少なくありません。

その原因の多くは、Tryが抽象的なまま、日々の業務に組み込まれていないことにあります。

本記事では、KPTの意味・由来から、他の振り返り手法との違い、6ステップの進め方、部署別の具体例、形骸化させないコツまでを図解で解説します。

すぐに使えるエクセルテンプレートも用意しました。

KPTとは？意味・読み方・由来をわかりやすく解説

KPTは、一定期間の仕事を振り返り、次に何をするかをチームで決めるための枠組みです。

まずは意味と読み方、そして生まれた背景を押さえましょう。

KPTの意味：振り返りを3つの枠で整理する

KPTは「Keep・Problem・Try」の頭文字で、振り返りを3つの観点に分けて整理するフレームワークです。

Keepは良かったことや続けたいこと、Problemは問題や困っていること、Tryは次に試すことを指します。

この順番で書き出すことで、「良い点を守る」「問題を直す」「次の行動を決める」が1回の話し合いで完結します。

振り返りというと反省ばかりになりがちですが、KPTは良かった点にも同じ重さで着目するのが特徴。

対象期間は、1週間のスプリントでも、1か月の営業活動でも、半年のプロジェクトでも構いません。

対象もチームに限らず、個人の週次振り返りや、上司と部下の1on1でも使えます。

構造が単純で業種を選ばないことが、KPTがこれほど広く使われている理由です。

枠	書く内容	問いかけの例
Keep（キープ）	良かったこと・続けること	うまくいったことは？次も続けたいことは？
Problem（プロブレム）	問題・困っていること	うまくいかなかったことは？困っていることは？
Try（トライ）	次に試すこと	問題を解決するには？良い点をさらに伸ばすには？

読み方は「ケーピーティー」または「ケプト」

KPTは「ケーピーティー」と読むのが一般的で、現場では「ケプト」と呼ばれることもあります。

どちらの読み方も広く使われており、意味に違いはありません。

チームで「KPTをやる」と決めたら、呼び方と目的を最初に共有しておくとスムーズです。

また、「KPT法」「KPTフレームワーク」「KPT振り返り」など呼び方もさまざまですが、指しているものは同じです。

Actionを加えた「KPTA（ケーピーティーエー）」という派生形もあり、後ほど詳しく解説します。

社外の人と話すときは「KPT（Keep・Problem・Try）」と正式な語を添えると、誤解なく伝わります。

KPTの由来：アジャイル開発の「ふりかえり」から広まった

KPTは、アジャイル開発の提唱者の一人であるアリスター・コーバーン氏の「ふりかえり」の手法が原型とされています。

コーバーン氏は、著書『Crystal Clear』で、チームが定期的に集まって働き方を見直す「Reflection Workshop（ふりかえりワークショップ）」を紹介しました。

そこでは「続けること」「問題」「試すこと」を書き出す形式がとられており、これがKPTの原型になったとされています。

日本では、アジャイル開発のコミュニティを通じて「KPT」という呼び名とともに広まりました。

たとえば、平鍋健児氏のブログ記事「アジャイルの肝『ふりかえり』ワークショップ開催」（2006年）では、「KPT法」を徹底的に学ぶワークショップが紹介されています。

その後、ソフトウェア開発にとどまらず、一般のビジネス現場へと浸透していきました。

スクラムのレトロスペクティブとの関係

KPTは、スクラムの「スプリントレトロスペクティブ（振り返り）」を進める具体的なやり方として、よく使われています。

スクラムガイドは、スプリントレトロスペクティブの目的を「品質と効果を高める方法を計画すること」と定めています。

チームは「何がうまくいったか、どのような問題が発生したか」を話し合い、改善に最も役立つ変更を特定します。

この流れは、Keep・Problemを出してTryを決めるKPTの構造とほぼ同じ。

また、『アジャイル宣言の背後にある原則』のページにも「チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します」と書かれています。

IPA（情報処理推進機構）の『アジャイル開発の進め方』のページでも、ふりかえりは代表的なプラクティスの一つとして紹介されています。

KPTは、この「定期的な振り返り」を特別な知識がなくても実践できる形にした道具だといえます。

KPTを構成する要素（Keep・Problem・Try・KPTA）

KPTの3つの枠は、それぞれ役割がはっきり分かれています。

各枠で「何を書くか」「よくある誤解」「具体例」をセットで押さえておくと、実際の振り返りで迷わずに済みます。

あわせて、Tryを実行計画まで落とし込む派生形のKPTAも紹介します。

ボードは「左上Keep・左下Problem・右Try」の配置が定番です。
KeepとProblemを見ながらTryを考えられるよう、Tryの枠を一番大きくとります。

Keep（キープ／良かったこと・続けること）とは？

Keepは、対象期間の活動で「うまくいったこと」「次も続けたいこと」を書き出す枠です。

成果が出た行動だけでなく、トラブルを未然に防げた工夫や、チームの雰囲気を良くした小さな習慣も対象になります。

「なぜうまくいったのか」まで言葉にしておくと、偶然の成功を再現できる仕組みに変えられます。

Keepを最初に書く理由は、振り返りを「反省会」にしないため。

いきなり問題点から話し始めると、場が重くなり、発言が減りがちです。

先に良かった点を共有すると、メンバーは自分の貢献が認められたと感じ、その後のProblemも率直に出しやすくなります。

また、Keepは放っておくと失われやすい資産でもあります。

忙しい時期に「いつの間にかやらなくなった良い習慣」を守るためにも、明文化して残しておく価値があります。

誤解されやすい点：Keepは「褒め合う時間」ではありません。
次も意図して続けるべき行動を特定し、チームの標準にすることが目的です。

Problem（プロブレム／問題・困っていること）とは？

Problemは、対象期間に起きた問題や、うまくいかなかったこと、困っていることを書き出す枠です。

実際に発生したトラブルだけでなく、「このままだと起きそうな不安」や「なんとなく非効率だと感じていること」も含めて構いません。

大切なのは、人ではなく出来事や仕組みに焦点を当てること。

Problemの質を上げるコツは、感想ではなく事実で書くことです。

「連携が悪かった」と書くと原因が特定できませんが、「仕様変更がチャットでしか共有されず、3日間古い仕様で作業していた」と書けば、打ち手が見えてきます。

「誰が悪いか」ではなく「何がそうさせたか」を問うのが原則です。

個人を責める空気になると、次回からProblemが出なくなり、KPTそのものが形だけになってしまいます。

誤解されやすい点：Problemは「反省点を並べる場」ではありません。
改善につながる課題を見つけるための入力であり、愚痴の言い合いで終わらせないことが重要です。

Try（トライ／次に試すこと）とは？

Tryは、KeepとProblemを踏まえて、次の期間に試す具体的な改善策を書き出す枠です。

Problemを解決する策だけでなく、Keepをさらに伸ばす策もTryになります。

Tryは「決意表明」ではなく、次回の振り返りで「やったか・効いたか」を確認できる行動であることが条件。

KPTの成否は、ほぼTryの書き方で決まります。

「コミュニケーションを良くする」「気をつける」といった抽象的なTryは、誰も実行できず、次回また同じProblemが出る原因になります。

「仕様変更は必ずタスク管理表のコメント欄に書き、担当者をメンションする（担当：田中、来週月曜から）」のように、行動・担当・期限まで落とし込みましょう。

Tryを「やってみる実験」と捉えると、失敗を恐れず挑戦しやすくなります。

効果がなければ次回のKPTでやめればよいのです。

誤解されやすい点：Tryは多ければ良いわけではありません。
実行できる数は限られるため、1回のKPTで決めるTryは2〜3個までに絞るのが現実的です。

KPTA（ケーピーティーエー／Actionを加えた派生形）とは？

KPTAは、KPTに「Action（具体的な行動）」を加え、Tryを実行計画まで落とし込む派生フレームワークです。

Tryが「何に挑戦するか」という方針だとすれば、Actionは「誰が・何を・いつまでにやるか」というタスク。

TryとActionを分けることで、決めたのに実行されないという、KPTで最も多い失敗を防ぎやすくなります。

KPTを続けているのに成果が出ないチームの多くは、Tryが会議室の中で終わっています。

KPTAでは、Tryごとに担当者と期限を割り当て、通常業務のタスクと同じ場所で管理しましょう。

そうすれば、改善策が日々のタスクの中に組み込まれ、自然に実行されるようになります。

誤解されやすい点：KPTAは別物の手法ではなく、KPTのTryを実行に落とし込む部分を強調した呼び方です。枠を増やすこと自体が目的ではありません。

KPTの進め方6ステップ【テンプレート付】

KPTは、準備から担当決めまでの6ステップで進めると、毎回安定した振り返りができます。

特に大切なのは、最初の「前回Tryの確認」と、最後の「担当と期限を決める」ステップです。

事前準備：テーマ・時間・ルールを決める

KPTを始める前に、振り返りの対象（テーマと期間）、時間配分、話し合いのルールを決めておきましょう。

テーマが広すぎると論点が散らばるため、「今月の新規案件の進め方」「先週のリリース作業」のように対象を絞りましょう。

道具は、ホワイトボードと付箋、またはオンラインのホワイトボードツールや共有スプレッドシートで十分。

話し合いのルールとしては、振り返りの分野で広く知られるNorm Kerth氏の『最優先指令（Prime Directive）』が参考になります。

これは、何が見つかっても、当時の知識や状況の中で全員が最善を尽くしたと信じるという前提です。

冒頭でこの考え方を共有するだけで、人を責める空気をかなり防げます。

準備項目	決める内容の例
テーマ・期間	9月の新規案件対応（9/1〜9/30）
参加者	営業チーム5名＋ファシリテーター1名
時間	60分（確認10分・Keep/Problem20分・Try25分・まとめ5分）
ツール	ホワイトボード＋付箋、またはオンラインボード
ルール	人を責めない・最後まで聞く・事実で書く

当日の進め方：6ステップ

当日は「前回Tryの確認 → Keep → Problem → Try → 担当と期限」の順に進めます。

1. 準備・ルールの共有（5分）：テーマ・時間配分・ルールを全員で確認する
2. 前回Tryの確認（10分）：前回決めたTryが実行されたか、効果はあったかを確認する
3. Keepを出す（10分）：各自が付箋に書き、1人ずつ読み上げながら貼る
4. Problemを出す（10分）：事実ベースで書き、似た内容はグループにまとめる
5. Tryを決める（15〜20分）：重要なProblemとKeepから改善策を出し、2〜3個に絞る
6. 担当と期限を決める（5分）：Tryごとに担当者・期限・次回の確認方法を決める

KeepとProblemは、最初の数分は各自が黙って書き、そのあとで共有するのがコツです。

いきなり口頭で話し合うと、声の大きい人の意見に引っ張られやすくなるからです。

Tryを考える時間は、全体の3分の1以上を確保すると、具体的な行動まで落とし込めます。

そのまま使えるKPTテンプレート（エクセル・CSV）

区分・内容・背景・担当者・期限・次回確認の6列で管理すると、Tryの実行状況まで追いかけられます。

ホワイトボードで出した内容は、終わったあとに表に転記して残しておきましょう。

次のテンプレートは、Tryに担当者と期限を書く列をあらかじめ用意しているのが特徴です。

コピーしてCSVとして保存するか、エクセルファイルをダウンロードしてお使いください。

区分,内容（事実で具体的に）,背景・理由,担当者,期限,次回確認
Keep,朝会で各自の優先タスクを30秒で共有した,作業の重複がゼロになった,全員,継続,○
Keep,顧客への回答テンプレートを共有フォルダに置いた,新人でも回答品質がそろった,鈴木,継続,○
Problem,見積もり承認待ちで平均2日止まった,承認ルールが決まっていない,－,－,－
Problem,仕様変更がチャットのみで共有され手戻りが出た,変更の記録場所がない,－,－,－
Try,承認は24時間以内に返し、超過時は自動リマインド,Problem1への対策,課長,来週金曜,次回KPT
Try,仕様変更はタスク管理表のコメントに残し担当をメンション,Problem2への対策,田中,来週月曜,次回KPT

↑をコピーして「kpt-template.csv」として保存し、エクセル／スプレッドシートで開けばそのまま使えます（文字化けする場合は文字コードを UTF-8 で開く）。区分の列に Keep / Problem / Try を入れ、Tryの行だけ担当者と期限を必ず埋めます。

頻度・所要時間・人数の目安

KPTは「短く・定期的に」が基本です。
1回30〜60分、2週間〜1か月に1回を目安にしましょう。

スクラムガイドでは、1か月のスプリントならスプリントレトロスペクティブは最大3時間とされ、スプリントが短ければ時間も短くするのが一般的とされています。

通常の業務チームであれば、そこまで長い時間は必要ありません。

振り返る期間が短いほど、記憶が新しく、Tryも小さく試しやすくなります。

項目	目安	補足
頻度	2週間〜1か月に1回	開発はスプリントごと、営業は月次が多い
所要時間	30〜60分	プロジェクト終了時の大きな振り返りは90分程度
人数	3〜8名	多い場合はグループに分けて最後に共有
Tryの数	2〜3個	実行できる数に絞る

KPTのメリット・デメリット

KPTは手軽に始められる一方で、運用を誤ると効果が出にくい面もあります。

導入前に、メリットと注意点の両方を把握しておきましょう。

KPTの4つのメリット

KPTの最大のメリットは、特別な準備や知識がなくても、今日から振り返りを「次の行動」につなげられることです。

1つ目は、シンプルで、今日からすぐに始められることです。

3つの枠を理解するだけで実践でき、ファシリテーションの経験が浅いリーダーでも進行できます。

2つ目は、良い点と問題点の両方を共有できること。

Keepがあるおかげで、成功体験がチームの共有財産になり、メンバーのモチベーションも保ちやすくなります。

3つ目は、次の行動が明確になること。

振り返りの終わりに必ずTryを決めるので、話し合いが「言いっぱなし」で終わりにくくなります。

4つ目は、定期的に繰り返すことで改善が習慣になることです。

小さなTryの積み重ねが、チームの仕事の進め方を少しずつ底上げしていきます。

1. シンプル：3つの枠だけで、経験が浅くても進行できる
2. 両面の共有：成功も問題もチームの学びになる
3. 行動が明確：毎回Tryという「次の一手」が残る
4. 改善の習慣化：繰り返すほどチームが自律的に良くなる

KPTのデメリット・注意点

KPTの弱点は、進め方を誤ると「反省会」や「やっただけ」になりやすい点です。

よくある失敗の1つ目は、Problemに議論が集中し、特定の人を責める反省会になってしまうことです。

責められる場になると、次回から誰も本当の問題を書かなくなります。

2つ目は、Tryが「気をつける」「意識する」といった抽象的な言葉で終わることです。

誰が何をするのかが決まっていないTryは、まず実行されません。

3つ目は、継続しなければ効果が出にくいことです。

一度きりのKPTでは、チームの仕事の進め方はほとんど変わりません。

また、KPTは「振り返り」の手法であり、根深い問題の原因を分析する手法ではありません。

複雑な問題は、KPTで論点を見つけたうえで、時間を設けて原因分析をするのが現実的です。

注意点	起きること	対策
反省会になる	発言が減り、本当の問題が出なくなる	人ではなく出来事に注目するルールを共有
Tryが抽象的	何も実行されず、同じProblemが繰り返す	担当と期限まで決める
継続されない	改善が定着せず、効果を実感できない	開催日を固定し、前回Tryの確認から始める
原因分析と混同	1つの問題に時間を使い、Tryが決まらない	深掘りは別の場に切り出す

KPTの具体例（開発・営業・個人）

KPTは、書き方の具体例を見るとイメージしやすくなります。

ここでは、開発チーム・営業チーム・個人の3つの場面で、実際に使える記入例を紹介します。

開発チームの例（スプリントの振り返り）

開発チームでは、スプリントごとにKPTを行い、Tryを次のスプリントの作業に組み込むのが定番です。

スクラムガイドにもあるとおり、改善策は次のスプリントバックログに追加できます。

Tryを「作業」として計画に入れることで、改善が後回しにされるのを防げます。

→ 表は横にスクロールできます

営業チームの例（月次の振り返り）

営業チームでは、月次の数字だけでなく「進め方」を振り返るのにKPTが役立ちます。

営業の振り返りは、売上や件数の結果だけで終わりがち。

KPTを使うと、結果の裏にある行動に目を向けることができ、成果を出したメンバーのやり方をチーム全体に広げられます。

→ 表は横にスクロールできます

個人・1on1の例（週次の振り返り）

KPTは、個人の週次振り返りや、上司と部下の1on1でもそのまま使えます。

個人で使う場合は、金曜日の終業前に10分ほどで書くのがおすすめ。

1on1で使う場合は、部下が事前にKPTを書いてきて、上司はProblemとTryの相談に乗る形にすると、話す内容が具体的になります。

上司がProblemを評価や叱責の材料にしないことが、継続的にKPTを実行する上での前提です。

枠	記入例
Keep	午前中の2時間を集中作業の時間にしたら、資料作成が早く進んだ
Problem	急な依頼を全部引き受け、自分の締め切りが2件遅れた
Try	依頼を受けるときは、今のタスクと期限を見せて優先順位を相談する（来週から）

KPTとYWT・PDCAなど他の振り返り手法との違い

振り返りの手法はKPT以外にもいくつかあります。

どれが優れているというより、目的に合わせて使い分けるのが正解です。

代表的な手法とKPTの違いを整理しましょう。

主な振り返り手法の比較

KPTは「良い点・問題・次の行動」をバランスよく扱える、汎用性の高い手法です。

→ 表は横にスクロールできます

迷ったら、まずKPTから始めるのがおすすめ。

観点がシンプルで、良い点と問題点の両方を扱えるため、多くのチームでそのまま機能します。

慣れてきたら、目的に応じて他の手法を試してみましょう。

KPTとPDCAの違い：振り返りの「場」と改善の「サイクル」

PDCAは改善のサイクル全体を指し、KPTはそのうち「振り返って次を決める」場面で使う手法です。

PDCAは、計画（Plan）から実行（Do）、評価（Check）、改善（Action）までを一つのサイクルとして回す考え方です。

一方のKPTは、計画がなくても、起きた事実から次の行動を決められる点が異なります。

両者は対立するものではなく、組み合わせて使えます。

たとえば、PDCAのCheck（評価）とAction（改善）の場面でKPTを使えば、評価が感想で終わらず、具体的な次の手につながります。

計画を立てるのが難しい新規業務や、変化の速い仕事では、KPTを単独で回すほうが向いていることもあります。

観点	KPT	PDCA
位置づけ	振り返りのフレームワーク	改善のサイクル（管理手法）
起点	起きた事実・出来事	立てた計画
主な使いどころ	定例の振り返り会	業務・プロジェクト全体の管理
組み合わせ	PDCAのC・Aの場面で使える	KPTのTryを次のPlanに反映できる

KPTとYWTの違い：行動の改善か、学びの言語化か

YWTは「経験から何を学んだか」に重心があり、KPTは「チームの行動をどう変えるか」に重心があります。

YWTは、日本能率協会コンサルティングが提唱した振り返り手法で、「やったこと（Y）・わかったこと（W）・次にやること（T）」の順に整理します。

やったことを時系列で振り返り、そこから得た気づきを言葉にする流れなので、研修や新人育成と相性が良い手法です。

一方、KPTはProblemという「問題」の枠を明確に持っています。

そのため、チームの仕事の進め方を具体的に直したい場面ではKPTのほうが使いやすいでしょう。

個人の学びを深めたいときはYWT、チームの改善を進めたいときはKPT、と使い分けるのがおすすめです。

KPTを形骸化させないコツとチームでの運用

KPTは始めるのは簡単ですが、続けて成果を出すには少しの工夫が必要です。

ここでは、形骸化を防ぐコツと、決めたTryをチームで確実に実行するための運用のコツを紹介します。

心理的安全性を確保する

本音のProblemが出るかどうかは、「発言しても責められない」という安心感で決まります。

Googleが社内のチームを調査したre:Work『効果的なチームとは何か』では、効果的なチームの条件として「心理的安全性」が最も重要だと報告されています。

KPTでも、人ではなく出来事や仕組みに焦点を当てるルールを徹底することが、良いProblemを引き出す近道。

ファシリテーターは、発言を途中でさえぎらない、Problemを書いた人を責めるような発言が出たら軌道修正する、といった役割を担います。

役職が高い人が最初に自分のProblemを出すと、メンバーも話しやすくなります。

振り返りの進め方をさらに深めたい場合は、Esther Derby氏とDiana Larsen氏の『Agile Retrospectives』が体系的な参考書になります。

よくある失敗パターンと対策

形骸化したKPTには共通のパターンがあります。早めに気づいて手を打ちましょう。

→ 表は横にスクロールできます

中でも多いのが、前回決めたTryを誰も確認しないまま、新しいKPTを始めてしまうこと。

次回のKPTを「前回のTryはどうだったか」から始めるだけで、Tryの実行率は大きく変わります。

振り返りを組織の仕組みにする

KPTを個人の頑張りに頼らず続けるには、定例会議や報告の仕組みに組み込むのが効果的。

組織の生産性向上には、定例会議の設定や報告フォーマットの整備といった「コミュニケーションの整備」と、チームのタスク管理が欠かせません。

KPTも、定例会議の議題として固定し、決めたTryをチームのタスクとして見える化してこそ、組織の習慣になります。

その中でも、タスクの見える化は最優先事項。

KPTで見つけた改善策も、チーム全員が見える場所で進捗を追える状態にすることで、初めて実行に移されます。

Tryを「タスク」に変換して、日々の業務で追いかける

Tryは会議の議事録に残すだけでなく、担当者と期限を付けて通常のタスクと同じ場所で管理しましょう。

KPTで決めたTryが実行されない最大の理由は、日々の業務のタスクとは別の場所に置かれていること。

議事録やボードの写真に残っていても、忙しい日常の中では誰も見返しません。

Tryを「誰が・何を・いつまでに」行うタスクとして、普段使っているタスク管理の仕組みに登録することが大切です。

そうすれば、期限が近づいたときに担当者が気づけますし、次回のKPTでも実行状況をすぐに確認できます。

これはKPTAの考え方そのものであり、振り返りと日々の業務をつなぐ一番の近道です。

KPTに関するよくある質問

KPTについて、よく寄せられる質問をまとめました。

KPTの読み方は？

「ケーピーティー」と読むのが一般的です。現場では「ケプト」と呼ばれることもあり、どちらも同じものを指します。

KPTはどのくらいの頻度で行うのがよいですか？

2週間〜1か月に1回、30〜60分程度が目安です。開発チームならスプリントごと、営業チームなら月次で行うケースが多く見られます。期間が短いほど記憶が新しく、Tryも試しやすくなります。

KPTとKPTAの違いは何ですか？

KPTAは、KPTに「Action（具体的な行動）」を加えた派生形です。Tryで決めた方針を、担当者と期限つきのタスクに落とし込むことで、決めたことが実行されない失敗を防ぎます。

KPTとPDCAはどう違いますか？

PDCAは計画から改善までを回すサイクル全体を指し、KPTは起きた事実を振り返って次の行動を決める手法です。PDCAのCheck・Actionの場面でKPTを使うなど、組み合わせて活用できます。

Problemが出にくいときはどうすればいいですか？

人ではなく出来事に注目するルールを最初に共有し、各自が黙って付箋に書く時間をとりましょう。上司やリーダーが先に自分のProblemを出すのも効果的です。

KPTは1人でも使えますか？

使えます。週末に10分ほどで、その週のKeep・Problem・Tryを書き出すだけでも、仕事の進め方を見直す習慣が身につきます。

まとめ：KPTは「Tryを実行する仕組み」までセットで行う

KPTは、Keep・Problem・Tryの3つの枠で振り返り、次の行動を決めるシンプルなフレームワークです。

アジャイル開発の「ふりかえり」から広まり、今では職種を問わず使われています。

KPTを成果につなげるポイントは、人を責めない場をつくること、Tryを具体的な行動にすること、そしてTryを日々のタスクとして追いかけること。

まずは次の定例会議で30分だけ時間をとり、テンプレートを使って最初のKPTを試してみてください。

参考文献・出典

• 小松裕介『1+1が10になる組織のつくりかた ── チームのタスク管理による生産性向上』実業之日本社、2025年、ISBN 978-4-408-65143-9
• Alistair Cockburn『Crystal Clear: A Human-Powered Methodology for Small Teams』（Addison-Wesley）
• 平鍋健児「JaSST大阪で、アジャイルの肝『ふりかえり』ワークショップ開催」（An Agile Way、2006年）
• スクラムガイド（2020年版・日本語）
• アジャイル宣言の背後にある原則
• アジャイルソフトウェア開発宣言
• IPA（情報処理推進機構）「アジャイル開発の進め方」
• Norm Kerth「The Prime Directive（最優先指令）」
• Google re:Work「効果的なチームとは何か」
• Esther Derby・Diana Larsen『Agile Retrospectives』（Pragmatic Bookshelf）
• 日本生産性本部「労働生産性の国際比較」
• 中小企業庁『2024年版 中小企業白書』