記事・コラムColumn

こんにちは、Kakitsuです。「BLoQ管理会計」開発日誌の第10回です。前回は、一つのシステムを複数のお客様に届けるために「テナント」という境界線を引いた話をしました。今回は、その中で動く予算づくりに「順番」と「合図」を持たせた回です。得点板があっても、いまが誰の番なのかが分からなければ、試合は進みません。

予算づくりには順番がある

予算は、経営者が大枠を作り、それを各ブロック長へ開放し、期限で締め切る、という順番で進みます。これまでのシステムはこの順番を持っておらず、権限のある人はいつでも入力できました。そこで会社と年度の組み合わせごとに進行状況を持たせ、経営者は大枠作成中だけ、ブロック長は開放後だけ、管理者はいつでも編集できるようにしました。開放しないまま締め切る、二重に開始するといった順番を飛ばす操作は受け付けません。ただし、すでに運用中の年度には進行状況を作らず従来どおり動かしています。新しい方式が効くのは、管理者が明示的に開始した年度だけです。編集できないときの画面表示も「権限がありません」ではなく「管理者が作成権限を開放すると編集できるようになります」と、いつ編集できるようになるかが分かる文言にしました。

内部取引の予算は、片方だけでは決まらない

部門間でやり取りする内部取引の予算は、売り手側と買い手側の双方のブロック長が承認して初めて確定する形にしました。いちばん手を入れたのは、実はデータの持ち方です。それまでは部門ごとの合計しか保存しておらず、「どの部門と、いくら取引する予定か」というペアを復元できませんでした。全社の合計が合わなくてもどのペアが原因か名指しできず、そもそも承認の単位が作れない状態だったのです。そこで明細を売り側・買い側それぞれのレコードとして保存するようにしました。予算は部門ごとに独立して入力するため、同じペアでも双方の金額が食い違うことがあります。1本の明細を1レコードで持つと、片方の保存がもう片方の入力を消してしまうのです。
運用ルールも一緒に決めました。月別まで金額が一致しないペアは承認できません。不一致のまま確定できてしまうと、会社全体の内部売上と内部仕入が合わないまま予算が固まり、この機能の意味がなくなるためです。承認済みのペアの金額を後から変えたときは、双方の承認を自動で取り消します。「承認済み＝その金額に双方が合意した状態」という意味を、いつでも保つためです。

通知は、業務を止めてはいけない

順番と承認を作ると、次は「自分の番になったことをどうやって知るか」が問題になります。そこでメール通知を入れました。設計でいちばん強く決めたのは、通知処理は例外を投げない、ということです。通知は業務データを保存した「ついで」に呼ばれます。メールが送れなかったせいで保存が取り消されるようでは本末転倒なので、呼び出し側は「送信した」「送信しなかった」「失敗した」という結果だけを受け取ります。
もう一つは、通知を既定でOFFにしたことです。機能を入れた瞬間に、すでに使っているお客様のところへ突然メールが飛ぶのは避けたい。ONにするのは会社ごとの明示的な操作にしました。そして、送らなかった場合も理由つきで記録に残しています。「通知が来ない」という問い合わせは、会社の設定がOFFなのか、宛先のブロック長が登録されていないのか、配信側が受け付けなかったのかを切り分けないと原因が分かりません。設定画面には直近の送信記録も並べ、ONにする・テスト送信する・結果を確認する、が一画面で完結するようにしました。

送りすぎない工夫

通知は、多すぎると読まれなくなります。内部取引で12か月分を一括生成したときには通知せず、1行ずつ手で入力した分が増えたときだけ送ります。操作した本人も宛先から外します。自分の操作の通知が自分に届いても意味がないからです。本文に載せる情報も絞りました。金額はどの通知にも載せません。部門名は、受信者がその取引の当事者であるか、全社を見る立場である場合にだけ載せます。メールは転送されることがあるので、誰が読んでも困らない粒度にそろえておく必要があります。

お客様に検証メールを送ってしまわないための安全弁

この機能の検証は、実際のお客様のデータで行うことになります。宛先は実在するブロック長のアドレスです。検証のたびに本物のメールが飛んでは大事故なので、設定を入れるとすべての通知が指定した一つのアドレスに差し替わる仕組みを先に用意しました。テスト送信の宛先も、任意のアドレスを入力できる形にはせず、操作している本人のアドレス固定にしました。自由に宛先を書ける口を作ると、このアプリが第三者へメールを送る踏み台になりうるためです。
実機での確認は、内部取引の実績が0件のお客様の環境を借りて8項目を通しで行い、送信8件・失敗0件。検証で作ったデータと送信記録はすべて削除し、設定も元に戻しています。このとき、最終承認の依頼だけが「宛先なし」として記録に残りました。調べると、承認したのが宛先である管理者本人で、「操作した本人は宛先から外す」という規則によって宛先が0件になっていたのです。動作は正しく、しかもその理由が記録を見るだけで分かる。送らなかった理由を残すという設計が、最初の実地検証でそのまま役に立ちました。

残った宿題

通知は既定でOFFなので、どのお客様のどの通知をONにするかは、運用に入る段階で一つずつ決めていく必要があります。検証用のメール差し替え設定は、本番移行のときに必ず外さなければなりません。外し忘れると、誰にも届かないまま「送信済み」の記録だけが残ります。しきい値を割り込んだときのアラート通知は、まだこれからです。

次回予告
第11回では、業種によって変わる「採算」の見え方——製造業と非製造業への対応と、KPIのアラートについてお話しします。
（次回に続く）

――――――――――
#freee会計 #LaQ #BLoQ管理会計 #全員参加経営 #アメーバ会計システム #決算早期化 #売上最大・経費最小 #管理会計システム #DX #経営効率化 #中小企業 #ニューブロック #Yondemy #ゲーミフィケーション #遊びと教育 #遊びと仕事 #盛和塾 #フィロソフィ経営 #稲盛和夫 #京セラ
――――――――――

本連載はKakitsu株式会社（Kakitsu）が開発・運営しています。
Kakitsu株式会社 公式サイト： https://kakitsu.co.jp/