曖昧要件のアジャイル開発で認識ズレを防ぎながら進めるコツ

はじめに

アジャイル開発の現場では、要件や仕様が完全に固まっていない状態でタスクが割り振られることがあります。

特に、スプリントが明確に設けられていない現場では、

• 「こんな感じの画面を作りたい」
• 「業務をもう少し便利にしたい」
• 「既存機能を改善したい」

といった、かなりふわっとした状態で開発が始まることも少なくありません。

本記事では、そのような曖昧要件のアジャイル開発において、認識ズレを防ぎながら進めるために意識していたことを書いていきます。

これまでの経験

私はこれまで、主にアジャイル形式の開発案件へ参画してきました。

フロントエンド・バックエンドの両方を業務レベルで経験しており、特にWebアプリケーション開発に携わることが多かったです。

その中で感じたのは、アジャイル開発では「実装力」だけではなく、

• 認識合わせ
• 方向性確認
• スピード感

が非常に重要だということです。

まず確認すること

曖昧な要望のタスクでは、チケットを作成した人の頭の中に、

• かなり詳細な完成イメージがある場合
• 根幹部分だけ決まっている場合

の2パターンがあります。

そのため、実装へ入る前にまず以下を確認するようにしていました。

• 最終的に誰がOKを出すのか
• チケット作成者はどのような意図で作成したのか
• どのタイミングで設計書を作成するのか

設計書についても、

• 実装前に作る現場
• 実装後に共有資料としてまとめる現場

があり、進め方は案件によってかなり異なります。

なぜ最初に画面を作るのか

要件が曖昧な場合、私はまず画面周りの大枠から着手することが多かったです。

理由は、利用者や依頼者が最もイメージしやすいのがUIだからです。

テキストや設計書だけでは認識がズレていても、実際に画面が見えると、

• 「思っていたものと違う」
• 「このボタンはいらない」
• 「この導線の方が使いやすい」

など、具体的なフィードバックが出やすくなります。

私の経験では、画面イメージが合っていれば、内部設計については細かく見られないケースも多くありました。

スピード感を重視する

画面作成では、「まず動くものを早く見せる」ことを強く意識していました。

1日で完成しない場合でも、なるべく1日単位で途中経過を見せるようにします。

特に、

• 最終的な決裁権を持つ人
• 実際に利用するユーザーに近い人

には、早い段階で画面共有を行い、方向性を確認してもらうようにしていました。

そして、画面の方向性でOKが出てから、

• 細かい調整
• バックエンド実装
• 内部設計

を本格的に作り込むようにしていました。

100点を目指しすぎない

アジャイル開発では、最初から完璧なものを作ろうとしすぎると、認識ズレが発生した際の手戻りコストが大きくなります。

そのため、

まずは60点でもよいので早く見せる

ことを重視していました。

特に曖昧要件では、

• 作りながら認識を合わせる
• フィードバックを何度も受ける
• 徐々に完成度を高める

という進め方の方が、結果的にスムーズに進むことが多かったです。

まとめ

アジャイル開発では、仕様が完全に固まるのを待つよりも、

まず動くものを見せながら認識を合わせていく

力が重要だと思います。

また、技術力だけではなく、

• 誰が決裁権を持っているのか
• どの粒度で確認を取るべきか
• どのタイミングで見せるべきか

を意識することも非常に重要でした。

曖昧要件の現場では、スピード感を持って小さく確認を繰り返すことが、認識ズレを防ぐ一番の近道だと感じています。