アジャイル開発とは

開発対象の正解がまだ分からない場合はアジャイルを採用します。仕様が外部の条件で確定していて変更されない場合は、先に仕様を確定させてから開発します。判断の材料は手法の好みではなく、開発しながら仕様が変化する見込みの大きさと、発注側が開発に関わり続けられるかの2点です。

アジャイルが向くのは、利用者の反応を確認して機能を足し引きしたい新規事業やサービス、現場で利用してみないと必要な画面や項目が確定しない業務システムです。逆に、法令や制度で仕様が確定している対応、既存システムを同じ機能のまま刷新する移行、他社システムとの接続仕様が先に確定している開発は、先に仕様を確定させるほうが予算と納期を約束しやすくなります。1つの案件の中で、利用者が操作する画面はアジャイルで開発し、外部接続や移行は計画どおりに遂行する組み合わせも珍しくありません。

導入する場合は1チーム10人以下とし、3か月から半年で最初のリリースまで到達できる範囲で区切ると向き不向きを確認しやすくなります。最初のリリースまで半年を超える計画は、範囲を分割できないかを先に検討します。数週間で完了する小さな改修や、SaaS（Software as a Service）の設定だけで済む導入では、どちらの進め方かを気にする必要はほとんどありません。

予算と期間に上限を置き、その中で開発する範囲を優先順位に従って調整して管理します。最初に全機能の一覧と総額を確定させる管理はアジャイルと両立しません。

具体的にはチームの人数と期間から費用の上限を定めます。そのうえで2〜4週間ごとに動作するものを確認して、継続するか、優先順位を変更するか、中止するかを決定します。最初の判断の区切りを目安として2〜3か月後に設定し、その時点で最低限の機能が稼働していなければ計画そのものを再検討します。提案を受けた段階で次の3点を質問すると、提案の妥当性を見極めやすくなります。最初のリリースで何を利用できるようにするのか、どの頻度で何を見せてもらえるのか、優先順位を誰が決定するのかです。この3点が曖昧な提案は名前だけがアジャイルで中身は管理を緩めただけの進め方になりやすいです。

契約は開発会社が完成の責任を負う請負より、作業に対して支払う準委任で締結することが多いです。IPA（情報処理推進機構）が2020年に公開したアジャイル開発版のモデル契約も準委任を前提にしています。準委任ではチームを配置している間は費用が発生し続け、完成の責任も開発会社に一括では負わせられません。そのため、進捗を確認して中止するかどうかを決定する責任は発注側が担います。どちらの契約にするかは要件定義の段階から決定しておきます。

準委任で発注側の担当者が開発会社の個々の技術者に直接作業を指示し続けると、偽装請負とみなされるおそれがあります。厚生労働省がアジャイル型開発について示した見解は、適正とみなせる条件を整理しています。見解では発注側と開発会社の担当者が対等に協働し、開発会社の技術者が作業の進め方を自ら決定している実態があれば適正としています。契約前に、指示や依頼を誰から誰に発するかの運用を定めておきます。

優先順位を決定する権限を備えた担当者を1人選任し、週の3割から半分程度の時間を開発に割り当てます。予算は期間と上限額で承認します。担当者が兼務で週に数時間しか確保できない体制では、判断待ちで開発が停滞し、アジャイルを採用する意味が薄れます。

担当者には事業や業務の目的を理解していて、何を先に開発するかをその場で決定できる権限が必要です。決定のたびに社内の承認を何段も経る必要があると、数週間ごとの見直しが機能しません。スクラムではこの役割をプロダクトオーナーと呼び、IPAのモデル契約も発注側から選定する前提にしています。

社内の稟議を機能一覧と総額の確定で承認する形のままにすると、途中で開発する範囲を変更するたびに承認のやり直しが必要になります。最初の判断の区切りまでにかかる費用を上限額付きで承認し、区切りごとに継続するかを再決定する形に変更すると、承認の手続きと進め方が整合します。この体制と承認の形を社内で用意できない場合は、仕様を先に確定させて発注するほうが社内の負担を見積もりやすくなります。