補助金申請システム（jGrants）を省庁とアジャイル手法で開発

はじめに

2019 年 12 月に運用を開始した経済産業省のＪグランツは、事業者の補助金への申請および、補助金事務局での申請や事業情報の管理を効率化するためのウェブアプリケーションです。このプロジェクトは ANNAI が経済産業省と 3 年間密接に協力しながら基礎的な調査を踏まえ、アジャイル開発手法を用いて開発に当たりました。このブログポストでは対官公庁ならではの課題や、Ｊグランツをアジャイルで開発する至った経緯、アジャイルを実践する上でクリアしていった課題や、アジャイルがもたらす恩恵の中でも一般的には語られないものについて記したいと思います。

（なお弊社開発のＪグランツは、雇用調整助成金のインフラおよびシステムから完全に独立したサービスです。また、持続化給付金とは異なる契約・予算に基づくプロジェクトであり、サービスデザイン推進協議会は関与しておらず、同協議会の下請け企業等とも一切関係ありません）

問題：高度に複雑化した補助金の申請プロセスと運用業務

補助金申請・管理の現状の複雑さゆえに、まず開発のスタートラインに至るまでに多大な労力を要しました。たとえば補助金と一口に言っても、そこには直接補助金と間接補助金の二種類が含まれます。前者は省庁が直接運用・管理を行い、後者は省庁から直接委託を受けた下部組織や外郭団体、さらにはそこから再委託を受けた組織など様々な機関・組織により運用・管理されます。また、補助金の申請・採択・運用等のプロセスは統一されておらず、補助金等に係る予算の執行の適正化に関する法律（以下「適正化法」）などに基づいて補助金ごと・または機関ごとに定められています。さらに、その管理方法も機関・組織によっては全てが紙ベースであったり、独自のシステム化が進んでいたりなどの状況にあり、結果としてそれらの違い全てを網羅するシステムの開発は現実的ではありませんでした。そのため、まず主要機関の申請・採択プロセスや管理方法を観察／分析したうえでの Business Process Re-engineering (BPR / 業務改革）に取組み、業務プロセスを簡素化した上でシステム化することを提案しました。

アジャイル型のプロジェクト管理

確立していない業務プロセスからは仕様を起こすことはできないため、プロジェクトの管理はディスカバリー・開発・改良を繰り返すアジャイル型で進めていくことを ANNAI が提案し、これが受け入れられました。しかしこれは同時に、最終的に納品されるプロダクトの完成形が定義されていないことも意味します。政府のソフトウェア開発プロジェクトでは今でもウォーターフォール型が主流なため、経済産業省の関係者にはプロジェクトを進めていくなかでアジャイル開発手法について体得して頂きました。

プロジェクトの計画段階では、API の公開およびフロントエンドとバックエンドのデカップリング等を検討していました。その実現可能性の査定としてプロジェクト初期にプロトタイピングを行い、その過程で業務フローを精査しながら必要な UI やロジックの洗い出し、またそれらの要素の関係性についての理解を深めた上で、最終的なアーキテクチャーを決定する必要がありました。このような柔軟な対応を要するプロジェクトは、開発前に全ての仕様定義を必要とするウォーターフォール型による管理が難しいため、アジャイル型アプローチを採用したからこそ実現できたと言えます。

プロジェクト管理はスクラムをベースに行いましたが、現実の状況に対応してプロセスに様々な変更を加える必要がありました。また、実際の運営には多くの苦労がついて回りました。まず担当の方々にアジャイルの概念を理解していただき、その上でプロジェクト上の各役割とその責任、また頻繁にコミュニケーションを取ることの重要性、要件やタスクに優先順位があることや、それが状況によって変化することなどを学び・実践していただきました。実際にこれらを踏まえて実際にスムーズにプロジェクトを進行できるようになるまでには時間を要しました。

アジャイルの実践

アジャイル型のプロジェクト管理をする上で重要なのは、クライアント - 特にスクラムでいうプロダクトオーナーの役割を担う人 - がアジャイルの価値およびフレームワークのルールを理解した上で実践することです。プロダクトオーナーはいわばプロダクトのディレクターです。重要な判断や責任の所在を分散させず、プロダクトオーナーという特定のロールに限定することで、決断にかかる時間を短縮しプロジェクトの進行速度を高めることが可能になります。しかし、アジャイルに馴染みがない方がプロダクトオーナーに指名された場合、ウォーターフォールとは全く異なるマインドセットをもとにプロジェクトを進めていくことに苦労するケースが多いようです。そのため、ANNAI はアジャイル手法が掲げる価値に基づいてプロダクトオーナーがその権限・責任に従ってプロジェクトを進められるよう、プロジェクトを通してサポートを行いました。

要件・仕様の変化とコミュニケーション

ウォーターフォール型開発では、しばしば開発の初期段階でクライアントが開発側に要件を伝え、それをもとに仕様が決定され開発が行われます。しかし、アジャイル型開発では仕様の決定はプロジェクトの全期間を通して徐々に行われます。状況が変化したり、技術的問題と遭遇したり、クライアントがシステムへの理解を深めるなかで要件や仕様が決定・変更されていくため、プロダクトオーナーはプロジェクトのゴールを見据えつつ、刻々と変化していくシステムの要件や仕様を把握して、どのような開発が行われるべきかの適切な判断を随時下していく必要があります。

要件・タスクの優先順位

アジャイルがウォーターフォールと根本的に異なる点の一つとして「時間とリソースは有限である」という考え方が挙げられます。この制約のなかで、プロダクトの価値を最大化するために何を実装すべきかをその都度判断する必要があります。

開発側はマイルストーンやスプリントごとにクライアントと仕様の詳細を詰めながら、特定の機能の実装にかかる工数（時間数またはエフォート）を見積ります。それをもとにプロダクトオーナーがその機能をオリジナルの仕様のまま実装するか、仕様を変えるか、または実装自体を見送るかなど、その機能の要件、その時点での全体の状況、および他の要件の優先順位を鑑みて総合的に判断します。これはウォーターフォール型の開発において「仕様に含まれているから」という理由で機能の価値を問わず実装するマインドセットとは根本的に異なります。そのため、アジャイルをコーチする側は、プロダクトオーナーがこの考え方を正しく理解することを促し、これが一貫性をもって実践されていることを継続的に確認する必要があります。

私たちはしばしば「このマイルストーン（またはスプリント）で A の機能を実装するためには、B・C・D のいずれかの機能をスプリントから外す必要があります」といった交渉を持つ必要がありました。これはプロジェクト当初、ウォーターフォール型に慣れているクライアントにとって受け入れが難しいものでしたが、時間の有限性と優先順位の 2 つの概念の理解が浸透したあとでは、この会話を自然に持てるようになりました。

スケジュールに対するクライアントの期待値の管理

アジャイル型開発においては、仕様が徐々に明らかになっていく上で、開発速度へのクライアントの期待値が上がるのをどのようにマネージするかというのも、プロジェクト管理上のチャレンジでした。

アジャイル型開発では仕様が明らかになってきたとしても、詳細は実装直前、または実装時まで明らかになりません。そのため、クライアントとのコミュニケーションを取らずに開発だけを進めることはできません。異なる機能の開発が並列して進む場合、プロダクトオーナーの作業量が増えてボトルネックとなるため、複数のプロダクトオーナーを養成する必要が生じます。前述のようにプロダクトオーナーの養成には時間がかかるため、「予算を１０倍にするから、１０倍のスピードで複数機能の並行開発をしてほしい」とリクエストされても、そもそもクライアント側が対応できないという事態が発生します。

また開発側としても、プロジェクトにリソースを投入する際には開発者のオンボーディングやコミュニケーションオーバーヘッドの増加などにより、暫くのあいだ開発速度が落ちることが知られています。分かりやすく言えば、残された開発業務の見積もりが 100 人日だとしても、100 人の開発者を投入して 1 日で完成させることはできないのです。またアジャイルのスケーリング自体が日本ではまだメジャーではなく、ANNAI においてもその実践は課題です。

クライアントにこのような理解が欠けている場合はリソース不足との烙印を押されかねないため、アジャイル型のプロジェクト管理や、開発業務の性質をクライアントに正しく理解していただけるよう説明を重ねるのもプロジェクト管理上の重要な作業でした。

成果物に対するクライアントの期待値の管理

冒頭で触れたとおり、現実世界での補助金の運用は非常に複雑で、無数に存在する既存のプロセスに対応するシステムを開発するのは現実的ではなかったため、BPR をもとにプロセスの共通項を抽出し、よりシンプルなプロセスとしてデザインし直した上でシステム化するというアプローチを採りました。

ステップ数が多く複雑な業務プロセスを文章や図などで表現してもクライアントに伝わりにくく、そのため機能詳細を詰める際のコミュニケーションに支障が生じました。そのため、プロトタイプを元に仕様詳細を決めていくアプローチで進めることで合意しました。プロトタイプは手に取って確認できるという大きな利点があるものの、新たなリスクをもたらします。例えば、クライアントがプロトタイプを完成品と誤認してしまい、細部への批評が殺到するなど思わぬ反応が返ってくることがありました。

また、「メテオフォール型開発」と揶揄されるような突然の変更を何度か乗り越えることにもなりました。例えば上位ステークホルダーによる方針転換やスケジュール見直しにより、開発アプローチを根本から見直す必要に迫られるという自体も発生しました。

開発者に負担をかけることでこのような危機的状況を凌ぐケースが散見されますが、これは長期的にサステイナブルな解決法ではありません。また、上記のスケーリングの議論のように、人数を増やして短期間で解決できる問題でもありません。そのため「現状のニーズを鑑みて、どの機能を優先的に実装するか・現実的な対応は何か」という、時間とリソースの有限性に基づく優先順位の決定というマインドセットをクライアントと共有していることで、チーム全体として最善の判断を選択して危機を乗り越えることができました。

アジャイルがもたらす恩恵

アジャイル開発手法を用いることで、システムの価値を最大限に高めるかたちで要件を実装しつつ、スケジュール通りにＪグランツをローンチすることができたのと同時に、このような開発工程を通して関係者のプロジェクトへの関わり方にも大きな変化をもらたしました。

ウォーターフォール型では要件定義以降、検収までは開発側に任せきりになりがちですが、前述のとおりアジャイルが提供する環境下ではまったく異なります。関係者がチームとして主体性をもってプロジェクトに継続的に関わるようになったことで、現実の状況やニーズの変化を見据えながらの最適なシステムの構築が可能になりました。また、このプロジェクトを成功に導く上で不可欠だったプロダクトオーナーは、この開発プロセスを通してシステムの仕様を最も良く理解するに至りました。これらの人材は、今後も引き続きＪグランツを発展させていく上でクライアント自身にとっても掛け替えのないものです。

アジャイル型手法は、開発の迅速性や柔軟性にフォーカスを当てられることが多いものの、上記のようにプロジェクトおよびプロダクトを深く理解する人材の育成にも大きく貢献するため、結果としてプロジェクトに長期的な好影響を与えることは特筆すべき点だと考えます。

官公庁プロジェクト特有のチャレンジ

アジャイルの価値の実践を妨げる官公庁プロジェクトの仕組み・構造上の問題

官公庁のプロジェクトにおいては年度当初の予算獲得と執行の枠組みがあるため、アジャイル型開発手法に基づき、プロジェクト開始後に要件定義を行うことを契約上合意しているにも関わらず、入札時に想定した仕様やマスタースケジュールの死守を求められ、途中でどのような不測の事態が起こったとしても変更できないという問題があります。

また、複数年掛けて構築すべき大きな課題を一部ずつリリースするということができず、常に単年度のグランドオープンを求められがちなことも、官公庁のプロジェクトの難易度を上げる原因となります。

このように現時点では官公庁向けの IT プロジェクトは、仕組み・構造的にアジャイルの価値の実践をサポートできないという根本的な問題があります。

なおイギリス政府は、政府系の IT プロジェクトは必ずアジャイル型開発を採用する必要があること明確に定めており、アジャイルについての説明や、アジャイルデリバリーのための高品質なサービスマニュアルも提供しています（https://www.gov.uk/service-manual/agile-delivery）。日本政府が今後アジャイル型開発を活用して効率的に価値ある IT システムを構築していくには、政府内部での様々な改革が必要だと言えます。

まとめ

数千もの事務局においてそれぞれ異なるプロセスの共通項を導き出す作業に始まり、おぼろげな輪郭しか持たない要件から実装可能なレベルの仕様に固めていく作業は非常に困難なものでした。また、スケジュールの前倒しなど様々な問題が生じる中、経済産業省の担当チームと ANNAI が一丸となってプロジェクトに取組むことで数々の制約や困難を乗り越え、Ｊグランツはスケジュール通りにローンチを迎えることができました。そして Drupal の柔軟性と信頼性の高さを最大限に活かし、アジャイル開発手法を効果的に利用することで、ANNAI はこの難易度の高いプロジェクトを成功に導くことができました。また、経済産業省にとっても目的としていたシステムの完成だけでなく、アジャイルという今までとは異なるマインドセットに基づいたプロジェクト運営を成功させた功績・経験や、人材上の恩恵は特筆に値することでしょう。