１.レジリエンスとフルーガル
前回、都市がレジリエントになるためのキーワードとして、「フルーガル」の考え方をご紹介した。フルーガルな情報システムとは、最小限のリソースを用いながら現場のニーズに機動的にこたえていくものである。都市を襲う突発的なショック要因、あるいは長期的な影響をもたらすストレス要因に対応するための情報システムの在り方として重要な考え方となる。続編となる本稿では、まず、著者がなぜフルーガルの考え方が重要だと思うにいたったのか、少し時間をさかのぼるが2011年東日本大震災の事例を踏まえながらご説明する。ここからは、地域ごとに異なる状況や時間の経過とともに変わっていくニーズに、情報システムがどのように応えていくことができるのか？という視点を持ちながらお読みいただきたい。
9年ほど前の2011年の秋、当時のLASDEC（現J-LIS）と共同で、東日本大震災で被災した岩手・宮城・福島3県内の13市町を対象に、情報システムの被害や復旧プロセスに関する調査研究を行った1。この調査と並行して、岩手・宮城県内のいくつかの被災自治体へのヒアリングを実施した。ヒアリングの焦点の一つに、「被災者支援システム」の活用実態を明らかにすることがあった。「被災者支援システム」は、阪神淡路大震災の後に開発された災害対応業務に特化した情報システムである。現在は、汎用WebシステムとしてJ-LISから全国の自治体に無償で提供されている。調査は9年前に行われたもので、現在とは利用環境や導入自治体数など異なる点も多いが、2020年の我々にも響く重要な示唆を与えてくれるものであった。
当時の事前の想定では、災害発生後の業務は、被災者支援システムを活用することで迅速な対応が可能となるはずであった。しかしながら、本調査では、①このシステムを使い慣れていない、②システム導入の方法が分からない（あるいはそもそもシステムの存在を知らなかった）、③自分たちのニーズや、やり方にマッチしていない、という理由などから、マイクロソフト社のエクセルやアクセス、あるいはオープンソースのソフトウェアを活用しながら自前で、現場のニーズに沿ったシステム開発の実態が明らかとなった。具体的には、各地域において、安否確認システムや被災者相談窓口システムなどがゼロから開発された。被災者支援システムの活用を試みた自治体においても、提供されたシステムをそのまま利用するのではなく、改修を施した上で使う例がみられた。
1 （財）地方自治情報センター・慶應義塾大学SFC研究所、「東日本大震災における地方公共団体情報部門の被災時の取組みと今後の対応のあり方に関する調査研究報告書」、2012年3月（https://www.j-lis.go.jp/rdd/chyousakenkyuu/cms_92685924.html）
２.短期的ショックに対応する現場開発の重要性
上述の「被災者支援システム」の活用を断念した理由①は、システムを普段使いしていないことから生じている。現場開発された仕組みの多くが、職員が普段業務で使いなれているエクセルをベースにしていたことから、災害などの突発的なショック要因に迅速に対応するためには、普段使い・慣れ親しんだシステムが重要であることが分かる。②は、災害が起こる前の準備段階から、システムを起動させ試運転を徹底することで改善することができる。ただしここで問題となるのは、事前準備された、あるいは事前に想定された現場の課題とその課題を解くためのシステムが、実際の状況にどの程度マッチするものであるのか、100％の想定が難しい点だ。どんなに事前準備を完璧に行ったとしても、「想定外」が起きれば事前のシナリオは通用しなくなる。事前シナリオに基づいた情報システムもしかりである。
この問題が上記③につながってくる。災害は広範囲に影響を及ぼし、被災状況は地域により異なり、必要なソリューションは統一的なものではなく、多岐にわたった。加えて、時間の経過とともに状況が変化し、ニーズが変わっていった。対応にあたる職員たちは、その場その場の状況に応じて必要なツールやシステムの判断を行い、できる範囲で自らツール開発を担ったことになる。さらには、自治体ごとに業務のやり方が異なるケースがあり、被災者支援システムが用意した環境をそのまま使えなかったという事情もあった。例えば、被災の事実を証明するため住民に発行される罹災証明書の帳票の仕様が、被災者支援システムの帳票と異なるためにそのまま使わなかった自治体もあった。
東日本大震災は100年に一度の災害と言われ、災害の規模、影響の大きさ、すべてに「想定外」の枕詞がつけられるほどの未曾有の自然災害だった。すべてが想定外だったからこそ明らかとなった、短期的なショック要因に対応するためのシステムの本質は、その場で利用可能な最小限のリソースと、ユーザーが普段使い慣れたツールを用いた現場開発、これらを可能とするICT環境ということになる。
３.データの不一致がもたらす災い
前回、フルーガルな情報システムを達成する4つの条件として、汎用性・遍在性・唯一性・一貫性をご紹介した。これらは、情報システムの中でも特に「情報」の特徴に着目した条件となる。それぞれの説明は前回をご参照いただくとして、先にご紹介した調査の中でこれらの条件の重要性を示唆した事例についてみてみたい。
短期的なショック要因（本稿においては自然災害）に対応する情報システムは、普段使い慣れた最小限のリソースを用いた現場開発であると述べた。このような現場開発は、刻々と変化する現場のニーズに応えることはできるものの、フルーガルの4条件を満たさない限り、長期的なニーズに応える持続可能なものにはならない。どういうことだろうか。
安否確認システムや、避難所管理、罹災証明書発行業務など、東日本大震災後に各地で様々なシステムが自発的に開発された結果、各システムに格納された住民情報の名寄せが問題となった。住民情報の入力ルールが決まっておらず、その場その場で決められた形にそっていたため、システムAに記載された「佐藤〇〇さん」と、システムBに入力された「佐藤〇〇さん」が同一人物なのか別人物であるのかどうか、さらには住民記録上のどの「佐藤〇〇さん」と同一人物なのかを見極めるために、調査を実施したほとんどの自治体で、住民記録情報との名寄せを行わなければならなくなった。フルーガル4条件の「唯一性」「一貫性」を欠いたシステムは、その場限りのアドホック的対応においては効果が高いものの、レジリエントプロセスにおける復旧から進化フェーズにかけて、他の仕組みを含めた全体の組織化が行われる際には脆弱性を抱えてしまうことになる。住民情報の名寄せは、職員が不眠不休で作業をして、場をしのいだ事例が多かった。職員の使命感と馬力に頼ることには限界もあるため、私たちは、この教訓を生かしていく必要がある。
４.問題の本質は改善されていない
唯一性と一貫性の問題については、上記の事例とほぼ同様のことが、コロナ禍のマイナンバーカードを用いた特別定額給付金の業務で散見されたことは記憶に新しい。国民一人あたり10万円給付と決まってから給付まで時間がなく、急ごしらえのシステム開発が進められた。マイナンバーカードを用いたオンライン申請は国が用意するマイナポータルのぴったりサービスで受け付け、給付業務は基礎自治体が担う二重構造となった。
マイナポータルから基礎自治体が管理する住民記録にアクセスする方法はないため、給付業務を行う自治体ではマイナポータルから送付される申請情報と住民記録情報との突合業務が発生した。他にも世帯主申請だったことなど、現場の混乱を増幅させる要因が重なり、自治体職員が休日返上で、2人一組になって目視で突合作業をする様子が度々報道された。
本来ワンストップでスムーズな給付が望めるはずのオンライン申請だったのが、100を超える自治体で、あまりの手間にオンライン申請は中止して、郵送受付のみに切り替えた2。郵送用の申請書に自治体独自の照会番号を記載し、その番号をもってオンライン申請をするためのシステムを開発した自治体もあった。
結果的に、マイナポータル経由のオンライン申請では、自治体のコンビニ交付でも使用されているJPKIのシリアル番号を使って申請者の識別を行うことが可能と判明したものの、そのための仕組みを事前に用意していた自治体はなく、システムの対応が間に合わず大きな混乱を招くことになった。唯一性と一貫性の欠如を現場の踏ん張りで乗り越える構造は、9年前から変わっていない。
2 7月30日までに111自治体が中止・停止した（朝日新聞2020年8月21日付）。
５.全国共通のシステムか現場開発か
ここで冒頭の問いに戻ろう。地域ごとに異なる状況や時間の経過とともに変わっていくニーズに、情報システムはどのように応えていくことができるだろうか？
結論としては、唯一性を担保する認証や識別子の部分は全国で共通の仕組みを構築し、一貫性を実現するためのデータ連携にはAPIを活用する。共通基盤の上に、地域の実情やニーズに応じて現場開発されたアプリケーションが接続される。アプリケーションは、業務内容によっては、全国一律で運用できるものもあるかもしれないし、災害対応など現場で臨機応変に対応が求められる業務においては、現場開発やカスタマイズを前提とするのが良いかもしれない。いつでもどこでも情報やサービスにアクセスできるように（遍在性の確保）、利用者の環境を制限しないことも重要となる。オンラインサービスはPCだけではなくスマートフォンでのアクセスが前提となりつつあるし、最近は災害対応の現場でも自治体職員が出先でスマホから情報の入力を行うケースが増えつつある。より汎用性の高い（標準的でオープンな）仕組みを活用することで、システムの利用者側の利便性が向上する。2011年の段階では、被災自治体においてはエクセルが多く使われていたことは前述の通りである。
ここで最大の課題として立ちはだかるのが、データモデル（ここでは情報格納のルールと構造を指す）の存在だろう。東日本大震災の調査では、各地域に設けられた避難所ごとに避難者リストが作成され、統一的なルールがなかったことから後の情報の突合に影響を与えた。住所（番地）の書き方、氏名の入力方法（漢字・かな・カタカナどれを使用するのか）などが避難所ごとに異なることで、突合作業は困難を極めた。住民記録の基本4情報については、JPKIを利用することで統一化を図れる一方で、異なるアプリケーション間に格納されたデータをAPIで相互接続し連携していくためには、共通の理解や意味に基づきデータが記述されている必要がある。一時的でアドホックな情報連携であれば職員の目視突合で乗り切れたとしても、日常的に行うことは不可能だ。
近年相次ぐ豪雨災害の現場では、災害対応業務に従事する多様な組織間でリエゾンが組まれるが、その中での情報共有が課題となっている。被災自治体Aに対して事業者B、C、Dなどが同じ情報を求めるなど、情報共有が上手くいかないことにより非効率な対応となっている現状がある。一方で、過去の研究が示しているように、事前に決められたソリューションは必ずしも現場の状況をサポートするものではない。これらの問題意識を踏まえながら、筆者は現在、災害時の自治体の受援力を高めるための共通データモデルについて、全国の自治体と共同研究を行いながら検討しているところである。
６.多様な選択肢を可能にする組み合わせ
フルーガル4条件の「唯一性」と「一貫性」について紙幅を割いてきたので、最後に「汎用性」と「遍在性」を考える上でヒントになる事例をご紹介した
い。汎用性とは、平たく言うと普段使いしている、あるいは使い慣れたシステムや仕組みのことを指している。遍在性は、いつでもどこでも、がキーワードだ。マイナポータルを例にとるならば、ポータルへのログイン時にスマホでカード情報を読み取れるようになって利便性が格段に向上したことは、遍在性の強化と言ってよいだろう。マイナポータルはブラウザ上で動くため、汎用性の観点から必要条件は満たしているものの、まだ日常使いをするような仕組みになっていない点が改善ポイントとなる。日常使いを実現するためには、まずはそこに多くのサービスが展開されていることが必須条件となる。さらに、既に私たちが日常に使っているサービスとの連携により、使い勝手を高めていく方法もある。
下図は、筆者が3年間暮らした北欧・ノルウェーの行政ポータルサイトへのログイン画面である。Altinnと名付けられていて、考え方としてはマイナポータルが目指しているものに近い。Altinnは、“あなたとのデジタルガバメント対話ポータル（Altinn -Your digital government dialogue）”だと説明されている。ログインしようとすると、6つのオプションが提示される。
図表1 ノルウェーのポータルAltinnログイン画面
（出典）Altinnウェブサイト（https://www.altinn.no/en/）
筆者はこのポータルを日常的に使っていた。日本とはガバナンスの構造が異なるためそっくりそのまま参考にできるわけではないが、役所からのメールを読んだり、毎年の税還付の申請、引っ越しの手続きなど、すべてこのポータルで済ませていた。ログインIDとなる個人番号を受け取るために一度税務署に行ったきり、行政手続きをするために役所に行ったことは一度もなかった。
話を図に戻して、ログインオプションで特徴的なのは、“BANKID”である。これはバンクID、すなわち銀行が発行したIDという意味で、筆者は日常的にこのIDを使用していた。Altinnを日常的に使うことが多かったとはいえ、日々の暮らしで最も利用頻度が高いオンラインサービスはオンラインバンキングだった（ほぼ現金を使わない生活だったことも影響している）。オンラインバンキングのログインIDがAltinnのログインにも使えることは、とても便利であった。一番上の“MINID”とは私のIDという意味で、個人番号を申請すると役所から送られてくるパスワードカードのようなものを指す。様々なログインオプションが用意されていることは、利用者にとっては使い勝手がよく、普段自分がよく使うサービスのIDをそのまま使えることも、ポータルの利便性を高めている。
７.おわりに
以上、東日本大震災の研究から現在の災害対応、マイナンバーカードやマイナポータルの事例をもとにフルーガルの考えについてご説明してきた。まとめると、フルーガルな情報システムとは、全国共通の仕組み（認証、識別子）＋現場開発を許容する環境＋異なるアプリケーション間のデータ連携（API）を肝とする仕組みである。クラウドなどの共通基盤の上で多様なアプリケーションの組み合わせを可能とし、データ連携により現場の非効率性の解消を図ることが、フルーガル情報システムの目指すべき方向性ということになる。
短期的ショックへの対応だけではなく、システムが長期のストレス要因にも対応し、持続可能になることは社会全体のレジリエンスにもつながるため、筆者はフルーガルの考え方をレジリエンス達成のための重要なエッセンスとしてとらえている。
