業務の最適化とマラソンマッチの違い
最近マラソンマッチが流行ってるみたいなので流行に乗って書いてみます
新卒のペーペーですが複数社でヒューリスティックな最適化系のタスクしてきたので参考程度にはなるかも？
そもそも最適化とは
ja.wikipedia.org
まぁこれなんですが、簡単に言うと、パソコンとか数学使って賢いことをすることでリソース（お金）を得る（節約する）ことです。
巡回セールスマン問題（TSP）は有名な例で、複数の荷物を届けるときにどの順番で家を訪れれば最も移動距離が短くできるかみたいな問題は、パソコンを使うと人間よりもかなり賢く解けます。
マラソンマッチとは
（組合せ）最適化問題が与えられるので、最もいいスコアが出せた人が優勝！っていう競技です。
昔は海外サイトばかりでしたが、最近はAtCoderというサイトでマラソンマッチが割と頻繁に開かれるようになりました。
競技なので勿論問題設定や各種制約が厳密で、終盤になるとその問題に特化した非常に技巧的なテクニックが使われるようになったりします。
個人の趣味なので、スコアさえ上がれば正義と言って好き勝手やってよくて楽しい（主観）です。
業務最適化とは
巡回セールスマン問題の例がありましたが、工場で機械にどうやって仕事を割り振ればいいのか、倉庫にどうやって荷物を積めばいいのかなど世の中の産業には割と最適化を行う場面が多いです（そして最適化によって大きいお金が動いたりします）。
業務最適化における目標はクライアントを満足させることで、特定の最適化問題を解くことではないです。
現実の話になるので、問題設定や各種制約が厳密に定められているわけではなく、場合によっては評価基準（何をもっていいとするのか）などさえ曖昧な場合も多いです。
これは例えば日本からパリに最安値で旅行するプランを建ててくださいって言われたときに、乗り物は何を使っていいのか、いつ旅行をするのかなどが曖昧ということで（極端ですが）、最適化という数値と向き合うタスクに挑む際には非常に厄介な問題になります。
業務最適化で一番大事なこと
問題設定の厳密化です。
大抵の場合はクライアント（取引先）もやって欲しいことを何となく言語化はできてるものの、ちゃんと定式化はできてないです。
特に最適化のテクニックは与えられた問題の性質をフル活用しようとするので、制約に漏れがあるとその制約の穴を突いて賢くやってしまいます。
何をやってよくて何をやってはいけないのか、そして何をして欲しいのかをできるだけ明文化（定式化）するのがかなり大事で、クライアントが満足する厳密な問題設定を設計出来たらもう9割9分勝ちです（まぁ大抵は最後まで曖昧で終わるんですが）。
最適化のテクニックでどうこうするよりも、仮定していい特徴を話し合いで1つ見つけるほうが強い場合が多いですし、制約が1つ追加されたことでこれまでの手法がパーになることもあります。
勿論クライアント側としてはすぐにシステムに組み込めるような手法を求めるわけですが、現実には不確定要素が多いことなどから実現が難しい場合が多いです（体感です）。
よって、話し合いによってなぜ実現が難しいかを納得させ、この制約はどうしても無理だとかこの辺りまでならいけるみたいな妥協点を探り合うことになります。
現実で使えない手法作ってどうするんだってなりがちですが、大抵の場合は既に動いてるシステムをさらに良くするために最適化問題が解かれるので、現実には無理だけどこういう設定なら実はこういうことができるよって既にあるシステムにアドバイスするだけで価値がある場合も多いです（クライアント側も難しさをわかっていて最初からこれを目指してることも多いです）。
極端な例ですが、1000mを100秒で走るペースを知りたいっていうときに、ずっと10m/sで走るダミーをずっと見せてあげれば走る人には助かるはずです（実際に走者が10m/sで走るわけではないが参考にはなるという）。
業務最適化で好まれる手法
制約が追加で振ってきたり、利用できるデータが増えたりしたときに柔軟に対応できる手法です。
マラソンマッチでは問題の特性をフルに活用した手法が大切でしたが、それとある意味対極をなすことになります。
とはいえ最終的には問題設定を無理やり固めて何かしらを最適化することになるので、プロジェクトの進行具合に伴って徐々に柔軟性を失うと共に精度を上げていくイメージになります。
これは結構意識するべきことで、まだ問題設定が固まりきってないうちにコードを複雑化させて暫定的なスコアを上げてもその実装はいずれ捨てることになることが多く、なんなら捨てきれずに将来の負債になることさえあります。
マラソンマッチがどの場面で役に立つか
POC (proof of concept, 概念実証）においては結構役に立ちます。
クライアント（取引先）と問題設定のすり合わせを行う際に、この設定は足せる？この設定は？みたいな話になるんですが、マラソンマッチ（最適化）に明るい人がいると、この問題に対してこの制約はヤバイ、この制約はあっても問題ないみたいのが聞いただけでわかったりもするので話し合いがやりやすいです。
また、場合によっては仮の問題設定でそれなりのスコアをパッと提示することでプロジェクトの方向性が見えやすくなったりします（これを最適化に明るい人がやると信憑性が増す）。
ここで使うスキルは主にマラソンマッチの経験的な部分であって、詳細を限界まで詰めるみたいな要素はあんまないですが、場合によっては無理やり頑張って最適化することで数字を見せてクライアントを満足させるみたいなこともあります。
マラソンマッチが好きな人が業務の最適化で気を付けるべきこと
マラソンマッチが好きな人は問題の特徴をexploit（弱みにつけ込むみたいな意味）することで細かい改善を続けるのが好きな人が多いと思います。
ただ、業務の最適化においては、知られてない問題の特徴を見つけたらまずそれを仮定していいのかクライアントに確認したほうがいいですし、細かい改善を繰り返すフェーズに入るのはかなり後半です（場合によっては最後まで問題が曖昧なのでそのフェーズにすら入らないです）。
テストケース（入力データ）も数個しかないような場合もあって、最適化周辺のソフトウェアやインフラも少しは触れる必要があったりもします。
つまり業務の最適化はマラソンマッチと結構違うので、マラソンマッチの気分で取り組もうとするとコウジャナイ感に襲われるかもです。
ただ、根幹が最適化問題であることに変わりはないのでスキルが全く無駄になることはないです（多分）。
