開発前に一つの成果を選ぶ
次の期間で顧客が何をできるようになるかを決め、その達成に必要な作業を選びます。項目の数を増やすより、動く状態で確認できるまとまりを優先します。未解決の仕様や外部依存がある場合は、先に調査する作業を切り出します。
レビューで触って判断する
進捗表を見るだけでなく、実際の画面で主要な操作を行います。仕様どおりかと、利用者に価値があるかは分けて確認します。新しい要望はその場で無制限に追加せず、次の優先順位の候補として管理します。
予算は消化と残る問いで管理する
何割の機能ができたかだけでは、事業としての進み具合が分かりません。残予算、未検証の仮説、公開に必要な条件を並べ、継続・縮小・変更を判断します。契約上の範囲変更や費用への影響も記録します。
毎回の振り返りを一つの改善へ
承認待ち、テスト不足、資料の不足など、詰まった原因を振り返ります。次の期間で変えることを一つ決め、実施できたかを確認します。会議を増やすより、情報と判断が届く経路を短くすることを目指します。
参考資料と編集について
- アジャイル領域へのスキル変革の指針 アジャイル開発の進め方（2024年5月）（IPA 独立行政法人 情報処理推進機構） ↗
- ITSS+（プラス）アジャイル領域（IPA 独立行政法人 情報処理推進機構） ↗
- アジャイル開発版「情報システム・モデル取引・契約書」（IPA 独立行政法人 情報処理推進機構） ↗
新規事業.com の関連ナレッジ ↗をもとに、Otsumuが検証・実装・運用の観点から再編集しました。制度・仕様・サービスの現況は、各提供元の最新情報をご確認ください。
編集：Otsumu株式会社 ／ 編集日