Seibiiでアプリケーション領域の開発を担当している橋本です。普段は整備士向けのモバイルアプリケーションの開発やバックエンドの開発を行っています。
Seibiiが提供するサービスの1つに出張整備サービスがあり、現場では自動車の部品を扱います。自動車部品の仕入れ先である部品商への発注情報や、作業で使用した部品の情報は、社内システム上で記録・管理しています。
今回、この部品まわりのシステムにいくつかの機能追加を行いました。本記事では、追加された機能に関するテーブル設計や、得られた個人的な学びなどを紹介します。
社内の既存の部品管理システムについて
社内にはすでに部品発注のためのシステムが内製されており、見積もり依頼から発注、さらには現場での使用まで含めた一連のフローが運用されている状態でした。
簡略化された部品オペレーションの全体像:
新たに生じた要望
事業の拡大に伴い、部品を「商品」単位だけでなく、より抽象度の高い「カテゴリ」単位でも扱いたいという要望が生まれました。
部品を扱う業務では、フェーズによって必要となる情報の粒度が異なります。あるフェーズではカテゴリ、別のフェーズでは具体的な商品を扱うため、後続のフェーズで当初の分類情報を参照しにくい課題がありました。そこで、確定時点のカテゴリ情報をどのように保持し、後続の処理でも追跡できるようにするかを検討しました。
初手の設計
部品オペレーションの起点は、必ず見積もり依頼です。そして、見積もり依頼を出す時点での部品の単位は「カテゴリ」でした。であれば、見積もり依頼が発生したタイミングでカテゴリの実体を表すレコードを作成しておき、そのレコードを以降の各オペレーションフェーズ（見積もり回答、発注など）で作られるレコードから参照させれば、発注後もカテゴリを追跡できるのではないか、と考えました。
※ 以降の図では抽象化されたモデルのみを表示し、設計上の関係性だけを示します。
最初に考えた方針は、次のようなものです。
- 部品カテゴリを管理するマスタテーブルを新設する
- 見積もり依頼の発生時にその依頼に紐づく「部品カテゴリインスタンス」を表現するテーブルを新設する。このテーブルのレコードが、以降のフェーズから参照される「ハブ」となる
- ハブテーブルには、対象の部品カテゴリが記録される
- 見積もり依頼以降の各テーブルは、すべてこのハブテーブルを参照する構造とする
これなら、発注後のどのフェーズからでもハブテーブルを辿ることで部品カテゴリを追えるようになると考えました。
設計の改善
しかし、設計レビューでは、複数のフェーズで参照するカテゴリ情報を、後から更新可能な共通レコードに集約しようとしている点に懸念があると整理しました。
このような構造では、
- フェーズごとの要件変化に弱くなる
- 例外的な事象が発生した時の対応が複雑かつ困難になってしまう
- ハブテーブルのカテゴリが更新されると、すでに記録された部品オペレーションイベントの解釈まで変わってしまう
といった弊害が出やすくなります。
今回必要だったのは、共通の最新状態を参照することではなく、「その時点でその部品をどのカテゴリとして扱ったか」を記録することでした。そこで、中央に更新可能な「ハブ」を置くのではなく、各フェーズがそれぞれで確定したカテゴリ情報を保持する設計に落ち着きました。
- 見積もり依頼の明細に部品カテゴリを属性として持たせる
- 発注明細を参照し、部品カテゴリも属性として持つ発注時のカテゴリ情報を作る
- 発注時のカテゴリ情報には、見積もり依頼の明細からカテゴリを引き継いで記録する
- 部品の使用記録にも部品カテゴリを属性として持たせ、レコード作成時には発注時のカテゴリ情報に記録されたカテゴリを引き継ぐ
この設計により、どのフェーズのテーブルも「自分のフェーズで確定した情報を記録する」という責任だけを持てばよくなりました。また、過去の発注や使用について「当時どのカテゴリとして扱ったか」を、後続フェーズのレコード自身に記録できるようになりました。
イミュータブルデータモデルを参考にした視点
この設計に落ち着いた後、同じような考え方が体系化されていないか調べてみたところ、「イミュータブルデータモデル」として知られる設計手法に出会いました。(イミュータブルデータモデル(入門編))。この手法では、更新を抑えながら、システムが扱うデータを状態が変化しうる「リソース」と、発生した事実を表す「イベント」に分けて捉えます。
今回の設計は、イミュータブルデータモデルを完全に適用したものではありません。更新・取消・訂正をどのように扱うかまでを含めた設計ではないためです。一方で、確定した時点のカテゴリ情報を、後続の情報更新から独立して残すという点では、参考にした考え方と重なる部分があります。
仮に各フェーズの記録が更新可能なハブテーブルのカテゴリを参照し続けると、ハブテーブルのカラムが後から更新された場合、過去の記録の解釈まで変わってしまいます。各フェーズに確定時点のカテゴリ情報を記録することで、「現在どのカテゴリに属するか」と「当時どのカテゴリとして扱ったか」を分けられます。
まとめ
今回、部品カテゴリを発注後のフェーズでも追跡できるようにするという、一見シンプルな要件がきっかけで、イミュータブルデータモデルの考え方に出会いました。最初は更新可能なハブテーブルに情報を集約する設計を考えていましたが、フェーズごとに確定した情報を記録し、過去の解釈が後から変わらないようにする設計に切り替えました。この視点によって、変更に強く見通しの良いテーブル設計ができたと感じています。今後の機能開発でも、確定した情報と更新可能な情報をどのように分けるべきかを意識して設計していきたいです。
Seibiiでは、今回紹介したような部品管理をはじめとしたモデリングや設計判断のしがいがある課題がたくさん存在します。少しでも興味を持っていただけたら、ぜひ採用サイトも覗いてみてください。
Seibiiは出張整備をはじめとする自動車アフターマーケット市場に新しい価値を生み出すことを目指すスタートアップです。
現在、社内の業務システム開発などを担うアプリケーションエンジニア(Ruby on Rails, React, Flutter, etc...)を含むいくつかのポジションで採用活動を行っています。詳細は採用サイトでご確認ください。
Discussion