2020年10月号トピックス　行政機関におけるアジャイル型開発の導入に関する調査研究―実践のポイント―

1.はじめに

最近、官民を問わず、アジャイル型開発を組織に導入しようとする動きが広がりを見せている。民間企業では、全社的な研修を導入する企業が相次いでいるし、いくつかのSI企業では、数百人規模でアジャイル型開発人材の確保を進めている。行政機関や自治体の一部でも、アジャイル型開発の現場レベルでの実践が始まっている。本稿では、なぜ今、行政機関でアジャイル型開発の導入が進められようとしているのか、そして、アジャイル型開発の導入はどのように進めればよいのかについて、一般社団法人行政情報システム研究所が2019年度に実施した「行政機関におけるアジャイル型開発の導入に関する調査研究」報告書（以下「報告書」）の内容を交えて解説したい。

2.なぜ今、アジャイル型開発なのか

ひと口にアジャイル型開発といっても、Scrum、エクストリーム・プログラミング（XP）、ユーザ機能駆動開発（FDD）など様々な手法がある。これらを等しくアジャイル型開発たらしめているのは、2001年に米国ユタ州スノウバードで同分野の専門家によってとりまとめられた「アジャイルソフトウェア開発宣言（※1）」と言える。同宣言では、「プロセスやツールよりも個人と対話を、包括的なドキュメントよりも動くソフトウェアを、契約交渉よりも顧客との協調を、計画に従うことよりも変化への対応を」価値とするとしている。こうした価値観に基づくソフトウェア開発のアプローチこそがアジャイル型開発の本質といえる。例えば、Scrumはアジャイル型開発の価値観を色濃く体現した、高度に洗練された手法の一つである。
アジャイル型開発は、20世紀末に体系化が進み、急速に情報システムの世界に認知が広がった。今や情報システム開発におけるウォーターフォール型開発の対概念として、どんなテキストでも紹介されている。しかし、これだけ広く認知されている概念であるにも関わらず、実践されている例は乏しい。情報システム構築に携わったことのある者の多くは、ウォーターフォール型開発の限界を知っており、“痛い目”に遭っている者も少なくない。にもかかわらず、アジャイル型開発に踏み出すことができずにいる。そこで感じられている懸念は、典型的には以下のようなものであろう。
・ 要件定義が明確でなければ要求が膨張して収拾がつかなくなるのではないか
・ 要件を明確に定義しなければ公平な調達はできないのではないか
・ 成果物の基準が不明確では検収のしようがないのではないか
・ そもそも請負契約とアジャイル型開発は相いれないのではないか、等々
しかし、これらの課題は乗り越えられないものではない。実際に、調達制度や会計制度は長年ほとんど姿を変えていないにも関わらず、最近になって行政においてもアジャイル型開発が実践されるようになっている。何が変化したのかといえば、それはアジャイル型開発への切実なニーズの高まりである。かつてはそれが乏しかったがゆえに、導入のハードルを乗り越えてまで取り組もうとする組織が少なかった。そのニーズとは、大きく次の2つである。
（1）利用者中心のサービス開発
近年、行政機関には、かつてないほど強く、利用者視点での行政サービスの開発が求められるようになっている。利用者を重視するという考え方自体は目新しいものではない。今から17年前に策定された、最初の「電子政府構築計画（各府省情報化統括責任者（CIO）連絡会議決定）2003年」でも、「利用者本位で、透明性が高く、効率的で、安全な行政サービスの提供」が第一に掲げられていた。しかし、このときの「利用者本位」とは、行政側が一方的に考える「利用者本位」に過ぎなかった。極端に言えば、行政職員が「こうすれば利用者は便利になるだろう」という想定があれば、それは利用者本位だったのである。つまり、
「利用者のために」開発すること≠「利用者の視点で」開発すること
ということが十分に理解されていなかった。
真に「利用者の視点」で開発を行うためには、実際に利用者にプロトタイプを使ってもらい、そのフィードバックを得ながら、改善を重ね、作りこんでいくほかない。いくら「利用者のために」、プロジェクト開始時に要件を完璧に整理しても、実際の利用者の視点に基づかなくては、利便性の高いサービスが実現する可能性は低い。だからこそ、かつての行政の情報システムは使いにくかった。
それが大きく変化している。エポックメーキングとなったのは、2017年の政府の「デジタル・ガバメント推進方針」である。同方針によって、それまでコスト削減・業務効率化に傾注してきた電子政府の取組は「利用者中心」へと大きく舵が切られた。そして「サービスデザイン思考」が掲げられ、利用者の視点を実際の開発に取り込んでいくという方向性が示された。感度の高い行政職員は、実際に利用者の参画を得ない限り、利用者視点は得られないことを理解している。そうした職員のいる機関が自らアジャイル型開発の導入へと舵を切り始めたと言えるのである。
（2）デジタル技術の活用
いま一つが、ここ2、3年程の間に大きく進展してきた、AIを始めとするデジタル技術の行政サービスでの活用へのニーズである。これらのデジタル技術は、従来の情報システムとは大きく異なる。従来の情報システムの導入には、業務の電子化・効率化といった決まった方向性があったため、極端に言えば、現場の業務と要求要件をヒアリング等を通じて把握・整理し、機能を備えておけば、多少使い勝手が悪くても、そこそこの効果を得ることができた。
デジタル技術活用のプロジェクトではそうはいかない。あくまで現場の課題が出発点となっており、その課題設定が違っていれば、そもそも導入すべき技術そのものが全く異なってくる。課題設定を見誤れば、構築したシステムは確実に用をなさないものとなる。現場の利用者の課題認識を取り込み、サービスを作り込んでいかざるを得ない。
これが、アジャイル型開発が必要とされる理由の2つ目である。
こうした環境変化によって、アジャイル型開発が今更ながら脚光を浴びるようになっているのが現状と言える。
（※1）https://agilemanifesto.org/iso/ja/manifesto.html

