数理最適化システムベンダーは筋が悪い？ ~ 『ドメイン駆動設計をはじめよう』を読んで

はじめに

自分はITベンダーでしがない数理最適化エンジニアをやっています。仕事についてざっくり説明すると、ユーザー企業から受託開発という形で数理最適化を活用したシステムの設計・開発をしています。私の所属するチーム自体が数理最適化を専門として仕事をしているのですが、なかなかチームの全員が最適化の案件に携われているわけではなく。なんとなく、「最適化の仕事って生まれにくいなあ」と感じていました。

そんなときに、『ドメイン駆動設計をはじめよう』を読みました。当初はドメイン駆動を学ぶために読み始めたのですが、その中で上記の「なんとなく仕事が生まれない」原因について、こういうことかなという推測ができたので、文章化したいと思います。

本記事内での用語

数理最適化システム
数理最適化¹技術を用いたシステム。システム全体の中の一部のみに数理最適化が用いられている場合、その一部分のみを「数理最適化システム」と呼ぶことにする

ベンダー
システム開発を請け負う会社のこと。本記事では特に、数理最適化システムの開発を得意とする会社を指す。

ユーザー企業
何かしらの事業でお金を稼いでいる会社のこと。ベンダーにシステム開発を委託する。

数理最適化エンジニア
数理最適化システムの開発・設計（・保守）をする人。

数理最適化コンサルタント
数理最適化システムをユーザー企業へ導入する際に、一緒になって考えてくれる人。大体の場合はこの人が最適化モデリングを担当する。数理最適化エンジニアと兼ねている場合が多い。

要約

• 『ドメイン駆動設計をはじめよう』によれば、数理最適化システムのような複雑な業務に関するソフトウェア開発は内製化すべき
• 数理最適化システムは企業固有の複雑な業務をモデル化している
• おまけに数理最適化システムはお金になりにくい
• 内製化すべきもの、お金になりにくいものをベンダーが売りにするのは筋が悪くないか？

『ドメイン駆動設計を始めよう』とは

この本は、ドメイン駆動設計の考え方とやり方を、著者の豊かなソフトウェア開発経験をもとに、具体的かつ体系的に説明しています。
『ドメイン駆動設計をはじめよう』訳者まえがきより

エリック エヴァンスが提唱したドメイン駆動設計に関する基本的な考え方と、技術的な実現方法、加えてアーキテクチャに関するトレンドと具体例に関して非常によくまとまった一冊です。訳者の方によるまとめスライドも公開されています。
https://speakerdeck.com/masuda220/learning-domain-driven-design-japanese-edition-findy-2024-7

この中で、本記事において重要な部分は 1章です（技術的な話には全く踏み込みません）。簡単にまとめると、

• 企業²は何かしらの事業領域で事業活動を展開し、お金を稼いでいる
• 事業領域を細分化したものが業務領域。企業は事業目標を達成するために、各業務領域で業務活動を行う
• 業務領域は大きく3つのカテゴリーに分類できる
  • 中核の業務領域：競合他社との違い（競争優位）を生み出す。この業務領域で企業はお金を稼ぐ。競合他社が簡単にはまねできない独自の仕組みとなるため、非常に複雑であり、頻繁に変更される
  • 一般の業務領域：どの企業も同じやり方をする。中核同様非常に複雑だが、（どの企業も同じやり方なので）パッケージ製品やクラウドサービスが利用可能。そのため競争優位性を生み出さない
  • 補完的な業務領域：事業活動を支える。中核とは異なり、競争優位を生み出さないし、業務ロジックは単純（CRUD機能程度）
• 例えば、Uber社のライドシェアサービスを事業領域としてとらえるとする³
  • 中核の業務領域：今までになかった独自の移動方法（ライドシェアサービス）、低コストで移動できるためのアルゴリズム（同じ方向に移動したい利用者を1台の車に相乗りさせるなど）、使いやすいモバイルアプリ
  • ⁴一般の業務領域：最短距離を算出するための地図情報サービス
  • 補完の業務領域：アプリに掲載する広告データの取得、上記の地図情報の取得
• 中核の業務領域の開発を外部委託するのは、賢い選択ではない。中核は頻繁に変更されるため、自社でもっとも有能な技術者を中核の業務領域のソフトウェア開発に振り向けて、修正・拡張をすばやくできるようにするべき。⁵外部委託すると変更が容易でなくなる

本論

この記事で最終的に伝えたいのは1つで、「ベンダーが数理最適化システムの開発を売りにするのは筋が悪くないか？」です。以下、なぜそのように思うのか考察していきます。

数理最適化システム≒中核の業務領域

様々なところで言われていますが、「業務を最適化モデルとして落とし込んで、システム化して意思決定を自動化する」というのを実現するのは大変です。なぜなら⁶

• 会社独自の複雑な業務をモデル化する必要がある
  • ほとんどの企業ではその企業にあったやり方をしており、既存のアルゴリズムで解決できることはない
