こんにちは、Kakitsuです。「BLoQ管理会計」開発日誌の第17回、ひとまずの最終回です。前回まで、作ってきたものを順に書いてきました。今回は、本番に出す前に外部の会社へコードレビューを依頼し、54件の指摘を受け取った話です。
なぜ外部に頼んだか
第14回で、マニュアルを書いたら自分の設計の粗が出てきたと書きました。作った本人には見えない段差がある。説明を書くだけでそれだけ出てくるなら、他人にコードを読んでもらえば、もっと出てくるはずでした。
お願いしたのは読むだけのレビューではなく、使い捨てのデータベースに検証環境を立てて実際にAPIを呼ぶ形です。再現テストが63件付いてきました。本番環境には一切つないでいません。
褒められたところも、ちゃんと書いておく
先に、問題がなかったと言われたところを書きます。採算表の計算そのもの、会社の中の部門権限、freeeのトークンの暗号化と更新の直列化。そして他社のIDに差し替えて書き込みを試す試験が20本あり、全部が拒否または無視になったこと。
ここは正直うれしかったのですが、だからこそ残りの54件が効きました。土台が立っていることと、商売として人に使ってもらえることは、別だったのです。
致命的だった一件は、機能ではなかった
54件は、致命1、高20、中20、低13。そして致命と判定された唯一の一件は、プログラムの不具合ではありませんでした。利用規約も、プライバシーポリシーも、問い合わせ先も無い、という指摘です。
言われるまで、頭から抜けていました。一年以上、採算の計算と権限と数字の整合ばかり見てきて、お客様のデータを預かるサービスとして当たり前に要るものを、一つも用意していなかった。作っている人がいちばん見落とすのはここだという、ありがたい指摘でした。
残りの柱は二つあって、一つは他社データの分離、もう一つは数字がずれる系です。
ログインした瞬間の写しで、動き続けていた
いちばん効いた指摘は、権限の反映でした。ログイン状態の中に役割と所属が入っていて、それは発行した時点の写しです。有効期限は十四日。つまり利用者を無効にしても、役割を下げても、契約を止めても、手元のログイン状態が切れるまでは操作を続けられる状態でした。事業所を別の契約先へ移しても、移す前の管理者がそのまま触れた。
直し方は地味で、書き込みの通り道を通るたびにデータベースと照合する、というものです。この人はいまも有効か、役割は変わっていないか、いま開いている会社はいまも担当の契約先か、その契約先は止まっていないか。実機で、無効にした直後・役割を下げた直後・契約を止めた直後のいずれも拒否になることを確かめました。
数字がずれる、の中身
もう一つの柱は、気づきにくいものばかりでした。
freeeで廃止した部門の、閉じる前の実績が全社合計から消えていました。集計の対象を「いま有効な部門」に絞っていたからです。明細は未割当にも数えられないので、画面を見ても気づけない。廃止された部門も、その期間に数字がある分だけは「（廃止）」を付けて列に出し、合計にも入れるようにしました。
勤怠は二つありました。取得に失敗したときに「勤務ゼロ」として、その月を0で上書きしていたこと。権限エラーでも通信が切れても同じでした。いまは「勤務が無い」と「取れなかった」を区別し、取れなかったら止まります。止まれば前のデータが残ります。もう一つは、翌月払いの会社で勤務月が一か月ずれていたこと。freeeが返す期間の月に保存する形に直しました。
夜間の自動取り込みが、当月しか取り直していなかったのも指摘されました。freeeで過去の月を直しても拾わない。いまは当月に加えて、過去の月を日替わりで一つずつ取り直します。月末までに一巡するので、遅くとも一か月以内には反映されます。
自分が入れた安全装置が、保存を止めていた
これは反省の記録です。一か月ほど前の全体点検で、労働時間の入力チェックを足しました。一日は1440分を超えないという上限です。ところがそれを月の行にも当てていました。部門の延べ時間は人数分だけ積み上がるので、月に744時間を超える部門は、その日から予算を保存できなくなっていたのです。
レビューには応援時間の側だけが載っていましたが、調べたら予算の予定労働時間も同じでした。実データを見ると、あるお客様では十二行が旧上限を超えていました。つまり点検を入れた日から、その部門の予算は保存できていなかった。安全のために足したものが、止めてはいけないものを止めていました。
取込は正しかった。比べ方が揃っていなかった
レビューに無い不具合も、この作業の中で二つ見つけました。両方とも「freeeの数字と合わない」という話です。
一つは、freeeの試算表を取る経路によって、返るものが月次の金額か期首からの累計かで違っていたこと。累計を月の値として保存していたので、月を足すほど二重三重に積み上がります。影響は仕訳帳を使わない開発用の事業所だけで、お客様の数字は無傷でしたが、気づかずに本番へ出していたら厄介でした。
もう一つは、照合の基準でした。あるお客様の数字が数千万円ほど合わない。日付の取り方を疑って調べた結論は「取込は正しかった。比べ方が二つ揃っていなかった」でした。freeeのレポートは既定で承認フロー進行中の仕訳を除きますが、取り込みに使う仕訳帳は含みます。残りの差は、今日より先の日付の仕訳。取込は今日まで、レポートは月末まで。期間も揃っていませんでした。
基準を揃えたら、年度を通して差がゼロになりました。合わないときに疑うのは自分の計算のほうですが、そのときに「何と何を、どの期間で比べているのか」を先に確かめるべきだった。これも前回と同じで、検算の道具を検算していなかった話です。
これからのこと
対応は三段に分けました。ローンチ前に必須の二十一件、使ってもらいながら直す二十件、出したあとでよい十三件。あわせて、過去の取り込みは当時の不具合の影響を受けているので、全社・全年度を取り込み直します。そして規約とポリシーと問い合わせ先、監視とバックアップの手順。
というわけで、本番稼働はまだです。得点板はできていますが、まだ試合には出していません。急いで出して、数字を間違えるほうが怖い。
また今回の管理会計システムの構築については、稲盛和夫さんとDDIの立ち上げから今日のKDDIを育て上げられてきた元KDDI役員の野村一さん、元京セラでKCCSのコンサルタントOBの山下博士さんからも様々な助言をいただきましたが、やはり一番面白かったのは現場での稲盛さんの素顔や色々なエピソードがたくさんお聞きできたことでした（^ ^）
私が盛和塾で25年近く学んできたことと会計士という専門性を活かして自分の直感で始めたシステムづくりでしたが、その中でやはり稀代の名経営者と言われる稲盛和夫さんの偉大さを改めて気づかせていただくことが出来ました。
システムの開発日誌としては、今年の6月から、ほぼ毎日このシステムを触ってきました。書き始めたときに想像していたよりも、記録に残ったのは「直した話」と「気づかなかった話」ばかりでした。たぶんそれが正直な開発日誌なのだと思います。
動き出したら、また書きます。ここまで読んでいただき、ありがとうございました。
――――――――――
#freee会計#全員参加経営 #管理会計システム #DX #経営効率化 #稲盛和夫 #京セラ
――――――――――
本連載はKakitsu株式会社（Kakitsu）が開発・運営しています。
Kakitsu株式会社 公式サイト：kakitsu.co.jp