「あの人がいなくなったら仕事が回らない」を解決　属人的な業務から脱却する「最適化」の実践方法 [2/2]

最適化の種は「あの人がいなくなったら仕事が回らない」

梅田：まずは最初の話ですが、プロジェクトのライフサイクルに沿ってお話をしていきたいなと思っています。たぶんどんな人たちもまず、「最適化の種を見つける」というポイントにぶつかるかなと思っています。

我々受託企業としては当然ネタを見つけるというか、営業していって会社とプロジェクトを作るところからスタートします。さっき言った事業会社の例においても、何かミッションとして「会社のどこかとそういうプロジェクトをやって」と雑に振られて、仕事を探すのはよくやることなのかなと思っています。

我々にとっては特にこれが死活問題なので、けっこう本気で「どこかに最適化のネタがないかな」と常に考えています。いろいろな切り口があると思うのですが、1つは「人によって差が出る業務がないですか？」という切り口で探すことが多いですね。

仕事をしているんだけど、すごくベテランの方と、初期でアサインされた新人の方でパフォーマンスの差がある仕事は、けっこう最適化のネタとして通ずるところがあるのかなと思っています。

例えば属人化した業務で、現場で特定の仕事を長年ずっとやっていて、「あの人がいなくなったら仕事が回らない」というシチュエーションはけっこうあると思うんですよね。

「この人がいなくなったらどうしよう」とか、新人が育っていなくて「この人が消えたらこの業務、消えるかもしれない」みたいな。そういうことはわりと、若手がいなくなっているという今の日本の社会現象みたいなものにも即していて、よくあるシチュエーションかなと思っています。

人によってパフォーマンスがばらつく仕事に着目

梅田：これに付随しているのですが、解読不能なExcelが現場に散らばっていることもわりとあったりします。

マクロが裏で張り巡らされていて、どうやって動いているのか、誰がどうメンテナンスしたらいいのかわからないんだけど、何かデータを入れたら答えが出てくるみたいなやつ。こういうところもわりと最適化の仕方があるところかなと思っています。

3つ目がさっき言った、パフォーマンスがばらつくというところですね。これも我々の中では、そういうものを見たら最適化のネタとしてありかなと思ったりします。

下に書いてあるのですが、人によって差が出るというのは、効率的な方法と非効率な方法がある。そして、効率的な方法がある業務には、良いアルゴリズムが存在するということだと思うんですよね。ということは、そのアルゴリズムを最適化する機会もある。最適化のプロジェクトのネタ（を探す）となると、そんな感じでけっこう思ったりはしています。

顧客の業務を理解するためのノウハウ

梅田：晴れてなんとなく最適化のネタが見つかりそうとなった時。いざお客さまに売りに行くとか、社内で説得をする時に、業務を理解するフェーズは間違いなくやってくると思っています。

ここが一番大事と言っても過言ではない気はします。最初に言ったとおり業務を完璧にわかっている状況からスタートすることはまれなので、みなさんもこのフェーズを絶対通過するかなと思っています。

いろいろな方法があると思うのですが、まずできるんだったら、詳しい人に聞いちゃうのが一番いいなと思っています。エキスパートインタビューですができたら一番いいですね。このエキスパートインタビューも「そりゃそうでしょ」って感じだと思うのですが、本当に人脈をたどってたどって、けっこう大胆にいろいろやっていきます。

例えば私だったら毎回新しい業界に入るたびに、過去の友人や学生の時の伝手やメーリングリスト、指導教官、大学のほうをたどっていったり。とにかく人脈をフルで活用して、その業界に詳しそうな人を徹底的に探します。

これを本当に真剣にやっていて、なんとなく感覚として「この業界のドンに会いたいな」と思った時に、その人が日本人であれば、2～3人たどっていったら確実に出会えるという感覚を持っています。なので、そこまでけっこう徹底してやります。

政治家とかは厳しいのですが、そうでない限りはわりと「この人にこの話を聞きたい」と思ったら、なんとかしてがんばったらたどり着ける気がしています。

より深い業務理解のためには「業務体験」までやらせてもらう

梅田：2つ目が論文や文献を調査するところで、これはみなさんたぶん最初にやることかもしれないです。ネットで探したり、最近だったらChatGPTやGeminiの、Deep Researchをかけるのかなと思っています。

これもけっこう大事で、私も最初に業界に入って勉強をするとなったら、まず本屋に行って、本を数冊バーっと買ってきて読んで、学術的なレポートや論文、コンサルとかの資料を読んでいく。その参考文献をまた探していく感じで、どんどん本を読んでいきます。

最近だと、たどっていくとけっこう昔の文献や本に出会うことがあって、年に何回か国会図書館に行くんですよね。そこまでたどり着いて、絶版になっているけどめちゃめちゃ良い本みたいなやつを探しに行ったりして、そこで本を読んで、複写して持って帰ってくるということをしています。

3つ目が業務体験で、これは次のフェーズとして執り行われることが多いと思うのですが、もう実際に業務をやらせてもらう。もしくは隣に座らせてもらって、じっとその作業を常に追わせていただきます。

