経済産業省で補助金申請システムを立ち上げた後、東京都のICT職第一期生として転職した宮部麻里子さん。「行政プロダクト開発の現場」で感じたこと、行政でプロダクトマネジメントする醍醐味について語ってくれた。
※2021年10月26日に開催された【Product Manager Conference 2021】より、東京都デジタルサービス局戦略部戦略課主任 宮部麻里子さんのセッション「行政プロダクト開発の現場の話」をピックアップ。書き起こし形式で編集したものをお届けします。
【プロフィール】東京都デジタルサービス局戦略部戦略課 主任(ICT職)宮部 麻里子
大学卒業後、電力系システム子会社で大規模基幹系システムの開発・保守を担当。2018年に経済産業省に転職、デジタル化推進マネージャー(任期付)としてgBizIDとjGrantsという2つのサービスの立ち上げを担当。2021年4月より新設されたICT職第一期生として東京都に転職。
まず最初にDXの観点で行政でいま起きていることをお伝えできればと思います。
国では、2018年に「デジタル・ガバメント実行計画」がリリースされ、この頃から電子行政の推進について議論される機会が増えてきました。2019年には、行政手続きを原則オンライン化していくための「デジタル手続法」という法律ができ、少しずつデジタル・ガバメントに向けて準備を進めてきました。
ただ、2020年、コロナ禍において給付金など至急の事務でデジタル化の遅れが顕在化し、当時デジタル改革担当大臣だった平井卓也さんは「デジタル敗戦」と表現しています。そこから、行政のデジタル化は最優先で取り組まなければならない重要な政策だと認知されるようになり、2021年にデジタル庁が設立されました。
自治体でも同様にデジタル化に向けた動きがはじまっています。今年、自治体の情報システム標準化に関する法律が定められました。デジタル庁が司令塔となり、自治体のシステムを標準化していくための法律です。地方自治体の現場では、職員は不足する一方住民サービスは多様化を求められ、デジタル化による業務効率化は必須だと考えられるようになっています。
続いて、行政プロダクト開発の現場ってどんな感じなのか?お話していきたいと思います。
みなさんはもしかしたらこんなイメージを持っているかもしれません。スライドに洗い出してみたのですが、正直ほぼその通りです。
行政を取り巻くステークホルダーは多岐に渡ります。国会や議会、国民の皆様からのご意見、それ以外に社会情勢なども踏まえながら意思決定していく。
また、長い間、行政にはシステムに詳しい人がおらず、ベンダーとうまく連携が取れない状況が続いていました。行政としても、デジタル化の遅れに危機感があり、少しずつ変わりはじめています。
ここからは私が経済産業省にいたときにプロダクトオーナーとして携わった案件を例に、具体的にどのような形で行政プロダクトの開発が進行したのか、ご紹介できればと思います。
「jGrants(ジェイグランツ)」という事業者のための補助金の電子申請システムの立ち上げを担当しました。国や自治体の補助金がネットでいつでもカンタンに申請できるサービスです。補助金の申請フォームの受付はもちろん、受付後の審査や通知などのフローも含めて、全てオンラインで完結できるようになっています。
「jGrants」を開発するにあたって、3つのチャレンジがありました。1つ目は、開発チームに民間のICT人材をアサインして、省庁側の体制を強化したことです。私自身、このタイミングで採用された一人でした。
さきほどもお伝えした通り、これまで行政とベンダー間のコミュニケーションがうまく取れず、結果的にベンダーに丸投げしてしまう現状がありました。システムに強いICT人材を民間から採用することによって、行政がやりたいことを我々が巻き取って要件定義する。それをベンダーとコミュニケーションを取りながら、プロダクトマネジメントしていました。
2つ目は、アジャイル型の開発プロセスに取り組んだことです。行政プロダクトはステークホルダーが多様かつ、社会情勢によって求めるニーズや優先度が変わりやすい特性があります。要件が変わったとしても柔軟に対応できるように、プロセスも適したアプローチを採用しておくことが行政のプロダクト開発において重要です。
実際に「jGrants」も、コロナ禍をきっかけに当初の要件から大きく変更がありました。もともと「jGrants」は働き方改革の文脈で、事業者の残業時間を減らすために、工数のかかっていた行政手続きをシンプルすることが目的ではじまりました。なので、最初のシステムはシンプルで、BPR前提で補助制度をカンタンにしてから、システム化していく戦略でした。
ただ、2020年、コロナ禍で立ち上がった補助金も「jGrants」を使えるようにしたいというニーズがでてきて。そういったときに、BPRをしてシステムに載るのではなく、すばやく補助金を立ち上げられることに優先度が高くなりました。結果的に戦略を見直して、汎用性、柔軟性の高いシステムに作り変えました。
また、行政プロダクトはスケジュールの見直しが難しいという特性もあります。とくに補助金の申請は、年間スケジュールが決まっています。4月から事業を始めるために、だいたい1月くらいから公募がスタートするのですが、機能がそこまでに間に合っていないと山を一年逃してしまいます。
スケジュールが動かせないので、決められた期間のなかで機能性や優先度を適宜見直さなくてはならなかったので、柔軟に対応できるアジャイルのプロセスがフィットしていたなと感じています。
3つ目のチャレンジは、アジャイルで開発を進める上で「設計ドキュメント」の作り方に工夫をしたことです。
最初にユーザーストーリーマッピングをして実現したい体験を定めた上で、「誰が●●できる」という単位で設計書を作成しました。
作成したのは、「WHY」「WHAT」「HOW」を定義した3つのドキュメントです。
・なぜつくるのか?(WHY)を定義したMRD
・なにをつくるのか?(WHAT)を定義したPRD
・どのようにつくるのか?(HOW)を定義したDevSpec
さらに大きなチャレンジだったのは、MRDをオーナー側、つまり行政側が執筆したこと。民間企業では当たり前かもしれないのですが、行政側がMRDを書くことはほとんどありませんでした。
執筆する際に心がけていたのは、「どんな機能がほしいか」だけでなく、どんな課題(Issue)があり、それをどういう状態にしたいのか(Goal)、またその先にどんなユーザーシナリオが実現するのかまで書くこと。
そうすることで、「どんな価値を提供したいか」をプロジェクトメンバーに共有することができ、手戻りや認識の齟齬を防ぐことにつながりました。
最後に、行政でプロダクト開発する魅力についてお伝えできればと思います。
もともと私は民間企業出身で、任期付きで経済産業省に転職しました。任期が切れたタイミングで、行政に残るか、民間に戻るか悩んだのですが、最終的に行政に残ることを決断しました。今年の4月から、東京都に転職し、デジタルサービス局で働いています。
行政に残ることを選んだ理由はいくつかあるのですが、ひとつは「後世に残る仕事」に携わることができるからです。冒頭でもお伝えしましたが、行政のデジタルシフトは今が黎明期です。これから行政のベースとなるルールやプラットフォームをつくっているタイミングだからこそ、携わったプロダクトがプラットフォームなら10年、データの台帳のようなデータレジストリものだったら、もしかしたら100年使うベースになるものかもしれません。
もうひとつは、行政には民間でやってきた経験が活きる場がたくさんあります。現場には瞬時にわかる課題が山ほどあるんです。少しの工夫で大きく変えられる領域がたくさん残されています。
しかし、日本の役所には海外と比較してもICT人材が少ないのが現状です。とくに必要としているのはプロダクトマネジメントができる方。いきなり内製化をすることはむずかしいので、ベンダーと連携しながら、システムを適切に設計し開発していけるように体制を強化していきたいと考えています。
東京都もデジタルシフトに向けていろんな取り組みをはじめたところです。昨年のPMカンファレンスで、東京都副知事の宮坂学さんが「なにもかもができる可能性に満ち溢れているけど、パターンがまだ決まっていないんですよね」とおっしゃっていました。まさに我々、パターンを決める仕事を進めていきたいと思っているところです。
この発表がみなさまの心に響いて、行政に少しでも関わりたいと思ってくだされば幸いです。本日はありがとうございました。
(おわり)
取材 / 文 = 野村愛
4月から新社会人となるみなさんに、仕事にとって大切なこと、役立つ体験談などをお届けします。どんなに活躍している人もはじめはみんな新人。新たなスタートラインに立つ時、壁にぶつかったとき、ぜひこれらの記事を参考にしてみてください!
経営者たちの「現在に至るまでの困難=ハードシングス」をテーマにした連載特集。HARD THINGS STORY(リーダーたちの迷いと決断)と題し、経営者たちが経験したさまざまな壁、困難、そして試練に迫ります。
Notionナシでは生きられない!そんなNotionを愛する人々、チームのケースをお届け。