FDE現場でのスプリント期間はどれくらいが適切ですか？

3〜5日が基本です。2週間スプリントにするとクライアントの関心と記憶が薄れ、フィードバックの質も落ちます。週1回のデモを維持できる長さに設計します。

FDE1人でアジャイルを回すことはできますか？

可能です。バックログ管理はシンプルなスプレッドシート1枚で十分で、スプリントレビューはクライアント担当者との30分の定例に組み込みます。形式よりリズムを守ることが優先です。

クライアント側にアジャイルの知識がない場合はどうすればよいですか？

アジャイルという言葉を使わず、「毎週月曜に動くものを確認する打ち合わせ」として設定します。スプリントレビューもデモも、クライアントが慣れた言葉に置き換えて説明します。

アジャイルがFDE現場で機能しなくなるのはどういうときですか？

意思決定者がデモに来なくなるとき、スプリント期間が2週間を超えたとき、バックログの優先順位をFDEが単独で決めているときの3つが主なパターンです。

FDEとアジャイル：クライアント現場でのスプリント設計と進め方

結論

FDEの現場でアジャイルを機能させる鍵は、3〜5日以内に動くものを見せるサイクルを最初から崩さないことです。スプリント期間を2週間にすると、クライアントの関心と記憶がその間に薄れます。次のデモまで2週間待つということは、方向が間違っていても2週間気づかないということです。FDE現場では「短く見せて、すぐ直す」サイクルだけがリスクを小さく保ちます。

FDE現場でのスプリント設計

期間は3〜5日

教科書的なスクラムでは2週間スプリントが標準とされています。しかしFDE現場ではこれが機能しないケースが多くあります。理由は3つです。

1つ目は、クライアントの優先順位が週単位で変わることです。社内の意思決定会議や経営判断によって、月曜日に「最重要」だったタスクが金曜日には「後回し」になることがあります。2週間を1サイクルにしていると、そのズレを修正する機会が月に2回しかありません。

2つ目は、フィードバックの鮮度の問題です。「先週見せたものについて」と言われても、クライアントは細部を覚えていないことがほとんどです。前日か2日前に見たデモなら、具体的なフィードバックが返ってきます。

3つ目は、FDE自身のモメンタムです。2週間待ってデモして「方向が違う」と言われると、1〜2週分の作業が無駄になります。3〜5日なら2〜3日分です。

実際のスプリント長の目安は次のとおりです。

フェーズ	スプリント期間	理由
最初の1〜2ヶ月（探索・概念検証期）	3日	方向が固まっていないため短く回す
方向が固まった実装期	5日	安定して動くものを作る期間を確保
リリース準備・安定化期	7日	バグ修正・ドキュメント整備が中心

参加者の設計

スプリントデモには必ずクライアント側の意思決定者を含めます。担当者だけが参加するデモは、フィードバックが「上に確認してから連絡します」で終わります。それは実質的にデモではありません。

参加者の構成例は次のとおりです。

クライアント側：意思決定者1名＋現場担当者1〜2名
FDE側：FDE本人（1人体制の場合）

デモは30分以内に収めます。それ以上長くすると、参加者の集中力とスケジュール確保の両方が難しくなります。

バックログの作り方：クライアントと一緒に優先順位をつける

バックログはFDEが単独で作るものではありません。クライアントと一緒に作ります。この点が、FDE現場でのアジャイルが機能するかどうかを最も左右します。

初回バックログ作成の手順

プロジェクト開始後、最初の3〜5日で次を行います。

クライアントが「今すぐ解決したい問題」を箇条書きで出してもらう
FDEがそれを技術的な実装タスクに分解する
クライアントとFDEが一緒にMoSCoW法で分類する（Must / Should / Could / Won’t）
最初のスプリントはMustの中で最も小さく動くものを1〜2個に絞る

MoSCoW分類の現場での使い方

MoSCoW法はアジャイルで広く使われる優先度付けの手法です。FDE現場での運用では、クライアントが「全部Must」と言いがちな点が課題になります。

そのときに使う問いかけは「もしこのプロジェクトが今週で終わるとしたら、何だけは絶対に動いていないといけないですか？」です。この問いによって、クライアントの本当のMustが浮き彫りになります。

バックログ管理ツールの選択

FDE現場では、クライアントが日常的に使っているツールにバックログを置くことが重要です。FDE側だけが使えるJiraやNotionにバックログを置いても、クライアントはそれを見ません。

現実的な選択肢は次のとおりです。

クライアントがExcelを使っている → Googleスプレッドシートで共有
クライアントがNotionを使っている → Notionに置く
クライアントのITリテラシーが低い → メールで週次に共有するシンプルなテキスト一覧

形式よりも「クライアントが見る場所にある」ことを優先します。

FDEの現場全般についてはFDEとは何かを参照してください。

スプリントデモをクライアントが理解できる形にする工夫

デモを見せたのに「それで何ができるんですか？」と聞かれるケースがあります。これはデモの見せ方に問題があります。FDE現場でのデモは、技術デモではなく業務シナリオの実演です。

デモの構成

30分のデモを次の構成で進めます。

前回からの変更点を1分で説明する（スライド不要、口頭で十分）
クライアントが実際に行う業務シナリオに沿ってシステムを操作する（15〜20分）
「これはどう思いますか？」「次に何をやってほしいですか？」と問いかける（5〜10分）

重要なのは2番です。「在庫の確認をしたいとき」「担当者が引き継ぎをするとき」といった実際の業務シーンとして操作することで、クライアントは自分ごととして見られます。

