「計画と運用」をごちゃ混ぜにすると崩壊する　ビジネスに使える最適化システムの“境界線”の引き方 [1/2]

唯一の最適解は目指さず、「それなりの解」で十分

梅田龍介氏（以下、梅田）：プロジェクトがけっこう煮詰まってくると「これどうする？」という空気になってきて、よく終わりが見えないシチュエーションになるのですが、大事だなと思っていることが1つあります。「最適解は目指さない」ことがものすごく大事だなと思っています。

「最適化で最適解を目指さないってどういうこと？」となると思うのですが、唯一の大域的最適解みたいな「この1点が本当に一番良い解です」という解を探そうとするな、というのが私がプロジェクトで言いたいことです。

これをやろうとすると途端に効率が悪くなっていくんですよね。最後のラストワンマイルの調整に時間をかけるみたいなところです。私のイメージで言うと、解の精度が良くなればなるほど、そこから先の時間はタイパが見合っていない気がしていて。

例えば登山をけっこうするのですが、5合目から6合目はさっと行けるのに、同じ1合でも9合目から10合目はむちゃくちゃ時間がかかって、進んでいる気がしないみたいな。プロジェクトの時も、そんな状況になるんですよね。

得てしてその最後の1合は、いらない努力のような気がしているんです。なぜかというと、例えば計画を作る時に最適化ってよく登場すると思うのですが、インプットとして、何かしらの将来の想定を与えると思うんですよ。

さっきの電力会社さんの例で言うと、需要予測みたいなものをインプットに入れて問題を解くのですが、その需要予測って「どんな精度で入れてるの？」という話になるんですよね。

「来年の計画を最適化します」ということのために、ほかにもいろいろな予測値を入れていくのですが、インプットの精度が大して高くないというか、当たるかわからないものを入れているのに、こっち（最適解）の精度を0.01パーセント上げようとするな、とすごく思っています。

であれば、それなりの解で計算をバッと切っちゃって、さっき言ったようにインプットが不安定で揺れるんだったら、そっちのパターンを増やしてあげる。需要が高い時、低い時、真ん中みたいな感じで、3回計算を回して、「計算結果が3つ出たほうがいいんじゃないの？」とすごく思っていて、実際実用上もそのほうがよく回ることが多いです。

なので、最適解を目指すのはたいてい割に合わない努力というか、時間を投資している感じになります。

最適化システムをうまく作る時は、そんな感じでそれなりに良い解、「これがあったら今までの人の業務をそれなりに代替できるな」というところまで出したら「最後はもう人が調整しましょう」という役割分担をしたほうがいいかなと思っています。

最適化プロジェクトを考える時になかなか気づかないこと

梅田：続いて、プログラムを設計する時に「将来の拡張性を見越した汎用的なプログラムを設計したほうがいい」という話です。これはプログラムの設計の話なので、少し込み入ってくるんですけど。

これも書いていることはわりと当たり前だと思うんですよね。「それができたらいいよね」という。ですが、こと最適化のプロジェクトにおいてはかなり難しくて経験を要することだなと思っています。

例えば何かしらの巨大なシステムをSIerとして納めます。基本設計書、詳細設計書がしっかりある段階だと、「将来こういう拡張をして……」というところまで、なんとなくみんながイメージを持ったままプロジェクトを進められると思うんですけど。

最適化においては、それは普通なかなか気づかないというか。注意しないと頭の中から抜けていっちゃうというか、気づかないことがたくさんあると思うんですよね。

「なんか怪しそうだな」は後でとんでもないことになりがち

梅田：例えば、少し前に「社員のリソースマネジメントを最適化したいです」というプロジェクトの依頼がありました。やっていることは社員の最小化問題を解くような感じで、少ない人数で回すためにシフトを効率的に解くプロジェクトだったのですが。

よくよく聞いていくと、実は業務は社員以外にもパートナーさんというか委託先、外注先がいる。外注のエンジニアみたいな人がいたりして、自分たちの社員と外注先で組んでチームを作っています、といった話がけっこうあるんですよね。

でも、スコープは自社の社員のマネジメントなので、外部の外注先は「今回考えなくていいです」と、お客さまは言ってくると。制約条件なども、自社の社員に関わる社内の労働基準法のようなところだけ説明してきて、外注先の人間のマネジメントについては、一向に話してこないようなことがあるんですよね。

これってけっこう怪しいサインで、たぶんプロジェクトを進めていくと「やっぱり外注先も一緒にまとめて考えないと、この問題は社員に関しても解けないじゃん」というふうになる気がするんですよね。

経験を重ねてくると「どうせ後で制約条件が増えるんだろうな」と分かってきます。「先方はいらない」と言っているのですが、たぶんそうなりそうだなと思って「制約条件や登場人物が拡大していくな」と思いながらプログラムを設計することが、ものすごく大事だと思っています。

こういうサインは、ほかに登場人物がいるというのもそうですし、モノでもいいんですよね。ほかにも登場しているモノがあったりする時は、絶対何か業務の中に巻き込まれているから、一緒に考えないといけない。いずれ将来プログラムを拡張しないといけなくなっちゃうと。