これができるとかなり深く「この人、ここにこれだけの時間をかけて作業をやってるんだ」「このぐらいの人数をかけてるんだ」「こっちは紙でやって、こっちはデータとして残ってるんだ」とか、いろいろわかってきます。

あとは人とも仲良くなれるので、ここまではやりたいですね。業務体験までやって、私たちは業務の理解に努めていきます。

ソルバーを使い「聞いたそばからモデリング」を繰り返す

梅田：業務が理解できて、晴れてプロジェクトっぽくなってきたら、いよいよインタビューをして、効率的に要件を引き出していくフェーズに入っていきます。流れとしては、まず「どういう課題感ですか？」「どういう条件で何を解く必要がありますか？」という話を、初期ヒアリングというかたちでしていきます。

次のステップでGurobiさまも登場するのですが、私たちはGurobiを使って要件定義を同時にどんどんやっていきます。聞いたそばからモデリングしていき、来週にはその結果を出すというのをどんどん繰り返していく感じです。

お客さまにその結果を提出すると、何かしら「ちょっと違うんだよね」と言われるんですよね。「これだと現場が使えないんだよね」とか「現場がきついんだよね」と言われます。

でも、こちらとしては聞いた要件に沿って、そのルールの範囲内で最適化しているんだから「何がおかしいんですか？」って感じになって、話していくと「あぁごめん、言うの忘れたけど、こういうのがあったんだよね」という制約条件が出てきます。

これは本当であれば最初のヒアリングでもちろん出してほしいところではあるのですが、「制約条件や業務のルールはありますか」と聞いて、完璧に網羅的なかたちでリストで提出してもらうことは不可能なので。

そういうものを出しやすくするために我々は、ソルバーでパパッと結果を出してモデル化する。そして、お見せすることに努めています。これをできるだけ速く、何サイクルも回すのが、お客さまの要件を引き出す時に最も大事なことかなと思っています。

「イチからアルゴリズムを作る」だと要件定義においては開発速度が不十分

梅田：ここであえてソルバーを使っている理由ですが、「イチからアルゴリズム作ったらええやん」という人もいるかもしれないですけど、その速度感はやはりイチからアルゴリズムを作っていると出ないと思っています。

要件を聞いて、来週モデルを出してくる。「ごめん、ちょっと要件変わったわ」「新しいのを追加して」というのに対応していくのは、ソルバーであればこそできることだと思うんですよね。イチからアルゴリズムを作っていればたぶん、手のひら返しでイチからもう1回作らないといけない瞬間もあると思うので。

それだけソルバーの整数計画法による定式化は表現力が高いものなのかなと思っているので、要件定義の序盤の段階では本当に大活躍すると思います。

続いてプロジェクトインタビューをしていって、結果をお見せしてというふうに話を進めていくと、その中でやはり「ちょっと伝わりづらいな」という瞬間が出てくるんですよね。

パワポを見せるより、AIでアプリを作って見てもらう

梅田：最近気にしているのは動くものを見せるというところで、「UI/UXを具体化させることで議論を加速する」って書いているんですけど、そういうことをやっていきます。

なので、私たちはパワポをあまり使わなくなりました。お見せする時はアプリを作って、モック版を持って行ってお見せすることを徹底しています。

これは「もちろんアプリができたらうれしいでしょ。そりゃやるよ。でも時間かかるじゃん」という話は今までずっとあったと思うのですが、生成AIの登場によって、それはもうぜんぜんハードルにならなくなってきたという印象です。

私も生成AIはプロジェクトを進める時にかなり使っています。自分のやり方で言うとまず数式だけは自分で書くのですが、その数式のかたちでプロンプトを生成AIに投げると、Gurobiのコードはかなり良い感じで書いてくれるんですよね。そのコードを私のほうで直すというのを対話的にやっていく。

そのあと出来上がってきたGurobiのコードを「アプリにしてください」という感じで、ちょっとした設計と一緒に投げます。そうすると下手な日本語で「こういうアプリを作って」と言うよりも、コードを整数計画法の定式化のまま投げているので、ちゃんとした要件が向こうに伝わって、良いアプリができてくる感覚があるんですね。

それもうまくやれば、ものの10分とかで出来上がるんですよね。なのでアプリを作ってお客さまに見せるというのが、ぜんぜん苦ではない感じになっています。パワポってけっこう作りづらいんですよね。できればみなさんも、人を説得する時はもうパワポ資料はやめて、アプリでお見せできたらいいかなと思っています。

ちなみに今回の私のこの発表資料は、全部生成AIで作っているものですが、わりとアプリを作るよりも修正に時間かかっていて、やはりパワポと生成AIってけっこう相性が悪いかなと思ったりはしています。

でも、この今発表しているプレゼン自体もたぶん1時間半ぐらいでバーっと作ってくれたので、そういった意味ではだいぶ使いやすくなっていて、業務効率化という意味ですごく役立っています。