こんにちは、カジです。
これまで3回にわたり、ヤマト運輸が作り上げた「宅急便」という社会インフラの美しき設計思想と、それを支える強靭なネットワークについて解剖してきました。
しかし、どんなに優れたシステムでも、設計時の想定を遥かに超える負荷がかかれば、いつかは破綻します。
2010年代。ヤマト運輸を襲ったのは、Eコマース（電子商取引）の爆発的な普及という、巨大な津波でした。
ITエンジニアである私の目には、当時の状況は、サーバーに対して処理能力を超える大量のリクエストを送りつけ、システムをダウンさせようとする「DDoS攻撃」を受けているかのように映りました。
第4回となる今回は、この未曾有の危機に対して、ヤマト運輸がいかにして向き合い、断腸の思いで「システムの再設計（リファクタリング）」を断行したのか。その苦渋と再生のドラマに迫ります。
※この記事に掲載されている挿絵は、内容の理解を助けるためのイメージであり、実在の人物、製品、団体等を示すものではありません。
想定外のアクセス過多（オーバーロード）
かつて、宅急便が「発明」された時、主な利用者は「個人」でした。おばあちゃんが孫に送るリンゴや、ゴルフ場へ送るゴルフバッグ。これらは季節波動こそあれ、ある程度予測可能なトラフィックでした。
しかし、AmazonをはじめとするECサイトの台頭は、その前提を根底から覆しました。
「ポチる」だけで翌日に届く便利さは、爆発的な物流需要を生み出しました。システムへのアクセス数（荷物量）は右肩上がりに急増。しかも、その多くは「送料無料」が当たり前で、単価は安く、不在再配達のリスクも高い。
ネットワークの帯域（配送能力）は限界に達し、現場のセールスドライバー（CPU）の稼働率は100%を超え、熱暴走寸前（過重労働問題）に陥りました。
これは明らかに「システムエラー」の警告音でした。しかし、「サービスが先、利益は後」という創業以来のDNAが、現場に無理をさせ続けてしまったのかもしれません。
「総量規制」という名のQoS制御
2017年、ついにヤマト運輸は大きな決断を下します。
それは、「荷物の取扱量を抑制する（総量規制）」そして「運賃の値上げを要請する」という、物流業界の常識では考えられない方針転換でした。
「運びきれない荷物は、受けない」
これは、エンジニアリングの観点から見れば、極めてまっとうな「QoS（Quality of Service）制御」です。
QoSとは、ネットワークが混雑した際に、通信の品質を維持するために、優先度の低いパケットを破棄したり、帯域を制限したりする技術のことです。
サービス品質（翌日配達、丁寧な接客）を守るためには、入力されるトラフィック（荷物量）を、システムが処理できる適正範囲内にコントロールしなければならない。
それは、企業の成長（売上拡大）を一時的に犠牲にしてでも、システム全体の崩壊を防ぐための、勇気ある「緊急パッチ（修正プログラム）」の適用でした。
「安さ」から「価値」へのOSアップデート
この危機を経て、ヤマト運輸のシステム設計思想（OS）は、大きくアップデートされたように見えます。
それは、「何でも、どれだけでも、安く運ぶ」という量的な拡大路線から、「持続可能な適正価格で、高品質なサービスを提供する」という質的な転換です。
最近では、EC専用の配送ネットワークを切り出したり（EAZY）、置き配を標準化したりと、ECという特殊なトラフィックに最適化された「サブシステム」の構築も進んでいます。
これは、メインのシステム（従来の宅急便）への負荷を分散し（ロードバランシング）、それぞれのニーズに合わせた最適なプロトコルで処理しようという、極めて合理的なアーキテクチャの進化です。
システムは、一度作って終わりではありません。
環境の変化に合わせて、バグを修正し、コードを書き換え、時には痛みを伴う仕様変更も行わなければならない。
ヤマト運輸のこの数年間の苦闘は、巨大な社会インフラ・システムが、生き残りをかけて自己進化しようとする、壮絶な「デバッグ」のプロセスだったと言えるでしょう。
さて、危機を乗り越え、システムは安定を取り戻しつつあります。しかし、未来の課題がなくなったわけではありません。
最終回となる次回は、少子高齢化や環境問題といった次なる制約条件の中で、このシステムがどこへ向かおうとしているのか。AIやロボティクスが切り拓く「未来の物流」の姿を展望してみたいと思います。
コメント