モチベーション
前回、記事を描いてからとてつもない時間がたってしまいました。その間、筆者が何をしていたかと言うと、最適化の実務適用をしていました。（#1 Google OR-toolsを使って hello-worldするで宣言していましたね。）まだ仕事が全て終わったわけではないのですが、一旦一区切りがついたと思っています。そこで、今回はなるべく差し障りのない範囲で思ったことを書きたいと思います。
結構、設計能力を要求される
実務適用の際に一番に苦しんだといっても過言ではないポイントだと思っています。文章として書くと至極当たり前ではあるのですが、現実の問題を最適化問題に帰着させるために「現実のモデル化」を行います。それはすなわち「設計」することと大差ありません。これが難敵で、小さく問題を区切っても、設計部分はどうしてもある一定の時間はかかってしまいます。あくまで体感・直感の話で戯言のようなものなのですが、これくらいの難易度の「設計」ができる人は、ORで活躍するよりもっと別の分野で「設計」する方がお金になるんではないかなと思います。（あと、それぐらい「設計」ができる人は市場になかなか出てこないレベルで貴重な気がします。）
これがエキスパートシステムの時代に流行らなかった一番の理由とも思えます。
ドメイン知識を要求される
これは前述の「設計」の話にも言えることではあるのですが、最適化問題を適用するためには、最適化問題のドメイン知識と、実際に適用する業務のドメイン知識がどうしても必要になってきます。どちらが欠けてと良い定式化ができなくなってしまいます（例えば不要な変数を定義してしまう、実は暗黙に了解していることを見逃して無意味な最適化を行ってしまう）。今回のプロジェクトは、最適化分野の情報収集と業務知識のヒアリングを同時に進めていきました。業務知識の方は今の所、問題がありませんが、定式化の学習がどうしても実務に追いつかず、「この実装、本に書いてあるし！しかもこの実装の方が良いし！」なんて言いながら、結構手戻りを発生させてしまいました。
表現方法に気をつけつつ、変数立てを行う必要がある。
最適化問題を解くだけ、ならとても簡単な話なのですが、今回は実務適用であるため、非エンジニアもわかるように話を進めなければなりません。これが大変難しく、アルゴリズムとその表現方法を同時に考える必要に迫られます。当たり前の話ではあるのですが、自分の作った定式化により、最適化問題が正しく解けていることを理解してもらう必要があります。今回の問題に対しては、複数の変数の切り方があり、それぞれの切り方によって、表現を実装するのがとても大変になることがわかりました。しかし表現実装のコストを安くすると、変数の数が非常に多くなるため、痛し痒しでした。
意外と解くスピードが早い
これはびっくりしたのですが、ナイーブな変数設定にも関わらず、Google OR toolsは非常に高速に解いてくれるようでした。今回の変数数は実務を模したデモデータに対して約16万個あったのですが、おおよそ80分程度で解いてくれます。もっと変数の数を抑えることはできるはずなので、
- 変数を抑えて実装すること
- 制約条件が凸型になっていることを確認すること（かなり意識して設定したので大丈夫なはず）
- 線形緩和問題に切り替えること
- ヒューリスティクスの利用
これらの要素を検討してあげれば、もっと高速になる気がしています。
振り返り
実際に作業を行ったのは2週間前後、ヒアリングだったり設計に別業務と平行で1ヵ月かけているので、結構大変な仕事でした。急ぎ仕事でもあったので、早急にリファクタリングして、今後のアップデートに対応したいところです。
終わりに
自分の記事のクオリティを高めたいので、質問でも、次の要望、ただの感想、何でもいいのでコメントを残して頂けると幸いです。