開発会社の技術者がshiftect.の説明を受けたとき、頭の中で何が起きているのかを考える必要がある。
技術者は案件を受け取る際、まず分類する。
Webアプリケーション、データ基盤、機械学習、数理最適化。
この分類が決まれば、必要な技術スタック・工数・体制の見当がつく。
見当がつくから見積もりができる。
分類できなければ、見積もりができない。
「数理的処理」「スケジューリング最適化」という言葉が出た瞬間、技術者の分類は数理最適化に向かう。
数理最適化はソルバーの領域だ。
ソルバーを使う案件は、どのソルバーを使うか、制約をどう定式化するかという研究的な判断が必要になる。
研究的な判断が必要な案件は工数が読めない。
工数が読めなければ請負契約ではなくタイム＆マテリアルになる。
この判断のプロセスは技術者として合理的だ。
問題は、shiftect.が解こうとしているのが数理最適化の問題ではないという点だ。
最適化エンジンそのものを開発するわけではなく、業務の状態に応じて最適化処理への入力構成を自動的に切り替える制御の構造を実装することが核心だ。
どの条件を探索対象とし、どの条件を固定対象とするかをシステムが状態情報に基づいて自動的に決定する。
この区別が、「数理的処理」という言葉の時点で消えてしまっていた。
制御の問題を最適化の問題として処理された結果、詳細な設計資料が揃っているにもかかわらず、見積もり不能な研究案件として扱われ続けた。