公共基幹システム刷新におけるアジャイル調達と法令改正対応
R市（人口28万人）は、住民記録・税・福祉の基幹業務システムを刷新する。国は標準化・共通化を方針として示しており、調達は設計・開発・運用の3分割で、ベンダーは1社に集約される見込みである。現行のウォーターフォール調達では仕様確定に1年を要し、その間の法令改正（2年後に予定）への対応が遅れる懸念がある。業務部門はアジャイル開発を希望しているが、契約は請負・一括固定価格が前提で、スコープの流動性を認めにくい。市の情報政策課は職員5名で、アジャイル経験者は1名のみ。監査部門は要件定義の確定と変更管理の証跡を求めており、業務部門の「動かしながら決める」という要求と相反している。予算は12億円、工期は3年である。庁内の意思決定は稟議と委員会で行われ、月1回のsteering committeeが設置されている。また、住民窓口の繁忙期は3月と6月で、その期間のリリース停止が必要である。現行システムの更改は2015年以来で、職員の業務知識は属人化している。
1. 請負契約のままでアジャイルの利点を活かすには、契約・調達をどう設計すべきか。
Read the worked answer
契約を二段階に分ける。上流の要件定義・設計は準委任とし、業務部門とベンダーが一緒にバックログを作る。開発は請負とするが、固定価格の範囲を「コア機能」に限定し、オプション領域は別契約または単価契約とする。検収はインクリメント単位で行い、変更管理条項に優先順位の付け替え手続きと、未実施分の次期繰越ルールを明記する。公共調達では、仕様書にアジャイル前提の変更手続きと、プロダクトオーナーの権限を記載することが重要である。監査証跡は、バックログ、意思決定ログ、リリース判定記録で確保する。請負のままでも、スコープを機能群で区切り、変更の入口と出口を決めればアジャイルの反復効果は得られる。
2. 2年後の法令改正リスクに備えるアーキテクチャ上の分離方針を示せ。
Read the worked answer
法令に依存するロジックを業務プロセスから分離する。具体的には、制度計算や判定条件をルールエンジンまたは設定ファイルに外部化し、改正時は設定変更で対応できるようにする。データモデルは国の標準仕様に準拠させ、独自拡張はAPI層に閉じ込める。住民記録・税・福祉の間はAPIで連携し、改正の影響範囲を特定のモジュールに限定する。これにより、2年後の改正時に全システムの改修ではなく、該当ルールと画面の部分改修で済む。分離の単位は「制度の変更頻度」で決め、頻度の高い領域ほど外部化を徹底する。アーキテクチャの判断は、工期3年の中間時点で改正対応のリハーサルを行い検証する。
3. 監査部門と業務部門の相反する要求をどう調和させるか。
Read the worked answer
「要件の確定」と「詳細の確定」を分けて合意する。監査部門には、全体のスコープと変更管理の証跡、トレーサビリティ、リリース判定基準を保証する。業務部門には、詳細要件を反復で決める権限と、優先順位を付け替える際の承認ルールを求める。steering committeeで変更承認プロセスを明文化し、監査部門もその場に参加させる。繁忙期のリリース停止は制約として計画に織り込み、停止前の品質ゲートを監査と共同で定義する。対立を解消するのではなく、監査には「統制の証跡」、業務には「変更の裁量」を渡し、意思決定の場を共有することが調和の要点である。