ライフイベント型サービス設計とは何か:行政窓口が市民を疲弊させる理由

市民は「税務署」も「運輸局」も「年金事務所」も見ていない。見ているのは「子どもが生まれた」「親が亡くなった」「会社を辞めた」という自分の人生だけだ。ところが行政のデジタル窓口は、いまだに組織図をそのままウェブサイトに移しただけの構造になっている。市民が迷子になるのは能力の問題ではない。設計の問題だ。

ライフイベント型サービス設計とは、行政サービスを「部署」や「手続き」単位ではなく、出生・結婚・失業・死別といった市民の人生の出来事を起点に再構成する設計手法である。これにより、複数の省庁・地方自治体・民間機関にまたがる申請を、市民の視点から一つの筋の通った体験として束ね直すことができる。目的は美しいポータル画面ではない。市民が本来払わなくてよい「認知コスト」を取り除くことだ。

なぜ部署ベースの行政サービスは市民を疲弊させるのか

答えは単純だ。行政の組織構造は行政官のために最適化されており、市民のために最適化されていない。出生届は自治体、児童手当は別の部署、健康保険の変更は保険者、産休給付は雇用保険と、同じ一つの出来事に対して市民は五つ以上の窓口を回らされる。それぞれの窓口は自分の手続きしか見えていないため、市民がすでに提出した情報を何度も入力させる。

これは行動経済学者リチャード・セイラーが提唱した「スラッジ(sludge)」の典型例である。摩擦(friction)が単なる手間であるのに対し、スラッジは組織側の都合や責任回避によって不必要に積み重ねられた手続き上の負担を指す。セイラーとキャス・サンスティーンは2021年の論文で「スラッジ監査」の必要性を説き、サンスティーン自身も同年の著書Sludge: What Stops Us from Getting Things Done and What to Do about It(MIT Press)でこの概念を体系化した。行政の窓口分断は、悪意のない設計の積み重ねが結果としてスラッジを生む典型的なケースだ。

部署ベース設計の問題は、責任の所在は明確になるが、体験の所在が誰にも属さなくなることにある。誰も「出生という体験全体」の責任者ではないため、体験全体の質は誰にも測られず、誰にも改善されない。

ライフイベント型設計は実際にどう機能するのか

ライフイベント型設計を実践している国の多くは、あるパターンを共有している。手続きの入口を「窓口」ではなく「出来事」に置き換え、その出来事に必要な複数の手続きを一つの筋道として提示するというパターンだ。代表的な事例を挙げる。

• デンマークのborger.dkは、市民ポータルを「出生」「引っ越し」「死別」などのライフイベント単位で構成し、関連する複数機関の手続きを一つのページ内で案内している。
• 英国のGOV.UKは「Having a baby」「Death and bereavement」といったライフイベント別のガイドを設け、複数省庁の情報を単一の導線に統合している。これはGOV.UKサービスマニュアルが定める「ユーザーニーズから始める」という設計原則の実装形態の一つである。
• オーストラリアのmy.gov.auは、複数の給付・登録手続きを結びつける「Tell Us Once」的な仕組みを一部の生活イベントで導入し、同じ情報を複数機関に別々に入力させる負担を減らしている。

これらの事例に共通するのは、フロントエンドの見た目を変えただけではないという点だ。バックエンドで省庁間のデータ連携を前提にしないと、ライフイベント型のフロントは「案内はまとめたが入力は結局分断されている」という半端な体験に終わる。ここが多くの国が苦労するポイントであり、欧州連合が単一デジタルゲートウェイ規則の中で掲げる「ワンス・オンリー原則(once-only principle)」――市民や企業が同じ情報を行政に一度しか提供しなくてよいという原則――が重要になる理由でもある。

行動経済学はライフイベント設計にどう効くのか

ライフイベント型設計が有効なのは、単に手続きを束ねているからではない。市民がその瞬間に置かれている心理状態に対して、設計が誠実に応えているからだ。

出生、死別、失業、離婚――ライフイベントの多くは、認知資源が枯渇している最中に発生する。心理学でいう二重過程理論(システム1／システム2)に従えば、疲弊した市民は熟慮的なシステム2ではなく、直感的で誤りやすいシステム1で行政サイトを操作している。この状態でリンクを10個提示すれば、市民は途中で離脱するか、間違った手続きを選ぶ。ライフイベント型設計が効くのは、選択肢を絞り、順序を決め、次に何をすべきかを一つだけ示す選択アーキテクチャそのものだからだ。