3.国内外の取組の動向

こうした状況の変化が起きているのは、ひとり日本だけの話ではない。同様の変化は諸外国、特に電子政府先進国と呼ばれる国々でも起きており、既にシステム開発アプローチの変革が進められてきている。いまやアジャイル型開発は、多くの国々の行政機関で当たり前のアプローチになりつつある。それは個々の現場で実践されているだけではない。取組の組織化も様々な形で進められている。
例えば、近年、各国政府では、デジタル化推進の部門横断的組織の設置が相次いでいるが（※2）、こうした組織では、各省庁の変革支援の基本的アプローチとして、アジャイル型開発が位置付けられている。
また、表1に示すように、アジャイル型開発実践にあたっての様々なガイド類の整備が進められている。さらに、ITスキル向上のための職員向け研修では、アジャイル型開発が中心的なメニューの一つとして位置づけられている。
このようにアジャイル型開発は、組織として取り組むべき課題となりつつある。これに対し、日本では、こうした課題は一部で認識されてはいるものの、具体的な対応策は講じられていない。例えば、2017年の「世界最先端IT国家創造宣言・官民データ活用推進基本計画」（IT戦略）では、「ITをめぐる環境の変化にアジャイル型で対応できるようにすることが重要」とされたが、その後のIT戦略では「アジャイル」には言及されなくなっている。また、「デジタル・ガバメント推進標準ガイドライン」では、「利用者が多岐にわたり、要件定義等の関係者に対して綿密な調整が必要となる等の場合は、開発手法としてアジャイル型を導入することで、利用者の利便性を向上させるよう考慮する。」とされているが、具体的な方法論が示されているわけではなく、「デジタル・ガバメント推進標準ガイドライン解説書」（※3）などで簡潔な解説がなされるにとどまっている。
このように日本の行政機関では、アジャイル型開発の具体的な実践については、大まかな方向性が示されるにとどまっている。

表1　アジャイル型開発の組織的推進のツールの例

（出典）著者作成

（※2）米国のUSDSや18F、英国のGDS、豪州のDTA、デンマークのデジタル化庁など
（※3）https://cio.go.jp/sites/default/files/uploads/documents/kaisetusyo_3-7_20200331.pdf
（※4）https://18f.gsa.gov/2019/08/20/an-agile-softwaredevelopment-solicitation-guide/
（※5）https://www.iais.or.jp/reports/labreport/20190331/designthinking2018/
（※6）https://www.gov.uk/service-manual/agile-delivery
（※7）https://hallways.cap.gsa.gov/app/#/gateway/itacquisition-university
（※8）https://www.iais.or.jp/

4.アジャイル型開発実践のポイント

アジャイル型開発は、必ずしも特定の手法（例えばScrum）に依らなければならないわけではない。専門知識を欠いたまま、恣意的、場当たり的に、良い所取りしてしまうのは危険であるが、専門家の助言を得ながら、部分的にアジャイル型開発の要素を取り入れることは少なくない。本章では、こうした場合も視野に入れつつ、どうすれば、アジャイル的な要素をプロジェクトに取り込むことができるのかを、特にアジャイル型開発の導入に当たり論点となることが多い、適用範囲、意思決定プロセス、人材、組織、調達という5つの側面から検討する。
①　適用範囲
出発点となるのは、そもそもある場面で、アジャイル型開発を適用すべきか／すべきでないかという判断である。アジャイル型開発には原理的に適用できない領域はない。しかし、経験則的に向いている／向いていない領域は存在する。基本的には、どう課題解決すべきかを試行錯誤を通じて探索しながら作り込んでいく必要性が高い部分はアジャイル型開発に向くのに対し、実現すべき要件が定義されており、全体最適の視点でロジカルに構築することが求められる部分は、ウォーターフォール型に向いている。概念的には、プロジェクトのフェーズやスコープによって、次のように区分できる（表2）。

