00:00:00 スケジュールの複雑性の紹介
00:02:30 航空宇宙における相互依存性とサービスレベルの課題
00:06:14 部品表とリソースについての議論
00:13:15 日々のスケジュール管理の課題と人間の限界
00:20:45 効率的なスケジュール管理のためのアルゴリズムの紹介
00:28:30 航空宇宙における緊急対策とAOG価格設定
00:36:02 スケジュール影響に関する数学的視点
00:43:47 タスクスケジューリングにおける複雑性と制約
00:50:17 スケジュール最適化のための計算能力の活用
00:57:39 MROにおけるFIFOの限界の批判
01:04:15 サプライチェーンにおける意思決定と自動化
要約
最近のインタビューで、LokadのコミュニケーションディレクターであるConor DohertyとCOOであるSimon Schalitは、航空宇宙分野、特に航空機製造およびMRO業務におけるスケジュール最適化でのLokadの画期的な成果について議論しました。彼らは、伝統的な手法では管理が困難な、数多くの相互依存する部品、技能、装置を調整する複雑さを浮き彫りにしました。Lokadのアプローチは、Bill of Materials (BOM) からリソース表（BOR）へとシフトし、必要なすべてのリソースとその変動性を考慮します。計算アルゴリズムを活用することで、Lokadは迅速に実用的な解決策を生成し、財務リスクとダウンタイムを最小限に抑えます。この自動化と人間の戦略的洞察の統合は、複雑な環境における効率的かつ効果的なスケジュール管理に不可欠です。
詳細な要約
Lokadでの最近のインタビューで、コミュニケーションディレクターのConor Dohertyは、COO兼サプライチェーンサイエンス責任者であるSimon Schalitと共に、特に航空宇宙分野におけるスケジュール最適化の複雑さを掘り下げました。この会話は、航空機製造や整備・修理・オーバーホール（MRO）業務に多大な影響を及ぼす、Lokadがこの分野で達成した重要なブレークスルーを浮き彫りにしました。
Conorは、製造および修理業界におけるスケジュール管理の複雑な性質を強調しながら、話の幕を開けました。彼は、予測不可能に変動する多数の部品、工具、人材の広大なネットワークを管理することがいかに困難であるかを指摘しました。その後、Simon Schalitは、航空工学の例を用いてこの複雑さを詳述し、航空機エンジンのような精密な装置の製造や修理には、数多くの部品、技能、装置の調整が必要であると述べました。彼は、他のサプライチェーンセグメントでは意思決定が独立して行われることが多いのに対し、MROや製造業、特に航空分野では、すべての要素が相互に依存していると強調しました。百の部品のうちわずか一つが欠けるだけで、全体のプロセスが停止し、残りの99の部品が無意味になってしまう可能性があると指摘しました。
Simonは、この相互依存性により、従来の部品表（BOM）の視点から、より包括的なリソース表（BOR）への移行が必要であると説明しました。BOMがタスクに必要な部品のリストを示すのに対し、BORは部品、技能、装置といったすべての必要なリソースを含みます。この全体的な視点は、各リソースの利用可能性と変動性を考慮するために極めて重要です。例えば、部品はリードタイムの変動の影響を受ける可能性があり、技能は人材の利用可能性に依存し、装置は使用中または修理中であることがあります。
ConorとSimonは、このアプローチの実際的な影響について議論しました。従来のMRO環境では、毎日の計画は部品や人材の利用可能性に基づき手動でスケジュールを調整することが多く、この方法は一般的であるものの、複雑で相互依存する変数を扱う際の人間の限界から非効率でエラーが発生しやすいという問題があります。Simonは、スケジュールのわずかな変更でも連鎖的に予測不可能な結果を引き起こし、最適な計画の実現が困難になることを強調しました。
その後、会話はこれらの課題に対処するための計算アルゴリズムの役割へと移りました。Simonは、Lokadのアルゴリズムがすべてのリソースの現状を考慮して十分に良い解決策を迅速に生成できると説明しました。この能力は、ダウンタイムの一分一秒が極めて高価である航空業界にとって極めて重要です。アルゴリズムの強みは、さまざまな「もしも」のシナリオをシミュレーションする能力にあり、企業が異なる意思決定や緊急対策の財務的影響を理解するのに役立ちます。
Conorは、目標は完璧な解決策を見つけることではなく、財務リスクを最小化し、リソースの現状を反映した実用的な解決策を見つけることであると強調しました。Simonも、利用可能なリソースに基づいて迅速に新たな一連のイベントを生成する能力が、財務的影響を最小限に抑えるために極めて重要であると同意しました。
議論はまた、FIFO（先入先出法）などの従来のヒューリスティックの限界にも触れました。FIFOはシンプルで迅速ですが、さまざまなタスクの財務的および戦略的な重要性の違いを考慮していません。Simonは、各タスクの具体的な文脈と制約を考慮した、より精緻なアプローチが効果的なスケジュール管理には必要であると主張しました。
結論として、SimonとConorは、計算ツールと人間の戦略的洞察力を統合することの重要性を強調しました。人間は戦略的計画において優れていますが、大規模な業務におけるスケジュール管理の細かな複雑性に対処する能力は限られています。アルゴリズムを活用することで、企業はより効率的で財務的にも健全なスケジュール管理の意思決定を実現できます。
Simonは締めくくりとして、サプライチェーンの意思決定の未来は、自動化、特に航空宇宙のような複雑な環境にあると断言しました。彼は、Lokadのアプローチが、詳細な意思決定に必要な計算能力と人間の専門家が提供する戦略的な監視を組み合わせ、製造および修理業界におけるスケジュール最適化の課題に対する堅牢な解決策を提供することを強調しました.
完全なトランスクリプト
Conor Doherty: Lokadへようこそ。スケジュール管理は、製造および修理業界において最も複雑な概念の一つです。なぜなら、膨大な数の部品、工具、人々のネットワークを管理しなければならず、そのネットワークは瞬時に変化する可能性があるからです。
本日のゲスト、Simon SchalitはLokadのCOOおよびサプライチェーンサイエンス責任者であり、彼はこの問題にどのように取り組んだのかを議論するためにスタジオに参加しました。今回は主に航空宇宙におけるスケジュール管理について話しましたが、今日議論した内容は他の製造業にも同様に当てはまります。いつものように、もしこの動画を気に入ったら、いいねを押し、YouTubeチャンネルを購読し、LinkedInでフォローしてください。それでは、Simon Schalitとの本日の会話をご覧ください。
本日のテーマはスケジュール最適化と、サプライチェーンサイエンスチームがこの分野で画期的な成果を上げるために行った広範な取り組みでした。では、その詳細に入る前に、あなた自身の視点から、航空宇宙という具体例を用いて、エンジニアリングチーム、すなわち我々のサプライチェーンサイエンティストチームが解決しようとしているスケジュールの問題は一体何なのか説明していただけますか？何が問題なのでしょうか？
Simon Schalit: では、航空宇宙、MRO、または製造の例を挙げましょう。たとえば、航空機やその主要部品、例えばエンジンの製造や修理を試みる場合、非常に複雑な問題に直面します。これは、工学的な観点からも複雑であるだけでなく、製造や修理という与えられたタスクを遂行するために必要な膨大な数の部品、技能、装置を組み合わせなければならないからです。
サプライチェーンの多くのセグメントでは、意思決定は独立して行われると考えられ、あまり害はないと言えます。例えば、商品Aを購入することを決めた場合に、商品Aが在庫切れであっても、商品Bや商品Cを販売することは可能です。結果に影響があるかもしれませんが、一般的にはそういうことです。したがって、独立して考えることは必ずしも害になるわけではありません。
しかし、MROや製造、特に航空宇宙の環境においては、これは全く当てはまりません。例えば、エンジンの修理に100個の部品が必要な場合、99個しか揃っておらず1個が欠けていると、全く部品がないのと同じ状況になります。
Conor Doherty: どういう意味ですか？
Simon Schalit: なぜなら、たとえ1個の部品が欠けていても、エンジンは―つまり航空機は飛行できないからです。99個あっても航空機は飛行できません。ですから、各部品を個別に持とうとするのではなく、すべての部品、そして実際にはすべてのリソースを適切な場所とタイミングで確保する必要がある問題に直面しているのです。さもなければ、何もできなくなります。
実際、このことは問題を完全に変えてしまいます。たとえ、ほとんどの企業の多くの人々が「それは十分であり、高いサービスレベルだ」と言うような、99%のサービスレベルを持っていたとしても、個々に99%のサービスレベルとみなす場合は非常に高いですが、100個の部品それぞれに対して99%のサービスレベルが必要だとすると、つまり各部品が期待した瞬間に存在する確率が99%であるとすると、それらが独立していると仮定すると、この単純な場合の合計サービスレベルは実際には極めて低くなり、40%以下になるでしょう。
つまり、たとえ99%のサービスレベルを持っていても、100種類の異なる部品またはリソースが必要な場合、修理や製造工程を実行できない可能性は偶発的なものではなく、常態化するのです。実際、その確率は50%以上になります。それは、従来のサプライチェーン意思決定とは全く異なる世界にあなたを置くことを意味します。非常に高いサービスレベルであっても問題が発生するのが常態であり例外ではない世界です。したがって、サプライチェーンやその意思決定プロセスを、この状況に対してレジリエントに構築する必要があります。これは全く別の問題です。
Conor Doherty: ありがとうございます。そして、いくつかの用語について触れられていましたが、部品とリソースについて言及された点を少し区別してほしいと思います。同義語として使っているのではなく、明確な区別をしていると理解しています。つまり、リソースと言うとき、それは単に物理的な部品だけを指しているのではないですよね。たとえエンジンやAPUの修理についてであっても、プロセスには物理的な部品が関与しますが、リソースと言う場合、具体的には何を指しているのでしょうか？
Simon Schalit: 修理や製造について話す際、人々は部品表という概念に言及します。部品表とは、航空機やエンジンなど、何かを完成させるために必要な部品のリストのことです。しかし、これは問題の一部にすぎません。実際にタスクを遂行するためには、他の種類のリソースも必要になるのです。
主に、これらのリソースとは、人々が持つ技能や、消費するわけではなく使用する装置を指します。そして多くの場合、それらは非常に高価であり、例えば航空宇宙の場合、テストベンチのようなものは無限に存在しないため、すべての部品が揃っているだけでは不十分なのです。安全かつ技術的に有効な方法で部品を操作し組み合わせるためには、適切な装置―テストベンチ、クレーンなど―とそれを扱う人材が必要です。
したがって、これらの部品表の問題点とその使用法について議論する際、私たちはリソース表という概念を用いることを好みます。これは、単に材料だけでなく、問題全体を包括するという意味で、より正確と表現されます。
Conor Doherty: さて、今や誰もが馴染み深い部品表という用語が再登場しましたが、リソース表という視点と比較して、具体的に対比していただけますか？例えば、シンプルにするために、航空機を使用したMROの意思決定を例に取り、BOMの視点がリアルタイムでどのように展開されるかと、より洗練されたリソース表の視点がどのように機能するかを説明してください。
Simon Schalit: わかりました。通常、MRO活動や製造活動は、一定の順序で進行する複数のステップに従います。前にすべきこと、後にすべきことがあるのです。しかし、各ステップは、それぞれ独自のリソース表、すなわち、その特定の修理ステップを実行するために必要な部品のリスト、（人々ではなく）それぞれ異なる技能を持つ可能性があるため、必要な技能のリスト、そして必要な装置のリストとして定義することができます。
部品は通常、装着されるという意味で消費されます。技能は、人々がその技能を保持しているため同じ方法で消費されるわけではありませんが、一定期間の時間という観点から消費されます。装置も同様です。これらの三つの要素―部品、技能、装置―はいずれもそれぞれ固有の変動要素を伴います。
部品の場合、変動性は通常、在庫があるかどうかという単純な表現で示されます。その背後には、主にリードタイムの変動性、そしてもちろん、注文を適切なタイミングで行ったかどうかという概念が隠されていますが、通常は主にリードタイムの変動性が関係しています。
スキルに関連する変動性は、その人物が出席し利用可能かどうか、特に作業を実行するために実際に出席するかどうかに起因します。つまり、一般に人間に付随するすべての変動性、例えばその人物が病気かどうか、計画が正しく行われたか、法的観点から有効なスキルを持っているかなどが関係してきます。そして実際、これはリードタイムよりもさらに把握し制御するのが難しい種類の変動性で、誰かに病気にならないよう強制することはできません。人が病気であれば、病気なのです。
そしてもちろん、設備の利用可能性もあります。設備は一定期間中に使用されますが、当然病気になる可能性は低いです。これに相当するのは、機械が故障している、修理中である、あるいは別のエンジンや航空機の修理で依然として使用中で、その特定の作業から解放されていない場合です。これらが、私が言うところの三つであり、どれもそれぞれの変動性を伴っており、それが問題を複雑にする原因となっています。
Conor Doherty: では、具体例を挙げてみましょう。伝統的なMROが部品表（BOM）の視点で物事を進める方法と、例えば我々のクライアントの中にはリソース表の視点で進める場合があり、その違いをシナリオにおいて比較できます。たとえば、修理するのはA380だと思います。月曜の朝、エンジンAを修理する必要があります。現場に入り、あなたはBOMの視点を持っています。すなわち、物理的で決定論的なBOMの視点です。修理に必要な部品の数、すなわち100個が必要だと分かっています。月曜の朝に現場に到着すると、全ての部品が揃っています。しかし、SimonとConnorは不在です。たとえば、Simonは何かを教えており、Connorは重い物を持ち上げて背中を痛めているため、利用できません。
つまり、部品は全て揃っており、その点では運が味方しているのです。100個の部品も全て揃っています。実際、必要な工具も—たとえば20個の工具だとしましょう—全て揃っています。つまり、100個の部品と20個の工具は手元にあるのに、重要なスキルが欠けています。そして、全てのスキルではなく、特定の部品を取り付けるために必要なライセンスを持ったSimonと、その作業を監督するConnorが不足しているのです。リソース表の視点で見ると、こういった状況下で意思決定はどう変わるのでしょうか？
Simon Schalit: リソース表を持っていること自体が大きな違いを生むわけではありません。リソース表は、先ほど説明した三つのセグメントに存在する様々な不確実性を統合し、あなたが述べたようなインシデントが起こる可能性がどれほどあるのかを把握する手助けをしてくれます。そのような問題に対処できるよう、組織を整える必要があるのです。
しかし、あなたの例を見てみましょう。たとえ部品も設備も全て揃っていても、人員が揃っていない場合が多々あります。実際、これは多くの理由でよく起こることです。現状、人々は、たとえば大規模な修理工場の場合、毎朝、あるいは1日に2回、各修理ラインの担当者が集まり、その日のスケジュールを再構築しようとしています。
彼らは、部品なのか人員なのか不足しているものを確認し、「さて、今日の計画は消えてしまった。もう存在しない。では、我々が人間で時間が限られている中で、最低限どのくらいの変更を加えられるだろうか？その日の目的から大きく逸脱しないように、実行可能なスケジュールにするために、最低限どれだけの変更が可能か？」と話し合うのです。
問題は、この最小限の努力という論理が、実際にはあまりうまく機能しないことにあります。人々は他に手段がないためにこの方法を取りますが、非常に単純な理由でそれはうまくいかないのです。
少し計画を変更するというのは、単純な状況下では、その最小限の変更が最小限の結果しかもたらさないだろうという考えに基づいています。つまり、変更量に対して結果の量にある種の連続性や線形性が存在するという仮定です。そのため、複雑にならず、結果も大きく変わらないことを望んで最小限の変更を行うのです。
しかし、スケジューリングの場合、これは各々独自の制約と変動性を伴う、数十、いや数百にも及ぶ異なる活動を再編成することを意味します。したがって、変更の大きさと影響の大きさとの間に何らかの関連性があるという考え方は、残念ながら幻想的なものと言わざるを得ません。
しかし、人間の思考能力は限られており、全体の影響を見積もろうとすらできないため、最小限の変更にとどめて影響が小さいことを期待するのです。しかし、絶対に確実なことは、たとえ最初の計画が良いものであったり最適に近かったとしても、変更を加えた瞬間に、新しい計画が全く新たな最適計画に近いという保証は全くない、という点です。結局のところ、その計画は単に「うまくいく」計画に過ぎないのです。
Conor Doherty: それでは、私の言い分を反映させてみますので、もし誤解していれば訂正してください。非常に興味深い点です。先ほど、SimonとConorが不在でエンジンAの作業が必要だと述べました。例えば、Joannisが、ペンと紙またはExcelのスプレッドシートを使って「まあ、Max、カメラの裏でビデオ撮影もしている我々のエンジニアは、実はSimonとConorが持っているスキルを有している。彼を予定していた作業から引き離せば、エンジンAの作業が可能だ。問題解決だ」と言ったとしましょう。つまり、私はただ一人を動かすだけで、シンプルな解決策になるのです。
しかし、それによって実際には過剰な影響が生じる可能性はあるのでしょうか？MaxがエンジンAの作業に費やす同じ時間で、彼はエンジンB、C、D、E、Fに対してタスク1、2、3、4、5、6、7、8、9、10、11、12をこなすことができ、その組み合わせが単にエンジンAの作業をするよりも大きな財務的リターンをもたらす可能性があるのです。
Simon Schalit: はい、その例はまったく正しいです。重要なのは、これらのタスクはある一定の順序で実行されなければならないということです。したがって、1つのタスクが実行されなければ、その問題はそのタスクが行われなかっただけでなく、タスクAが完了しているという前提で予定されていたすべての事柄が実現できなくなるということです。
ですから、もし他の作業から誰かを引き抜いて「タスクAを実行せよ」と命じれば、B、C、Dも実行可能になるはずです。しかし、問題は、その人が本来別の作業を担当していたため、その作業が実施されず、連鎖的な影響が生じることです。いわゆるバタフライ効果が働き、どの効果が財務上最も大きな影響を及ぼすか、どの選択をすべきかを人間が判断するのは非常に困難なのです。これは、非常に小規模で複雑でない環境でさえ難しい問題であり、大規模なMRO活動の規模に持ち込めば、ほぼ最適な策を講じるというのはまったく馬鹿げた考えです。
Conor Doherty: ここで非常に注意したいのは、我々が伝えたいメッセージは「人々が愚かだ」というものではないという点です。MROのカンファレンスに参加した私の経験から言えば、我々が扱っているのは非常に賢く才能ある人々であるということです。非常に賢いエンジニアやそのグループに、何十億ドル規模の航空会社で、一日に何度も各ステップが財務的影響を持つ極めて複雑な一連のイベントを再構築させるのは不合理です。それは不合理な提案です。あなたの提案は、そういったことをさせるのではなく、他の方法を取るということですか？
Simon Schalit: はい、その通りです。人々がそのような方法を取ってきたのには正当な理由があります。まず、代替手段がなかったこと、そして当然、問題は発生するという前提に基づいていたからです。すべてを再編成しなければならない状況は存在しますが、一般的なサプライチェーンでは頻繁には起こりません。しかし、この特定の文脈では毎日起こるのです。これが問題であり、人間が圧倒されるのは、無能や愚かであるためではなく、単に人間がこの問題に対処するようには設計されていないからです。
では、私たちがこれを異なる方法で行う提案は、もちろん、機械、つまりコンピュータにアルゴリズムを使って処理させるというものです。これは新しい考えではありません。この種の組織問題は、特に過去数十年の計算能力の向上とともに、コンピュータによって対処されてきました。問題は、私が述べたように、非常に複雑な一連のイベントを含む極めて複雑な文脈にあることです。各イベントは、複雑なリソース表、依存関係、そして不確実性を伴います。
伝統的な対処方法は、通常、十分に満足のいく結果をもたらさず、さらに重要なのは、十分な速さで動作しないということです。これが問題なのです。そのような問題をコンピュータに解決させ、十分に優れたアルゴリズムを構築すれば、その特定の問題に十分な時間と計算資源を投入することで、良い解決策が得られる可能性が高いです。しかし、それは困難で、多くの解決策はその段階にさえ達しませんが、実現可能です。
問題は、あなたが直面している状況が月曜の朝であるという点です。ワークショップは、まだ始動していない場合でも、通常は月曜の朝ということで、速やかに作業を開始する必要があります。部品が不足している、あるいは特定の人物が不在であるため、全てを再スケジュールしなければならないのです。問題解決に数時間もかける余裕はなく、数分しかありません。航空業界では1分1秒が非常に高価であるため、数秒か数分以内にその問題を解決しなければならず、非常に切迫した問題なのです。
ここが本当に困難な部分です。そこで私たちは、十分に良い方法でその問題を解決できるアルゴリズムを開発しました。あなたの解決策が最適であると証明することは不可能ですが、少なくとも他の解決策と比べて非常に良い結果をもたらし、財務的に見ても数分以内に非常に良い解決策を提示できることを証明できます。我々のクライアントは、通常、問題解決にかかる分数について非常に厳密な要求を持っています。
その背後にある考え方は、数学やコンピュータの詳細に深入りするつもりはありませんが、コンピュータの計算能力を活用し、求めているのは解決策そのものではなく、数分以内にその問題を解決できるソルバーの構造をどのように作るかにあるということです。実際、これは一種のメタ問題でもあります。この点について何時間も議論するのは非常に興味深いのですが、今はその時間がありません。要点は、解決策を探すのではなく、夜間や時間に余裕があるときに計算して得た理想的な解決策に基づいて、解決策を導き出すソルバーを構築することなのです。
Conor Doherty: クライアントの視点からすれば、彼らは解決策を求めており、できるだけ早く新しいシーケンスを生成してほしいのです。ここであなたが述べた点についてもう少し掘り下げたいのですが、この会話における期待値の管理という観点から、例えばエンジンを修理するための膨大な作業スケジュールを、リソース表の新しい状態を反映させるために常に3～6分、いや6分で再生成できるというわけではないということです。
期待値管理の観点から言えば、これは完璧なものだとか、10年間考え続けてもより良いものが出ないという意味ではありません。単に、現在利用可能な状況を反映し、財務リスクを管理するための良い解決策であるということです。
Simon Schalit: はい。
Conor Doherty: これらの利用可能なリソースを用いて新たなイベントシーケンスを実施することは、財務的に特定の結果をもたらします。
Simon Schalit: はい、まさにそれが私たちのしていることでもあり、あなたも望んでいることです。なぜなら、それは必要なことだからです。単に一つのスケジュールを再生成するだけでなく、クライアントに現実を変える可能性を提供したいのです。これがいわゆる「もしも」シナリオです。
例えば、今日1人が不在であれば、作業が遅れることになります。良い解決策は見つかるかもしれませんが、その解決策でも1人不足した状態が続くため、追加の人員があった場合よりも状況は改善されません。全体的に、すべてがわずかに遅れることになるのです。そこで、クライアントに「今日は1人不足していた。失われた時間を取り戻す必要がある。もしかすると、明日の通常のスケジュールに加えて誰かを追加するか、または通常は休業日の日にもう1日稼働する」といったシナリオを生成する可能性を提供したいのです。たとえば、通常はワークショップが閉まっている土曜日に稼働した場合、どのような結果になり、どれだけの時間を取り戻せるのかを知りたいのです。
つまり、ツールには実際に何が起こっているのかをシミュレートする能力が必要です。なぜなら、それが今日あなたが行うことだからです。しかし同時に、クライアントが今すぐ取れる緊急措置を統合した「もしも」シナリオをシミュレートできるようにもしておく必要があります。しかし、これらの緊急措置がどのような結果をもたらすのかを理解することが重要です。なぜなら、緊急措置と呼ばれるのには理由があり、通常の業務においてはコストがかかるため、頻繁に利用するものではないからです。通常、それらは非常に高額なコストを伴います。だからこそ、定常的な運用には使われません。
Conor Doherty: 例えば、最後の瞬間に部品を調達するためのAOG価格のような例です。
Simon Schalit: まさにその通りです。例えば、1つの部品が不足して作業停止を引き起こす場合、その特定の部品に対して支払う意志のある価格は天文学的な高値になる可能性があります。これは航空業界では当然のことであり、例えば自動車業界でもよく知られています。不足している部品を天文学的な価格で輸送する準備が整っているのです。
Conor Doherty: 全く出荷しない場合の財務的損失の方が、はるかに大きいからです。
Simon Schalit: その通りです。つまり、クライアントに緊急措置の費用を考慮する際、得られる利益のおおよその見積もりを示し、その上で財務的な視点からその緊急措置を採用することに意味があるかどうかを、十分な情報に基づいて判断できるようにするということです。意思決定を下し、その決定を社内で正当化するために文書化する必要があるのです。なぜなら、コストのかかる緊急措置に頼った場合、上司や会社全体にその責任を問われることになるからです。
Conor Doherty: 改めて申し上げますが、ここでは言葉遣いに非常に注意したいと思います。あなたは「もしも」という緊急シナリオについて触れましたが、会話の初めに、緊急事態の認識とその偏りについて話していました。何を緊急とみなすかについての人々の理解は、もしかすると少し単純すぎるのかもしれません。そこで、その点について詳しく分けて説明していただけますか？
APUの製造や修理、またはAPUの製造について話すとき、私たちは大量の部品、大量の工具、そして多くの人々のことを考えています。もし、航空機全体の製造となれば、さらに多くになり、50万個の部品、数百の工具、場合によっては数百人のエンジニアや技術者が必要となります。ですから、資源の規模を考慮すると、資源表の一部が欠けているという状況を「緊急事態」と呼ぶのは、実際には非常によく起こる、あるいは少なくとも確率的に非常に起こりやすいことを示しているのでしょうか？
Simon Schalit: そうです。まず一つ理解すべきことがあります。航空分野の場合、本質的にも設計的にも、非常にリスク回避的な業界であるのはごく当然の理由によるものです。供給チェーンにおいて、例外なくすべての決定は一つの賭けであり、未来が自分の予想通り大きく変わらないという仮定のもとでその賭けを行っているのです。
この賭けはリスクが高い場合もあれば、そうでない場合もあります。そして、プレイヤーではなくむしろカジノのように行動するという賭けの比喩にまで踏み込むこともできるでしょう。しかし本質的には、スケジュール設定に関する文脈では、未来に対して行うこの賭けが極めて複雑であるという点が重要です。未来が予想通り、あるいは計画通りに完全に整うという考えは現実的ではなく、計画通りには進まないのです。
Conor Doherty: 話を遮ってすみませんが、とても興味深い点です。例えば、エンジンを修理するために100個の部品が必要だと言ったとしましょう。月曜の朝には100個の部品、10個の工具、そして5人のエンジニアが必要になるという、私が計画している未来です。それはどの程度現実的でしょうか？ そこから説明をお願いします。
Simon Schalit: はい。全てのリソースが存在するという前提のもとで計画を立てます。理論上、予定通りに進むはずの一連の出来事を計画しますが、その数の多さ、いわゆる次元の呪いを考えると、実際にはそうはなりません。たとえば、99%のサービスレベルで100個の部品を例に取ると、全てが適切な場所に適切な時間に同時に存在する確率は既に40%未満になるのです。つまり、計画通りにはならないということです。
問題は、企業がリスク回避的であるため、本能的に「99%のサービスレベルでは十分でないなら、もっと高くしよう」と傾くことにあります。部品に関して99%のサービスレベルというのは、部品が実際に到着するまでのリードタイムの変動に対応するため、より早い段階で部品の注文をかけるという意味です。なぜなら、部品において最も大きな不確実性はこのリードタイムにあるからです。
そのため、99%から99.9%に達するまで、ますます多くのバッファーを取ることになります。しかし、もし100個以上の部品が必要であれば、十分な統合サービスレベルに達するために必要な資金は、手が届かないほどの額になってしまいます。だからこそ、「自分が安心できるサービスレベルにまで押し上げ、そのおかげで考えた計画を実行できることを保証する」という従来のアプローチは、必ずしも有効な方法ではないのです。
もちろん、航空業界では高いサービスレベルが求められます。しかし、本当に必要なのは、その場その場で新たな計画を立てるにあたって、持っている情報に基づく最善の計画であると保証できる、最も効率的でコスト効率の良い方法で計画を変更する手段なのです。実際のところ、これは単に計画通りに物事が進むという希望的観測や、適切なツールを持たずに毎朝人間が急ごしらえの新しい計画を立てるという方法と比べ、非常に大きな違いを生むのです。
Conor Doherty: つまり、要するに、あなたの主張は、—数学に深く踏み込むわけではありませんが、純粋に数学的な観点から、必要な物理的部品、工具、そして一連のアクションを完遂するために必要な抽象的なスキルや実際の人員を全てリストアップまたは図示し、なおかつそれらの要素が互いに独立しては起こらない、つまり一つのエンジンを修理しても、その後すぐに人々が帰宅するわけではないという、相互に連関する性質を持つことを考慮すれば、ということですね。
つまり、月曜の朝に現場に到着したとき、数学的には何かが欠けている確率は、人々が認識している以上、あるいは認識したがっている以上に高いのです。その結果、次に何をすべきか、どこに行くべきか、誰がそこにいるのか、何が利用可能かといったことを確認するために移動する一秒一秒が、即座に重大な財務的影響を及ぼすのです。私の理解で合っていますか？
Simon Schalit: その通りです。そして、計画を再調整するために失われる時間や、新たな計画に従うことで生じる最適とは言えない時間もまた、重大な影響を及ぼします。通常、この後者の部分は定量化が難しく、痛みとしては感じにくいかもしれませんが、実際には非常にコストがかかるのです。MROや航空機製造の現場では、すべての分が重要です。なぜなら、それぞれの分が新しい航空機の出荷や飛行するための一部、もしくは収益を生み出す一部となるからです。ですから、瞬時に新しい計画を策定する能力の効率が少しでも向上すれば、財務面で計り知れないほどの影響を与える可能性があります。
Conor Doherty: さらに思い浮かんだのですが、直接的な影響、例えば人が足りないとすれば、その結果すぐにエンジンのその部分が修理されないという直接的な結果がある一方で、間接的には他のプロセスへの波及効果もあります。現実的に言えば、それらは真空状態ではなく、ある工程から次の工程へと連鎖し、この部品がまた別の部品に組み込まれる、といったように、BOMのサブアセンブリが大きな部品全体を構成しています。さらに、MROであれば、航空機を運航に復帰させることに失敗した場合、契約上の義務にも影響が出るため、財務的な結果が生じるのです。
つまり直接的な影響もあれば間接的な影響もあるのですが、ここでの重要なポイントは、最適もしくは非常に良いスケジュールを組むためには、何百、いや何千もの決定が関与しており、それぞれの決定が財務的な影響を持つということです。そして、何かが欠けて上手くいかなくなると、その可能性は非常に高く、明日起こらなくても、その翌日やその次の日に起こる可能性があるのです。これが財務的なコストにつながるのです。
Simon Schalit: そうです。実際、日常業務において私が各社で目撃したのは、新しい計画を立てる作業が非常に時間を要し困難であるため、作業現場はその日把握している問題のみに集中し、他の問題に手を付ける余裕がないということです。結果として、翌日には未解決の古い問題に加えて新たな問題が発生するのです。
しかし、もし新たな問題の詳細を見れば、その半分は前日には予見できたものであった可能性があります。実際、予測することは可能だったはずです。しかし現実には、人々は今日解決すべき問題に極端に集中しているため、次の日々の問題を予測するための時間や知的余裕がなく、その結果、問題が時間とともに拡大し、通常はMROや製造活動において積み重なった遅延や、もちろん契約上の義務違反に繋がるのです。
Conor Doherty: もう一度言いますが、非常に良い点です。プロセスが単独で起こるわけではなく、外部要因や行動の結果は真空状態で存在しないということです。したがって、未処理の積み残しの蓄積、そしてそれに伴う財務的影響の蓄積は、あなたがそれを認めるかどうか、考えるかどうか、または対処するかどうかに関わらず、バックグラウンドで進行し続けるのです。あるいは、対処して「その問題は解決した」と思ったとしても、見落とした変数があるため、結局、私たちは皆人間であり、帳簿や請求書、メーターはバックグラウンドで依然として動き続けているのです。もしかすると、その進行に気づいていないかもしれません。
さて、少し話を進めましょう。スケジューリングの最適化の詳細に関して、部品や工具の在庫面についてはすでに話しました。ところで、スキルについてはどうでしょうか。単に、例えばその部品や工具を使い、Simonをそのエンジンの作業現場に派遣するという決定だけなのでしょうか、それとももう少し微妙なニュアンスがあるのでしょうか？
Simon Schalit: ええ、通常はそれに伴い多くの複雑な要素が絡むため、もう少し微妙なものになります。基本的には、出力として材料、部品、設備の推奨配置のセットが計画とともに示される形になります。例えば、この部品はあの航空機またはエンジンに割り当てられる必要があり、この特定の設備はその航空機またはエンジンがこの時間帯に使用する必要があります。そして、この特定のスキルを持った人物は、その期間中、対象の航空機またはエンジンに配置されなければなりません。システムは、これらの割り当てに際して設定された各タスクの制約条件を厳守することを保証する必要があります。
複雑性の観点では、部品に関しては通常、非常に単純です。部品は部品表の一部であるため、タスクに割り当てられればそれで問題ありません。しかし当然、実際にその部品が存在している必要がありますが、それは保証されているわけではありません。通常、交換は可能ですが、いつ割り当てるかを決め、再割り当てを避けるために可能な限り最終段階で行います。それが部品の単純な部分です。不思議なことに、多くの人が最もコントロールできると感じるのはこの部分なのです。
しかし、人員と設備の配置に関しては、通常はそれらが一体となっており、さらに複雑になります。特に、タスクによっては、単一のスキルや一人の能力だけではなく、技術的理由や安全上の理由から、複数の人々の異なるスキルが同時に必要となる場合があるのです。たとえば、作業場の中央でエンジンを移動させる際にクレーンを操作するだけでも、最低限、セキュリティのために二人が必要です。一人はクレーンを操作し、もう一人は何か問題が起きていないか、通路が確保されているかを確認する役割です。それが最低限の体制となるのです。
ですから、特に熟練したリソースについては、それらを完全に独立した存在と考えることはできません。それではあまりに簡単すぎます。むしろ、同じタスクのために、同じ場所に同時に存在するという制約条件を伴っていると考えるべきです。そして、タスクは同時にまたは順序立てて、あるいは非連続的に、一人、二人、三人、四人で遂行されるなど、さまざまな組み合わせが存在します。アルゴリズムは、これらのスキルが他の場所で消費されていないことを考慮しながら、最適な有効解を見つけ出す必要があるのです。
そのため、問題は非常に困難になります。もしタスクAを行うために二人が必要なら、彼らが特定の時間に利用可能でなければなりません。つまり、彼らが何をしていたとしても、ほぼ同時に作業を終え、両者ともそのタスクに移れる状態である必要があるのです。しかしこれは、しばしば一方がもう一方の終了を待たなければならない状況を生み、それがかなりのコストを伴うため、決して些細な問題ではありません。できるだけそれを避ける必要があります。一分一秒が重要であり、これらのスキルは非常に高価なものなのです。
Conor Doherty: では、改めてですが、聞いている人にはそれがまるで魔法のように聞こえるかもしれません。あなたが言っているのは、現在Lokadが行っていることは、スケジューリングにのみ注力するということで、在庫については既に議論済みで他の資料もある。つまり、「これを使い、この部品とこの工具がその時間にその場所にあること、そしてSimonがそこで一定時間、作業を行う」という決定をする、ということでしょうか？
Simon Schalit: はい、基本的にはその通りです。しかし実際、問題全体を考えると、私が言いたいのは、ふたつの要素があり、それぞれが単独で扱うには難しく、実際にコンピュータの助けがなければ人間が正確に行うことはほぼ不可能、あるいは限界に近いという点です。一つは賭けの側面、つまり賭けの結果を理解する部分であり、もう一つは配置、再配置、計画の部分です。
賭けの側面では、戦略を理解し、物事を金銭的な観点から捉えることに関係します。先ほど使った非常にシンプルな例ですが、人間は賭けを行う際、自分の知識や直感に頼ります。基本的に、彼らはカジノのプレイヤーとして、そこに伴うすべてのバイアスや感情を持って行動するのです。もし最近、ある部品で大きな問題があったなら、その部品に対して過剰な購入や大きなバッファーを設定してしまう可能性があるのです。これがバイアスなのです。
The machine, if fine-tuned correctly, will follow a strategy exactly like the casino. Same bet, same game. One follows a strategy and wins; it’s the casino. One doesn’t follow a strategy, or at least not a documented and consistent strategy; that’s the player, that’s the human being. In our case, the casino wins. The casino always wins. It’s not magic. It’s understanding that there is, even if it’s hard to calculate, an optimal strategy, and you don’t want to deviate from this optimal strategy.
したがって、この部分は魔法ではありません。実際にこのビジネスに精通した人々の頭脳から、重要な戦略的アイデアを抽出し、それをコンピュータ内の戦略、つまり意思決定プロセス（決定を生み出すアルゴリズム）に変換することを確実にするのです。これがサプライチェーンサイエンティストの役割です。魔法ではなく、一貫した戦略構築のプロセスなのです。
再配置も魔法ではありません。繰り返しますが、これは計算能力といくつかの数学的トリックの組み合わせです。計算能力は、特に私たちが使うようなクラウドコンピューティングを用いれば、ほとんどの人々が利用できます。しかし、私たちだけではありません。確実に、私たちよりも遥かに多くの計算能力にアクセスできる人々がいます。しかし、正しく使えば、その問題といくつかのトリックを解決することができます。
しかしながら、これらのトリックは純粋に数学的なものだけではありません。これは、根本的な数学的側面を組み合わせ、かつ問題の実際の形状を踏まえた方法で適用したものです。確かに、非常に大規模な汎用ソルバーに投入して何時間も動かし、最終的に良い解が得られることを期待することもできます。しかし、おそらくそれはうまくいかないか、うまくいったとしても時間がかかりすぎるでしょう。求められるのは、数学的アプローチをその特定の問題に固有の制約や構造に合わせて調整することを確実にすることです。
Conor Doherty: さて、私が追及したかったのは、Lokadが試みることに関して強調すべき広いメッセージに繋がる重要なポイントです。クライアント企業に実務者がいて、明らかに鋭い洞察を持っている場合、その情報を収集し、戦略、つまり意思決定プロセスに組み込むことが目的です。
その理由は、もちろん、もし私の言うことに間違いがあればご指摘ください、どんな一つの選択や決定においても、非常に優れた人間はアルゴリズムや自動化された意思決定プロセスと同等かそれ以上の判断ができるかもしれないからです。しかし、飛行機全体や複数の飛行機、場合によっては何十万もの部品、数百の工具、数百の人々を整備するという規模の複雑性になると、人間が自動化されたプロセスよりも大規模に全ての決定を下すことができるという考えは全く非現実的です。私が使う形容詞は: 非現実的 です。
Simon Schalit: 人一人でも、あるいはチームでも。
Conor Doherty: まさにチームです。
Simon Schalit: 人間の頭脳はそのために作られていません。そして、ここでコンピュータと人間の間の二元性について触れさせてください。流行語の「AI」を使うとすれば、それは単なるツールにすぎません。ツールであり、それ以上のものではありません。これらのアルゴリズムを構築する際の真の課題は、人間の頭脳から知識を抽出することにあります。私がよく言うのは、人間の頭脳は戦略においては非常に優れているが、戦術的、より細かなレベルになると迷子になってしまうということです。
それは、単に扱うべき事項の数が多すぎるために混乱するし、ある一定以上の変数、特に非連続的で非線形な変数が加わると、世界一の数学者であっても頭の中で解決することはできません。そんなことは不可能です。問題はあなたが誰かということではなく、人間にはそれができないということです。ツールなしでは到底不可能なのです。しかし、人間は高次の戦略を立案し、物事の財務的な影響を理解するには非常に優れています。
最終的には、会社がどの方向に進むべきか、また、特定の信頼性で顧客にサービスを提供できることが会社にとってどれだけ重要であるかを決定するのは彼ら自身です。彼らはその数値がどの程度のものかをある程度把握しています。問題は、彼ら自身が「アイデアを持っている」という自覚がないことです。直感に頼っており、その直感が「高いサービスレベルが欲しい」という結論に導いているのです。もしなぜ高いサービスレベルを望むのかと尋ねれば、単にそれが重要だと言うでしょう。
サプライチェーンサイエンティストが行うべき主要な作業の一つは、その重要性について彼らに説明させることです。もしそれが重要だとすれば、在庫切れのコストが高いと考えていることになります。さらに踏み込むと、それはドルやユーロ、財務的な観点で見た数値が高いということを意味します。その知識を抽出すれば、先ほど話した最適な戦略、つまり与えられた戦略的情報を考慮した上で最適な判断を下す戦略を実行に移すことができるのです。
この場合、コンピュータは戦略レベルで定められた目標を達成するために最も適した一連の行動およびリソースの配置を出力します。これがコンピュータの役割です。何かを発明するわけでもなく、人間を無用の長物にするわけでもありませんが、人間の頭脳ができないことを実行するのです。
Conor Doherty: 完璧な移行ですね。さて、この話題に関連して、以前私が参加したMROカンファレンスやトレードショーでは、ブースのポスターのテンプレートの一つとして、紙のごみ箱（バスケット）の真上に置かれた手が、くしゃくしゃになった紙片を落とし入れている様子がありました。その紙片には特定の用語が記されており、小売イベントか航空宇宙イベントかによって内容を変えています。このイベントでは、紙片にFIFOとMin-Max、Safety Stockが記され、ごみ箱に落ちていました。非常に挑発的なものです。
もちろん、人々が近づいてきて、その意図を理解すればコメントしてくれます。しかし、我々がこれらの概念に対して批判的であることを知らなければ、「ああ、これは面白いですね。もっと教えてもらえますか？」と言われるのです。
Simon Schalit: はい。
Conor Doherty: 実際、多くの人々がFIFOを非常に好んでいます。これが最もよく聞かれる意見です。先ほど、緊急時でも迅速に動作するソリューションについて言及していましたが、迅速な動作は極めて重要です。もしあなたに反対する意見を代弁するとしたら、「すでにヒューリスティック、すなわち非常に低コストでリアルタイムに超高速で動作する汎用の意思決定ソルバー、つまりFIFO（First In, First Out）を持っている」と言うかもしれません。それに対してどう答えますか？
Simon Schalit: そうですね、FIFOは確かに長い間使われてきたアルゴリズムです。実際、市場における我々の最大の競合相手だと言っても過言ではありません。FIFOの問題点は、確かに非常に高速に動作し、人間が理解しやすいという点にあります。なぜなら、「先に入ったものから先に出す」というのは、これ以上に単純明快な考え方はないからです。また、直感的に意味があるように思える点も良い点です。すなわち、何かが先に入ってきたならば、すぐに対処すべきだと考えるのは、すべての条件が等しく、同じ時間がかかるという前提のもとでは、遅れる可能性が最も高いからです。
しかしながら、サプライチェーンにおける多くの時代遅れの概念と同様に、必ずしも悪いわけではなく、単に少し時代遅れであるため、いくつかの前提に依存しています。第一の前提は、あなたが単純な環境にいるということです。つまり、FIFOを使うということは「先に入ったものから先に出す」ということであり、すべてのエンジン、すべての飛行機（航空の文脈であれば）が、企業の財務面や戦略の観点から見て完全に交換可能であると仮定しているのです。リスク管理の観点からも、どちらが遅れても同じと見なすのです。
実際のところ、それは本当なのでしょうか？全くそうではありません。顧客は異なり、航空機の種類も様々ですので、同じではないのです。一方の航空機での1日の遅延は、他方の航空機での1日の遅延と同じではありません。しかし、仮にすべてが同じであったとして、一種類の航空機を一人の顧客のためだけに整備する完璧な世界を想像してみてください。
問題は、一機または一つのエンジンで直面する問題を解決するために必要な労力が、必ずしも他のものを解決するための労力と同じではなく、おそらく異なるということです。たとえエンジンが同じであっても、修理内容、すなわちそのエンジンで実施すべき作業は同一ではありません。仮に同じだとしても、故障している部品が全く同一というわけにはいかないのです。これが、エンジンを分解した時に見つかる不確実性の一部であり、何が壊れているのか、何が腐食しているのかがわかる瞬間なのです。
Conor Doherty: そこまであるとは知らなかった。
Simon Schalit: まさにその通りです。ですから、「エンジンBより先に来たエンジンAに注力する」という発想は実際には意味を成さないのです。たとえエンジンAに全力を注いだとしても、実際に問題を解決するには多くの時間がかかるでしょう。一方、エンジンBであれば、非常に迅速に修理できる可能性が高いのです。
確かに、「エンジンAはまだ進行中だ」と言えるかもしれませんが、エンジンBを完成させれば作業場から出されることになります。そうなれば、新たなエンジンが入ってくる余地が生まれ、そのエンジンの点検を事前に行い、必要なものを把握できます。また、一人の顧客へのサービスが完了すれば、その分の収入が早期に得られ、他のオペレーションの資金調達に役立つのです。
つまり、作業の順序にはそれぞれ結果が伴います。各活動に費やす1分1分の価値は同じではなく、同じ結果をもたらすとは限りません。同じ潜在能力が引き出せるわけでもないのです。
FIFOはその点を全く考慮していません。FIFOは、修理や製造チェーンに対する単純なビジョンです。誤解しないでほしい、決して悪いわけではありません。適切なツールがない中で使える解決策の中では、おそらく最高、あるいは最高の一つでしょう。しかし、よく考えると、金銭的な影響を踏まえると、問題を単純化しすぎるのは避けるべきです。
Conor Doherty: もちろんです。そして、ここではあえて単純な例を示してこの点を説明しましたが、実際にはプロセスは2つだけではありません。エンジンAの修理とエンジンBの修理は、別々のスケジュール、またはシーケンスです。通常、もっと多くの要素が絡んでいます。そのため、頭の中で、あるいはExcelシートやソルバーを使って一覧にまとめる必要があります。考慮すべき要素ははるかに多く、重要なのは、そのコストが非線形であって必ずしも同じではないという点です。これを念頭に置くか、あるいはどちらに取り組むかの財務的影響を洞察できる何かが必要なのです。
Simon Schalit: さらに、エンジンAとエンジンBの両方が同じ部品を必要とするという単純な割り当て問題もあります。もしエンジンAが古い場合、通常はエンジンAに部品を割り当てるでしょう。しかし、もし何らかの理由でエンジンAが5種類の欠品部品を必要とし、エンジンBがそのうち1つだけで済むのであれば、その部品はエンジンBに行くべきだという非常に説得力のある理由があります。なぜなら、エンジンBではその部品だけが欠けており、取り付けられるのに対し、エンジンAにその部品を取り付けても、他の4つの部品が欠けているため効果がないからです。FIFOはその点を考慮していません。
Conor Doherty: さて、再び、先ほど述べたポイントを手短に強調したいと思います。可能な限り、我々の立場を明確に示すべきだと思います。そして、私はこれまで公にも私的にも一度も言ったことはありませんが、FIFOの適用が愚かだとか素朴だとかいうことではないのです。多くの場合、人間の頭脳は問題に取り組む際、最良の利用可能なツールを使うものです。明らかにより優れたツールがない場合、人々は少なくとも理解しやすく、見た目に機能しているものに依存するのです。
この長い会話から私が理解したのは、基本的な価値診断は財務的な範囲において非常に限定的であるということです。つまり、「エンジンが外れた、それで財務的な価値が付加された、あるいは価値が創出された。それで一段落」という考え方です。そして、今日あなたが説明している重要な洞察は、直接的なものだけでなく、より大きな間接的な財務的影響が存在するという点です。正直なところ、人間の頭脳は本能的にこれらに気付かないのです。あなたは設計の本質について語りました。人間の頭脳は、スケールで生じる非線形性や意思決定の外部的な財務影響を理解することができないのです。これが、自動化を利用し、この情報を抽出して繰り返し可能な意思決定エンジンに変換できるサプライチェーンサイエンティストを活用する理由に繋がるのです。
Simon Schalit: はい、私たちのこの件における立場は非常に明確です。サプライチェーンにおける意思決定の未来は、すべて自動化にかかっており、状況が複雑であればあるほどその重要性は増します。私たちにとって、これが進むべき方向です。
Conor Doherty: まとめとして、素晴らしく正確かつ重大な主張を耳にした皆さん、そして未だに「Simon、あなたの説明は非現実的だ、魔法のようだ、不可能だ」と考えている方々に向けて、最後に30秒で一言お願いします。
Simon Schalit: ええ、すでに起こっていることです。ここ数年続いている現象であり、サプライチェーン全体が向かっている方向そのものです。大規模な自動化、そしてより細かなレベルでの自動化が進んでいくのです。なぜなら、我々は計算能力を持っており、サプライチェーンサイエンティストのおかげで、その概念と役割が確立されているからです。必要なデータや戦略的・財務的情報をアルゴリズム、すなわちコンピュータに提供する能力があるため、人間が設計し、目標に向けて最適化できる戦略が大規模に適用されるのです。
Conor Doherty: 以前、非常に似た質問への回答でおっしゃっていましたが、正直なところ文脈は覚えていません。しかし、このトピックについて、人々が実際にはリアルタイムで行おうとしていることを考えると、それが可能だと信じないという驚きは、むしろ当然のことなのです。つまり、月曜の朝、重要な意思決定者であり主要な関係者である誰もが、サイモンとコナーが不在のためにスケジュールを見直す必要があるのです。彼らがリアルタイムで行っていることこそ、コンピュータやアルゴリズムを用いて私たちが説明しているものと本質的に同じプロセスです。最適化された解決策を求めているのです。ですから、それは魔法ではなく、そのプロセスに対する技術的介入に過ぎないのです.
Simon Schalit: はい、彼らは手作業で行っています。非常に骨の折れる方法、というか、彼らにとっては苦痛であり、ある意味で会社にとっても苦痛です。なぜなら、最適化された解決策に到達できていないのは、スキルの不足ではなく、ツールの不足によるものだからです。そこで、我々が提供するのは、細部において不足している人間の要素を実際に置き換えるために必要なツールであり、理想的な人間の要素、つまり戦略的レベルは維持するものです。つまり、コンピュータの細部レベルと人間の戦略的レベルを組み合わせるのです.
Conor Doherty: サイモン、本当にお時間をいただきありがとうございました。これ以上質問はありません。大変光栄でした.
Simon Schalit: 私も同じです。改めてお時間をいただき感謝します。そして、皆さんご視聴いただきありがとうございます.