もう一つ効くのがデフォルト設計である。死別のような場面で、遺族に「年金停止の申請フォームを探してください」と求めるのと、「すでに把握している死亡登録情報を基に、関連する三つの手続きを自動的に開始しますか」と提示するのとでは、負担の質が全く異なる。市民に何もしないことを許すデフォルトは、悲しみの中にいる人間にとって最も人道的な設計になる。

行政デジタル化の失敗の多くは、技術の失敗ではない。市民が最も脆弱な瞬間に、最も多くの意思決定を要求してしまう設計の失敗である。

さらに、給付の申請を先延ばしにする市民の行動は、しばしば怠惰ではなく現在バイアスの結果である。将来もらえる給付より、今この瞬間の煩雑な入力作業の痛みの方が心理的に重く感じられる。ライフイベント型設計は、申請の入口を出来事発生の通知そのものに埋め込むことで、この心理的な重さを減らす。

設計チームはどこから着手すべきか

ライフイベント型設計への転換は、ポータルの見た目を変える仕事ではなく、組織横断の運用モデルを変える仕事だ。着手順序を誤ると、既存の部署別サイロをきれいなラッピングで覆っただけの「見せかけの統合」に終わる。実務では次の順序が機能する。

1. 対象となるライフイベントを絞り込む。すべてのイベントを同時に扱おうとせず、発生頻度が高く、かつ複数機関にまたがる度合いが大きいイベント――出生、死別、失業、引っ越し――から着手する。
2. 現状のジャーニーを機関横断でマッピングする。市民が実際にどの窓口をどの順序で回っているか、どこで情報を再入力させられているかを、部署ごとの視点ではなく市民の視点で洗い出す。
3. データ連携の現実的な範囲を確認する。どの機関間ならデータ共有の法的根拠と技術基盤が既にあり、どこにワンス・オンリー原則を適用できないギャップがあるかを特定する。
4. 単一の導線としてイベントを再構成する。複数手続きを一つの申請フローに統合できない場合でも、進捗状況を一つの画面で追える「見える統合」を先に実装する。
5. 脆弱な瞬間に対応する例外設計を組み込む。死別や失業のように心理的負荷が高いイベントでは、デフォルトでの自動処理や、人間による支援への即時エスカレーションの経路を用意する。
6. 体験指標で継続的に測定する。処理件数や稼働率ではなく、完了までの所要時間、再入力の回数、途中離脱率といった市民側の指標で成果を追う。

この順序の要点は、技術統合を最初に完璧に済ませてから体験を作るのではなく、体験の輪郭を先に確定させ、データ連携はその輪郭に追随させる点にある。多くの行政デジタル化プロジェクトが失敗するのは、逆の順序――システム統合を先に完璧にしようとして、何年も市民に見える変化が届かない――を選んでしまうからだ。OECDが2023年に公表した「OECD Digital Government Index 2023」は、複数国の政府デジタル化の成熟度を比較する指標として、ユーザー中心設計の実装度合いを重要な評価軸に据えており、技術整備と体験設計を並走させる必要性を示している。

実装で崩れる典型的な落とし穴は何か

ライフイベント型設計を導入した組織が共通してつまずく点がある。一つずつ見ておく価値がある。

• イベントの定義が行政側の都合で切られている。「出生」を戸籍上の届出の日で区切ると、実際に市民が動き始めるのは出産前後の数週間だという現実とずれる。市民の心理的な開始点から定義し直す必要がある。
• 統合が見た目だけに留まる。ポータルのトップページに「ライフイベント」というタブを追加しただけで、クリックした先は結局部署別の申請フォームが並んでいるという状態は、市民の失望をむしろ増幅させる。期待を作って裏切ることは、期待を作らないことより悪い。
• 脆弱な瞬間への配慮が抜けている。死別や失業のような心理的負荷の高いイベントを、引っ越しや車の登録変更と同じ効率化ロジックで設計してしまう。速さだけを最適化すると、悲しみの中にいる市民には冷淡な印象しか残らない。
• 組織インセンティブが体験と逆方向を向いている。各部署が自部署の処理件数やSLAで評価される限り、部署をまたいだ統合に協力する動機は生まれにくい。体験全体の責任者(オーナー)を組織的に立てない限り、統合は一時的な取り組みに終わる。

