はじめに
3名のエンジニアチームでアジャイル手法を急遽導入することになった際の現実的な課題について、対話形式で深掘りした記録です。理想と現実のギャップ、組織の制約、そして実践的な対応策について議論した内容をまとめています。
対話記録
Q: Epicとユーザーストーリーの使い分けとは？
A: Epicとユーザーストーリーの基本的な使い分けについて整理します。
Epic（エピック）：
- 大きな機能や要件のまとまりを表現
- 複数のスプリントにまたがる大規模な開発項目
- ビジネス価値や目標に直結する機能群
- 1つのEpicは複数のユーザーストーリーに分解される
ユーザーストーリー：
- 具体的で実装可能な単位の要件を表現
- 1スプリント内で完成できるサイズ
- ユーザーの視点から書かれた具体的な機能
- 受け入れ基準が明確に定義できる
使い分けの基準は、計画フェーズ（Epic：長期的なロードマップ、ユーザーストーリー：スプリント計画）と粒度の違い（Epic：数週間〜数ヶ月、ユーザーストーリー：数日〜1週間）です。
Q: アジャイルの文脈で、ユーザーストーリーを作成するという使い方はあってますか？
A: はい、完全に正しい使い方です。アジャイルでは以下のタイミングでユーザーストーリーを作成します：
- プロダクトバックログの整理時
- スプリント計画前の準備
- 新しい要件が発生した時
- 既存ストーリーの分割が必要な時
チーム全体（プロダクトオーナー、開発者、テスター）で作成・改善に参加し、技術的な実現性とビジネス価値の両方を考慮したストーリーを作ります。
現在の状況説明と課題分析
状況整理
プロジェクト状況：
- 要求整理は完了、資料受領済み
- 3名のエンジニアチーム
- アジャイル採用（スクラムではない）
- 権限のあるリーダーとマネージャーの間で意見が割れている状況
今後の予定：
- 数週間後にWBSを提示
- エンジニア側からユーザーストーリーを洗い出して期間を算出
- ポイント見積もりは使用しない
Q: 進め方に関して何か思うことありますか？
対話を通じて明らかになった課題：
1. ステークホルダー間の認識齟齬
Q: エンジニア側が「急にアジャイルを採用する」とマネージャーが感じている点について、どう思われますか？
A: 困惑すると考えます。私だったら驚きます。また、採用する経緯、背景を説明してほしいと思います。
Q: WBSの提示とユーザーストーリーベースの見積もり、この2つのアプローチの違いをどう捉えていますか？
A: ユーザーストーリーを洗い出せば、WBSも自ずと明確になるのではと考えております。
2. チームのスキル課題
Q: みんなアジャイルのやり方がわかっておらず、リーダーが独断で決めているという状況で、チームの学習についてどんなアプローチが効果的だと思いますか？
A: ベストはアジャイルについて認識合わせをして"あるべき"を導かせる必要があると思います。ただ、リーダー的には、フレキシブルに進めましょうという方針でした（とりあえずやってみようぜ方針）
3. 実践的な課題
Q: 実際の進め方について、ユーザーストーリー作成からWBS提示まで数週間という流れで、どんな課題が想定できますか？
A: 現状は3人でユーザーストーリーを作成して持ち合い議論します。（特殊なやり方）事前にアウトプットも定義されず、何をしたら良いかわかっていません。また、特定の人は要件を把握しているそうですが、ユーザーストーリーを作るにしては、前提条件、細かな仕様がわかっておりません。
深掘り分析
情報格差の問題
Q: 「特定の人」が持っている情報と、足りない情報の境界線はどこにありそうですか？
A: 前提条件、各メンバーがストーリーに着手する場合に、何をすれば良いかイメージできている
プロセスの課題
Q: 通常のアジャイルチームだと、誰がユーザーストーリーの作成をリードしますか？
A: スクラムマスターだと思います（ただ、スクラムの場合。アジャイルの場合はなんと言えば良いのか知りません）
Q: 今回の進め方で、どんな混乱が起きそうか想像できますか？
A: ２歩進んで１歩下がるような、トライ&チャレンジーの頻発
成果物の認識
Q: マネージャーが期待している「WBS」と、エンジニア側が作ろうとしている「ユーザーストーリーベースの見積もり」、この2つは本当に同じものになりそうでしょうか？
A: 同じものになると考えます。通常のフローをトップダウンとするならば、今回のアクションはボトムアップになりそうです。
現実的な対応策の検討
効率性の課題
Q: リーダーの方針（各々のアプローチを確認したい、バラツキを許容）について、あなたが「非効率的」と感じる理由を具体的に教えてください。
A: 非効率と感じるのは、まず、理解している人が答えを提示して、それを模倣して作業を全員で理解向上のために行う方が良いと感じました。検証フェーズなどではなく、もう期限がある程度決まっている機能に対して行うアプローチではないと感じました。
品質担保
Q: 「何を持って妥当なユーザーストーリーか検証するのかが不明」という課題について、あなたなりの提案はありますか？
A: 工数の妥当性は置いておいて、必要なストーリーの過不足を判断できる人が評価すべき。
Q: 現在のチーム構成で、この「過不足を判断できる人」は具体的に誰になりそうでしょうか？
A: はい、最終的にNさんが要件を把握していそうなので、その人が各々のストーリーをジャッジするのだと思います。
最大の懸念と対応
懸念事項の整理
Q: 数週間後のマネージャーとの打ち合わせで「問題が発生する」とすれば、どんなパターンが考えられますか？
A: こちらの提出したマネージャーを納得させるためのWBSの根拠を確認されて、相手が納得してくれないことの懸念。
具体的なリスクシナリオ
Q: マネージャーが「納得してくれない」可能性について、具体的にはどんなシナリオを想像していますか？
A: マネージャーの理解を後に置いたエンジニアだけがユーザストーリーを把握している状態による反発。副次的に妥当性を判断できず、話が進まない状態になりそう。
現実的な対応
Q: もしマネージャーから「このWBSの根拠は何ですか？」と聞かれた時、現在のアプローチをどう説明しますか？
A: 根拠は特にありません。ただ、そのスケジュール通りに進めますと伝える。（リーダーはそのように押し通す想定）
最終的な対応戦略
採用した戦略
Q: 現在の制約を前提として、あなたが取れる現実的なアクションは何がありそうでしょうか？
A:
- とりあえず、リーダーの方針通りに進める。マネージャーとの打ち合わせの時に問題が発生したら、そこで対応を考える。
- 工数の妥当性は置いておいて、必要なストーリーの過不足を判断できる人が評価すべき。
学習としての位置づけ
Q: この経験から、あなたが学び取りたいと思っていることはありますか？
A: 反面教師として発生する問題を観察して次回に生かそうと思います。
理想と現実のギャップについて
理想的なアプローチ
Q: 今回の状況を振り返って、もし最初から理想的に進めるとしたら、どんな手順で進めたかったですか？
A: [対話者の回答を踏まえて] 事前の認識合わせ、段階的な学習、ステークホルダー全員の合意形成が重要だったと考えられます。
現実の制約
Q: 現実には様々な制約がありますよね。あなたが今回感じている「こうあるべきだが、現実はそうはいかない」という部分はどこでしょうか？
A： 組織の力学、時間的制約、既存の人間関係など、理想的なプロセスを阻む様々な要因が存在することが明らかになりました。
まとめ
この対話を通じて明らかになったのは、アジャイル導入時によく発生する課題の典型例です：
- ステークホルダー間の認識齟齬：技術チームとマネジメントの期待値の違い
- チームスキルの不足：新しい手法に対する理解不足
- プロセス設計の課題：標準的でない独自のアプローチによる非効率性
- 情報格差：要件理解の偏在による品質リスク
- 現実的制約：理想的なプロセスを阻む組織的な制約