こんにちは、Kakitsuです。「BLoQ管理会計」開発日誌の第9回です。前回は、得点板自体の名前——ブランド名とロゴが開発の中で二度変わった裏側についてお話ししました。今回は、その得点板を自分の事務所だけでなく、他のお客様にも使っていただけるようにするための、開発の中でも一番大きな設計判断についてお話しします。
自分の事務所専用のツールを、外に出せる形にする
BLoQ管理会計は、もともと自分の事務所の顧問先向けに作ったものでした。管理者権限を持つユーザーは、登録されている全事業所を自由に行き来でき、freeeとの連携トークンも事業所単位で保存するだけで、どのユーザーが認証したものかの記録もありませんでした。事務所の中だけで使う分には問題になりませんが、外部のお客様にサービスとして届けるとなると話は別です。あるお客様の管理者が、契約していない別のお客様の数字まで切り替えて見られてしまっては、得点板としての信用が根底から崩れます。ここで初めて、「契約単位でデータを分ける」という設計が必要になりました。
freeeの「本人確認」を借りて、なりすましを防ぐ
まず確かめたのは、「管理者を名乗る人が、本当にそのお客様のfreee管理者かどうか」をシステム側で検証できるかでした。freeeのAPIを実際に呼び出して確認したところ、OAuth認証を経由して本人情報を取得するAPIを呼べば、ログインメールアドレスと、その人がrole=adminとしてアクセスできる事業所の一覧を取得できることが分かりました。メールアドレスの文字列を単純に照合するのではなく、freeeのOAuth認証そのものを経由させることで、なりすましによる不正登録を防げます。この検証結果をもとに、要件定義書に「マルチテナント管理・管理者本人確認」という項目を新たに書き起こしました。
「契約」という単位を作り、境界線を引く
実装の中心は、会社・ユーザー・freee連携トークンのすべてに「テナント（契約）」という所属を持たせることでした。既存のお客様と全ユーザーは、まず1つのテナント（自分の事務所）にまとめて移し、既存の管理者は本人確認済み扱いとしてロックアウトを防いでいます。会社の切り替えや編集は自分のテナントの中だけに制限し、テナントをまたぐ操作はすべて拒否します。さらに、テナントを横断して見渡せる「運営者」という役割を新設し、管理者の発行・停止・パスワード再設定や、契約ごとの稼働状況を確認できる専用コンソールを用意しました。管理者が別の管理者を勝手に作れないようにする制御も、同じタイミングで入れています。
検証したのは「動くこと」より「越境できないこと」
この機能でいちばん大事なのは、正常に動くことよりも、「やってはいけないことが本当にできないか」です。テナントをまたいだ会社の切り替えが拒否されること、契約を停止したテナントのユーザーがログインしようとすると「ご契約が停止されています」と表示されて弾かれること、管理者が別の管理者を発行しようとしても拒否されること——125件の自動テストに加えて、実際に検証用のテナントと管理者を作って一つひとつ手で確認しました。検証に使ったデータは、確認後すべて削除しています。
残った宿題
本番のfreee OAuth認証は、開発環境の擬似データではなく実際のfreeeアカウントを使って、freeeに接続できる環境で改めて確認する必要があります。また、この仕組みを入れたことでログインの仕組み自体が変わったため、既存の全ユーザーに一度再ログインをお願いすることになりました。
次回予告
第10回では、予算の提出から承認までを支える、通知とワークフローの仕組みについてお話しします。
（次回に続く）
――――――――――
#freee会計 #LaQ #BLoQ管理会計 #全員参加経営 #アメーバ会計システム #決算早期化 #売上最大・経費最小 #管理会計システム #DX #経営効率化 #中小企業 #ニューブロック #Yondemy #ゲーミフィケーション #遊びと教育 #遊びと仕事 #盛和塾 #フィロソフィ経営 #稲盛和夫 #京セラ
――――――――――
本連載はKakitsu株式会社（Kakitsu）が開発・運営しています。
Kakitsu株式会社 公式サイト： https://kakitsu.co.jp/