これらの落とし穴に共通するのは、技術的な失敗ではなく、組織設計と評価指標の失敗だという点だ。ここはチェンジマネジメントの領域であり、ポータルの刷新以上に難しい仕事になる。

成果はどう測るべきか

ライフイベント型設計の成果を「ページビュー」や「デジタル化率」で測ろうとすると、体験の質を見誤る。測るべきは、市民がその出来事を通過するまでに要した総労力である。

具体的には、イベント発生から全手続き完了までの日数、同一情報の再入力回数、途中で人手のサポートに切り替えざるを得なかった割合、そして完了直後の満足度――特にカーネマンのいうピーク・エンドの法則に基づけば、最後の手続きが終わった瞬間の体験が、市民の記憶全体を決定づける。最初の四つの手続きが快適でも、最後の一つで再び同じ書類を要求されれば、市民が持ち帰る記憶は「面倒だった」に上書きされる。だからこそ、統合の最終ステップこそ最も注意深く設計しなければならない。

組織としてどこまで成熟しているかを客観的に把握したい場合は、部署別の取り組みの集合ではなく、体験全体を横断した成熟度で評価する視点が要る。CX成熟度診断のような12の構成要素にわたる評価は、民間企業向けに設計されたものだが、公共サービスにおいても「どこが部署ごとの最適化に留まり、どこが市民視点の統合に到達しているか」を可視化する枠組みとして応用できる。

公共部門ならではの制約をどう扱うか

民間企業のCX改善と公共サービスのCX改善には、決定的な違いが一つある。民間の顧客は不満なら離脱できるが、市民は行政から離脱できない。この非対称性は、設計者にとって重荷ではなく、むしろ責任の明確化として捉えるべきだ。

市民が選べない以上、行政には「使いやすさ」を選択の自由の代替として提供する義務がある。これはサービスデザインの実務では、アクセシビリティとチャネルの多様性を後付けの配慮ではなく設計の出発点に置くことを意味する。デジタルに不慣れな高齢者や、障がいのある市民、居住地域の通信環境が乏しい市民にとって、ライフイベント型ポータルが唯一の入口になってしまえば、統合は新しい排除を生む。窓口・電話・対面という従来の経路を並走させながら、どの経路を選んでも同じ体験の質と情報の一貫性が保たれることが前提になる。

公共部門ならではのもう一つの制約は、失敗の非対称性だ。民間企業のUXミスは顧客満足度の低下に留まるが、行政のミスは給付の遅延や社会保障の欠落という具体的な生活への打撃につながる。だからこそ損失回避の心理を軽視できない。市民は「もらえるはずの給付を逃すかもしれない」という不確実性に対して、実際の損失よりも大きな不安を感じる。イベント発生時に自動で通知し、申請の進捗を可視化するだけで、この不安の多くは解消できる。

これからのライフイベント設計はどこへ向かうか

ライフイベント型設計の次の段階は、案内の統合から、予測と先回りへの移行だ。出生登録が完了した時点で、児童手当・保育所の空き情報・予防接種のスケジュールまでを能動的に提示する。失業保険の受給が始まった時点で、再就職支援や職業訓練の情報を、申請させるのではなく届ける。これはデジタルトランスフォーメーションの話であると同時に、行政と市民の関係そのものの再定義でもある。行政は「申請を待つ機関」から「生活の変化に寄り添う機関」へと役割を移す。

この移行を組織的に進めるには、ライフイベントごとのカスタマージャーニーを継続的に維持・更新する仕組みと、複数部署をまたいだ責任者の設置が欠かせない。公共サービス分野のCXとデジタルトランスフォーメーションに関する知見が示すように、これは一度の刷新プロジェクトではなく、継続的な運用体制の問題として扱う必要がある。

市民が求めているのは、賞を取るようなポータルではない。人生の混乱期に、余計な混乱を一つも増やされないことだ。行政サービスの成熟度は、市民が最も脆弱な瞬間に何を要求されるかで測られる。組織図に沿った窓口をいくつ揃えたかではなく、市民の人生の出来事をいくつ、余計な手間なく通過させられたかで測られるべきだ。次に問うべきは「うちのポータルは何ができるか」ではなく、「うちの市民は今、人生のどの出来事の真ん中にいるか」である。