決算の途中で、ある取引の税区分がおかしいことに気づく。経理が情シスに聞く。「そこはベンダーが設定した領域なので、こちらでは分かりません」。ベンダーに聞く。「導入時に貴社の要件どおりに設定しております」。要件を出した担当者は三年前に異動している。ここで会話は終わる。誰も嘘をついていない。にもかかわらず、会社の中に答えを持っている人が一人もいない。 これは能力の問題ではなく、役割設計に穴が開いている状態である。穴の名前は、業務システムのオーナーだ。
「誰も嘘をついていない」から、話が止まる
システムの中身が分からない状態は、たいてい事故ではなく、正常に運用した結果として生まれる。
導入プロジェクトの時点では、業務要件を出す人が社内にいた。その人が仕様書のレビューをし、テストシナリオを書き、稼働判定に立ち会った。要件と設定の対応関係は、その人の頭の中で結ばれていた。文書にも一部は残った。ところが、稼働後にその対応関係を維持する役割が誰にも割り当てられていない。プロジェクトは終わり、体制は解散する。
その後に起きることは決まっている。制度改正で税区分が増える。組織改編でコードが増える。新しい取引形態が出る。そのたびに変更が入るが、変更の依頼は「こうしてほしい」という結果の形で出され、なぜそうするのかは記録されない。三年もすれば、設定は残り、理由だけが消える。
情シスに聞いても答えが返らないのは当然で、彼らが持っているのは基盤とアクセス権と稼働の責任であって、勘定科目の意味ではない。ベンダーに聞いても答えが返らないのも当然で、彼らが持っているのは「言われたとおりに設定した」という事実であって、言われた理由ではない。
足りていないのは知識ではなく、知識を持ち続ける役割である。
内部統制の基準は、ベンダー管理を統制項目として名指ししている
「ベンダーに任せている」は説明として通らない。実施基準は、ＩＴへの対応を基本的要素に加えた背景として、情報システムの開発・運用・保守などＩＴに関する業務の全て又は一部を外部組織に委託するケースもあり、かかるＩＴの委託業務に係る統制の重要性が増していることを挙げている。組織が考慮すべきＩＴ環境の具体例にも「ＩＴに係る外部委託の状況」が並ぶ。
つまり、外部委託そのものは問題ではない。外部委託を統制できていないことが問題になる。そして統制の対象として実施基準が挙げるのは、契約の管理と、開発・保守の管理である。契約書のファイリングではない。何を委託し、何を委託していないのか、委託していない部分は誰が持っているのかを、会社が説明できる状態を指す。
業務処理統制の側はもっと直接的だ。「マスタ・データの維持管理」が具体例に置かれている。勘定科目マスタ、取引先マスタ、税区分、支払条件、承認限度額。これらは業務の意思決定そのものであって、システムの設定という顔をしているだけである。誰が登録し、誰が承認し、誰が定期的に棚卸すか。この問いに経理が答えられない会社は、統制の要件を人ではなく空席に割り当てている。
なお実施基準は、統制環境のうちＩＴに関連する事項として「組織の構成員のＩＴに関する基本的な知識や活用する能力」と「ＩＴに係る教育、研修に関する方針」も挙げている。育成が統制環境の一部として書かれている、という事実は覚えておいたほうがいい。人を置くだけでは足りず、置いた人が学び続ける前提まで含めて統制と呼ばれている。
三点セットの更新運用が形骸化する会社では、この空席がそのまま原因になっていることが多い（J-SOX財務報告内部統制：3点セットを形骸化させない更新運用の実務）。
法令が最後まで自社に残しているのは、一種類の書類だけ
電子帳簿保存法施行規則第2条第2項第1号の構造は、この論点をきれいに切り出している。
備付けを求められる書類は四つある。イがシステムの概要を記載した書類、ロがシステムの開発に際して作成した書類、ハが操作説明書、ニが電子計算機処理並びに電磁的記録の備付け及び保存に関する事務手続を明らかにした書類である。そして柱書の括弧書きが、次の二つの例外を置く。保存義務者が開発したプログラム以外のプログラムを使用する場合はイ及びロを除く。電子計算機処理を他の者に委託している場合はハを除く。
市販のパッケージを使い、処理を外部に委託している会社に残るのは、ニだけになる。
これは緩い規定に見えて、実は逆のことを言っている。システムの中身は買ってきてよい。処理も外に出してよい。だが、自社の業務がどういう手順で回っているかを自社の言葉で書けることだけは、外注できない。ここを書けるのは経理しかいない。情シスは処理の順序を知らないし、ベンダーは会社の承認ルートを知らない。
優良な電子帳簿の要件を見ると、書ける／書けないの差が金額に変わる。同規則第5条第5項第1号は、訂正又は削除を行った場合にこれらの事実及び内容を確認することができること、通常の期間を経過した後に入力した場合にその事実を確認することができること、関連する帳簿との相互関連性を確認できるようにしておくこと、そして検索機能を確保しておくこと（電磁的記録の提示又は提出の要求に応じることができるようにしている場合は範囲指定と組合せ条件の部分を除く）を求めている。これらの要件を満たすと、電子帳簿保存法第8条第4項により、その記録事項に関して修正申告等があった場合の過少申告加算税の額が、百分の五の割合を乗じて計算した金額だけ軽減される（隠蔽し、又は仮装された事実がある場合を除く）。
問いはひとつだ。自社の会計システムは、訂正削除の履歴を残す設定になっているか。答えられる人が社内にいなければ、この軽減は取りにいけない。 帳簿を電子化した効果の一部を、役割の空席で捨てていることになる。日々の運用にどう落とすかは、決算工程の側から設計するほうが早い（電子帳簿保存法スキャナ保存・電子取引の決算実務への落とし込み）。
会社法の側からも同じ席が見える。会社法施行規則第100条第1項第1号は、業務の適正を確保するための体制として「当該株式会社の取締役の職務の執行に係る情報の保存及び管理に関する体制」を挙げている。会計システムに入っている情報は、その体制の中身そのものである。
置くべき席は、二軸のどこにあるか
役割設計を「ITに強い人を経理に採る」という話にすると失敗する。必要なのは二つの軸の交点であって、片方の軸の高さではない。
右上の人を外から採ろうとすると、たいてい二年探して見つからない。業務会計とシステムの両方を持つ人は希少で、しかも高い。一方、左上には自社の経理の中核がいる。決算を締められ、なぜその科目なのかを説明でき、監査法人の質問に答えている人だ。この人に足りないのは設定の読み方だけで、それは学べる。 逆に右下の人に業務知識を足すのは、はるかに長い時間がかかる。内製か採用かの判断軸は、この非対称性から決まる（経理DX人材は内製か採用か 既存メンバーのリスキリング判断軸）。
左下を厚くしても状況は変わらない。人数が増えるだけで、要件を説明できる人は一人も増えない。ここを勘違いすると、経理の人員は増えているのにシステムの話は止まったまま、という状態になる。
オーナーの職務は四つに絞る
役割を作るときに一番よくある失敗は、職務を盛り込みすぎて誰も引き受けられなくすることだ。この席の職務は四つでいい。
| 職務 | 具体的にやること | 今どこにあるか |
|---|---|---|
| 設定台帳を持つ | 勘定科目、税区分、取引先区分、承認限度額など業務判断に直結する設定を一覧にし、各行に「なぜその設定か」の根拠（規程・稟議・法令）を紐づける | どこにもない。ベンダーの設計書に断片が残るだけ |
| 変更の入口を一本にする | 設定変更の依頼は必ずこの席を通す。依頼は結果ではなく「業務上こうしたい」という要件の形で書かせ、設定への翻訳はこの席が行う | 各担当がベンダーに直接依頼している |
| マスタの維持管理 | 新規登録の承認、重複と休眠の定期棚卸し、廃止のルール。実施基準がＩＴに係る業務処理統制の具体例として挙げている領域 | 登録は誰でもでき、棚卸しは誰もしていない |
| ベンダー回答の技術的評価 | 「できません」「標準にありません」という回答が、本当に制約なのか、単に見積りが増えるだけなのかを判定する | 評価されず、そのまま制約として受け入れられている |
四つ目が効く。ベンダーの回答を評価できない会社は、業務要件を落とすか、言い値で追加開発を買うかの二択になる。判定できる人が一人いるだけで、この二択が三択になる。標準で出すか、作るか、やめるかの三分類は、そのまま日々の判断になる（SAPの帳票・レポート要件の絞り方｜標準で出す・作る・廃止するの3分類）。
設定台帳は、一気に作ろうとしないほうがいい。決算で一度でも論点になった設定から書く。税区分、収益認識のタイミングに関わる設定、原価の配賦ルール、外貨の換算レート種別。この四つで、実務上ぶつかる論点の大半が拾える。
兼務でよい。ただし外してはいけない条件がある
専任を置ける会社は多くない。兼務で構わない。ただし三つの条件は外せない。
第一に、決算の実務から離さないこと。締めに入っていない人は、設定が業務にどう効くかの感覚を失う。設定台帳が現実と乖離していく最大の原因はここにある。
第二に、変更の実行権限とは分けること。この席は「何をどうすべきか」を決める側であり、システムに実際に設定を入れるのは情シスまたはベンダーでよい。判断と実行を同じ人に持たせると、変更の記録が残らなくなる。職務分掌の観点でも、判断と実行の分離は基本形になる（SAPの権限設計とSoD（職務分掌）｜内部統制を仕組みで担保する）。
第三に、二人目を必ず置くこと。一人だと、この席自体が新しい属人化になる。主担当と副担当で年に一度入れ替える運用にしておけば、設定台帳は自動的に読み手を得る（属人化した決算を組織知に変える 担当者が辞めても締まる引き継ぎ設計）。
キャリアの見え方も設計しておきたい。この席は、経理の中では珍しく市場価値が外に通じる経験になる。会計システムの設定と業務要件を両方語れる人は、事業会社でもコンサルでも希少で、本人にとって損な配置ではない（経理のキャリアパス｜事業会社・コンサル・SAP人材の3つの道）。この点を最初に本人へ説明できるかどうかで、引き受けてもらえる確率が変わる。
設定は、業務要件が最後に残った形
会計システムの設定を情シスとベンダーだけで回す運用は、短期的には効率的に見える。経理は業務に集中でき、技術的な判断は専門家がする。役割分担として筋が通っているように見える。
崩れるのは、要件を出した人が異動した瞬間である。設定は動き続けるが、その設定が何を意味するのかを知る人がいなくなる。残っているのは、原文を失った訳文だけだ。 この状態は決算の遅れとしてではなく、監査の指摘、制度改正への対応の遅れ、追加開発の言い値、そして「なぜこうなっているのか分からない数字」として表に出てくる。
置くべき席は一つでいい。業務の手順を自社の言葉で書けて、その手順がどの設定に対応しているかを言える人。専任でなくてよく、コードが書ける必要もない。必要なのは、ベンダーの回答が自社の要件に合っているかを判定できることと、判定できない部分を「不明」と書けることである。
始め方も決まっている。直近三期の決算で論点になった設定を書き出す。各行に根拠を紐づける。埋まらない行は不明と書く。不明の行について、業務としてどうあるべきかを先に決める。決めてから現行設定と突き合わせる。この順序を逆にすると、ベンダーの回答が要件になってしまう。
