企画・製品のKPTとペルソナのアップデート

• 日程: Day 22 / セッション 1
• 時間: [9:30-10:15]
• 形式: 演習
• ゴール: 企画・製品の課題を洗い出し、KPT（Keep/Problem/Try）形式でまとめ、今後の開発方針としてペルソナをアップデートできる
• 学習形式: グループワーク（AIサポートあり）

成果発表会、お疲れさまでした。22日間の最終日です。

今日のテーマは「振り返り」です。ここで少し考えてみてください。プロジェクトは発表が終わったら「おしまい」でしょうか？

実務では違います。リリースは「終わり」ではなく「次の改善の始まり」です。発表会でもらった質問や講評は、お金を払っても手に入らない貴重なフィードバックです。これを放置するのはもったいない。

このセッションでは、次の2つの問いで企画・製品を振り返ります。

• 企画を実際に形にすることができたか
• ユーザ・お客様に製品をアピールすることができたか

そして「もし続きを開発するなら」という視点で、ペルソナをアップデートします。Day 3 で作ったペルソナを覚えていますか？　あの人物像は、22日間を経た今のあなたたちの目にはどう見えるでしょうか。

KPTは、振り返りを3つの箱に整理するフレームワークです。

• Keep: 良かったこと。今後も続けること
• Problem: 問題だったこと。うまくいかなかったこと
• Try: 次に試すこと。具体的な改善アクション

部活の試合後ミーティングに例えると分かりやすいです。「守備の連携は良かった（Keep）」「終盤に集中力が切れた（Problem）」「次の練習から終盤を想定した紅白戦を入れる（Try）」。感想会ではなく、次の行動を決める会議です。

具体例で確認しましょう。企画・製品のKPTなら、こうなります。

一方、こういう書き方はKPTとして機能しません。「みんな頑張った」はKeepに該当しません。なぜなら、何を続ければよいのか分からないからです。「もっと頑張る」もTryに該当しません。行動が具体的でないため、次のプロジェクトで実行できないからです。「良かった／悪かった」という感想ではなく、「続けること／やめること／試すこと」という行動で書くのがコツです。

ここで少し考えてみてください。ProblemとTryはどんな関係にあるべきでしょうか？　答えは「対応関係」です。Problemに挙げた問題には、対応するTryがあるのが理想です。

• KPTは感想文ではなく「行動の仕分け」。Keep・Tryは次のプロジェクトで実行できる粒度で書く
• Problemは「人」を責めない。「Aさんが遅かった」ではなく「タスクの依存関係を共有できていなかった」と仕組みの問題として書く
• よくある間違いは、Problemだけ大量に出してTryが空になること。Problemを1つ書いたら対応するTryを考える

KPTはアジャイル開発の振り返り（レトロスペクティブ）の定番手法で、ソフトウェア技術者Alistair Cockburn（アリスター・コーバーン）の振り返りフレームワークが起源とされ、日本のアジャイルコミュニティで広く普及しました。海外では「KPT」より「Start / Stop / Continue」という呼び名の方が通じることもあります。中身はほぼ同じで、「始めること・やめること・続けること」。世界中のチームが「振り返りは感想ではなく行動で締める」という同じ結論にたどり着いているのが面白いところです。

今回のKPTは、次の2つの問いを軸に行います。

• 企画を形にできたか: 企画段階で描いた価値は、製品として実現できたか。削った機能は何か、それはなぜか
• 製品をアピールできたか: 発表で製品の価値（誰の・何が・どう変わる）は伝わったか。質疑で答えられなかった質問は何か

材料は、昨日の発表会の質疑応答メモと講評です。たとえば「そのペルソナは本当にこの機能を使いますか？」という質問をもらったなら、それは企画と製品のズレを示すヒントです。

KPTが出そろったら、ペルソナのアップデートに進みます。「もし続きを開発するなら」という視点で、Day 3 のペルソナを見直します。

• 発表会の反応から、想定ユーザ像で変わった部分はないか（年齢層、利用シーン、価値観）
• 開発を通じて分かった「ペルソナが本当に困っていること」は、最初の設定と同じか
• 属性の追加・修正・削除を行い、変更理由を一言添える

