この記事は Hacobu Advent Calendar 2025 の 6日目の記事です。
こんにちは。
株式会社Hacobuでバックエンドエンジニアとして働いている平田です。
ここ最近、チームメンバーとの輪読会で、アーキテクチャやモデリングに関する書籍を読む機会がありました。
- 『ソフトウェアアーキテクチャの基礎』
- 『ドメイン駆動設計をはじめよう』
どちらの本も、モデルをどう捉えるべきかについて多くの示唆があり、個人的には次のような点が特に心に残りました。
- モデルは現実をそのまま写すものではなく、目的に合わせて簡略化してよいこと
- アーキテクチャの選択には必ずトレードオフがあること
- 課題ごとにモデルを分けていくことは自然な判断であること
これらの考え方が、自分が普段触れているドメインにどう当てはまるのか気になり、現在プロダクト開発で関わっている 物流（輸配送）領域 を題材に、本で得た知識をおそるおそる当てはめながら改めて自分なりにモデルとして見直してみました。
その中で、いくつか面白い発見があったため、備忘も兼ねて書き残しておきたいと思います。
輸配送の取引を眺めてみる
物流の現場では、
- 荷物を送りたい会社（荷主）
- 実際に輸送を行う会社（運送会社）
が異なることはごく自然で、むしろ一般的な構造です。
例えば「この荷物をここからここまで運んでほしい」という会社間の取引を課題として捉え、モデルに落とし込もうと考えると、
まずは次のような、とても単純なモデルが思い浮かびます。
ユースケースを集めて課題の集合を作る
現実の業務は、もちろんこんなに単純ではありません。もう少し肉付けをして、課題の断面とそれを解決するモデルの糸口を探します。
本に書かれていたように、まずは 同じデータソースに対して操作を行うユースケースを特定し、まとまりとして集めてみる という手順で、課題解決の断面を探してみました。
取引という側面でユースケースをいくつか書き出していくと、はじめは単なる一覧のつもりだったのですが、並べているうちに「どうも性質の違う二つのまとまりがあるようだ」と感じはじめました。
たとえば取引の前段階に関するユースケースには、
- 依頼内容の作成
- 受託できるかどうかの判断
- 条件調整・金額交渉
といった「取引の約束」に関するものが並びます。
一方で取引の後段階に関するユースケースには、
- 運行実績の登録
- 単価に基づく金額計算
- 請求書の作成
- 入金の確認・消込
といった「実績をどうお金として扱うか」に関わる処理が中心になります。
フェーズによるモデルの境界が見えてくる
まだ厳密に線引きをしているわけではないのですが、扱う情報や関心の向きがまったく異なるため、自然と 発注・受注 と 請求・支払 の二つのフェーズとして分かれていくように感じられました。
よく考えると、これらを担当する“部署”や“役割”もおそらく異なるのではないか という点にも気づきます。発注や受注に関わる業務は営業や調整の担当者が、請求や支払に関わる業務は経理や請求管理の担当者が扱っていることが多いはずです。
担当する人が違うということは、扱う責務や優先する観点も異なるということです。
そのため、このあたりに モデルとしての境界が1つ存在していそうだ と、少しずつ輪郭が見えてきました。
2つのアクターをまたぐ境界で悩む
ここまで、フェーズ（受発注／請求・支払）とアクター（荷主／運送会社）の二軸でユースケースを整理してみると、
業務としてはきれいに フェーズで分けられそうなことが分かってきました。
一方で、ここから先は少し悩ましい話になります。
「荷主と運送会社という 2 つのアクターで、どこまで同じ“取引モデル”を共有すべきか」 という問題です。
たとえば「1 件の取引」という観点で見ると、
- 荷主から見た「この取引」の情報
- 運送会社から見た「この取引」の情報
は、かなり重なっているようにも見えます。
同じ荷物・同じ日付・同じ金額を扱っているのであれば、1 つのレコード（あるいは 1 つの集約）にまとめておいたほうが、シングルソースとして安全そう にも思えます。
一方で、ユースケースを眺めていると、
- 荷主側は「依頼をどう出すか」「どんな条件で頼むか」という視点が強い
- 運送会社側は「受けられるか」「どう運ぶか」「どう請求するか」という視点が強い
というように、同じ取引であっても、アクターごとに見ているもの・気にしているものが少しずつ違う ことも見えてきます。
そうなると、設計としては大きく二つの方向がありそうです。
-
1 つの“取引”モデルを共有する方向
- 両者が同じレコードを見ており、情報のズレが起きにくい
- ただし、どちらか一方の都合で項目が増えたり、制約が増えたりしやすい
- 「片側の仕様変更が、もう片側のモデルにも波及する」可能性がある
-
荷主向けの取引モデルと、運送会社向けの取引モデルを分ける方向
- それぞれのアクターにとって自然な形でモデル化できる
- 権限や見せ方の違いも表現しやすい
- その代わり、両者の間で「どの取引がどれに対応しているか」を結びつける仕組みが必要になる
実際にモデルをどう切るかを考えはじめると、「シングルソースで持っておきたい気持ち」と「アクターごとに責務を分けたい気持ち」がぶつかる場所 が、この荷主と運送会社の境界なのだと感じました。
ここはまさに、アーキテクチャの本に書かれていたような「どこに境界を引くか」「トレードオフをどう受け入れるか」を突き付けられるポイントでした。
延々と悩んでいる中で複式簿記に出会う
取引モデルをどう扱うか、モデルの境界をどこに置くべきか悩んでいたときに、
「実際の業務の現場では、請求・支払の情報をどう扱っているのだろうか」と調べていたら、複式簿記に行き当たりました。
複式簿記とは、一つの取引を「原因」と「結果」の両面から見て、「借方」と「貸方」に分けて記録する方法です。
たとえば同じ輸配送の取引でも、複式簿記の世界では立場によってまったく別の勘定科目として記録されます。
荷主（買い手）側の例：
| 借方 | 金額 | 貸方 | 金額 |
|---|---|---|---|
| 運送料（費用） | 50,000円 | 買掛金（負債） | 50,000円 |
運送会社（売り手）側の例：
| 借方 | 金額 | 貸方 | 金額 |
|---|---|---|---|
| 売掛金（資産） | 50,000円 | 売上（収益） | 50,000円 |
同じ1つの出来事でも、売り手にとっては“収益”、買い手にとっては“費用” として扱われます。
同じ事実を扱っているのに、記録する場所も名前もまったく異なります。
会社が違うのだから帳簿も違うのは当然じゃない？と思われるかもしれませんが、取引モデルをどこまで共有するか悩んでいた私にとってこれは青天の霹靂でした。
複式簿記は、立場が変われば意味が変わる世界を、無理なく扱えるように設計された“モデル” なのだと感じました。
この仕組みに触れたことで、輸配送の請求・支払フェーズでも、同じ金額を扱っていても立場によって意味が変わる場面があることに改めて気づき、
この部分は無理にひとつのモデルにまとめなくてもよいのかもしれない と素直に思えるようになりました。
おわりに
輸配送という日々触れている領域を、改めて「モデル」という視点で見直してみたところ、自分が思っていた以上に多くの気づきがありました。
あくまで自分が考えている最中のメモのようなもので、特別な結論があるわけではありません。
ただ、本を読んだり業務を眺めたりしながら得られた気づきが、同じようにモデリングで悩む方の視点の一つになれば嬉しいです。
お読みいただき、ありがとうございました。
Discussion