デジタル行政は“全部デジタル”でいいのか？ マルチモーダルUXが生む包摂性と実装術

どうも〜おかむーです！今日はちょっと技術寄りだけど市民目線で読める話をするよ〜

• デジタル行政は“デジタル化すればOK”じゃない。市民が使える仕組みを複数チャネルで用意するのが肝心
• エストニアの成功も、英国の巨大失敗（FiReControlやPrism）も、実は「チャネルと段階設計」の差が大きい
• 日本がやるべきは“選べるUX”と運用重視のモジュール化。技術は既に足りてるんですよね

結論

デジタル行政は単にシステムを作ることじゃなくて「誰が、どこで、どの手段でサービスを受けるか」を想像して作ることが重要。オンライン一択にせず、オンライン（ウェブ・アプリ・チャット）＋オフライン（電話・窓口・郵送・キオスク）を組み合わせたマルチモーダル設計が成功確率を高める。要するに、サービスの“入口”を増やして、各入口を小さなモジュールでつなぐのがコツです。

レポート本文

世界の事例から学ぶ“選べる”設計

• エストニア：e‑ID、X‑Road、e‑Residencyで一貫したデジタル体験を提供している。これ、すごくないですか？ ただしエストニアでも郵送や対面がゼロというわけじゃなく、認証例外や救済措置を整備している
• イギリス：FiReControl（NAO報告で約£469mが無駄に）やPrism（約£88.5mの注目案件）といった大規模失敗は、要するに『一度に全部変えようとしてリスクが爆発した』ケース。設計が一枚岩で、代替チャネルや縮退運用が弱かったんです

成功と失敗を分けるポイント

• 段階的移行：クリティカルな機能は段階的に切り替え、フォールバック（旧システムへの戻し）を常備する
• チャネル冗長性：オンラインがダウンしても電話や窓口で処理できるルートを維持する
• 小さな勝利（MVP×多数）：大規模一括開発より、小さく回して改善する方が結果的に安い

技術の実装ヒント（実務チェックリスト）

• 認証：eIDやOAuth2/SAMLをベースに、電話や窓口での本人確認プロセスを明文化する（要するに“フェデレーション＋物理確認”です）
• データ連携：X‑Road的な疎結合のメッセージバス、もしくはKAFKA／メッセージキューで非同期連携。APIは“助走”に使う程度に
• オフライン対応：PWAのオフラインキャッシュ、IVR（音声自動応答）＋SMSの一時認証、自治体キオスクのハードウェア設計
• 運用性：コンテナ（Kubernetes）でマイクロサービス化、ログ・監査は不可欠（改ざん防止のために監査ログは別保管）
• プライバシー：データ最小化と暗号化（TLS・静的暗号化）、アクセス権はロールベース＋最小権限

市民UXの評価指標（使える指標に落とす）

• 到達率（チャネルごと）：オンライン、電話、窓口、郵送それぞれの利用割合と遷移率
• タスク成功率：1回で手続き完了できた人の割合（QoE）
• レスポンスタイム：チャネルごとの平均処理時間
• 支援ニーズ：支援窓口の利用理由をカテゴリ化して改善に結びつける

日本への示唆（具体案）

• デジタル庁は「窓口・電話・郵送の並行運用ルール」を自治体向けにテンプレ化して公開すべき。これでFiReControl的な一斉切替リスクを下げられる
• 既存のマイナンバー／マイページ基盤を活かしつつ、IVRやSMS認証を公式にサポートするSDKを標準配備する
• 地方自治体向けに“キオスク＋PWAパッケージ”を低コストで配布。UIは共通パターンで作っておくと運用が楽
• 市民参加のフィードバックループを制度化（窓口での改善報告を行政内KPIに取り込む）

まとめ

ぶっちゃけ、技術的には日本でも十分できるんです。でも“全部デジタル化＝完成”という考え方がリスクを招く。市民目線で選べるUXを用意し、段階的に移行する。技術はモジュール化して、小さく回して改善する。そうすれば失敗コストを抑えつつ利用率と満足度は上がりますよね。

おかむーから一言

僕は起業してコードも書いてきた身として言うけど、テクノロジーは“便利さの選択肢”を増やすための道具です。日本のDXはスマートにやれば世界に誇れるはず、まずは市民が選べるUXを徹底しましょう！