要件定義の後半に入ると、必ず「日本固有要件」と題した一覧が回ってくる。インボイス、電子帳簿保存法、消費税の区分、請求書と支払通知書の様式、源泉徴収、印紙。数十行の表で、各行の備考欄には「標準では対応不可」と書かれている。書いた人を辿ると、現行システムの帳票を作った担当か、その帳票を毎月使っている経理の実務者に行き着く。この一覧をそのまま開発要件として受けると、開発本数が二倍に膨れ、結合テストの手前で工数が尽きる。日本固有要件が膨らむのは、法令が求めていることと、いまの帳票がそう見えていることが、同じ行に混ざって書かれているからだ。 切り分けは要件定義の工程でしかできない。設計に入ってからでは、切り分けそのものが仕様変更として扱われ、動かなくなる。
「日本固有」と呼ばれた要件の半分は、法令ではなく現行帳票の見た目である
一覧の行を一つずつ潰していくと、同じ構造の誤りが繰り返し出てくる。「請求書に税率ごとの消費税額を印字する必要がある」という行と、「請求書は左上に自社ロゴ、明細は20行で改ページ、末尾に振込先を3行で印字する必要がある」という行が、同じ重みで並んでいる。前者は消費税法が求める記載事項の話で、後者は現行帳票のレイアウトの話だ。にもかかわらず、どちらの備考欄にも「インボイス対応のため必須」と書かれている。
分解の手順は単純で、各行に対して「この形でないと法令違反になるか」を一問だけ聞く。違反になるなら法令要件、ならないなら体裁要件である。答えられない行は、その場で保留にして起票者に戻す。実務者は悪意で書いているのではなく、いまの帳票がその形で承認を通ってきたという事実を、要件だと受け取っているだけだ。だから聞き方も「必要ですか」ではいけない。必要かと聞けば全部が必要になるのは、帳票要件の棚卸しで既に分かっている構造と同じである（SAPの帳票・レポート要件の絞り方｜標準で出す・作る・廃止するの3分類）。
この分解で、一覧の行数はたいてい三割から四割減る。減った分は消えたのではなく、体裁要件として別の管理表へ移る。移した先では「標準出力のままで取引先に出せるか」を営業と購買に確認する工程を、要件定義の中に一本入れておく。設計工程まで持ち越すと、開発を止められない時期に「やはり従来の様式で」と言われて手戻りになる。
要件定義の出口は「一覧」ではなく「受け皿の割り付け表」である
受け皿は四つある。SAPの標準機能で受ける。SAPが日本向けに提供している機能で受ける。追加開発で受ける。システムの外側、つまり人の運用と別のツールで受ける。この四つのどれで受けるかを全行に書き込んだ表が、要件定義工程の成果物になる。要件一覧に優先度のA・B・Cを振っただけの表を成果物にすると、設計に入ってから受け皿の議論が始まり、そこで初めて「標準では無理」が判明する。
| 受け皿 | 判定の根拠 | 確定させる工程 | 決めずに進めたときに起きること |
|---|---|---|---|
| 標準機能 | 標準の出力・設定で要件を満たせることを、実機で出して確認した | Fit-to-Standardワークショップ | 「たぶん標準で出る」のまま設計に入り、結合テストで出ないと分かる |
| 日本向け提供機能 | 導入するリリースで提供されていることを、公式ドキュメントとノートで確認した | 同上（確認担当と期日を明記） | 別リリースの情報で「ローカライズで受けられる」と判定し、後で追加開発に振り替わる |
| 追加開発 | 標準でも提供機能でも満たせず、法令要件であることが確認済み | 設計着手判定 | 体裁要件が紛れ込み、開発本数が実力より二倍になる |
| システム外の運用 | 件数が少なく、開発しても保守が割に合わない | Fit-to-Standard終了判定 | 回避手順が議事録に眠り、稼働後に現場がExcelを作って埋める |
二行目の扱いが、このプロジェクトの後戻り量を左右する。会議の場で「それは日本向けの標準機能で対応できる」という発言が出たとき、その場で受け皿に書き込んではいけない。導入するリリースとバージョンで実際に提供されているかを、公式のドキュメントとノートに当たって確認し、確認者の名前と確認日を割り付け表の欄に書く。ここを口頭の記憶で埋めると、設計の途中で提供範囲が想定と違うことが判明し、追加開発へ振り替わる。振り替わった時点で、その開発は見積りの外側にある。
四行目の「システム外の運用」を受け皿として明示的に持つことが、開発本数を抑える最大のレバーになる。年に数件しか発生しない処理を、二十人日かけて作り込む必要はない。ただし後述するとおり、この受け皿に落とすときの作法を決めておかないと、単に要件を捨てただけになる。追加開発の是非そのものを固有性と保守コストで切る判断は別稿で整理している（SAPアドオン（追加開発）をどこまで作るか｜Fit-to-Standardの判断基準）。
消費税の区分だけは、後から統合できないので先に固定する
日本固有要件のうち、消費税の区分は他の行と性質が違う。標準か開発かという受け皿の話ではなく、粒度の話だからだ。そして粒度を後から変えられない。
税コードは伝票に焼き付く。稼働後に「この二つの区分は分ける必要がなかった」と気づいても、過去の伝票を遡って統合することはできない。逆に「この区分を分けておけばよかった」と気づいた場合も、過去分は分解できない。管理会計の分析軸を後から遡って付けられないのと同じ構造で、しかも税務申告という外部提出物に直結する分だけ後戻りが重い。
粒度の決め方は、勘定科目から考えない。消費税の申告書と付表に並んでいる欄、それから申告調整で使う集計単位を先に書き出し、その欄を埋めるために伝票に何が入っていなければならないかを逆に辿る。課税・非課税・不課税・免税という大分類だけで足りることはまずなく、税率ごとの区分、仕入税額控除の可否、控除対象外消費税額の処理、輸出免税、リバースチャージの扱いといった単位で欄が割れる。この欄の数が、税コードの下限を決める。
上限のほうは運用が決める。コード数が増えすぎると、伝票を起票する現場が選べなくなる。選べない体系は結局よく使う数個に丸められて入力され、丸められた瞬間に申告の集計が壊れる。設計会議では下限と上限の両方を出し、その間で決着させる。決着した体系は、「どういう取引でこれを使うか」の例を三つずつ書いたコード表として稼働前に配る。この一覧が無いまま稼働すると、誤用が積み上がり、期末に手作業で洗い替える工程が固定化する。
税額の端数処理も、粒度とは別に設計で確定させる論点になる。適格請求書における消費税額等の端数処理は、一の適格請求書につき税率ごとに一回と定められている。明細行ごとに消費税額を計算して積み上げる作りにすると、請求書に印字される消費税額と、税率ごとに一回で計算した額がずれる。これは会計伝票側でなく請求書出力側の設計事項であり、販売管理を別システムで持っている会社では境界がさらに曖昧になる。どちらの側で税額を確定させるかを、インターフェースの設計と同時に決める（SAPとサブシステムの連携設計｜販売・購買・経費・給与でデータが合わなくなる境目）。
電子帳簿保存法は、会計伝票に持たせる要件ではない
一覧に「電帳法対応」と書かれた行が数本並んでいることがある。この行を会計システムの要件として受けようとすると、途端に開発が膨らむ。証憑のスキャン画像を伝票に添付し、タイムスタンプの状態を伝票の項目に持ち、検索画面を作り込む。作れば動くが、保守の対象が増え、アップグレードのたびに検証範囲になる。
そもそも法が求めているのは保存であって、会計伝票の中に置くことではない。電子計算機を使用して作成する国税関係帳簿書類の保存方法等の特例に関する法律は、第7条で電子取引を行った場合に取引情報に係る電磁的記録を財務省令の定めるところにより保存すべきことを定め、第8条第1項で、財務省令の定めに従って保存された電磁的記録は他の国税に関する法律の適用上その帳簿書類とみなすとしている。要件を満たす保存が成立していればよく、その器がどのシステムかは条文の問題ではない。
検索の要件も、実務で必要な範囲は絞られている。保存したデータを取引年月日・取引金額・取引先の三項目で検索できる状態にすること。この三項目は、証憑を受け取る動線の側で必須入力にすれば埋まる。会計伝票の項目を増やして埋める必要はない。電子取引データの電子保存は2024年1月から原則として義務化されており、猶予措置はあるが紙に逃げる前提はもう立たない。だからこそ、受け皿を会計システムの中に置くか外に置くかの判断が効いてくる。運用への落とし込みは別稿で工程単位に分解している（電子帳簿保存法スキャナ保存・電子取引の決算実務への落とし込み）。
インボイスは機能の問題ではなく、マスタと締めの問題に落ちる
インボイス制度、すなわち適格請求書等保存方式は2023年10月1日に始まっている。導入プロジェクトで新規要件として扱われることは減ったが、移行の設計では別の形で顔を出す。登録番号をどのマスタのどの項目で持つか、その番号の妥当性をいつ誰が確認するか、という二点だ。
登録番号は、法人番号を有する課税事業者であれば「T」に13桁の法人番号を続けた形になる。項目としては短く、格納場所に悩む要素は少ない。悩ましいのはその先で、取引先が登録を取りやめてもこちらのマスタは自動では変わらない。誰がいつ何を根拠に確認し、確認結果をマスタのどの項目に残すかを決めておかないと、仕入税額控除の判定が担当者の記憶に依存する（SAPのマスタデータを稼働後に劣化させない｜登録権限とオーナーシップの決め方）。
売手側にも設計事項がある。売上に係る対価の返還等を行う場合、原則として返還インボイスの交付が必要になるが、その金額が税込1万円未満であれば交付義務は免除される（消費税法第57条の4第3項）。適用期限も事業者の規模要件もない恒久的な措置だ。振込手数料相当額を売上値引きとして処理する設計は、この免除を前提に組める。混同されやすいが、税込1万円未満の課税仕入れについてインボイスの保存を不要とする少額特例は別の制度で、こちらは2023年10月1日から2029年9月30日までの時限措置であり規模要件もある。両者を同じものとして設計に持ち込むと、消込ルールの前提が期限付きになってしまう（入金消込と滞留売掛金｜消込できない入金が月次決算を止める構造を直す）。
「作らない」を確定させるのは、Fit-to-Standardの終了判定である
作らないという判断は、放っておくと誰も下さない。作りますと言えば会議は終わるが、作りませんと言えば「では誰が困るのか」の議論が始まるからだ。この非対称があるかぎり、判断は工程の側で強制するしかない。強制する場所は一つで、Fit-to-Standardワークショップの終了判定である。全行に受け皿が入っていない状態では、この工程を終わらせない。
四手目が最も飛ばされる。作らないと決めた瞬間に安心して次の行へ進み、回避策が議事録の中に残ったまま稼働日を迎える。現場に渡らなかった回避策は、担当者が自分でExcelを作って埋める形で復活し、そこから二重管理が始まる。
- ① 回避手順（誰が、どのタイミングで、何を使って処理するか。ツール名まで書く）
- ② 担当部署とオーナー名（情シスでなく、業務を持っている部署に置く）
- ③ 年間発生件数の見込み（見込みを書かせると、そもそも要らない行がここで落ちる）
- ④ 見直し期限（稼働後1年など。期限が無い運用回避は恒久化する）
四点が揃った行だけを閉じる運用にすると、副次的な効果が出る。年間発生件数を書く段階で、起票者自身が「これは年に一度も発生しない」と気づき、要件そのものを取り下げる行が出てくるからだ。件数を書かせるという一手が、要件の間引きとして働く。
作り切る順番は、分解・割り付け・裏取り・出口の四手である
日本固有要件で工数が破綻するプロジェクトに、特別な事情はほとんどない。一覧をそのまま開発要件として受け、受け皿の議論を設計工程へ持ち越し、作らないと決めた行に出口を付けないまま稼働している。この三つを塞げば工数は収まる。塞ぐ場所は要件定義工程の中にしかなく、設計に入ってからの切り分けは仕様変更として扱われて政治の問題になる。要件定義の終了判定に「全行に受け皿が入っていること」「提供機能と判定した行に確認者名と確認日が入っていること」「作らないと決めた行に四点が入っていること」の三条件を置き、揃うまで工程を閉じない。この規律だけが、日本固有要件を実装可能な量に落とす。消費税の区分は例外で、後から統合も分解もできないため、申告書の欄から逆算した粒度を要件定義の段階で凍結する。
