こんにちは、 Leaner Technologies の石渡（@mishiwata1015）です。
2022 年 1 月施行の電子帳簿保存法（以下、電帳法）の改正に Leaner見積が対応しました。
法律要件に基づいた開発ということで、普段の開発とは少し性質の異なる問題が発生しました。
今回は、電帳法改正対応でどんな問題があってどう乗り越えたのか、開発裏話をします。
電帳法改正とは？
画像引用元: https://mag.leaner.jp/posts/3230/
ざっくり説明すると、電子取引における国税関係書類（見積書、請求書、発注書等）の保存条件が変わります。国税関係書類を扱うシステムとしては以下の要件を満たす必要があります。
-
真実性の要件
- データを訂正・削除できない状態で保存できること
- 訂正・削除可能とする場合は履歴を残すこと
- データを訂正・削除できない状態で保存できること
-
可視性の要件
- 取引年月日・取引金額・取引先名で検索できること
- 取引年月日、取引金額は範囲指定で検索できること
- 各条件を AND で検索できること
Leaner 見積は見積書のデータを扱うので、電帳法改正の要件を満たすための改修が必要でした。
当初の改修案では法律要件を満たせないことが判明
当初は、可視性の要件を満たす検索機能追加だけで対応できる想定でした。
- 可視性の要件
- 取引年月日・取引金額・取引先名で検索できること
- 取引年月日、取引金額は範囲指定で検索できること
- 各条件をANDで検索できること
しかし、法律要件と現状のプロダクト仕様を厳密に調査したところ、当初案では法律要件を満たせないことが判明しました。具体的には以下のような状況でした。
- 取引先へ発注依頼するたびに、見積案件の発注依頼日を上書き更新していた
- 複数回の発注依頼で過去の発注依頼日時が分からなくなってしまい、真実性の要件でアウト
詳細は省きますが、他にもいくつかデータのライフサイクル絡みの問題があると分かりました。
当初案の実装で法律要件を満たしたと思ったら実は不備があった、という状況になっていたかもしれません。怖いですね。
どのように仕様の不備に気づき、代替案の実装に至ったかの過程を掘り下げていきます。
通常の開発と法律要件の開発の違い
そもそも、通常の機能開発と法律要件の開発では、開発の進め方が大きく異なります。
通常の機能開発ではユーザーストーリーを掘り下げて機能要件を詰めていきますが、法律要件の開発では以下 2 ステップが必要です。
- 法解釈
- プロダクトの厳密な仕様把握
それぞれ説明していきます。
法解釈
法解釈を通して「どういう状態になれば法律要件を満たしたシステムと言えるのか」の Goal を明確にします。
この法解釈がなかなか大変で、ユーザーストーリーの掘り下げとはまったく別の難しさがあります。
法律の条文や以下のような補足資料を読み込み、「で、結局どうすればいいの？」を整理していきます。
電帳法の場合は納税者向け（ユーザーとなる企業向け）の記載も多く、SaaS 提供者としてどう解釈すべきか判断が難しいものもありました。
例えば、見積書の内容を PDF ではなく、 Web 上のフォーム入力をもとに直接 DB へ保持している場合はどう解釈すべきか、など細かい考慮事項がたくさんありました。
このあたりは、Biz の山下（@shohey_leaner）が必要に応じて税務署に電話確認まで徹底し、セミナーを開催するほど深く理解した上で、分かりやすく Notion にまとめてくれました。
これは本当に助かりました。
プロダクトの厳密な仕様把握
法解釈を通して Goal が明確になったところで、次に現状のプロダクトとの差分（開発内容）を洗い出す必要があります。
「厳密な」というところがポイントです。
通常の開発では機能不備があったら追加修正すれば済みますが、法律要件の場合はそうもいきません。具体的には、以下の内容を重点的に抑えておく必要があります。
- 必要なデータを取得できているか
- 更新してはならないデータが編集/削除されてしまうユースケースがないか
ユーザーとなる企業は法対応を目的にサービス導入するケースもあります。
それが実は法律要件を満たせていなかったとなると、取り返しのつかないことになる可能性もあります。
ここに、エンジニアもガッツリ時間を割いて入ったため、当初案の仕様不備に気づくことができました。
当初案を通常の開発タスクと同様に扱っていたら、誰も仕様不備に気づけなかったかもしれません。
Leaner 見積はまだそこまで複雑性の高いプロダクトではありませんが、それでもデータのライフサイクル周りの把握はそれなりに大変でした。
ビジネス上重要なデータは、なるべくイミュータブルに保っておくべきですね。
何が重要かを判断するために、エンジニアもビジネス理解を深めておくことが大事です。
実装方針をADR(Architectural Decision Records)として残す
ここからはエンジニア主導で、法律要件を満たす代替案を策定することにしました。
代替案の実装方針を整理するため、ADR(Architectural Decision Records)を作成しました。
ADR とは「アーキテクチャ上の設計判断と意思決定の履歴を、テキストベースの軽量なテンプレートを使用して記録するもの」です。
決定事項はコードを見れば分かりますが、そもそもなぜこんな設計に至ったのか Why を補完する目的で作成するドキュメントです。
Leaner では、ある程度大きめな機能開発する場合など、必要に応じて ADR を作成しています。
以下のようなフォーマットで Notion 上に作成しています。
- タイトル
- 背景・必要要件
- 現状整理
- 選択肢
- 各選択肢のメリットデメリット
- ボツ案とその理由も残す
- 決定事項
主に、設計の壁打ちをするためのたたき台のような使い方をしています。
Leaner における ADR の運用については、また別記事で紹介できたらと思います。
電帳法改正対応の代替案は、発注依頼アクションのタイミングで新たに発注履歴データを生成する方針に決定しました。
この ADR のレビューを通して、開発チーム全体に 「このデータは法律要件に基づいてるから絶対に変更してはならない」 という、ある意味最も重要で絶対的な法律のドメイン知識を効率良く共有できました。
そして、代替案の実装により Leaner 見積の電帳法改正対応が無事完了しました。めでたしめでたし。
普段からのBizとエンジニアの連携が大事
今回の電帳法改正対応は、Leaner の Biz とエンジニアがうまく連携できている象徴的な開発でした。
Biz、エンジニアどちらかに主導権が偏った開発ではうまくいかなかったと思います。
また、法律対応不備というヒヤリハットを経験した開発でもありました。（マジで怖い）
また、最近の Leaner は、Epic 単位に Biz とエンジニアが組んで開発するスタイルを取っていてうまく回っているなと感じています。
Epic 担当外のエンジニアにも ADR や PR のレビューを通してコンテキストを共有しているので、担当者以外何も分からない、という状況を防ぎつつ開発スピードを高めています。
法改正への対応は大変
エス・エム・エスさんの法改正対応が壮絶でした。
今回の介護報酬改定でも2021年4月1日から施行される内容の確定版が通知されたのは2021年3月31日でした。
そんなことある！？無理じゃん！？
って気持ちになりますが、こんなパターンもあるんですね。
- 法解釈分析班：開発チームの中でもドメインに詳しいメンバーで構成され、法解釈とカイポケへの影響を把握し、開発チーム内や法改正窓口に連携する。
- 法改正窓口：ビジネスサイドの介護やシステム開発に詳しいメンバーで構成され、社内で取りまとめた質問を一手に回答する役割。ここで回答出来ないもののみが法解釈分析班に渡される。
このようなコラボレーションを実現するための基礎となる、エンジニア組織とビジネスサイドとの関係作りに、日頃から取り組んでいます。
かなり大規模な法改正対応だったと思うのですが、うまく役割分担していてすごいなと感じました。
一朝一夕ではなかなか難しいので、Biz とエンジニアが常日頃から連携するのが重要ですね。
大事なこと
サービス運営側としては、法改正って厄介なイベントかもしれませんが、嫌がらせ目的で行われるものではありません。
例えば、電帳法改正にはペーパレス化の促進によって納税者側の帳票保存の負担を減らしてほしい狙いがあります。
確かに、既存の業務フローが破壊的に変更されたり、システム改修対応が必要になったりネガティブな面もあります。
法律は必ず目的があるものなので、サービス運営側としては真摯に対応していける体制を整えておくのが重要ですね。
まとめ
- 法律要件の開発は、法解釈とプロダクト仕様把握が大変
- 法律要件への対応は Biz とエンジニアの連携が重要
- Biz が、プロダクトの内部的なデータサイクルまで詳細に把握するのは大変
- エンジニアが、法律要件の詳細まで把握するのも大変
- どちらかが欠けてもダメだし、それぞれ役割分担して協力した方がうまくいく
- Biz とエンジニアが急に連携しようと思っても、普段からできてないと大変
- 法律要件対応は、プロダクト開発チームの底力が試されるところ
参考
宣伝
Leaner Technologies では Biz と連携して開発したいエンジニアを募集しています！
Discussion