こんにちは．研究開発室の福井です．研究開発室においてオペレーションズ・リサーチ(OR)のビジネス活用について研究を行っております．本稿では，Flect 社内における OR の技術の横展開に向けた取り組みを紹介します．
Flect におけるオペレーションズ・リサーチの研究
オペレーションズ・リサーチ(OR) とは実務において数理的な手法を応用するための研究全般を指しており，具体的には実務を念頭に置いた数理最適化やデータ分析等がテーマとしてよく扱われます． 特に，業務上の意思決定を支援するための数理最適化に関連した課題が取り上げられることが多く，配送計画問題，在庫の最適化，シフトスケジューリング等の問題が有名な事例となります*1． Flect のクラウドインテグレーション事業部では，様々なお客様の業務のDX化を支援ていますが，人手不足が加速する近年においてはデジタル技術を用いてより専門性の高い業務を自動化/効率化することが重要な課題となります．ORの技術はこれらの課題解決の一助となるという期待から，研究開発室では今日までに様々な研究開発を行ってきました．
Flect の研究開発室において私が OR の研究を始めてから 2 年半ほどとなります．これまでに配送計画，配船計画，社内のアサインメントに関する計画問題等を扱ってきました．また，大変ありがたいことに社外のお客様と協力して OR の技術をお客様の現場で応用する機会をいただくこともできました．
これまでの研究開発を通して OR に関する知見や技術が当初よりも研究開発室内で蓄積されつつあります．その一方で，ビジネス上の課題も見えてきました．現時点での最大の課題は，OR に関する知見や技術を持った人員が研究開発室内のごく少数に限られているという点にあります．このため，Flect 全体で見ると，並列して受注可能な OR 関係の案件数が大きく制限されてしまい，ビジネスとしてスケールさせることが困難な状況となっていました．この問題を解決するには，何らかの施策によりFlect 社内の誰もが比較的容易に OR の技術を利用することができる状態を作り上げて，OR 関係の新規案件の受注可能性を高める必要があると考えました．採用や教育により人材を増やすという考え方もありますが，多数の専門的な人材の確保は一朝一夕にはできないため，まずは誰でも簡単に使えることを直近のゴールとして設定しています．
横展開する上での課題と取り組み
前節で述べたように，ビジネスとしてスケールさせるために OR の技術を誰でも使えるような状況を作る必要がありますが，この状況を作り出すまでの間にもいくつかのハードルが存在します．具体的には，
といったハードルが存在しており，これらのハードルをいかに取り除くかが課題となります．これらの課題に対して，研究開発室では以下のような対策を始めました．
- 比較的すぐに対応可能な OR の問題(+対応可能な要件)のメニュー化
- 比較的すぐに対応可能な問題のモデルを容易に用いるための wrapper ライブラリを作成
前者は課題 1〜2 を解決するための施策で後者は課題 2〜3 を解決するための施策となり，上記のメニューと wrapper をあわせたものを以降ではパッケージと呼びます．メニュー化とは，具体的にはパッケージがすぐに実現できる要件(i.e. wrapper 上で実装済みの要件)一覧を資料化したものを指しています．定式化前のヒアリングにおいては何がモデルの制約条件と強く関わってくるのかを意識する必要がありますが，そもそも何が制約条件に関係して何が関係ないのか区別するには OR に関する事前知識がある程度必要となります．メニューはこのような状況において要求される事前知識を減らすためのものであり，ヒアリングの際にはお客様から伝えられた要件とこのメニューの内容を照らし合わせることでヒアリングの作業負荷を軽減できるのではないかと考えています．より具体的には，図 2 のようにすぐに対応できる要件のチェックリストのようなものを用意した上で，その中から必要なものをピックアップするだけで済むような状態を目指しています．
一方，wrapper に期待される効果はモデルの実装作業の負荷の軽減です．OR のモデルを実装するには自然言語で表現された要件を定式化し，その上で数式を何らかの solver 上に実装していく必要がありますが*2，先にも述べたように一連の作業を一気通貫で担当可能な人材を一定数揃えるのは容易ではありません．そこで，対応可能な問題の種類*3を先に述べたように予めメニュー化した上で*4，数理的な知識が無くても(メニュー上の)要件に対応したモデルの実装が行えるようなインタフェースを持った wrapper ライブラリを用意します*5．こうすることで，先に説明したメニューから要件一覧のピックアップまでが完了すれば，後は各要件に対応した wrapper 上のインタフェースを呼び出すことでモデルに対して要件を設定できるため，実装作業の負荷を大幅に下げることが可能となります．
スケジューリング問題のパッケージ化
冒頭にも述べたように OR には様々な問題が存在します．そして，パッケージ化するにあたり，予め取り扱う問題を絞る必要があります．FY22-3Q では，パッケージ化の第一段としてスケジューリング問題を取り扱いました．一口にスケジューリングと言っても様々スケジューリングが存在しますが，ここでは図 4 のような問題を考えます．
上図において，1 つ 1 つの独立した作業を抽象的に捉えたものを item，作業を実施する主体を抽象的に捉えたものを worker と表記しています(便宜上このように表記しているだけで，学術的にこの呼び方が一般的というわけではない点にご注意ください)．ここでのスケジューリング問題とは複数の item と worker が与えられたときに，各 item をどの worker に割り当て，どの時刻に開始するかを決定する問題となります*6．至ってシンプルな問題に思われますが，いくつかの重要な実問題をこの枠組に落としこむことができます．
1 つめの実問題の例としてはシステム開発のスケジューリングがあります．システム開発ではタスクを分解した上でガントチャートを作成する必要がありますが，このさいにどのタスクをいつ頃開始しするか? また，誰にアサインするか?を決定する必要があります．先に抽象化した問題の枠組みに当てはめるとタスクが item，開発を行うエンジニアが worker ということになります．
2 つめの実問題の例としては，産業機械のスケジューリングの問題があります．機械を用いてある製品を加工するさいに複数種類の作業が要求される場合があります．この加工作業の順序を最適化して，できるだけ早く全ての作業が終わるようにするという問題が存在します*7．この例におていは加工作業が item に相当し，機械が worker となります．
FY22-3Q では上記のスケジューリング問題の wrapper を実装し，実際にその wrapper を用いてシステム開発のスケジューリング問題を解くデモを作成することで wrapper の再利用性の確認を行いました(図 5)．その結果，課題であったORのモデル自体の実装作業をほぼ wrapper に任せてモデル以外のコードの実装に集中できることが確認できました．
まとめと今後の課題
本稿では，OR のビジネス活用における課題とその解決のためにFlect 社内において OR の技術を横展開する取り組みに関して紹介させていただきました．パッケージ化による横展開の試みはまだ始まって間もないですが，既にいくつかの問題に対しては実装の再利用が可能であることが確認できています．
今後の課題としては，
- より多くの実問題の実装を通して wrapper の再利用性を確認し，より多くの実問題の実装が行えるように機能追加する
- OR に対して馴染みが薄い第三者からのフィードバックを元に wrapper のインタフェースのブラッシュアップを行い，より多くの人にとって簡単に実装できるようにする
等が挙げられます．今後の研究開発においてアップデートがあれば再びブログにて紹介させていただきます．
最後に
最後まで読んでいただきありがとうございました．Flect では今後もお客様にとって付加価値となるような新たな分野や技術に関して開拓を行っていきます．今回紹介したスケジューリング問題以外にも様々な OR の諸問題に関しても研究を行っているため，もしご興味がありましたら是非ご相談ください．
*1:その他の事例に関しては，OR 学会のOR 辞典をご参照ください
*2:この一連の流れに関してはPython ではじめる数理最適化において詳しく解説されています
*3:OR ではこの種類のことを問題クラスと呼びます．
*4:幅広い問題クラスの中から一番業務に即したものを選び出すのは難しい作業となりますが，予めパッケージで対応可能な問題をメニューに記載されたものに限定してしまうことでこの問題クラスの特定作業を簡略化します．
*5:完全に知識が不要となるわけではないですが，少なくとも数式に直接触れる必要は無くなります．
*6:バイトなどのシフトスケジューリングとは種類が異なる問題である点にご注意ください
*7:細かい問題設定の違いに応じて job-shop スケジューリングや flow-shop スケジューリングなどと呼ばれます．
