【6月ユーザー会】井上様による登壇レポート記事
目次
ユーザー会でのLT（ライトニングトーク）登壇の様子をレポート！
この記事はユーザー会での北九州市役所 井上さんのLT（ライトニングトーク）登壇の様子をお届けするレポート記事です。
今回は「FormBridgeで本人しか申請できない仕組みを作ってみた話」でご登壇いただきました！
はじめに
こんにちは、北九州で働いております、井上です。
2年前はcybozu Daysで開催された「kintone AWARD」に、昨年も同じくcybozu Daysで開催された「kinton show+case unlimited」に登壇いたしました。
実は、もっとkintoneに触れたくて、家族で「チーム応援ライセンス」を購入しています。
システム開発の背景
今回は、「FormBridgeで本人しか申請できない仕組みを作ってみた」ということでお話しさせていただきます。
ただ、結論としてすぐに実用化できるシステムではないです。もう少し頑張ればなんとかなりそうかな、という学びを得られたので皆さんに共有させていただければと思います。
作りたいシステムとしては、以下のものを想定しています。
- 会社や役所からたくさんの人に通知を送る
- 通知の中には申込コードが書いてある
- 申し込みにはWebサイトにアクセスして申込コードや氏名の認証が必要
- 認証が取れた場合のみ申し込みができる
FormBridgeとkViewerで、Toyokumo kinoneApp認証を利用すれば、申込コードの送付をせずに実現できますが、その場合、最大でも1,000件までの上限が付いてきてしまいます。
※オプション契約により、最大10,000件まで認証上限数を追加可能です。詳しくはこちらのヘルプページをご確認ください。
そこで、北九州市では、コロナの給付金事業の際に、紙で申込コードを送付して、そこから電子申請をしてもらう仕組みを採用しました。
※コロナ禍での北九州市のkintoneとトヨクモ製品活用事例については以下の記事に詳細を記載していますので、ぜひ併せてご覧ください。
◾️行政×トヨクモで広がる可能性！コロナ禍の業務ひっ迫を救ったシステムとは
電子申請の際には、申込番号と生年月日を使い、その人が本人かどうかを照合して、OKがでないと、その画面の先に進めないシステムを組んだのです。
この”データベースと照合して、ないデータだと進めない”という機能は、FormBridgeだけでは実装できず、当時はカスタマイズでAWSと連携して実現しました。
この機能を、トヨクモ製品とkintoneの標準機能だけで何とか実現できないかというのが今回のチャレンジになります。
必要なものとシステム構築の下準備
今回の仕組みを構築するのに必要なものは以下の通りです。
- 表計算ソフト（Excel、Google スプレッドシートなど）
- kintone
- FormBridge
- kViewer
FormBridgeとkViewerでAPI連携を使うので、プレミアムコース以上が必須となる点だけご注意ください。
まずは、こちらのように表計算ソフトで名簿データを作成します。
「氏名・カナ氏名・申込コード（ランダム生成）・生年月日」を並べ、その右に「重複確認コード」を作成します。
重複確認コードは、申込コード・カナ氏名・生年月日を文字列で結合したものです。
ポイントは、この重複確認コードをkintone側の計算フィールドではなく、あえて文字列フィールドとして持たせることです。これにより、あとでFormBridge側で処理しやすくなります。
このデータをCSV形式でkintoneにインポートしたら、kintoneで「名簿データアプリ」と「申請情報アプリ」の2つを作成します。
どちらにも重複確認コードを登録し、「重複禁止」の制限をつけておきます。これが、”1度しか通らない仕組みの核”です。
名簿データアプリには、あらかじめ「データフラグ：無効」というフィールドも付けておきます。この“無効”フラグは、後で「不正な申請かどうか」を判定するために使います。
FormBridgeとkViewerで申請画面を構築
ここからは、FormBridgeとkViewerルックアップで申請画面を作っていきます。こちらが実際のフォーム画面です。
赤丸で囲んでいる「回答データを複数のkintoneアプリに保存するフォーム」の設定が、今回の仕組みでは大事になってきます。
まず、「申込コード検索」に申込コードを入力し、kViewerルックアップで名簿データから一致するデータを検索します。
申込コードが完全一致した場合のみ、そのコードが「確認済申込コード」に自動入力される仕組みです。
本人が編集できるのは氏名や生年月日などの最低限の項目のみで、他のフィールドはすべて編集不可や非表示にしています。
なお、申込コードは完全一致しないと検索できないので、申込コードを知らないと先には進めません。
生年月日は、わざと日付フィールドを使わず、西暦・月・日を別々に入力させています。後述の「文字列連結処理」で文字列として扱うためです。
回答保存プロセスの解説
ここからは、FormBridgeの回答保存プロセスについて解説していきます。
申請時には、入力された値から重複確認コードを再生成し、以下の処理を行います。
- 名簿データアプリに保存しようとする
- 重複確認コードがすでに存在していれば保存失敗（＝一致している）
- 保存に失敗した場合のみ、申請情報アプリに記録（＝正しい申請）
つまり、「名簿に登録できなかったら本物」「登録できたら不一致」という逆転の発想で本人確認をしているのです。
もう少し詳しく、それぞれの処理について解説していきます。
文字列連結処理で重複確認コードを生成
まずは、文字列連結処理で重複確認コードを作ります。
生年月日を日付フィールドにせず、文字列フィールドにしていたのはこのためです。
文字列連結処理で使えるフィールドは、「文字列（1行）、数値、ラジオボタン、ドロップダウン」のみなので、月・日などをドロップダウンに設定していました。
フォーム申請時の挙動
複雑ながらも、本システム最大のポイントとなるデータ登録時の挙動について解説します。
まず申請が行われた際、FormBridgeはその内容を「名簿データアプリ」に保存しようとします。
ここで保存されるのは、申込コード・重複確認コード・カナ氏名・データフラグ（初期値：無効）の4つです。
ポイントは、名簿データアプリの「重複確認コード」フィールドにkintone側で重複禁止の設定がついていることです。
つまり、すでに同じ重複確認コードが存在していれば保存に失敗＝その人は本物という判定になります。
逆に、保存できてしまった場合は「その人は対象者ではない（情報が一致していない）」ということになります。
この「保存できたら失敗」「保存できなかったら成功」という判定がシステムの肝です。
さらに、「保存できた＝不一致だった申請者の情報」も、無効フラグ付きで名簿データに記録されてしまいます。これが次に効いてきます。
「名簿データに無効フラグ付きで一度登録された情報」が、再度申請されると、重複確認コードの重複により、申請情報アプリへの保存もエラーとなるのです。
これにより、誤った申請者が何度も再申請することを防ぐことができます。
以上の仕組みで、「一致している人（＝本物）だけが、名簿データへの登録に失敗し、申請情報アプリにのみ保存される」という構造を実現しています。
最後に、こちらがフォーム申請時のフローチャートです。
大前提として、申込コードが正しくなければ申請自体できないので、完全な部外者から申請されることはありません。
あくまで、申込コードを知っている前提かつ本人しか申請できないことを想定しているので、このように複雑な処理をしています。
本人確認付申請システムの課題
今回構築した申請システムですが、成功しても失敗してもkintone上ではエラーとして処理されてしまいます。
つまり、申請が正しくても保存ログ上はエラーが増えるという、運用者泣かせの挙動になります。
また、本当は、成功時にメール通知までしたかったのですが、FormBridgeの現状の条件式では細かい分岐処理ができません。
「すべて成功」または「いずれか失敗」しか条件にできず、直前の処理単体で分岐することができないのです。
まとめると、現状では「申請の成否を申請者に伝えることができないシステム」となってし
まい、実用レベルには至りませんでした。
まとめ
今回、kintoneとトヨクモ製品の基本機能のみで、本人しか申請できないシステムを構築してみました。
実用レベルには至りませんでしたが、今回のチャレンジを通して、一切カスタマイズせずとも、ここまでの本人確認機能を再現できることが分かったのは大きな収穫です。
なお、こういったテスト開発は、本番環境ではなかなか試せないと思います。今回、私はkintoneの開発者ライセンスとトヨクモの30日間の無料お試しを利用して検証しました。
本番環境では試せないことも、気軽に検証ができるので非常におすすめです。ぜひ試してみてください。
本日は以上です。ありがとうございました。
ご登壇ありがとうございました！
井上さん、今回はご登壇いただきましてありがとうございました！
トヨクモ製品は何度でも使える30日間の無料お試しを実施しております。
気になる方は、ぜひ以下のフォームよりお申し込みください。
https://www.kintoneapp.com/trial
