最近、名目上はアジャイル開発を採用しているものの、実態はウォーターフォールに近い進め方をしている新規プロジェクトに参加することになりました。
チームの一員として関わる中で、このギャップが将来的な問題につながる可能性を感じ、アジャイル開発手法への段階的な移行を内部で提案してみた内容をまとめました。
課題感
新しいプロジェクトに参加してすぐに感じたのは、以下のような課題でした。
1. 曖昧なタスク定義: 作業内容がざっくりと定義されているため、正確な工数見積もりができない
2. 頻繁な要件変更: 週次ミーティングでクライアントから次々と新しい要望が出てくる
3. 優先順位の不明確さ: 何を先に実装すべきかの基準がない
4. プロジェクト全体の見通しの不透明さ: 「いつまでに何ができるのか」がわからない
これらは「ウォーターフォール的アジャイル」とも呼べる状況の典型的な特徴です。
名目上はアジャイルを採用しているものの、実態はウォーターフォールに近い進め方をしており、アジャイルの利点を十分に活かせていない状態でした。
予想されるリスク
このまま進めた場合、以下のようなリスクが予想されました。
1. スケジュール管理の難しさ
タスクが明確に定義されていないため、今後の工数見積もりが困難になり、納期に間に合わない恐れがあります。
2. 要件変更への対応の限界
週次定例でクライアントから新たな要望や改善点が出され続け、それらを既存の計画にどう組み込むかの仕組みがないため、混乱が生じる可能性があります。
3. チームの疲弊
優先度が明確でないまま、次々と要件が追加されると、チームは常に「潜在的な納期遅れ」のプレッシャーにさらされ、疲弊してしまいます。
4. プロジェクトの失敗リスク
このままあいまいな状態で進めると、納期や品質に影響が出る可能性が高くなります。
アジャイル開発手法の導入プラン
これらの課題を解決するため、以下のようなアジャイル開発導入計画を立てました。
1. カンバンボードの実装
- タスクの可視化を進め、「今何が進行中で、何が待機中か」を明確にする
- ボトルネックを早期に発見できるようにする
2. ユーザーストーリーの整備
- 曖昧な要件を明確なユーザーストーリーとして再定義する
- 各ストーリーにポイント（難易度・工数の指標）を付与し、定量的な管理を可能にする
3. スプリント計画の導入
- チームの消化可能なポイント数（ベロシティ）を把握し、現実的な計画を立てる
- 2週間単位のスプリントを設定し、その期間内で達成可能な目標を設定する
期待される効果
アジャイル開発を正しく導入することで、以下のような効果が期待できます。
1. クライアントとのコミュニケーション改善
- 「今週は○○ポイントまで消化可能であり、これらの機能を実装できます」と具体的に説明できるようになる
- 追加要望があった場合、「この要望を優先すると、他のこの機能は次スプリントに持ち越しになります」と明確に提示できる
- プロジェクトの状況が「見える化」されることで、より焦点を絞った建設的な対話が可能になる
2. プロジェクト管理の透明性向上
- 進捗状況が可視化され、問題の早期発見が可能になる
- 変更による影響範囲を定量的に評価できるようになる
3. チームの持続可能な開発ペース確立
- 達成可能な目標設定により、チームは無理なく効率的に開発を進められる
- 過剰な負荷を防止し、品質を維持できる
4. リスクの低減と早期対応
- 技術的な課題や実現可能性の問題を早期に発見できるため、プロジェクト後半での大きな問題発生を防止できる
- 問題が発生しても影響範囲が限定的で、素早い対応が可能になる
クライアントとの共有ポイント
アジャイル開発への移行を成功させるためには、クライアントの理解と協力が不可欠です。以下の点をクライアントと早期に共有することにしました。
1. 優先度の明確化
- 機能の優先順位を一緒に決定することの重要性を説明する
- 「すべてが最優先」は不可能であり、限られたリソースで最大の価値を生み出すための選択が必要であることを理解してもらう
2. 変更管理プロセスの確立
- 新たな要望はプロダクトバックログに追加し、優先度に応じて取り込むプロセスを確立する
- 変更が及ぼす影響を可視化し、適切な意思決定を促す
3. 定例会議の活用方法
- スプリントレビューでは、完成した機能のデモを行い、フィードバックを得る
- スプリント計画では、次のスプリントで取り組む内容を明確にする
4. 追加要望と工数の関係
- 追加要望には追加の工数が必要であり、既存タスクとの優先度調整が必要なことを理解してもらう
- 「スコープ・時間・品質」のトレードオフ関係を明確に伝える
実施に向けた具体的なステップ
アジャイル移行の第一歩として、以下のようなステップで進める計画を立てました。
1. 現状のプロジェクト要件をユーザーストーリーとして整理
- 既存の要件をユーザーストーリー形式に書き換える
- 各ストーリーにポイントを割り当てる
2. プロダクトバックログの作成
- すべてのユーザーストーリーを優先順位順に並べたバックログを作成する
- クライアントと一緒にレビューし、優先順位を合意する
3. 初回スプリント計画
- 2週間のスプリントで取り組むストーリーを選定する
- チームのベロシティを保守的に見積もり、無理のない計画を立てる
4. カンバンボードの運用開始
- Notion等のツールを活用し、タスクの進捗を可視化する
- 日次のスタンドアップミーティングを短時間で実施し、進捗を共有する
5. 定例での振り返りと改善
- スプリントごとに振り返りを行い、プロセスの改善点を見つける
- 実績ベロシティを計測し、次回スプリントの計画に反映する
まとめ
アジャイル開発への移行は一朝一夕にはいきません。特に「アジャイルと言いながらウォーターフォール」の状態からの脱却は、チームだけでなくクライアントの考え方の変化も必要とします。
重要なのは、すべてを一度に変えようとするのではなく、小さな成功体験を積み重ねていくことです。
今回のケースでは、まずはユーザーストーリーの整備とカンバンボードの導入から始め、チームとクライアントの双方に「見える化」のメリットを実感してもらうことから始めました。
アジャイル開発の本質は、不確実性を前提とした上で、効率的にプロジェクトを進めていく柔軟性にあると思います。プロジェクトの成功確率を高め、クライアントとの良好な関係構築にもつながると考えています。
