業務システム設計の隠れた要件~会計監査やシステム監査
業務システムを設計していると、業務システムの設計の正当性を保証するステークホルダーが実はユーザでもITの技術者でもない事実がある。
考えたことをラフなメモ書き。
【元ネタ】
「売上伝票」を問い直す: 設計者の発言
【1】渡辺さん、@hatsanhatさん、@sugimoto_keiさん達と、販売管理システムで売上伝票はそもそも必要なのか、という議論があった。
元々の議論では、販売管理システムにおいて、売上伝票という形式はIT化される前のデータのフォーマットに過ぎず、売掛金履歴や出荷履歴などの業務データから、売上計上されるタイミングで自動仕訳されるのではないか、という考え方があった。
つまり、売上伝票という古くからある帳票に囚われるべきではない、という意見に落ち着いた。
その議論の中で僕が改めて疑問に思ったことは、販売プロセスにおいて売上計上のタイミングはどこなのか、と言う疑問。
売上に関する業務は、IT化する時に重要なポイントとして、売上の計上タイミングをどの時点にするか、という点がある。
小売業であれ、製造業であれ、IT企業であれ、売上計上のタイミングは微妙に違う。
普通の会社では、受注→出荷→売上計上→月末に締めて請求→翌月末に入金されて売掛金回収のような流れが多い。
つまり、売上を計上するタイミングは出荷という実績が発生したタイミングが多い。
何故なら、出荷した時点で自社から商品や製品が離れて、他へ責任が移ってしまうから。
このタイミングで、「売掛金//売上」という仕訳が発生する。
そして、日本の企業の大半は、月末に締めて、売掛金としてまとめて請求することで、翌月に一括入金される業務が多い。
つまり、当座預金へ入金されタイミングで「当座預金//売掛金」という仕訳が発生し、売掛金が相殺される。
この時、売上計上を出荷のタイミングではなく請求払いにした場合、本来の売上計上のタイミングが遅れてしまうために、会計監査で意図的な不正を行なっているという指摘を受ける場合があるらしい。
小売業や製造業ならば、倉庫から出庫した段階が多いが、IT業界ならば、顧客に納品して検収が終わらなければ売上計上できない時が多いだろう。
何故なら、ソフトウェアを納品されたとしても、業務でまともに使えなかったり、顧客の要望とずれている部分がたくさんあったりするので、顧客としては、検収してみてOKにならなければ、SIにお金を払いたいとは思わないからだ。
すると、IT業界の方が小売業や製造業に比べて、売上計上のタイミングがかなり遅い弱点がある。
つまり、会計監査の都合上、時代に合わなくなってきたために、ITプロジェクトでも工事進行基準を適用するような流れになっているのではないかと思う。
受託請負案件でも、工事完成基準のように、最後に売上を一括計上するやり方は、会計監査の観点では、顧客とSIが丼勘定でやり取りしているのではないか、と指摘されかねないのだ。
【2】そんな流れを考えてみると、販売管理システムにおける売上計上という機能は、最終的には税務署へ提出するBS・PLなどの会計帳票を出力するための機能でもあるために、税理士や会計士の観点で、会計監査が問題ない要件を満たさなければならないと思う。
すると、販売管理システムという業務的にはかなりシンプルなシステムでさえも、そのアーキテクチャの妥当性を保証する人は、顧客やSEではなく、税理士や会計士であるという点が出てくる。
販売管理という業務がシステムで運用できたとしても、そのシステムで作られた会計帳票が正式に使えないとしたら、システムとして不十分だ。
現在、業務システムのアーキテクチャ設計をIT技術者だけが保証することが原理的に難しくなっているのではないだろうか?
この例を更に膨らませてみると、最近の業務システムの要件として、会計監査やシステム監査、コンプライアンス(内部統制)などの監査要件の比重がかなり大きいと思っている。
業務を代行するシステムが意図的な不正を行なっていない、という要件を保証するために、それら監査の要件を満たすように、業務システムの機能がどんどん複雑化している現状がある。
個人的に思うのは、システム監査や会計監査は確かに必要だけれども、日本人はあまりにも真面目に運用しすぎているために、ビジネスのスピードを落とす方向に頑張りすぎている面があると思う。
だから、アジャイル開発という流れにも日本のIT業界は乗り遅れてしまっているのではないか、という気もしている。
| 固定リンク
「モデリング」カテゴリの記事
- 組込みソフトウェア開発でUMLを使う手法を説明した書籍のリンク(2022.06.17)
- 超高速開発でアジャイル開発を実現する話に違和感がある(2022.05.06)
- 事業活動のシステム化は非差別化しない汎用ドメインや支援ドメインに注力すべき(2022.04.13)
- 「大国政治の悲劇」の感想~現代はパワーポリティクスの歴史に戻ったみたいだ(2022.03.25)
- マイクロサービスはアトミックな操作で閉じるべきシステム分割論に基づいたアーキテクチャなのか(2022.03.20)
「ソフトウェア工学」カテゴリの記事
- Javaのラムダ式の考え方(2022.08.10)
- テスト管理ツールTestRail、CAT、QualityForwardの感想(2022.07.30)
- メトリクス分析のコツは良いIssueを見つけること(2022.06.29)
- プロセス設計はどの範囲を指すのか?~プロマネの仕事はテーラリングにある(2022.06.19)
- 「大人の学びパターン・ランゲージ」の感想~知識と経験を行ったり来たりするタイミングを大切にする(2022.06.05)
「Agile」カテゴリの記事
- 組織を芯からアジャイルにする対談の感想~今のアジャイルは先カンブリア時代なので何でもいい、アジャイル警察はいらない(2022.08.05)
- 製造業の業務にスクラムを適用できるのかという疑問~全てのビジネスモデルにスクラムを適用できるのか?(2022.07.31)
- 認定スクラムプロダクトオーナー研修の感想(2022.07.28)
- プロセス設計はどの範囲を指すのか?~プロマネの仕事はテーラリングにある(2022.06.19)
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
コメント
そうですね馬鹿正直というか、オーバーコンプライアンスの弊害は感じます。それとITの受託開発で工事進行基準を適用するのも違和感があります。その話は長くなりますので、また別の機会に。
投稿: きむらよしひさ | 2013/05/22 17:00