ここをお客さまの言ったとおり、社員のことだけを考えて固定してプログラムを書いていると、後でとんでもないことになるというか。「そっちもやるんですか？」みたいな感じで、もう拡張できないからイチから書かないといけなくなったりすることがあるんですよね。

なので、ここはすごく大事だなと思っています。「なんか怪しそうだな」というのはなんとなくわかってくると思うので、常に拡張する余地がないか。「ほかの人も巻き込みそうだな」「ほかの制約条件が増えそうだな」というのは、常に考えながらやったほうがいいかなと思っています。

人が考えた計画に負けるのは、比較条件が違うから

梅田：プロジェクトも終盤に差しかかってくると、じゃあいよいよ精度の話になってくるんですよね。今、現場で実際に計画を立てている人と、自分たちの作ってきた最適化システムで比べてみようと。「どっちがいい計画を作れるの？」みたいなことをやることがあります。

場合によっては、「いや、現場で人が考えてる計画のほうが精度が良いじゃん」となることがけっこうな頻度である気がします。その中で、ほとんどのケースにおいて同条件で比較されていないというのが私の経験知です。
どういうことかというと、最適化のシステムのほうはガチガチにルールを守っているんですよね。でも現場の運用は、作ってくれた計画をよくよく見ると「ちょっと破ってるじゃん」というものがわりとあるんですよ。

しかもこれは気づきづらかったりするので、最初はなんで負けているのかがわからないのですが、よくよく見てみるとそういうことがあるんですよね。

例えば、トラックの輸送計画の時にあった話です。法律でトラックの積載量が決まっていて、仮に1トンとします。1トン以上載せたらバツ、みたいな感じですね。

社内ルールとして、80パーセントまで載せていいと推奨しているとします。800キロまでは載せていいようにしているから、計画を作る段階では800キロを制約条件としてプログラムを書いてくれと言われる。

了解しましたと作っていく。結果、現場の運用と比較して「負けてるな」と思った時に見てみると、現場の運用で802キロとか積んでいることがあるんですよね。「2キロオーバーしてますよね」となるんですが、話を聞くと「社内ルールだから場合によっては破ってもいいんだよ」と言われたりするんですよね。そうすると同条件の比較じゃなくなっちゃうので、それは勝てないでしょとなる。これは本当によくある話です。

今のはけっこうわかりやすいのですが、ぱっと見ではよくわからなくて、2つの条件にまたがってズルしていることもけっこうあるんですよね（笑）。なので、比較して「負けてるな」と思う時は、ここをすごく疑ったほうがいいかなと思っています。

最適化モデル側に現場の運用の緩さを取り込んで「この制約条件はちょっと破っていいでしょ」というふうに寄せるか、現場の方々にちゃんとルールを守った上で計画を立ててもらう。どっちかに寄せたほうがいいですね。

そうしないとまともに比較できないので、「精度で負けてますね。このプロジェクト、やる意味あったんですか？」となってしまうことがけっこうあります。

年間計画と当日運用はまったくの別物

梅田：次は「計画と運用をごっちゃにしない」という話で、これもけっこうよくあるんですね。「計画」って何かと言うと、将来の物事について立てるのが計画で、ここで言う「運用」は、現時点での運用、オペレーションについて話しています。

例えば年間計画では来年の話をするのですが、運用はまさに今起きているところ。トラックの運転だったら「渋滞が今起きています」みたいな話ですね。

今の自分たちはプロジェクトのスコープでどっちを対象にしているのかというのは、常に意識したほうがいいと思っています。この議論をごっちゃにすると、訳のわからないことが起きます。

例として発電計画というものが書いてあるのですが、例えば年間の計画だった場合は、「来年はこういう感じでなんとなく発電機が動きそうだから、燃料はこのくらい必要だよね」という、燃料の調達の量を把握することが目的です。

でも、当日の運用計画の目的はまったく違って、「いかにして電気をちゃんと届けるか」というところじゃないですかね。なので、計画と運用は同じようなロジックで動いていると思いきや、実はぜんぜん大事にしているものも違うし、KPIも違うというのがよくある話なんですね。

イメージしてもらうとわかると思います。年間で計画を立てている部門の人を、当日の現場に放り込んだ時に仕事ができるのかというと、まぁできない。それはつまり、同じロジックで動いていないんですよね。

でも、プロジェクトをやっていると、例えば（お客さまは）年間計画のプロジェクトを当日にも使いたいと思っていて、当日運用の制約条件を説明されるようなことがけっこうあるんですよね。

でもそれはぜんぜん違うものだから、「そういう欲はかかないでください」ということで、「一緒にはできません。別のプロジェクトでやりましょう」となると思います。これができるとしたら、さっき言ったように人を交換しても仕事が回るような状態になっていないと、最適化システムも無理かなと思っています。

これが本当に煮詰まってくるとごちゃごちゃになってきて、年間計画の話をしているのに「現場はそんなに予想どおり動かないんだよ」と、よく言われたりもします。でも「それは話が違っていて、年間計画では平均的な状況を想定しているんですよね？」となるので、すごく大事なポイントかなと思っています。

けっこう意識して頭を切り替えていかないと、「今は何の話をしているんだっけ？」とごちゃごちゃになっちゃうことがよくあるかなと思っています。