書きたいこと
わたしは行政機関のシステム構築にほんの少しさわったことがあります。立場上、ほんの少しクリティカルな嘘を入れてあります。
行政機関における「アジャイル開発」について、実際に携わってみて正解がずっとわからず、今でも正解を探しているので、想定される良い面悪い面を書いて行きたいです。
色んな行政機関の色んな立場の人が、少しでも現状をよくしようと頑張っているのを知っているので、少しでも建設的な議論のきっかけになればうれしいです。
わたしは地方公共団体のシステムについて熟知しているわけではないのでここではそういった文脈を念頭において記載しません。珍しいでしょう？
また、それぞれ引用する文章の良し悪しについては本論ではないので記載しません。
アジャイル開発の検討
行政機関でガバメントクラウドを含む、クラウドサービスを使うときに参照すべき規範として、「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」というデジタル庁内タスクフォースの作成した方針があります。
この中で、「ウォーターフォールからアジャイルに発想を切り替える」という記載があり（リンク先のp.10）、（たぶん）政府情報システムはこうしたことを念頭に新規構築及び更改をするとされています。そのため、ガバメントクラウド含むクラウドサービスを利用する政府行政システム担当者は、（たぶん）すこしはアジャイル的な開発手法の導入を検討しなければならない感じになるのかな、と思っています。
実際、ウォーターフォールの最後の方でバグが発生して身動き取れなくなったりとか、本当はせめてもう少し機能を区切ってアジャイル的に開発すべきだったんだろうな、という事例及び意見に触れることもままあり、言いたいことは理解できます。
じゃあお前やってみろよ、ということで、実際にそのシステム企画/開発管理/説明責任を託された行政職員だったと想像して、その人がどう思うだろうか、を詳しく書いていきます。
アジャイルの何がよいか
急激なスコープ変更や優先順位変更に対応できる/しやすい
政府情報システムは、対象者属性が複数あって、しかもその属性ごとに機能が違うことがあると思います。例えば、地方支分部局向けには行政手続き処理関係の機能を持っていて、国民向けには処理した結果を表示するWEBアプリだったりとか。
対象者属性Aに対する機能とBに対する機能の優先順位が変わったりするとか、Bを精緻に作り込む要件が出てきたとか（そしてAは暫定リリース版のMVPで耐える）、こうした変化への対応がしやすい、というのがメリットだと思います。
とりわけ官公庁においてこれは割と大きいとわたしは考えます。
なぜなら、契約金額に跳ねるくらいのスコープ変更となった場合、官公庁の調達手続き上、再度の入札又は変更契約（の内部審査など）に要する日数が馬鹿にならないからです。再度の入札とかしていたら、3ヶ月くらいかかってしまいますから。
アジャイルの何が難しいか
説明責任を負う人間の負担が大きすぎる
政府情報システムの担当者は大体、利用者として官公庁職員、地方支分部局職員、自治体職員、士業関係者などに対し、システムの更新状況を説明する身にあることが多いと思います。
説明を聴く側は、「いつ、どのシステムで、何が、どう変わるか（どういう影響があるか）」を聞きたい訳で、故に説明するシステム担当者も、そこをきっちり説明したいわけです。
そのニーズがあるのに、アジャイルの特性上、「いつ」「何が」「どう変わるか」を事前にきっちり説明しきれないのはとてもしんどいことだと思っています。口が裂けても「今ベロシティーがこうだからこのくらいにリリースされそうです。変わるかもだけど。」とは言いづらい...
あと、ドキュメントを追従させて利用者にちゃんとアナウンスしていくのも難しいと思います。
担当者だけが苦悩するだけなので大局的に見ると些細ですが、ここは担当者としては本当にしんどいと思います。政府情報システムのステークホルダーの矢面に立つということは、ただでさえプレッシャーが大きいイメージがあります。
加えて、どのマイルストーンが組織としてのリリース判定とするかもとてもわかりにくくて難しさを感じるのではないかと思います。
まあでも、この辺はうまくやっている企業とかもありそうで、わたしが知らないだけで素敵なノウハウがある気もしますね。
速度向上のための増員が難しい
これは、契約的な観点であり、官公庁特徴的な部分です。
アジャイル開発をしていて、QCDのうちQとDを厳守、となった場合（補正予算という概念がある官公庁はえてしてそうなるのですが）、Cすなわち開発要員を増やす方向での調整になると思います。
例を挙げます。人月商売で開発を発注していて、5人のエンジニア＋1人のスクラムマスターで動いていることを想像してください。利用者属性A向けとB向けの2機能があり、それぞれをちょこちょこ平和に開発しているとします。
あるとき、B向けの要件が激増したとします。その激増分を予定納期までにリリースするためには、3人のエンジニア追加が必要だとすると、6人→9人に増えるので、純粋に契約金額が1.5倍になります。明朗会計すぎてそこに交渉の余地はあまりない。体感、普通のウォーターフォールより上がり幅がシャープな感じを受けます...
その上で、スクラムマスターが8人もまとめられるのか→それなら2チームに分けた方がいいのでは→じゃあマネジメントスキルのある人をもう1人追加しないと、とどんどん泥沼化していきます。
変更契約の増額割合が30%までと定められていたり、予算がなかったりしたら、再度の入札やら予算の工面やらで結局リードタイムがかかります。変化に対応できてない。
せめて民間企業がBPさん増やすみたいにリードタイムが週間単位で変更契約できたらいいのですが、行政機関はそうもいかないのが難しいですね。
これはおそらく、今回の例であればA向けとB向けを分けて分割調達しておいたりとか、適切に分けて開発できたらいいのだと思いますが、そんなに適切にスコープ区切れるのならアジャイルは採用しなくても良さそうだし、要件も突然追加にならなそうな気もします。本当にむずかしいですね。
むすび
ここでは、行政機関でアジャイル開発する際に難しいと思われることを中心に記載しました。
困難があったからといって、全く否定できるものではなく、前述のスコープ調整の容易性で多大なメリットを享受できている例を見たことがあります。
なので、検討のしよう、やりようなのかな、という気がとてもしています。別にゼロかイチかの世界でもないと思いますし。
過去の屍を乗り越えて正解に辿り着く人が出ることを祈っています。
余談ですが、アジャイル開発されているEDR製品が筆者の身近にあります。アジャイルが故にサポートアウトも早いしバージョンアップもいつ来るのかわからんし不具合もちょこちょこあるし、利用する側（特に情シス的な立ち位置の人）はたまらない気持ちでいっぱいです。そういう製品のサービスマネージャーは多分すごい大変だろうし、そういう話も聞いてみたいなあ...