表2　フェーズ・スコープによるアジャイル型開発の向き・不向き

（出典）著者作成

［フェーズ］
システム開発の最初期段階では、課題や解決策を試行錯誤しながら探索・定義していくことが重要となる。アジャイル型開発はこの局面に適したアプローチである。より端的に言えば、MVP（実用最小限の製品）（※9）の特定までは、アジャイル型開発で取り組むことが望ましい。
［スコープ］
上記のフェーズにかかわらず、フロントエンドのUI（ユーザーインターフェース）開発などでは、最後までアジャイル型開発で取り組むことが望ましい。これに対し、バックエンドのインフラやDBの構築などは、一般的にはアジャイル型開発に向かない。DBやシステムのアーキテクチャをしっかり固めた上で、アジャイル型開発でUIを作り込んでいくのが王道であろう。基礎を固めずにアジャイル型開発で要求を拡散させてしまうと収拾がつかなくなりかねない。
ただし、実際の開発では、フェーズやスコープをきれいに区分できないことも少なくないし、行政サービスは様々なプロダクトの組合せで成立するものなので、判断はそう簡単ではない。専門家の助言を仰ぐことが重要である。さらに、その判断に基づき、なぜアジャイル型開発が必要なのかを言語化することが、その後のプロジェクトにおいて重要な意味を持つこととなる。
②　意思決定プロセス
アジャイル型開発では、原理的に、予め仕様を完全に決め打ちすることはない。このことは発注者には、何を開発するのかを約束せずに期待通りの成果物が得られるのかという疑念をもたらす。また、受注者側には、無制限に要求が拡張するのではないかという不安をもたらす。ウォーターフォール型では、最初に品質を文書で明確に定義するのに対し、アジャイル型開発では、短期間で繰り返す開発サイクルごとにプロダクトオーナー（PO。開発するサービスの実質的な責任者）の責任において途中成果物を確定し段階的に品質を作りこんでいく。こうした慣れないプロセスを関係者に受け入れてもらう必要がある。この調整はときに困難を伴うが、関係者の理解を得ないままプロジェクトを見切り発車させると、納入時に期待ギャップが生じ、トラブルの原因となりかねない。
③　人材
アジャイル型開発において、もっとも重要な要素は何かと言えば、それは疑いなく「人材」であろう。どんな制約条件下でも、優秀な人材がプロジェクトをリードすれば、なんとか形にしてしまう。PO候補となる職員に研修や訓練を行うとともに、アジャイル型開発の経験を持つ職員にPOを補佐・支援させることも重要である。そうした人材が庁内にいなければ、外部専門家の支援を受けることも検討すべきである。ただし、アジャイル型開発に精通した人材は、世の中では引っ張りだこの状態なので、場当たり的に探しても良い人材が得られる可能性は低い。腰を据え、中長期的な視野に立って、人材確保の仕組みづくりをしていくことが重要である。
④　組織
アジャイル型開発は意思決定のスタイルが従来と大きく異なる。ウォーターフォール型の請負契約では、仕様を決定したら、基本的には受注者に責任が移る。発注者は最後に仕様通りの成果物が得られたかを検収すれば済むので、契約関係としてはシンプルである。これに対し、アジャイル型開発では、こうした開発前後の検収などのプロセスの意味は小さくなり、プロジェクトの過程で繰り返し行われる実質的な意思決定によって成果物が決まってゆく。したがって、POに成果物決定の責任を下ろさなければならない（注：もっともPOが専断できるという意味ではない）。
また、意思決定のレベルもフェーズによって柔軟に変えていく必要がある。MVP特定前の試行錯誤の段階では若手職員の方が、実導入に向けて関係部門との調整を行うフェーズでは管理職の方が、POとして向く、といったこともあるだろう。
さらに、中長期的にアジャイル型開発を根付かせようとするならば、部門横断的な支援組織も必須となる。個々の業務部門で得た知見やツールなどはいずれ忘却され、陳腐化する。これらを集約・共有・更新し、他のプロジェクトでの支援に活用していく機能が必要となる。こうした存在は諸外国ではCoE（Center of Excellence）と呼ばれ、米国のGSAのように部門横断的な組織に設置されている（※10）。
⑤　調達
アジャイル型開発を実践する中で最も行政職員が戸惑うのは、いかにアジャイル型開発に関する業務を調達するかである。
諸外国では、ソフトウェア開発をアジャイル型開発で行う場合、そもそも開発プロセス自体を内製化することが多い。しかし、現状、我が国行政機関では、内製化は困難であることが少なくない。外注を活用せざるを得ない場合、概ね以下のパターンで対応することとなる。
・ 準委任契約：「作業工数」を外注するという観点からは、無理なく発注できる契約形態である。経済産業省などで利用されることが多い準委任契約であっても一定の成果物を定めることができるが、発注者側がアジャイル型開発の観点でしっかり成果物をマネジメントできることが前提となる。
・ 労働者派遣契約：実質的に内製化に近い体制が実現できるので、最もアジャイル的な運用に向いた契約形態である。実際に特許庁などで調達が行われた例が見られる。組織内において、ある程度プロジェクトをリードさせることも可能である。問題は管理や事務手続の手間が大きくなることと、優秀なアジャイル人材を派遣契約で確保することは容易ではないということである。
・ 請負契約：請負契約でアジャイル型開発を行うことも可能であり、実践も行われている。パターンとしては、MVP特定までを調査研究の形で行う場合（この場合はプロセスを仕様として定義することになる）や、UIの開発において、例えば、画面の作り込みのために、開発サイクルの回数、期間、工数見込み等を定義しておくことが考えられる。これらの場合も、請負契約だからといって丸投げすることは許されない。うまく機能させるには、良い受注者を調達することも含めて、発注側の主体的なマネジメントが重要となる。上記報告書では会計検査院の事例を挙げているが、成功のポイントは何よりも、発注者と受注者が一体となってのプロジェクト運営であった。良い事業者を確保するためには、他機関も含めた情報交換のネットワークや、調達支援のアドバイザリなどが重要となってくる。
以上をクリアできれば、現行制度下でもアジャイル型開発の業務を調達することは可能である。なお、準委任契約及び請負契約については、偽装請負とならないよう気をつける必要がある。
（※9）MVP：Minimum Viable Product：実用最小限の製品。行政サービスであれば、実際にソフトウェアとして稼働する最小限のプロトタイプなど。
（※10）https://coe.gsa.gov/