• 頻繁にモデルが変わる
  • 業務の担当者はすべてを言語化できるわけではない。業務担当者にとっては当たり前すぎて、口にしないし、普段の業務でも無意識で守っている制約がある。そのため、ヒアリングをもとにした最適化モデルによる最適解を担当者に見せても「何か違う」と言われる
  • また、法規制、会社のKPIが変わったなどで最適化モデルが変わることもあります

というので、会社独自の複雑な業務を、素早く変更できるような形で実装する必要があります。

やっていることはどの会社も同じ業務というのもありますが、大多数の場合、会社独自のロジックが複雑さを増加させます。例えば、輸送・配送計画は「ある物資をどこからどこへいつどの車両で送るか」を決める計画です。物流が絡む企業であればどこも同じようにやっていることでしょう（小売店、コンビニに始まり、製造業でもどこの倉庫へいつ送るか、というのは決めていると思います）。そういった業務は「輸送・配送計画最適化パッケージ」が使える、いわゆる「一般の業務領域」になりえますが、大体の企業は「うちはただ車両数を減らすだけじゃなくて、AもBも考えないといけない」といったように、その会社独自のロジックが入ってくるかと思います。こういった場合、ただパッケージを導入するだけでなく、オーダーメイドの機能追加が必要になります。

このような「企業独自の複雑な業務」、もしくは「他の企業でも似たようなことをやっているけど、その企業独自のロジックが入った業務」の自動化に成功すれば、他社にはない強み=競争優位になります。

ということで、数理最適化システムは、自社固有の複雑な業務を最適化モデルに落とし込んで、頻繁な変更が必要で、他社との競争優位を生むものとなります。どこかで聞いた話ですね。そうです、『ドメイン駆動設計をはじめよう』的に言えば、最適化システムは中核の業務領域であるといえます。

最適化システムは目に見えるお金になりにくい

別の観点からの話になりますが、最適化システムというのは目に見えるお金になりにくい、という課題を抱えています。

えてして数理最適化システムというのは、コストカットは実現するものの、それ単体でお金を生み出すわけではないです。例として、何かしらの計画業務（配送計画、人員配置計画など）を最適化する状況を考えましょう。数理最適化を用いれば人間よりも効率的な（車両数が少ないなどの意味で）計画が作成できると思いますが、案外人間は頭がいいので、人手で作成した計画でも十分最適化されているのです⁷。じゃあ数理最適化システムは何を実現するのかというと、その「人手で作成した計画」を作成する過程で必要になる膨大な数の組み合わせの検証を、短時間で、自動でやってくれるわけです。なので、「最適化によって、さらにお金を稼げる計画にできます」ではなく、「最適化によって人手による負担を減らせます」になるのですね。

では「お金になりにくいこと」の何が問題かというと、ユーザー企業としての投資価値がないことです。上記の複雑な計画業務において、「最適化によって計画作成時間を削減しました！」となっても、それでいくら儲かったのかは数値として表れてきません。計画担当者によるサービス残業でこなしていたのなら、残業はなくなるかもしれないですが、ユーザー企業としては1円も儲からないような状況です。そんなことには投資できませんよね。

ベンダーが数理最適化システム開発を売りにするのは筋が悪い

• 数理最適化システムは中核の業務領域に属し、頻繁に変更される
• 数理最適化システムは目に見えるお金になりにくい

という話をしてきました。このことから、ベンダーが数理最適化システム開発を売りにするのは儲かるビジネスではない、筋が悪いと私は思います。

ベンダーは変更対応を増やすと利益が減るのですが、中核の業務領域は頻繁な変更に迅速に対応できないと競争優位性を生み出しませんから、中核の業務領域におけるシステム開発はベンダーとしてのインセンティブに反しています。ユーザー企業からみて、ベンダーが「弊社は（頻繁に変更が必要な）数理最適化システム開発が売りですが、自社の利益のために変更対応はいたしません」なんてのたまっていたら、契約したいと思いませんよね。なのでベンダーとしては、数理最適化システムを売りにするなら、自社のインセンティブに反して、少なくない変更に対応しないといけないわけです。

また、ユーザー企業にとってお金になりにくいというのは、ベンダーにとってもお金になりにくいということです。お金になりにくいことより目に見えてお金になる、儲かる方へシフトするのが（資本主義形態の）あるべき姿ですので、お金になりにくいこと（≒数理最適化システムの開発）にかけられる金額は小さくなります。しかしベンダーからすれば、数理最適化という高度な技術を用いていることもあり、安い額で開発を請け負いたくありません。

総じて、ベンダーが数理最適化システム開発を売りにすると、金額感の違いから契約を勝ち取るのが難しいし、契約できたとしても自社のインセンティブに反したやり方をせざるを得ないというところで、ビジネスとして筋が悪いのではないか、ということですね。

