顧客の使い方や必要な条件を、開発の最初にすべて予測できるとは限りません。
アジャイル製品開発は、小さな範囲で成果を作り、利用者や関係者から得た情報によって、製品と進め方を調整するアプローチです。
計画を持たず、思いついた仕事へ毎回移ることとは区別します。

短い周期で何を確かめるか

たとえば、倉庫で使う作業支援端末を開発するとします。
最初からすべての業務を再現するより、商品を読み取り、行き先を確認する小さな流れを作ります。
利用者が手袋をした状態で試すと、画面の情報よりも持ち替えが問題だとわかるかもしれません。
この結果から、次に作る範囲や端末の形を見直します。

変更できる計画を作る

目指す成果と制約を共有し、直近で完成できる仕事を詳しくします。
まだ情報が足りない仕事は、仮説と、次に確かめる時点を記録します。
途中で新しい要求が出たら、今の目的への効果と、進行中の仕事への影響を比較します。
変更を受け入れることは、すべての要求を同時に実行することではありません。

短い周期の中でも、品質の確認を後回しにしないことが必要です。
実装を繰り返しても、使える状態へまとめるまで数か月かかるなら、成果から学ぶ機会は増えません。
試験、設計の改善、運用への準備も含めて、完成できる範囲を選びます。

製品に応じた制約を扱う

アジャイル宣言はソフトウェア開発から生まれました。
物理的な製品へ適用する場合、部品の調達、試作品の製作、設備の変更などの期間を考慮します。
毎回量産品を作れなくても、模型、部分試作、シミュレーションなど、疑問へ答えられる成果を選ぶ方法があります。
ただし、模型で確認した結果を、量産時の耐久性の証明にはできません。

スクラムはアジャイルな開発を支えるフレームワークの一つですが、両者は同義ではありません。
投資判断の枠組みと組み合わせる方法はアジャイル・ステージゲート、試作品の選択はラピッドプロトタイピングも参照できます。

参考資料