「動いている」ことを最初に見せる

デモの冒頭3分で「動いている」状態を見せます。なぜなら、クライアントはFDEが何日も作業していてもまだ何も動かないと心配し始めます。最初のスプリントのデモがたとえ画面1ページしかなくても、それが実際にデータを取得して表示していることを見せることが重要です。

フィードバックのその場での記録

デモ中に出たフィードバックをその場でバックログに追加します。「それは追って検討します」と先延ばしにしないことが、クライアントとの信頼を積み上げる上で重要です。その場で追加したものを「次のスプリントでやります」「今回はShouldにします」とすぐに分類します。

FDEの1日でも触れていますが、クライアントとの関係は小さな信頼の積み重ねで成立します。

振り返りをFDE現場でどう回すか

振り返りはスクラムでいうレトロスペクティブです。FDE現場では、形式的な振り返りをクライアントと一緒に行うことは少なく、FDE自身が短時間で行うケースが大半です。

FDE単独の振り返り（15分）

スプリント最終日の終業前15分で次を確認します。

このスプリントで予定していたタスクのうち何割が完了したか
完了しなかった理由は何か（技術的な困難、クライアントからの情報待ち、スコープ変更）
次のスプリントのバックログを1つ調整するとしたら何か

記録はメモで構いません。重要なのは次のスプリントに反省を持ち込むことです。

クライアントを巻き込んだ振り返り（月次）

毎月1回、15〜20分の振り返りをクライアントと行います。このときは技術的な詳細ではなく、次の3点に絞ります。

「先月の中で一番役に立ったのは何でしたか？」
「もっとこうしてほしかったことはありますか？」
「来月の最優先事項は何ですか？」

この問いはシンプルですが、クライアントが本当に価値を感じていることとFDEが力を入れていることのズレを発見するために効果的です。

アジャイルが機能しない現場のパターンと修正方法

FDEの失敗パターンでも詳しく解説していますが、アジャイルが機能しなくなる現場には共通したパターンがあります。

パターン1：意思決定者がデモに来なくなる

症状：デモに担当者だけが来て、フィードバックが「上に確認してから」ばかりになる。

修正：次のデモの案内をする際に、意思決定者への参加依頼を明示します。「次回のデモでは方向性を決めたいので、○○さんにもご参加いただけますか？」という一言を添えます。それでも来ない場合は、デモの目的を「確認」から「決定」に変えます。「このデモでYes/Noをもらいたい」という前提を伝えることで、意思決定者が来ざるを得ない状況を作ります。

パターン2：スプリント期間が延びていく

症状：最初は5日だったスプリントが気づけば10日、14日になっている。

原因：タスクが大きすぎてスプリント内に収まらないか、FDE自身が「もう少し完璧にしてからデモしよう」と先延ばしにしているかのどちらかです。

修正：「60%でもデモできる状態」を基準にします。完成していない部分があっても、動く部分だけを見せます。未完成の部分は「次のスプリントでここを追加します」と明示することで、進捗を透明にします。

パターン3：バックログの優先順位をFDEが単独で決めている

症状：「次はこれをやろうと思います」とFDEが一方的に伝えるだけで、クライアントが選択していない。

修正：週の初めに「今週はAとBのどちらを先にやりたいですか？」と選択肢を2〜3個提示します。クライアントが選ぶ形にすることで、バックログへの当事者意識が生まれます。

パターン4：アジャイルの形式だけが残る

症状：デイリースタンドアップ・スプリントレビュー・レトロスペクティブのすべてをやっているが、何も変わらない。

修正：形式を捨てて、目的に戻ります。アジャイルの目的は「早くフィードバックをもらい、方向を修正すること」です。それが達成できている形式を残し、達成できていない形式は削ります。

FDE1人でアジャイルを回す場合の現実的な運用

FDE1人体制は珍しくありません。スクラムマスターもプロダクトオーナーも存在しない中で、アジャイルを機能させる現実的な運用を示します。

週次リズムの例（5日スプリント）

曜日	内容
月曜午前	バックログ確認・今週のタスク選択（15分）
月〜木	実装
金曜午前	デモ準備（30分）
金曜午後	クライアントへのデモ・フィードバック収集（30分）
金曜夕方	振り返り・来週バックログ更新（15分）

この運用で合計1時間の「管理コスト」で1サイクルが回ります。

バックログ管理は1枚のスプレッドシートで十分

複雑なバックログ管理ツールは不要です。Googleスプレッドシートで次の列があれば十分です。

タスク名
優先度（Must / Should / Could）
ステータス（未着手 / 進行中 / 完了 / 見送り）
スプリント番号
メモ

1人体制ではツールに時間をかけることに価値はありません。バックログが「クライアントと合意した優先順位の記録」として機能していればそれで十分です。

クライアントとの連絡は非同期を基本にする

毎日の進捗報告は必要ありません。週1回のデモで「動くもの」を見せることと、週1〜2回の短いチャットで「現在の進捗と次にやること」を共有することで十分です。

FDE単独での現場対応についてはFDE成功事例も参考にしてください。

まとめ

FDE現場でのアジャイルは、教科書どおりのスクラムではなく「3〜5日で動くものを見せる」リズムを守ることが核心です。スプリント期間を短く保ち、バックログをクライアントと一緒に管理し、デモを業務シナリオとして見せる。この3点が揃えば、1人体制でも現場でアジャイルを機能させられます。

形式よりもリズムを優先し、フィードバックをその場でバックログに落とす習慣が、FDE現場のアジャイルを支えます。