終わりに

結論

本記事で、ベンダーが数理最適化システムの開発を売りにするのは筋が悪くないか？ という疑問を投げかけました。『ドメイン駆動設計をはじめよう』が掲げるアーキテクチャの理想像からすると、ユーザー企業は自社の最適化を内製化すべきであり、そこに「数理最適化のプロ集団」であるベンダーは不要なのだと捉えました。私自身ベンダーに所属しているので耳が痛い話ではあるのですが。

個人的な感覚として、「数理最適化」という1分野を売りにしている人であれば、特定のユーザー企業に勤めている人は少なくて、「数理最適化のプロ集団」とうたうベンダーに集まっていると思います。数理最適化コンサルタント・エンジニアの方、特にベンダーで働いている方はどのように思われますか？ という問いかけで本記事を締めたいと思います。
ご一読いただきありがとうございました。

余談

なぜ数理最適化ベンダーは筋が悪いのに食っていけているのか？

ひとえに、ユーザー企業が適切なスキルを持った数理最適化コンサルタント・エンジニアを、適切な報酬で雇うのが難しいからだと思います。

前述のように数理最適化が目に見えるお金になりにくい技術であるので、ユーザー企業として報酬を決めづらく、専門のポストも用意しづらいと思います。数理最適化をやりたい人・得意な人としては、必ず「数理最適化」に携われるわけではなく、また報酬も不安定なユーザー企業に入るよりも、「数理最適化」を専門にしているベンダーに入るのは必然かと思います。

また、数理最適化システム開発・設計には高度なスキルを必要とします。「混合整数線形計画問題(MIP)⁸をモデリングする」だけなら正直中学校の数学ができれば可能だと思いますが、それを実業務やシステム上の制限⁹を満たしたうえで実業務に活かせる形にする、というのは数理最適化システムの設計・開発という業務に数年携わらないとわからない感覚だと思います。

というので、ユーザー企業に数理最適化システム開発を主導できる人員がいないので、外注せざるを得ず、結果ベンダーが食っていけているのだと思います。そのベンダーも、数理最適化だけやっているわけではなくて、むしろ他のデータサイエンス的な仕事（機械学習とか）が主な収入源なのかもしれないですが...

そもそも内製化したほうがいいなんてのは数理最適化システムに限った話ではなくない？

おっしゃる通りで、ベンダー（というか請負・委任・準委任契約）は撲滅すべきという論調はそこかしこに蔓延っており、数理最適化という一分野に限った話ではないと思います。とはいえ、他の分野と比べても輪をかけて筋の悪いビジネスなのかなと思い、本記事を執筆するに至りました。

この記事の執筆者は数理最適化ベンダーに中指突き立てたいの？

決して違います。私の願いは、ユーザー企業が数理最適化を内製化することです。ユーザー企業が数理最適化コンサルタント・エンジニアに対して適切なポストを用意するのは難しいと思いますが、本記事で述べたように（というか『ドメイン駆動設計をはじめよう』で述べられているように）、内製化は競争優位の源泉につながります。ぜひ内製化してください。そして私をベンダーから引き抜いてください。

1. 数理最適化 Advent Calendarの記事ということもあり、数理最適化とは何ぞや、というのをご存じの方が本記事を読んでいると想定するため、「数理最適化」という単語は既知のものとします ↩

2. 本記事内では「ユーザー企業」 ↩

3. 『ドメイン駆動設計をはじめよう』でも述べられていますが、Uber社はライドシェアのほかに、料理の配達サービスや自転車のシェアリングサービスも事業領域となります ↩

4. 一般、補完の業務領域に関しては『ドメイン駆動設計をはじめよう』では述べられていません。私のイメージで補完しています ↩

5. 最後の一文は私の解釈です。本の中では中核を外部委託することに関して、以下のように述べられています。
   「中核の業務領域を外部委託するのは短期的に見て危険です。長期的には会社の存続にかかわる問題を引き起こします。たとえば、変更がやっかいで危険なコードベースでは、事業目標の達成を支援できません」
   上記以外に、契約のためのリードタイムだなんだでソフトウェア開発以外のところに時間を取られ、修正・拡張をすばやくできない、ということから「外部委託すると変更が容易でなくなる」と記述しました。 ↩

6. あくまで最適化のモデリング関連に絞った話です。他にも「データがそろっていて利用できる状況であるか」「予測値が必要な場合、ブレを許容して平均を利用するのか、ブレも考慮して分布の情報をモデルに組み込むか」「ソルバーは十分なパフォーマンスを出せるか」といったことも考慮する必要がありますが、記事の本筋から外れるので省略しました ↩

7. 尊敬する上司の受け売りです ↩

8. 実務で一番よくあらわれる、最適化問題の一種 ↩

9. 「制約」と記述すると「最適化問題の制約条件」と混同するため、「制限」と記述しました ↩