アジャイル開発とは？進め方と依頼側が準備すること

アジャイル開発は、作ったものから学び、次に取り組む内容を調整していく考え方です。「最初に何も決めなくてよい」「依頼側は完成を待てばよい」という意味ではありません。小さく確認を繰り返すためには、判断する人と材料が必要です。

この記事では、スクラムを一つの例に、依頼側が準備する意思決定と要求の優先順位を整理します。スクラムをアジャイル開発の唯一の方式として扱わず、契約の種類や法的な解釈も一律には決めません。

小さく作り、結果から次を調整する

スクラムガイド2020は、作業をプロダクトバックログに並べ、スプリントで価値のある成果へ変え、結果を検査して次へ向けて調整する流れを示しています。プロダクトバックログは、取り組む内容を整理する一覧と考えると入口をつかめます。スクラムガイド2020 日本語版

この流れを業務システムへ当てはめるなら、先にすべての画面を作り切るだけでなく、一部の業務が成立する単位で確かめ、分かったことを次へ反映する進め方が考えられます。

小さく作ることが目的なのではなく、不確かな点を確かめるために単位を選びます。何を知りたいかが曖昧なまま細かく分割すると、完成物が増えても意思決定につながらない場合があります。

IPAのアジャイル開発版モデルでは、ユーザ企業がプロダクトオーナーを選び、適時の情報提供や意思決定、関係者との調整を行う役割を明確にしています。これは同モデルが置く前提の説明です。IPA「情報システム・モデル取引・契約書（アジャイル開発版）」

依頼側の準備としては、役職名を置くだけでなく、誰が何を決められるかを確認します。利用部門の希望が対立したときに優先順位を決める人、業務条件を説明できる人、試した結果を返せる人が必要です。

確認のたびに長く回答待ちになるなら、開発の区切りだけを短くしても調整しにくくなります。どの程度の頻度で参加できるか、判断に必要な資料を誰が集めるかを開始前に相談しましょう。

要求は、機能名だけでなく、「誰の何を改善したいか」「確認できたら何を判断するか」まで書くと比較しやすくなります。次の表は、スクラムの公式ひな型ではなく、本記事の整理案です。

新しい要望を追加したら、何かを後ろへ送る必要があるかも見ます。「変更に対応できる」ことを、同じ期間と体制で無制限に追加できることと混同しないでください。

架空の備品申請業務で、「申請者が進捗を知りたい」「承認者がまとめて処理したい」「管理者が月次集計したい」という三つの要望があるとします。

利用者への確認で、最も不確かな点が「申請中という状態の意味が部門ごとに違う」ことだと分かったなら、先に一つの申請と状態表示を試す案があります。画面の見た目より、誰がどこで状態を変え、利用者がどう理解するかを確かめます。

試した結果、「確認中」と「承認待ち」を分ける必要が分かれば、一覧の内容を見直します。逆に、その違いが業務で不要なら、機能を増やさない判断もできます。

これは架空の検討例で、実施済みの成果ではありません。法令対応や他システム接続など、先に満たすべき制約がある場合は、それも順番の材料に含めます。

小さな単位でも、今回確かめる目的、利用可能とする条件、残った問題を見えるようにします。途中の画面が動くことと、本番の業務で利用できることは分けて判断してください。

依頼側は、毎回細かい実装方法を決める役になる必要はありません。業務上の優先順位と判断条件を示し、開発側と技術上の制約を相談します。変更時には、費用・期間・既存機能への影響を関係者で確認します。

開始前には、意思決定者、参加できる時間、最初に確かめたい問題の三つをそろえることを勧めます。要求を具体的な条件へ変える方法は要件定義の整理、全工程の関係は開発工程の解説をご覧ください。開発体制に関するご相談はSES事業からご確認いただけます。