世の中にはプログラミングのベストプラクティスとして紹介される原則があります。例えばDRY, KISS, SOLIDなどが挙げられます。

ハコベルのサービスを作ってきた歴史を振り返ってみると、YAGNIの原則に近い意思決定だったなと思うものがありました。その判断もたらした影響を、YAGNIの原則に従うメリットの事例として紹介したいと思います。今回紹介する事例と現在我々が取り組んでいること、両方が物流の効率化に関わるものとなっています。当時の想定と現在の取り組み、その違いと今後の展望についても併せて紹介していきます。

YAGNIとは

Wikipediaでは以下のように定義されています。

機能は実際に必要となるまでは追加しないのがよいとする、エクストリーム・プログラミングにおける原則である。 https://ja.wikipedia.org/wiki/YAGNI

"You ain't gonna need it" のアクロニム（頭字語）でYAGNIです。

実体験の紹介

ハコベルについて

まず背景として、ハコベルのサービスについてざっと紹介します。

現在ハコベルでは大きく2つの分野に向けてサービスを提供しています。一般の方も利用していただける物流リソースのマッチングサービス、企業の運送部門・運送会社の方の物流DXを支えるソリューションサービスの2つがあります。

https://www.hacobell.com/matching

https://www.hacobell.com/solution

今回はそのうちDXソリューション、企業向けのサービスの開発においての体験談です。

概要・背景

物流において重要な情報としては、依頼主、届け先、荷物の内容、集荷・配送日時が挙げられます。依頼主が品物を配送する依頼をするのがスタートです。集荷日になるとトラックは集荷地に向かい、荷物を積み、届け先に向かいます。届け先は1つの場合もあれば、複数地点が指定され順番に届けて回るケースもあります。

作らなかった機能

開発初期に、トラック運行の効率化のために注文を結合する機能を作るアイディアがありました。運行にかかる時間とコストを減らすことにつながり、機能として提供することでユーザーがサービスに魅力を感じるのではないかとする仮説です。例えば運送会社が複数の顧客注文を受け、そこに同じ配送先への配送があった場合、同じトラックに積み、まとめて納品をするようなケースを想定していました。

しかし、サービスのローンチに向けて、その機能は複雑なのでリリース時点からはスコープから外すことにしました。これはYAGNIの原則に従った決定だったと言えます。

後に与えた影響

後になってスコープから外した影響について考えてみたところ、サービス、技術両方の点で大きな影響があったとこに気づきました。

サービス面の影響

企業向けの物流においては、依頼主は製造業の物流部門担当者であるケースが多いです。彼らは自分のコストが低くなるよう考えた上で発注をしています。トラックを手配するのであれば、できるだけ積載率が高くなるように組み合わせて発注します。つまり、運送会社が注文を統合しようにもトラックにほかの注文の荷物を積めるスペースがないのです。

物流の品質の上でもリスクがあります。誤配送や配送遅れが起きる可能性が、配送の内容が複雑になることで高まります。またその場合リスクを誰が負うのか、再配送などのコストを負担するのかの問題も出てくるでしょう。

注：依頼内容、契約形態によっては、運行の最適化を含めて依頼するようなケースもありえます。しかしそういう場合以外では、一般的に依頼された注文を運送会社都合で結合することはまずありません

仮に注文結合の機能を作っていたとしたら、全く使われない機能となり開発に費やした時間が無駄になっていたでしょう。それだけではなくコードの複雑さが増すことで、機能の追加が難しいという問題を抱えていた可能性もあります。

後に述べますが、ハコベルでは物流における注文の最適化については現在別の方向からアプローチをしています。業界の理解を深めてから進めれる状況になった点でもYAGNIの原則に従った良い影響だったと言えるでしょう。

技術面の影響

同時に技術の観点、特にデータの構造の面でもこれまでの開発に対して良い影響を与えてくれました。データベースのテーブルの構造にこのYAGNIな機能を反映しなかったことで「注文」の単位がはっきりし、余計なデータ属性を持たない状態となりました。以下は当時の資料のイメージになります。詳細はぼかしていますが、複雑なデータになっていた可能性があるということをご理解いただけるのではないでしょうか。

このような複雑さをデータ構造に持ち込まなかったことで、テーブルごとの指す範囲が分かりやすく、拡張の難易度が上がらずに済んでいるように思います。

注：もちろん注文の結合機能を作っていてもデータ構造をシンプルにするこは可能でしょう。しかし機能の取捨選択により、シンプルさをより保ちやすい状況になっていたと考えています

DBの寿命はアプリより長い、ともいいます。

参考：DBの寿命はアプリより長い！長生きするDBに必要な設計とリファクタリングを実践から学ぶ - エンジニアHub｜Webエンジニアのキャリアを考える！

データ構造についてはすぐに「まだ不要」と判断するよりもドメインの分割、イベントとリソースへの分類などの整理などはしっかりやっておくのが拡張しやすいシステムとなるように感じます。YAGNIの定義でも「機能」と書いていることはとても示唆的に思えますね。

技術的に初期投資リターンが大きい、後から変更するコストが大きい場所に集中できるのも、YAGNIの原則を意識することのメリットです。

注：実際の開発の中ではチームで取り組み、ディスカッションを経て決断をしています。今回は分かりやすさのためにその経緯などは省略してお伝えしてきました。
また、結果的に切り捨てましたが、その機能についてディスカッションをしたこと自体を批判するものではありません。モデルの設計をより拡張可能にする過程だったと捉えています。