ペルソナを「30代会社員」のような曖昧な像に戻してしまうのは、アップデートに該当しません。なぜなら、判断基準としての解像度が下がるからです。逆に「質疑で『高齢の家族も使うのでは』と指摘されたので、ペルソナの家族構成に同居の母を追加した」は良いアップデートです。根拠があり、解像度が上がっています。

• 発表会の質疑・講評を必ず材料にする。記憶が新しい今日やることに意味がある
• ペルソナの変更には必ず「根拠（どのフィードバックから来たか）」を添える
• よくある間違いは、ペルソナを全部作り直すこと。実際の開発では、検証で得た事実の分だけ少しずつ更新する

ペルソナ手法の生みの親であるAlan Cooper（アラン・クーパー）は、もともとプログラマでした。自分が作った業務ソフトのユーザにインタビューした人物像を頭の中で「演じながら」運転していたら設計が一気に進んだ、という体験がペルソナの原点だと語っています。つまりペルソナは最初から「更新される前提」の道具でした。一度作って飾っておく肖像画ではなく、開発のたびに描き直すスケッチ。今日のアップデートは、ペルソナ本来の使い方なのです。

ここまでの内容で疑問があれば、AIに質問してみましょう。たとえば：

• 「KPTのTryが思いつかない。このProblemに対する改善案を3つ提案して」
• 「KPTとYWT（やったこと・わかったこと・次にやること）の違いは何？」
• 「このペルソナのアップデート案は妥当？　根拠が弱い箇所を指摘して」

チームで以下を行ってください（合計35分目安）。

1. 材料集め（5分）: 発表会の質疑応答メモ・講評・他チームからのコメントを付箋やドキュメントに書き出す
2. 企画・製品のKPT作成（20分）:

   • 「企画を形にできたか」「製品をアピールできたか」の2つの問いに沿って、Keep・Problem・Tryを各3件以上挙げる
   • ProblemとTryの対応関係を線でつなぐか、番号で対応づける
   • AIにKPTを見せて「Tryが具体的な行動になっているか」をレビューしてもらう
3. ペルソナのアップデート（10分):

   • Day 3 のペルソナを開き、フィードバックに基づいて属性を追加・修正・削除する
   • 各変更に「変更理由」を一言添える
   • 「今後どういう方向で開発を進めるべきか」を1〜2文でまとめる

• 「企画・製品のKPT」（Keep・Problem・Try 各3件以上、ProblemとTryの対応つき）
• アップデート版ペルソナ（変更理由つき）と今後の開発方針メモ

• KPTが出ないときは、AIに「私たちの製品は〜です。発表会で〜という質問を受けました。ここからProblemを抽出して」と材料を渡すと観点が広がります
• Tryが「気をつける」「意識する」になったら要注意。「いつ・何をするか」まで具体化しましょう
• ペルソナの更新箇所に迷ったら、AIにアップデート前のペルソナを演じてもらい、「発表会で指摘された利用シーン」を質問してみると、設定の矛盾が見つかります

今回学んだことを一言でまとめると「振り返りは感想ではなく、KPTで次の行動に変換する」です。

• KPTはKeep（続ける）・Problem（問題）・Try（試す）の3つの箱
• ProblemとTryは対応させる。人ではなく仕組みの問題として書く
• ペルソナは発表会のフィードバックを根拠にアップデートする

次のセッションでは、視点を製品から自分自身に移し、「社会人基礎力を身につけられたか」を全体KPTで振り返ります。

以下の問いに答えられるか確認してみましょう：

• KPTのK・P・Tはそれぞれ何を書く欄ですか？
• 「もっと頑張る」がTryとして不適切なのはなぜですか？
• ペルソナのアップデートで、各変更に必ず添えるべきものは何ですか？

答えに自信がない場合は、該当部分を読み返すか、AIに質問してみてください。

• 参考リンク: アジャイルレトロスペクティブ（振り返り手法）の解説記事を「KPT 振り返り やり方」で検索
• 発展課題: 今回のKPTのTryを1つ選び、「次のプロジェクトの何日目に実行するか」まで計画に落としてみましょう

このセクションは、受講者が理解を深めることをサポートする参考情報です。