5. おわりに―今後、行政機関が取り組むべきこと―

今後の行政サービスの開発・改革において、アジャイル型開発はますます重要となっていくことは間違いないと思われる。中長期的、組織的に推進していくためには、トップが明確な方針を示すこと、研修等を通じて管理職層はじめ関係者の理解を広げること、専門人材を確保し、組織内に一定程度プールすること、アジャイル型開発の支援組織を編成し、事例・ツール・ノウハウを収集・蓄積して個別組織の支援に当たらせることなどが重要となってくる。なお、ここでいう専門人材や支援組織とは、必ずしもアジャイル型開発に特化したものを指すわけではなく、例えば、CIO補佐官のスキルの一つとしてアジャイル型開発の資格や経験を求めたり、DX（デジタルトランスフォーメーション）推進組織のミッションとしてアジャイル型開発支援も含めたりする形で、アジャイル型開発の「機能」を備えさせるということである。こうした組織としての取組は、今後、どの行政機関でも重要になってくると思われる。
しかし、現場レベルでいえば、何よりも重要となるのは、繰り返すが「人材」である。力量のあるメンバーをいかにアサインできるか、そして、アジャイル型開発チームをいかに支援し、個々のメンバーが活躍できる場を作れるかが鍵となってくる。支援の方法として重要となるのは、①専門家をアドバイザーやメンターとしてアサインすること、②参加者にアジャイル型開発の実践に必要な実務知識を研修等を通じて付与すること、③物理的な空間や設備・備品だけでなく、関係者の理解も含め、メンバーが働きやすい環境を作ることである。これらは、必ずしも組織全体に広げなくても、部門レベルでスモールスタートできる。こうした取組が様々な機関で実践され、知見が共有されることが、我が国行政機関でアジャイル型開発が普及していくための第一歩になるだろう。
末筆ながら、本調査研究に協力いただいた、内閣官房IT総合戦略室、総務省行政管理局、「行政アジャイル開発研究会」を構成した当研究所会員企業（AWS、NEC、NTTデータ、日立製作所、富士通、日本マイクロソフト）、支援いただいたNTTデータ経営研究所、そして、ヒアリングに対応いただいた各機関のご担当者及び有識者各位に御礼申し上げたい。

本報告書は以下のウェブページに掲載されています。
一般社団法人行政情報システム研究所「行政機関におけるアジャイル型開発の導入に関する調査研究」報告書（2020年3月）
https://www.iais.or.jp/reports/labreport/20200331/agile2019/