コンパイルは供給チェーンを救うのか？
コンパイルとは、コンパイラ、すなわちソースコードを別の言語に翻訳するプログラムを作成する技術のことを指す。プログラマー以外はコンパイラが何をするものか知らず、プログラマーであってもその設計方法を知っている者はごくわずかである。初めは、コンパイルに関する問題は供給チェーンの問題とは程遠いものに思われた。しかし、今日においてLokadでは、次々と供給チェーンプロジェクトを救うのはまさにコンパイル技術なのだ。
Shameless plug: コンパイルスキルを持つソフトウェアエンジニアは木から生えるわけではありません。我々は採用中です。重要な仕事に携わりたいですか？もし次に部品の欠品であなたの飛行機が遅れたり、求めている医薬品が 在庫切れ になったとき、その時あなたは Lokadに参加する ことで変化をもたらせたかもしれない :-)
供給チェーンは複雑で、非常に複雑だ。グローバリゼーションにより調達機会は飛躍的に増加したが、遅延はこれまで以上に長く、不規則になっている。販売チャネルも倍増している。実店舗、オンライン店舗、マーケットプレイス、再販業者、卸売業者などが存在する。そして現在、Amazonのおかげで、どこにいても誰もが全ての商品を注文し、一晩で受け取ることを期待している。供給チェーンへの期待はかつてないほど高い。
供給チェーンの問題に、プログラミング言語の表現力を最大限に活用しないアプローチでは通用しない。レゴでのプログラミングが実現しないのと同様に、供給チェーンの課題もチェックボックスやドロップダウンに収まるものではない。ただし、ソフトウェアベンダーが試みることを妨げるものではない。平均して各テーブルが約100フィールドに及ぶ1000以上のテーブルを含むソリューションはあまりにも一般的だ。そして、クライアント企業がこのソリューションの機能のたった1%しか利用していなくとも、その普遍的な複雑性に対処しなければならない。
コンパイルは、高品質な抽象化を工夫するための豊富な知識とノウハウ、すなわち統計的および組み合わせ的な問題（その他多くの問題）を解決するためのパワーツールを提供するため、局面を打開する。その上、ほとんどの供給チェーンの課題はまさに統計的かつ組み合わせ的である。例えば、Lokadでは分布の代数を導入することで、パッケージ化されたソフトウェア機能によるより直接的なアプローチが奏効しなかった複雑なリードタイムの問題に"切り込む"ことに成功した。
言語機能が一般的なアプリ機能（wysiwyg）と異なる点は、言語機能が特定の課題の固有性に左右されにくいという点にある。例えば、極端な季節商品において在庫切れ検出ロジックが裏目に出る状況を考えてみよう。もしその機能が言語構造を通じて提供されるなら、意図された通りに機能するまで常にデータ範囲を絞り込むことができ、場合によっては特注の数値解析によって範囲を動的に調整することも可能である。一方、アプリ機能ではその機能に組み込まれたフィルタリングオプションに縛られてしまう。アプリ機能は、問題が狭く明確に定義されている場合にのみ適しており、それは供給チェーン最適化には全く当てはまらないのだ。
供給チェーンの領域では、プログラマビリティが光る理由は以下の通りである:
- 問題は高度に数値的であり、非常に構造化されている
- 供給チェーンはモジュール構造を持っており、そのモジュール性を活用する必要がある
- 変数の数は多いが、それほど膨大ではない
- 問題に正確に合致する形状に合わせることが重要である
多くのソフトウェアベンダーがプログラマビリティを 徐々に 再発明する様子は、やや滑稽である。ユーザーインターフェースがフィルター、オプション、前処理または後処理フック、テンプレート化されたアラート、KPIモニターを追加できる可能性とともに、その深さと複雑さを増すにつれて、_ユーザーインターフェースは次第にプログラム可能なもの_となり、結局はプログラマーだけが理解できる存在にまでなってしまう（それはまさに彼らの既存のプログラミングスキルのおかげである）。プログラム可能であるとはいえ、その方法は非常に複雑である。
コンパイルはエンジニアリングスキルを増幅させる芸術である。問題解決の思考を合理化するための抽象化や言語構造を巧みに設計しなければならない。ブライアン・カーニハンが有名な言葉で述べたように、バグ修正はプログラムを最初に書くのと同じくらい（いや、むしろ2倍）難しい。だから、もしあなたが書くときにどれだけ賢くあっても、いったいどうやってデバッグするのか? この論理は供給チェーン最適化にも当てはまり、コードを書くのと本質的には同じことである。実際、Lokadではそれは文字通り同じことである。
従来のITの知恵では、まず容易な部分を自動化し、複雑な部分は人間の専門家に任せるべきだとされている。しかし、供給チェーンではこのアプローチは 毎回必ず 裏目に出る。供給チェーンの最も複雑な部分はほとんどの場合、最もコストがかかり、緊急に対処すべき部分である。容易な部分は 最小最大 の在庫管理や Kanban により自動的に処理できる。自律走行車用のソフトウェアを、鉄道の自動運転向けソフトウェアの改良で作らないのと同様に、単純な課題を解決するために初めに設計されたソフトウェアを改良することで、困難な供給チェーンの問題に取り組むことはできない。
当然のことながら、コンパイルだけで供給チェーンの課題に対応するのは十分ではない。機械学習、ビッグデータ処理、そして相応の人間のスキルもまた重要である。しかし、いずれの場合も、高品質な抽象化を丹念に設計しておくことは大いに役立つ。入力データが十分に整備されていると、機械学習は格段に簡単になる。計算が高度に並列化しやすい場合、ビッグデータ処理もまたはるかに簡単である。
