業務システム設計の隠れた要件～会計監査やシステム監査

業務システムを設計していると、業務システムの設計の正当性を保証するステークホルダーが実はユーザでもITの技術者でもない事実がある。
考えたことをラフなメモ書き。

【元ネタ】
「売上伝票」を問い直す: 設計者の発言

【1】渡辺さん、@hatsanhatさん、@sugimoto_keiさん達と、販売管理システムで売上伝票はそもそも必要なのか、という議論があった。
元々の議論では、販売管理システムにおいて、売上伝票という形式はIT化される前のデータのフォーマットに過ぎず、売掛金履歴や出荷履歴などの業務データから、売上計上されるタイミングで自動仕訳されるのではないか、という考え方があった。
つまり、売上伝票という古くからある帳票に囚われるべきではない、という意見に落ち着いた。

その議論の中で僕が改めて疑問に思ったことは、販売プロセスにおいて売上計上のタイミングはどこなのか、と言う疑問。
売上に関する業務は、IT化する時に重要なポイントとして、売上の計上タイミングをどの時点にするか、という点がある。
小売業であれ、製造業であれ、IT企業であれ、売上計上のタイミングは微妙に違う。

普通の会社では、受注→出荷→売上計上→月末に締めて請求→翌月末に入金されて売掛金回収のような流れが多い。
つまり、売上を計上するタイミングは出荷という実績が発生したタイミングが多い。
何故なら、出荷した時点で自社から商品や製品が離れて、他へ責任が移ってしまうから。
このタイミングで、「売掛金//売上」という仕訳が発生する。

そして、日本の企業の大半は、月末に締めて、売掛金としてまとめて請求することで、翌月に一括入金される業務が多い。
つまり、当座預金へ入金されタイミングで「当座預金//売掛金」という仕訳が発生し、売掛金が相殺される。

この時、売上計上を出荷のタイミングではなく請求払いにした場合、本来の売上計上のタイミングが遅れてしまうために、会計監査で意図的な不正を行なっているという指摘を受ける場合があるらしい。

小売業や製造業ならば、倉庫から出庫した段階が多いが、IT業界ならば、顧客に納品して検収が終わらなければ売上計上できない時が多いだろう。
何故なら、ソフトウェアを納品されたとしても、業務でまともに使えなかったり、顧客の要望とずれている部分がたくさんあったりするので、顧客としては、検収してみてOKにならなければ、SIにお金を払いたいとは思わないからだ。

すると、IT業界の方が小売業や製造業に比べて、売上計上のタイミングがかなり遅い弱点がある。
つまり、会計監査の都合上、時代に合わなくなってきたために、ITプロジェクトでも工事進行基準を適用するような流れになっているのではないかと思う。
受託請負案件でも、工事完成基準のように、最後に売上を一括計上するやり方は、会計監査の観点では、顧客とSIが丼勘定でやり取りしているのではないか、と指摘されかねないのだ。

【2】そんな流れを考えてみると、販売管理システムにおける売上計上という機能は、最終的には税務署へ提出するBS・PLなどの会計帳票を出力するための機能でもあるために、税理士や会計士の観点で、会計監査が問題ない要件を満たさなければならないと思う。

すると、販売管理システムという業務的にはかなりシンプルなシステムでさえも、そのアーキテクチャの妥当性を保証する人は、顧客やSEではなく、税理士や会計士であるという点が出てくる。
販売管理という業務がシステムで運用できたとしても、そのシステムで作られた会計帳票が正式に使えないとしたら、システムとして不十分だ。
現在、業務システムのアーキテクチャ設計をIT技術者だけが保証することが原理的に難しくなっているのではないだろうか？

この例を更に膨らませてみると、最近の業務システムの要件として、会計監査やシステム監査、コンプライアンス(内部統制)などの監査要件の比重がかなり大きいと思っている。
業務を代行するシステムが意図的な不正を行なっていない、という要件を保証するために、それら監査の要件を満たすように、業務システムの機能がどんどん複雑化している現状がある。

個人的に思うのは、システム監査や会計監査は確かに必要だけれども、日本人はあまりにも真面目に運用しすぎているために、ビジネスのスピードを落とす方向に頑張りすぎている面があると思う。
だから、アジャイル開発という流れにも日本のIT業界は乗り遅れてしまっているのではないか、という気もしている。