役所の窓口で「出戻り」させない。QRコードで『マイ・タイムライン』を生成する、次世代手続き支援ツールの設計図

1. はじめに：なぜ「手続き」のDXに挑むのか

新社会人として最初の一歩を踏み出した時、私を待ち受けていたのは「引越し」という名の高い壁でした。
次から次へと現れる役所の手続き、公共料金の解約、住所変更の山。何から手をつければいいのか、書類に不備はないか。慣れない新生活の中で、暗闇を歩くような不安を感じたのを今でも覚えています。

その後、障害福祉サービスの現場に身を置く中で、その不安は確信に変わりました。
福祉サービスを利用される方やそのご家族にとって、手続きは単なる「事務作業」ではありません。生活の基盤を整えるための切実なプロセスです。しかし、窓口で渡される厚いパンフレットや、複雑に絡み合った提出順序の前に、多くの方が立ち尽くしていました。

「あの引越しの時の戸惑いを、福祉の現場でも繰り返させてはいけない」

「手続きの迷路」を、エンジニアの技術で「光の差す道」に変えたい。それが今回のプロジェクト『ライフイベントナビゲーター』の原点です。

2. 解決したい課題：窓口での「出戻り」という悲劇

行政手続きにおいて、最もユーザーの心を折るのは「書類が足りなくて、また明日来てください」と言われる出戻りです。 原因は、自分の状況に合った「個別の手順（クリティカルパス）」が見えないことにあります。

今回、私が設計したツールの核は「QRコードによる個別最適化」です。

• 事前準備: 公式サイトのQRから、一般的な必要書類を自宅で確認。
• 窓口連携: 窓口職員が提示するQRをスキャンするだけで、その人の状況（病状や家族構成）に合わせた「マイ・タイムライン」がスマホに自動生成されます。

3. 設計のこだわり：IPA「共通語彙基盤（IMI）」への準拠

個人開発であっても、公共性の高いツールには「信頼性」と「拡張性」が不可欠です。 そこで今回の要件定義では、IPA（情報処理推進機構）が提唱する「共通語彙基盤（IMI）」の考え方を採用しました。

■ 業務フロー（スイムレーン図）

ポイント: 職員と住民がQRコードという「共通の器」でデータをやり取りするフローを定義。これにより、入力の手間を省き、正確な情報をスマホへ届けます。

■ データ構造（クラス図）

ポイント: データの項目名をIPA標準（Person_Name, Organization等）に合わせることで、将来的に他の行政システムや医療機関とデータ連携（相互運用性）ができる「標準設計」を目指しました。

4. ロジックの肝：「待機中」と「依存関係」の可視化

単なるToDoリストとの最大の違いは、「依存関係（dependsOn）」と「バックアップ行動」の定義です。

• ロック機能: 「Aが終わらないとBができない」という依存関係をロジックで制御し、出戻りを物理的に防ぎます。
• 待機ステータス: 「連絡待ち」の期間に何もしないのではなく、「もし連絡が来なければここに電話する」というバックアップ行動を提示。看護師が患者さんの不安に寄り添うように、アプリがユーザーの不安に寄り添います。

5. おわりに：要件定義は、エンジニアの「アセスメント」

看護の世界では、適切な介入のために「アセスメント（現状分析）」が欠かせません。エンジニアにとっての「要件定義」も、全く同じだと気づきました。

生成AIと共に徹底的に設計を詰め切ったことで、今、私の頭の中には実装すべきコードの輪郭がはっきりと見えています。

次なるステップは、この設計図を現実にする「プロトタイプ実装」です。 ReactやモダンJavaScriptを駆使し、現場で本当に喜ばれる「迷わない体験」をカタチにしていきます。