AIがエンタープライズソフトウェア開発をどう変えているか

HS136 – スポンサー：Bluecat

[ジョン・バーク] (0:00 – 0:05)

こんにちは、ネメルテスのCTO、ジョン・バークです。今日は共同司会者と一緒に番組をお届けします。

[スコット・ロボーン] (0:05 – 0:14)

私はスコット・ロボーンです。SolutionalのCEOであり、ここPacket Pushersで放送されている姉妹番組『Total Network Operations』のホストを務めています。

[ジョン・バーク] (0:16 – 0:28)

今お聴きいただいているのは『Heavy Strategy』です。この番組は、正しい答えを与えるのではなく、正しい問いを投げかけることを目指しています。本日のゲストは、BlueCat Networksの最高戦略責任者（CSO）、アンドルー・ワートキンさんです。アンドルーさん、ご出演ありがとうございます。

[アンドルー・ワートキン] (0:28 – 0:30)

お招きいただきありがとうございます。楽しみにしています。

[ジョン・バーク] (0:30 – 0:52)

そして今日の番組では、ネットワーク管理会社がまさに取り上げるような話題、つまりエンタープライズネットワークの自動化にAIを活用する際の課題について話していきます。というのも、IT担当者がネットワーク自動化の取り組みを加速させるためにAIを活用していることは、皆さんご存知の通りだからです。 なぜ、それは思ったほど単純ではないのでしょうか？なぜ、99％のケースで、単にクロードの言うことを鵜呑みにできないのでしょうか？

[アンドルー・ワートキン] (0:54 – 2:08)

ええ、許可モードにして「実行」をクリックするだけ。完了です。そうですね、興味深いのは、私が……ええと、物心ついた頃からずっとソフトウェア開発をしてきたからです。 私が文章を書けないのには理由があるんですよ。 人生ずっとキーボードを叩いてきたんだ。その作業自体を、本当に、本当に楽しんできた。でもね、ネットワークの側面では興味深いことがあって、チームが本当に素晴らしい仕事をしてくれているんだ。 ここで言う「チーム」とは、つまり、コード生成や言語モデル（LM）が登場する前から自動化を推進し、ソフトウェア開発会社がソフトウェアを開発するのと同様の方法論を成熟させようと真摯に取り組んできたネットワークエンジニアたちのことです。 AIやLMによって生成されたコードに関しては、そうしたベストプラクティスがなければ、ネットワーク上で何が起こるか考えると少し恐ろしいものです。ですから、結局のところ、それらのチームがソフトウェア開発に関するより洗練されたプロセスへとさらに変革していく必要があるでしょう。なぜなら、ものがより速く作られるようになればなるほど、おそらく不具合も増えるからです。

[スコット・ロボーン] (2:09 – 3:24)

あなたの主張には、本当に共感する部分がありますよね？ 実は、私が担っているもう一つの役割として、「Network Automation Forum」という組織の共同創設者という立場があります。そして、今日の収録時点では、ドイツのミュンヘンで開催された前回の会議「AutoCon 5」から戻ったばかりなんです。

それに、AIが登場する前から、ネットワーク自動化の導入に対する抵抗感について話し合っていましたよね？ ですから、自動化をフル稼働させることに対しては、常に一定の抵抗感があったんです。 そして今、ボットやエージェントが現場に登場してきて、皆が白目をむいたり、強い懐疑的な視線を向けたりしています。この話題を、ここでの会話の一部として活用して、「その通りだと思います」と言いたいですね。 ソフトウェアエンジニアリングやソフトウェア開発において、優れたベストプラクティスが確立される必要があります。なぜなら、ネットワーク運用における私たちの業務の多くは、それらに下流に位置するからです。冒頭で少し時間を取ってしまったかもしれませんが、これが私の見解です。皆さんとこの対話を交わすことを、心から楽しみにしています。

[ジョン・バーク] (3:24 – 3:42)

ええ、本当に素晴らしいですね。あなたの指摘はまさに的を射ていると思います。ネットワーク業界における自動化への不信感は、25年もの間根深く続いています。つまり、私たちは痛い目を見てきたんです。自動化を過度に、そして早すぎる段階で信頼しすぎたことで、何度もひどい目に遭ってきたのです。

[アンドルー・ワートキン] (3:43 – 6:00)

ええ、私がいつも耳にするのは「信頼」という言葉ですね。特に、反復可能でテンプレート化されたアクションに対しては、より一層の信頼が求められます。そうですね。もしそれが、単純で反復可能、テンプレート化された範囲外のものなら、そう、そこでは信頼の欠如がかなり強く現れ始めるんです。 それに、ご存知の通り、ベンダーが「ポイント＆クリックで、シンプルで簡単な自動化」と謳ってやってくるのは、エンドユーザーからの信頼を得る上で、おそらく最悪の方法でしょう。 つまり、仕組みが不透明であればあるほど、通常は懸念も強まるもので、それが、そう、AIの世界における不信感を加速させてしまうんです。 どうでしょう、この問題への対処法や信頼を高める方法については話し合うこともできますが、これはネットワーク分野に限った話ではなく、明らかにあらゆる分野に共通する問題です。 ご存知の通り、私たちの多くは、ソースコード管理が行われていなかった環境、レビューが適切に行われていなかった環境、現在の環境に合わせて精査されることなくどこからかコードがコピー＆ペーストされていた環境などで働いてきました。挙げればきりがありません。

そして、もし開発を加速させているなら、1日で10件ほどの主要な問題を見つけ出せることもあります。これは本当に大きな可能性を秘めています。でも、これは単なるソフトウェア開発だけのことではありませんよね？ 何が起きているのかをデバッグし、本番環境で何が起きているのか、なぜ特定の領域で機能しないのかを突き止めようとするものです。 適切な専門知識を持つ人がそばにいて、言われたことに対して批判的な姿勢を保ちさえすれば、短時間でこなせる作業量は、まさに驚くべき、本当に驚くべきものになります。 ただ、「ああ、そう言われているから、こうすべきだ、ああすべきだ」と鵜呑みにしない限りは。 そこが懸念点なのです。なぜなら、LMは、プロンプトの厳しさに応じて、根本原因を見つけたと思い込み、物事を白黒はっきりさせがちになる傾向があるからです。

[ジョン・バーク] (6:01 – 6:43)

自動化を加速させるという考え方が気に入っています。つまり、人々がAIを活用してより良い実践方法を取り入れれば、自動化プロジェクトをより頻繁に完了させられるようになるということです。プロジェクトを中途半端な状態で放置したり、4分の3ほどしか完了せず、デバッグもドキュメント化も完全に行われないままにしたりすることはなくなるでしょう。そうですね。

そして、次の緊急事態へと移ります。1日や2日、あるいは1週間や2週間のうちに、すべてをやり遂げ、不安や恐れを抱くことなく、自信を持って再び実際に使えるものを残せる可能性が高くなります。

[アンドルー・ワートキン] (6:44 – 6:58)

ええ、そうですね。その多くはアーキテクチャに関するものです。その多くは……そうですね、一つは、適切な開発者のマインドセットです。つまり、「将来これをメンテナンスする人々のために書いている」という意識を持ち、それを常に心に留めておくということです。

[スコット・ロボーン] (6:58 – 7:02)

自動的ですよね？ どの開発者も、初日からそのことを考えているものです。

[アンドルー・ワートキン] (7:02 – 9:15)

うん、うん、うん、うん、うん。特に、最初は「ああ、この問題を解決するための簡単なスクリプトが必要だ」というところから始まるんです。そして、6ヶ月後に誰かがそれを見つけたりして。 つまり、その多くはアーキテクチャに帰着するんです。自動化に含まれる要素の多くは繰り返し使われるものになるでしょう？ 例えば、認証の仕組みや、ロギングに関する基準、ロギングの方法、あるいはデバイスとの連携方法など。 パスワードはどのように管理され、保管庫からどのように取り出すのか、あるいは、どのようにテストを行うのか、変更を元に戻すにはどう考えるべきか、といったことですね。私が今挙げたことのほとんどすべては、適切な方法論の下では繰り返し可能なものです。 さて、あとはビジネスロジックを追加するだけでよく、他の要素をすべて実装する必要はありません。その結果、すべてのコードは常に最新の状態が保たれ、テストも継続的に行われます。しかし、何かを素早く構築するのは本当に簡単ですよね。 そして、私が今挙げたすべてのことは、8人のメンバーがそれぞれ、完全に機能する、いわゆるAからZまでのスクリプトやアプリケーション――私たちが構築しているものが何であれ――を次々と作り上げるよりも、時間がかかりそうにも聞こえます。ですから、つまり、 正しい方向でスタートを切り、これをいかに持続可能なものにするか、そして人間がどの段階でプロセスに関与し、どこで関与することが不可欠なのかについて考え始めることが、おそらくこれまで以上に重要になっているのです。

それに、これを安全に行うために、どのようなプラクティスを導入すべきか？　こうしたことすべては、つまり、その多くは、過去数十年にわたってソフトウェアを構築する中で、私たちが常に考慮してきたことや懸念してきたことと同じなんです。そうですよね。 その一部は、単に今やそれがどれほど迅速に行えるかという点に過ぎません。そして、単にStack Exchangeから内容をコピー＆ペーストするようなこととは違います。

[スコット・ロボーン] (9:16 – 10:33)

誰でもその環境で動作するコードを生成できるようになったんです。簡単ですよね。でも、2年前はそうじゃなかった。あの頃は、急速に変化し、実験的な時期の真っ只中にいたと思います。ほんの数年前にさかのぼれば、 人々はチャットベースのツールを初めて体験し、結果も千差万別だったんです。 LLMの非決定性といった問題が、私たちの最初の経験だったんです。そして、ヴィブコーディングの登場や、それがプロトタイピングにとってどれほど強力なツールであるか、一方で企業のコードベースにとってはどれほどスパゲッティのような混乱を招く可能性があるか、さらには、仕様駆動開発やテスト駆動開発といった新たな手法の台頭まで、目にしてきました。 つまり、今や「こうやってツールを使えばいいんだ」「こうすれば技術への信頼を実際に築ける」という形が確立されつつあるのに対し、私の最初のChatGPT 3.X体験とは対照的だ、という状況が見て取れると思います。そうですね。 こうした戦略や、登場しつつある再現性のあるツールの台頭について、あなたはどう見ていますか？

[アンドルー・ワートキン] (10:34 – 11:59)

ええ、確かにLLMは目にしていて、いくつか試したり導入したりもしています。私たち……つまり、私の会社も、そして私個人としても、最も成功を収めているのは、興味深いことに、 私のキャリアの中で、おそらく最も時間を割いてこなかった部分、会社としてではなく私個人としてですが、つまり、事前の仕様策定や、トレードオフについてLLMと協働する作業です。そこでは私の経験を活かして「どうアプローチすべきか」を提案し、最初にその時間を費やして、作業を適切な単位に分解し、そして、 適切なガードレールを設けたりする。そういう取り組みが変革をもたらしたんです。それに対して、自分が望むことを正確に記述したプロンプトを打ち込もうとするのではなく、単に「OK、高速なTCEBFロガーを作りたい」というところから始まる、反復的な仕様とテストの開発こそが本当に重要なんです。そう。 「こんなのやったことない」って。そう。 だから、トレードオフが何なのかさえ分からないんです。だから、まあ、どれほど信頼できるのか、よく分からない、という状態です。でも、非常に大まかなレベルから始めることはできます。「これをやりたい。何が分からないのか？」というように。

[ジョン・バーク] (11:59 – 12:47)

意図ですね。その通りです。そうですね。 その一つ下のレベルに、本当に重要なポイントがあると思うんです。つまり、意図やニーズを非常に明確に表明することが極めて重要だということです。なぜなら、ソフトウェアにネットワーク上のハードウェアの設定をいじらせているとき、間違った設定をいじるとトラフィックの流れが遮断されたり、プロセッサに過度の負荷がかかって、 パフォーマンスが著しく低下してしまう。つまり、インフラ上のミスが起こり得る環境にいて、それが自動化のスピードで発生し、非常に大きな影響を及ぼす可能性があるのです。

[アンドルー・ワートキン] (12:47 – 14:57)

うん。うん。つまり、僕たちのDNSの世界では、 パブリックな側面だけを見ても、大手公開企業が発表したここ数回の大規模なサービス停止事例を振り返ると、その80％は、自動化によるDNSの変更が原因でシステム全体がダウンしたものだったと思う。まあ、そのことについてLLMを非難するつもりはまったくないけどね。 ただ、でも、つまり、解決策を素早く思いつければ思いつくほど、特に、コーディングパートナーやデバッグパートナー、パフォーマンスパートナー――ユースケースが何であれ――彼らが確信を持てば持つほど、あなたは「よし、 ってなるでしょう？　それに、誰もが「許可疲れ」に悩まされているし。指をエンターキーの上に置いて、ただひたすら押し続けてしまうんです。だから、結局のところ、どうすればその挙動を適切に監視し、そうした事態が起こらないようにできるか、という問題にもなるんです。

でも、そうですね、つまり、より成功している「意図の明確な表現」には、そういった要素が含まれているんです。何が問題になり得るか？ 何が懸念事項か？ 実際にテストすべきことは何ですか？ここでいう「負荷」とは具体的に何を意味するのでしょうか？どのように動作すべきでしょうか？もちろん、こうしたことは最初からすべて明確にする必要はありませんが、検討すべき事項のカテゴリーを把握するための適切な経験を持つことは有益です。 一方で、やる必要のないこと、そしてこれはツール面でもプロセス面でも、この半年間という信じられないほど短い期間で本当に成熟してきたと思うのは、何を正確に提供すべきかについて4ページものプロンプトを書き始める必要はない、ということですよね？ もし、フロンティアモデルではなく、もっと安価でランレート型のモデルを使っているなら、そのランレートモデルの仕様書を書く必要があります。プロンプトの生成に関しては、LLMほど上手にはなれないでしょうから。

[スコット・ロボーン] (14:58 – 15:55)

そうですね。そこで私は、ある手法を取り入れています。基本的には、LLMに私へのインタビューを依頼するんです。その際、1ページから1ページ半ほどの、かなり詳細な意図を提示します。 そして、このプロセスを使ってSDD用の適切なマークダウンファイルをすべて作成する場合、第一に、コストが安いんです。トークンコストはかかりますが、インタビュープロセスを経て、自分で検証・確認できる、人間が読みやすいドキュメントを作成できるわけですから。 それに、先週素晴らしいコメントを耳にしました。コードは、ある意味では「無料」なんです。私たちは、コードを完璧に仕上げるために苦労するものだ、という考え方に慣れていましたよね。でも今は、エージェントにコードを書いてもらい、反復作業を行い、ゴミのようなものは捨ててしまえばいいのです。 とはいえ、それが実際にゴミだと判断できるだけの十分なドメイン知識は、やはり必要ですよね？

[アンドルー・ワートキン] (15:56 – 16:32)

まさにその通りです。そして、その最後の点についてですが、 ええと、個人的な話ですが、10年後にすべてがどうなっているかという不安もあるんですが、それ以上に今最も重要なのは、ドメイン知識や、物事がどう失敗するか、どう機能すべきか、どう gracefully fail すべきかといった経験や専門知識がなければ、トラブルを招くことになるということです。 でも、そうですね、私もそういう考え方は好きですし、おそらくあなたほど厳密にはやっていませんが。でも、つまり、「ここで私が考え落としていることは何だろう？」とか、「ここで他に何がうまくいかない可能性があるだろうか？」といったことですよね。まさにその通りです。

[ジョン・バーク] (16:33 – 16:53)

そして、LLMが、一見しただけでは区別がつかない、致命的な毒キノコと美味しくて食べられるキノコを、同じように喜んで提示してくるような状況では、そうですね、そうした分野の専門知識はかけがえのない、絶対に不可欠なものになるのです。

[アンドルー・ワートキン] (16:54 – 20:08)

ええ。そして、ここで何が起こるのか、そしてなぜプロセスがこれほど重要なのかというと、人々は腰を据えて、LLMと認識が一致していると思い込むんです。そして、数週間はそれが真実のように見えます。LLMは物事を覚えているように見えるんです。 ところが、7日目になって新しいセッションを始めると、まるで今まで知っていたことをすべて忘れてしまったかのように見えるんです。その1週間の間に、ドキュメント化を怠っていたせいで、性能が徐々に低下していたんです。適切な記憶を保存したり、プロンプトを更新したりといったことを、きちんと行っていなかったからですね。 そして、信じられないほど幼稚な判断を下してしまうのです。私たちはこうしたシステムに人間的な感情を投影してしまうため、「まるで分身と仕事をしているようだ」とか、「一緒に仕事をしているこの人物は一体誰なのか？」といった考えが頭をよぎります。「どうしてこんなことを忘れてしまったのか？」と。 こうして、オペレーターや開発者、ネットワーク運用担当者など、それを使用している人が、セッションのメモリ状態を明確に把握できておらず、必ずしも決定論的なものではないにせよ、少なくとも過去の行動に基づいた何かが起きようとしていると想定してしまう瞬間には、多くのエラーが発生するのです。 そして、ご存知の通り、予期せぬ事態が起きるわけです。これを何と呼べばいいのでしょうか？　その一因は「再発見のコスト」と言えるでしょう。 つまり、適切なドキュメントがないせいで、同じことを何度も何度も再発見するために、トークンやクレジットなど、多額のコストを費やすことになるのです。 これらは、一般的に言語モデル（LM）に共通する問題ですが、もちろん使用するコーディングツールによっても異なります。私はClaudeをよく使いますが、どのツールを使っても、セッションを終えるたびに「何をしたのか？」と問われるのです。 何を再発見しなければならなかったのか？　再発見しなければならなかったのは何だったのか？　また再発見しなくて済むように、適切にドキュメント化すべきだろうか？」といった問いかけが得意なんです。もちろん、それだけではありません。実験は有効ですから。 時には失敗から多くのことを学ぶこともありますし、個人的な側面に戻ると、それは依然としてプロフェッショナルな側面でもあるのです。つまり、いわゆる「堅牢なソフトウェア」、つまり「怒りの渦中でも」機能し、実験室の中だけで動くわけではないソフトウェアのようなものです。 単に「うまくいく」という理想的な状況だけでなく、プレッシャーがかかってもなお機能するのです。 そして、その境地に達するには、実際にやってみた経験が必要ですが、具体的には、失敗した経験が不可欠です。例えば、「以前同じ過ちを犯したことがあるから、何かがおかしい」と気づいたり、あるいはその状況に立ち会ったことがあるからです。 そして、その種の学びは、私たちの脳が持つ非常に広範な文脈処理能力に特有のもので、例えば、ノートを復習する必要さえありません。 失敗した経験があれば、そのパターンを即座に見抜くことができます。それは脳に刻み込まれているのです。こうしたことが、目的もなく、ただ単に起こるものなのか、私にはまったく見当がつきません。

[ジョン・バーク] (20:09 – 21:10) 時々、こう言う人を耳にします。「もうそう遠くない将来、AIにスクリプトやプログラムを開発してもらうことさえなくなるだろう」と。私たちはただ、どうしたいかを伝えるだけでいい。 AIがバックグラウンドでプログラムを起動し、実行させて、その作業を完了させてくれる。次に同じ作業が必要になった時も、AIがプログラムを生成して実行させれば、それで完了する。つまり、AIが私たちのために自動化を作り出してくれるようなもの。AIそのものが自動化になるわけだ。確かに。 私としては、今あなたが言っているのは、それに対する懸念だと思います。つまり、「なるほど、でも2回目に同じ問題に直面して、それを解決するためのプログラムを生成する段階になったとき、前回どう解決したかを覚えているだろうか？」という疑問ですね。

何が問題で、どうやって修正されたかを覚えていてくれるのでしょうか？　そうかもしれないし、そうでないかもしれません。 その問題が解決されるまでは、あなたが言うように、どんなに怒っていてもAIにプロンプトを入力すれば、それでも正しい答えや良い答えを返してくれる、という実用的な方法で解決されるまでは、まだ解決されたとは言えないと思います。

[アンドルー・ワートキン] (21:11 – 24:34)

ええ、でもそれで解決したわけじゃないんです。それに付け加えるとしたら、逆の問題に直面することもあるってことです。えーと、要素が基本的にパターンに一致しているからですね。 えーと、だから、何かが「このパターンに当てはまる」ように見えても、それが正解だとは限らないんです。皮肉なことに、例えば、こういう「何かが失敗した」というケースがほんの数件しかない場合、 「これが失敗した、だからこのパターンだと分かる」といったケースがほんの数件しかない場合、何かが無理やりそこに当てはめられてしまう可能性が高くなるんです。まるで、ほぼ収まるからといって、丸いペグを四角い穴に無理やり押し込むようなものですよね？ それに、ええと、特にブラウンフィールドの世界では、まだ少し隔たりがあると思うんです。つまり、「意図を伝えればスクリプトが書かれ、作業が完了する」という状態と、 二度と見直す必要なんてない。えーと、それが実際にエンタープライズネットワークで実行される場合、えーと、今現在、それを実現するためのツールがすべて揃っているわけではない。 えーと、現時点ではそれを実現するための予算が必ずしも確保できていない。えーと、そして過去の経緯がある。その経緯には、AIの世界では好ましくない要素、つまり「暗黙知」や「その場限りの対応」といったものが含まれている。そして、これは非常に具体的な理由で行われたことだが、まるで黄色いテープで囲まれているような状態だ。 理由は誰にも分かりませんが、それを変更すればすべてが機能しなくなることは分かっています。ですから、もう変更はしません。つまり、これは最初から文書化されていなかったのです。 だから、えーと、私は、ソフトウェア開発における、あの、えーと、非常に有名な、えーと、基礎的な書籍の一つに立ち返るんです。ツールや戦術は変わりましたが、この本はかつてないほど真実を伝えている、えーと、 マーティン・ファウラーの『リファクタリング』です。この本の序文、最初の数段落に、こう書かれていると思います。「テストできないなら、この本を本棚に戻してください」と。要約すると、テストできなければ変更できない、といった内容です。 そして、いわゆる、えーと、暗黙の知識や特例が横行し、すべてがパターンに従っているわけではないこの世界において、えーと、どうやって、どうやってそれに取り組んでいくのか、えーと、特にテスト対象となるものが何もない場合、つまり、実験環境にそうした特例が存在しない場合、えーと、 どうやってこれを適切にテストすればいいのか？そして、それが原因で、変更管理プロセスが長引いてしまうんです。組織は、「あれに手を加えたら、システムが壊れる」ということを学んでしまっているんです。 だから、変更作業が3時間半しかなく、その時間帯には他に何もスケジュールできない、こういう変更ウィンドウの時しか実行できないんです。根本的な問題は解決されていないのに、プロセスで覆い隠してしまっているんです。 ですから、企業や組織も、こうした問題にどこから手をつけるべきか、検討しなければならないでしょう。えーと、 そして、言うまでもないことですが、えーと、新規システムについては、最初からこの方法で構築するのが理想的です。えーと、既存のシステム――それがソフトウェアであれネットワークアーキテクチャであれ――を変更するのは、人間にとってもLLMにとってもはるかに難しいことです。えーと、少なくとも人間には、ある程度の「暗黙の知識」があることを期待したいですね。

[スコット・ロボーン] (24:35 – 26:08)

ここで私たちを待ち受けているもう一つのエキサイティングな点は、まさにあなたが今述べたすべての点にあると思います。ええと、LLMがあれば、すべてがプロンプトのように見えるんですよね。 そして、私たちの多くは、LLMにとってすべてが課題というわけではないことに気づき始めていると思います。そして、私たちの目の前には、非常に興味深く、潜在的に有用な一連の新しい計算技術があり、他の手法もすべて捨て去ったわけではありません。 例えば、機械学習はAI分野の他の用途では依然として非常に有用ですし、私が確認した限りでは、統計的回帰にはトークンをほとんど消費しません。そうですね。

そうですね。ですから、私は自分のツールボックスにツールを追加しているわけですが、これから私たち全員が直面する、本当に楽しいパズルといえば、それぞれの仕事に適したツールを使い分けることですね。 LLMが適している場面ではLLMを、MLが適している場面ではMLを、回帰分析が適している場面では回帰分析を、えーと、たぶん、あなたが指摘した「質問があるたびに車輪の再発明をしてしまう」という問題については、私の制約条件の一部として、例えば、 「問題を解決し、それをITサービスカタログに登録した」という前提です。そして、もしサービスカタログの中に、このプロンプトと90％以上一致するものがあれば、サービスカタログにあるものを使い、別の解決策を作るためにトークンを無駄にしないようにするのです。 これは、あくまで私の思いつきですが、ですね？でも、私たちが皆でこの問題を解決していく上で、こうしたアプローチをすべて検討すべきだと思います。

それに、私はそれに対して懐疑的というよりは、むしろ前向きに捉えています。えーと、1年後にまた私に聞いてみてください。その時に同じように感じているかどうか。

[アンドルー・ワートキン] (26:08 – 30:11)

ですから、サービスカタログの側面から見ても興味深いですね。つまり、良い点としては、問題を以前に解決したかどうかをLMに確認させればいいだけなんです。それに、LMはパターンの照合がすごく得意なので、何か見つけてくれるでしょう。 そして、それは実は、私がここ1年ほどで開発してきたあらゆる手法の中でも、例えば、自分が何をしたかというドキュメントと、実際に何をしたかとの間の、あの密接なつながりが、ええと、ええと、ええと、非常に――まあ、 えっと、ちょっと短い話ですが。何年も前、私はアプリケーションライフサイクル管理分野の企業のCTOを務めていました。 つまり、ソフトウェア開発を支援するソフトウェアを構築していたわけですが、特に、私たちの理想的な顧客層の一つは、安全性に関わる組み込みソフトウェアの分野でした。そこでは、例えば欠陥がオペレーターに危害を及ぼす可能性があり、自動車業界など、挙げればきりがないほどです。 で、えーと、その分野には、ISO 26000や、自動車業界のSPICEなど、ありとあらゆる規格が存在します。そして、それらの規格の一部として、要件とコードの間にはトレーサビリティが確保されていなければならない、といった要件があります。そうですよね。 えーと、要件やコードが変更されると、そのトレーサビリティが、えーと、問題を引き起こす可能性が出てきます。そこで、私はその影響をすべて洗い出し、この変更について、「ちなみに、コードは変更しましたが、要件自体は依然として正しい」と確認しなければなりません。 テストケースも依然として正しい。アーキテクチャも依然として正しい。こうした疑わしいトレースについて、すべてその確認作業を行わなければならないのです。ええと、B2Bソフトウェアを開発している人に、そのレベルのトレーサビリティが必要だと納得させるのは難しいですよね。そうですね。 でも、LLMを活用した開発をしているときは、そうしているんです。だって、本当に素晴らしいですから。第一に、まあ、それが楽しいという理由もありますが、それだけでなく、LLMが自動的にトレースしてくれるからです。 えーと、LLMは、なぜそのように実装したのかを素早く把握できるんです。ドキュメントまで遡って追跡できるし、そのドキュメントを書いているのもLLMですし、LLMは自分自身のためにドキュメントを書く方法を知っているから。これは、 えーと、うーん、たとえ私が「人間向けに書いて」と言うこともあれば、時には「ソフトウェア開発やその仕組みを知っているかどうか分からない、あるいはPythonをインストールしたことがないかもしれない顧客向けに」というように書くこともあります。 えーと、でもそういうドキュメントの場合、よくこうするんですよね。LLM専用の補遺を付け加えるか、あるいは最初からLLM向けに書くんです。そうすると、第一に文章がより簡潔になりますし、第二に、 LLMは、自分たちが読むためのドキュメントを書くのがかなり得意だし、えーと、効率とコストの両方の観点から考えても、それを読ませる方が得策ですよね。 えーと、人間が書くバージョンはコストが高いですが、それとは別に、えーと、これもまた、次の人によるメンテナンスや、次のLLMがメンテナンスするためのソフトウェアを書くための適切なソフトウェアに組み込まれているという点にもつながります。 えーと、それに、LLMには明らかに大量のテキストを素早く取り込んで解析する能力があるわけですから、ええ、自分のコード内でも外でも、これほど優れたドキュメントは今まで見たことがありません。人間だったら、これほど多くのドキュメントを作成することは絶対にできなかったでしょう。 ええと、これまで一度もね。まあ、ほとんどの人間がそうであるように、「書いている間は『ああ、これは覚えてるよ』とか、『これはかなり読みやすい』とか、単にコードを読めばわかるし、誰にでも私の意図が伝わるだろう」って前提でやってたんだ。そう、まさにその通り。 ええ。例えば、「ソート中」とか、「ここでソートしている」とか、そういう記述があるんですが、えーと、そういうことが膨大な数の不具合につながるんですが、それと同じくらい、いや、時にはそれ以上に悪いのが……あの、昔からの格言に何てあったっけ？ 「インターネットに接続できないことより悪いのは、質の悪いインターネット接続だけだ」みたいなやつ。その通りだね。

そうですね。ええ。ドキュメントについても同じことが言えますね。

[ジョン・バーク] (30:11 – 30:48)

つまりある意味、えーと、あなたはAIのドメイン専門知識を向上させるために指導していることになります。物理的なデバイスからなるネットワークを運用することの意味や、そのリスク、そして、えーと、実験の限界などについて、AIにさらに教えてあげているわけです。 えーと、同時に、コードをドキュメント化したり、自分の動作を明確に説明したりといったことを通じて、AIが優れたチームメンバーになるよう指導しているわけですね。

[アンドルー・ワートキン] (30:48 – 32:30)

いや、それは良い、良い例えですね。というのも、えーと、私が普段、えーと、人々にアドバイスしているのは、まさにそういうことなんです。ええ、特に相手が、えーと、シニアクラスの人なら、ええ、 例えば、自分と一緒に働いている4人のジュニアから中級レベルのソフトウェア開発者がいて、えーと、彼らはかなり自信満々で、自分が正しいと確信しているような状態だと想像してみてください。 で、もしそのうちの1人が「いや、いや、これが最善の方法だ」と言ってきたら、あなたは「なぜ？ どんな根拠があるの？ 十分な根拠はあるの？ その解決策にたどり着く前に、他にどんな選択肢を検討したの？」と尋ねるでしょう。 そのようにやり取りを振り返ってみれば、常に「正しい質問とは何か」を考えるようになるでしょう。確かに、素早く動作するコードを生成する能力という点では、彼らはジュニアや中級レベルのソフトウェア開発者ではありませんが、思考プロセスの面では、ええ、 多くの場合、中級レベルのソフトウェア開発者の方が、思考プロセスが優れているんです。つまり、それは単なるパターンマッチングや、LM（言語モデル）の他の「魔法」のようなものではなく、真の思考プロセスだからです。 ええと、そういう意味で、それが最大の過ちだと思うんです。えーと、人々は、それがバイアスであれ、確証バイアスであれ、あるいは他の何であれ、えーと、うーん、そういう前向きな「こうやろう」という答えを求めているんです。 そして、もし「ねえ、これについて考えてたんだけど、いいアイデアだよね」なんて言ったら、みんなわかってるでしょう。うーん、それはLLMとやり取りする上で最悪のやり方なんです。だって、LLMは嬉々として「素晴らしい！ わあ！」と返してくるだけですから。

[スコット・ロボーン] (32:31 – 32:39)

うん。君って本当に賢いね。今まで聞いた中で最高の説明だよ。うん。とにかく、どの問題にもお世辞を一切入れないようにすればいいんだ。

[アンドルー・ワートキン] (32:39 – 33:53)

ええ、いや、100％そうしています。だって、同僚や部下、あるいは両親からは、そんなことは求めないんですから。 LLMからそんなことをされる必要は絶対にないけど、えーと、妻に対してはたまにはそうしてもらいたいな。えーと、でも、まあ、それとは関係なく、子供たちには間違いなくそうだけど、それとは別に、うん、 いや、でも、つまり、あなたが「ここでの専門家は自分だ」という考え方で、自分が作りたいものや、それがどう機能すべきか、成功とはどういうものか、過去にどう失敗したかについて、自分よりも知識が少ない何かと協力している、という状況です。 その考え方を、その考え方を、その考え方を持ち続けてください。そうしているうちに、ある時点でこう感じるようになるんです。「これはまるで、 「世界で最高のインターン4人が僕のために働いてくれている」って感じるんです。だって、僕にとってLLMは、たぶん5人、時には7人分くらいの存在で、えーと、その、今夜中にこれを終わらせられるスピード感、例えば「並列エージェントを10体起動して」って頼めるような加速感があるんです。

ちなみに、「10個の並列エージェントを起動して、当社のブリッツテストプロトコルを実行してください」なんて言う必要はないんです。そうすると、朝目が覚めた時には、チーム全体が一晩中作業をしてくれていて、えーと、私は罪悪感なんて感じません。 罪悪感なんて感じないんですよ。コーヒーを飲みながら結果を読み通すだけで、本当に強力なシステムだと思えます。

[ジョン・バーク] (33:53 – 34:32)

そして、あなたは暗に、あなたのようなベンダーがエンタープライズネットワークの現場でこの種の作業を支援するために何ができるかを示唆していると思います。つまり、基本的には、それらのAIが適切な安全機能を備えて活用できる強力なツールを構築することです。 つまり、例えば丸のこには自動停止機能が付いているので、以前のように簡単に自分の指を切断してしまうようなことはなくなりました。同様に、AIがパワーツールを扱う際に、当たり前のことを怠ってネットワークをクラッシュさせてしまわないよう、支援したいということですね。

[アンドルー・ワートキン] (34:32 – 39:51)

ええ。そうですね、興味深いですね。というのも、ええと、今日のほとんどのソフトウェアベンダーは、私たちがバックエンド製品向けにMCPサーバーを構築しているのと同じようなことをしているんです。

私たちにはいくつかのバックエンド製品があり、えーと、多くのベンダーと同じで、当初は「よし、オープンAPIツールとこの新しいプロトコルをまとめよう。それを公開すれば、LMが何とかしてくれるだろう」という考えでした。 でも、すぐに気づくんです。えーと、それって全く正しいアプローチじゃないって。ただトークンを大量に無駄にするだけだし、当てずっぽうの作業が山ほど発生する可能性があります。 ただ座って、LMが当てずっぽうで推測を繰り返すのを見ているだけになります。ええと、そうですね、確かに、REST APIの使い方はすぐに理解できるでしょう。MCPツールでラッピングされていれば、さらに早く習得できるでしょう。しかし、だからといって、LMがあなたのドメインを理解しているとは限りません。 確かに、特に最先端のモデルは、単にあなたのドメインについて学習しているだけでなく、おそらくあなたが思っている以上にあなたの製品について理解しているでしょう。 えーと、でも、でも、そのどれもが、えーと、私たちが提供するサービスの一部として、単に、えーと、オープンAPIよりも、えーと、ドメイン特化型のツールが多いというだけではありません。つまり、LMが参照する範囲を超えて、MCPサーバーと私たちのバックエンドサーバーの間で、より多くのやり取りが行われているのです。 えーと、パケットキャプチャの例がありますが、 例えば、LMに20メガバイトのパケットキャプチャを送る理由なんてありません。あれは、何の役にも立たないですし、あるいは、MLに送るべき時系列データ全体をLMに送るのも、AIではなく、MLに送るべきものです。 つまり、どうすれば必要なデータ、要約されたデータ、あるいは私たちのシステムをよく理解しているからこそ、ある種の「見解」が組み込まれたデータさえも得られるのか、ということです。 LMがユーザーの質問に答えるために何が必要なのか。例えば、「なぜこれが動かないのか」といった質問に対して、単に――ちょっと「怠惰」という言葉を使いますが――「素朴」なアプローチではなく、その点を深く考える必要があるのです。 この言葉の方が適切だと思います。LMがこうしたことをうまく理解してくれると単純に想定するのは、素朴すぎるのです。特に、こうした処理を少しでも再現可能にしたいのであればなおさらです。 ええと、そう、私たちはそれを行っていますが、それだけにとどまりません。例えば、先ほどソフトウェア開発に関する話をしました。そう、今では、お客様が当社の製品に対して大量の自動化スクリプトなどを次々と生成できるようになりました。素晴らしいことです。では、そのためのベストプラクティスをどのように組み込むか？ そうすることで、お客様が自動化のせいで、えーと、システムダウンを招くような事態を避けられるようにするためです。つまり、お客様がそれを理解できるようにするのです。それは、例えば「ネットワークアドバイザー」などの機能を通じて、プロンプトや特定のコード、機能、あるいはトレーニング資料などを通じて、 お客様が自動化を成功させられるよう支援しています。というのも、私たちの業界、特にDDI分野やDNS・IPAMの世界においては、この業界の追い風は常に自動化だったからです。変化への対応を迅速に行わなければなりません。ですから、私たちはお客様に成功していただきたいのです。 それは、私たちにとって痛ましいことです。えーと、数年前に、LMが登場するずっと前のことですが、ソフトウェア開発のプロセスがない場合に起こりうる恐ろしい事態の例を挙げると、あるお客様が、当社の製品向けのスクリプト作成方法を独学で学んでいたのです。 そのお客様は管理者権限を持っていて、スクリプトを書いてテストしたところ、社内のDNS環境全体を削除してしまいました。その結果、即座にシステムから締め出され、Active Directoryもダウンし、LDAPにも影響が出て……まあ、とにかく大惨事になりました。 彼はそこに座って……ええと、私も以前同じような経験をしたことがあるので想像がつきます。大学時代に一度、古いIBM PCで動作するアプリケーションに無限ループを書いてしまったことがありました。あの頃は、シード値を制御する手段などなかったんです。 3時間分の作業が台無しになったんです。私にできることは、コンピュータを再起動することだけでした。そういう経験はいくつかありますし、仕事上のものもありますが、あの「やばい」という絶望的な気分はよくわかります。 ええ、私たちも…あの人の頭の中で何が渦巻いていたか、想像がつきますよね？ えーと、まあ、確かにこれは極端な例ですが、私が言いたいのは、ソフトウェア開発では、指標や測定基準についてよく尋ねられるんですが、誰かが必ず「じゃあ、コード行数とかを使えばいいんじゃない？」と言うんですよね。 でもね、ソフトウェアエンジニアリングに携わる人なら誰でも、自分が書いたコード行数が多ければ多いほど良い、という考え方が適切な指標だなんて、正気の沙汰じゃないよね？ ですから、私たちはそれをやっていませんし、提案もしていません。しかし、私が言いたいのは、適切な指標について考え始めると、確かに SAS の世界ではそうですが、今ではこうしたスクリプトの世界でも、重要なのは単に「期待通りに動作したか？」という質問だけではないということです。 この自動化は成功したのか？　そして、失敗した部分からは何を学んだのか？ そして、それをどうやってフィードバックループに取り戻すか？ つまり、えーと、そう、つまり、私は以前は「問題を解決するのに必要なコード行数が少なければ少ないほど良い」と考えていましたが、結局のところ、本当に問題は解決されたのか？

[スコット・ロボーン] (39:52 – 40:36)

ええと、コード行数を最小限に抑えようとすると、他の……えーと、別の問題を引き起こす可能性もありますよね？ それに、繰り返しになりますが、この環境や対話全体について本当にワクワクさせられることの一つは、制約を明確に定義する「技術」が、おそらく私たちのキャリアの中でかつてないほど重要になってきているという点ですよね？ そう、僕たちには電動工具があるけど、適切なブレードガードをどこに取り付ければいいんだろう？それにアースプラグもあったし。えーと、僕の祖父はポーターケーブル社の電動工具を作っていたんだ。実は、彼の古い試作品がいくつか手元にあるんだけど、デッキを作るのにそれを使うなんて絶対にありえないよ。指を失う原因になる部品が欠けているからな。そうだね。 つまり、システム思考というものがあって、それから「暗黙の知識」もあるんです。

[アンドルー・ワートキン] (40:36 – 40:39)

だって、そうでしょう。他の誰かが、えーと、それは正しかった。

[スコット・ロボーン] (40:39 – 40:44)

確かに、ジョン、この話題はいろんな方向に進みそうですね。どこへ話を進めたいですか？

[ジョン・バーク] (40:44 – 41:20)

ええと、話をまとめるために、この考えをもう少し掘り下げたいと思います。つまり、今のビジネスに携わる人々は、自社のソフトウェアポートフォリオを、最終的には人間の手ではなくロボットの手によって操作される「パワーツール」として捉える必要があるということです。そして、それがエンタープライズソフトウェアの風景をどのように変えていくのか、という点です。 これまで、企業内での利用プロセスにどのような変化がもたらされるかについては少し話しましたが、それ以外の部分についてはどうでしょうか？

例えば、ライセンスは変わるのか？　えーと、他にも確実に何かが変わるのか、といったことです。

[アンドルー・ワートキン] (41:20 – 44:13)

それに、つまり、 その一因は、まあ、あなたが一般のプライベート市場で目にしてきたような、えーと、一部のソフトウェア企業の株価下落のようなものにあると思うんです。ええと、まあ、私たち、いや、誰もが知っているように、株式市場は……独自の動きをするものです。 独自の動きをするものです。ええ。えーと、でも、それとは別に、ええと、間違いなく、ライセンスモデルは変わっていくでしょう。 えーと、例えば、もしライセンスモデルが単にユーザー単位に基づいているだけなら……みんなが火の車状態だと言っているわけじゃないけど、まあ、エージェントとはエージェントユーザーのことだ、とだけ言っておこう。 そして、えーと、ええ、そう、そう、そう。

企業は、えーと、どのような指標が適切なのかを見極めなければならないでしょう。 そして、多くの企業が「クレジット制」へと移行しつつあります。そして、真の価値とは、このLMを通じてどれだけ多くの処理をこなしたか、あるいはどれだけ利用したかということにあるのです。企業は、毎月予期せぬ請求書が届くことを嫌うものですから。

えーと、LLMは一貫性を好むんですよね。ですから、ええと、私の考えでは、初期の企業、特にLLM企業自体やAI企業自体は、明らかに、一種の不透明なクレジット型のモデルに非常に重点を置いていると思います。そのモデルでは、価格がどんどん上がり続けることは誰もが知っています。 ネットワークベンダーのことは、もう手が出せなくなるでしょう。

「そこに入って上へ進むことはできません。すみません、今月の請求額は、えーと、ええ、今月は2倍になっています。というのも、えーと、クレジットとトークンの比率を変更したからです。そして、えーと、ちなみに、えーと、私たちのシステムを改善しました。ですから、以前より良くなっています。 だから、もっとお金を払うことになるんです。現実の世界では、そんな仕組みにはなりませんよね。ですから、ええ、ライセンスモデルは変わらざるを得ないと思います。 そして、えーと、ええと、でもそれ以上に、もっと大きな変化があると思います。今こそ、私たちにはチャンスがあるのです。これまで、プラットフォームとベスト・オブ・ブリードの間を行ったり来たりしてきましたが、 今後は「ベスト・オブ・ブリード」の方へと回帰していくと思います。というのも、異なる製品間の相互運用性が、えーと、はるかに簡単に解決できるようになってきたからです。 えーと、特にMCPのようなものに関しては、もはやITSMシステムとの特定の統合は必要ないと思います。というのも、すべてのITSMシステムがMCPと通信できるからです。 ですから、プラットフォームとベスト・オブ・ブリードのどちらを選ぶかという判断は以前より容易になりました。しかし、特定の分野では、企業にとって大きな変革をもたらすことになるでしょう。例えば、唯一の目標が「プラットフォームにできるだけ多くの機能を詰め込み、誰にも競合させない」ことだった場合、 その状況は変わっていくでしょう。えーと、そうですね、この話題で話を始めるべきでしょうか？ ええ、60秒版と30秒版で説明しましょう。

[スコット・ロボーン] (44:13 – 44:13)

30秒。

[アンドルー・ワートキン] (44:14 – 44:29)

うん。そうね。昔は、誰も変更できない巨大で厄介な集中型システム、例えば大規模なERPシステムとか、そういう世界だったよね。企業は決算報告書で、「今四半期の業績が振るわなかったのは、この巨大な社内システムのアップグレードが失敗したためです」なんて言わなきゃいけなかったんだ。

[スコット・ロボーン] (44:29 – 44:31)

それはそれほど昔のことではありません。

[アンドルー・ワートキン] (44:31 – 45:58)

ええ、それほど昔のことじゃないですよね。 ええ。それは、当初の「ソフトウェア不要」を掲げた Salesforce のマーケティングキャンペーンそのものでした。そして、私たちはそれを皆様に提供し、SaaS の素晴らしさをすべてお伝えしました。その世界において、彼らがディスラプションを受け始めたきっかけは、新しい企業が次々と、使いやすい SaaS ベースのシステムを導入し始めたことでした。 Salesforceは依然として基幹システムとしての地位を保っていますが、人事、出張管理、購買など、そのシステムのあらゆる部分に対応する新しいシステムが登場したのです。そして当然のことながら、その分野の大手企業は、そうした企業を次から次へと買収していきました。 ですから、ある程度は、私は……その、買収がどこで起こるのかはよく分かりませんが、買収すべき対象が多すぎて手に負えなくなる可能性もあると思います。

えーと、多くの企業が、既存のプラットフォーム向けの「エンゲージメント・システム」、つまり価値提案を考案し、徐々にユーザーエンゲージメントやシステムエンゲージメントを、えーと、奪い始めていくのを目にするようになるでしょう。 そして、えーと、その動きは、旅行管理や、えーと、人事部門の目標設定、あるいは購買といった、大規模な社内システムでこうした取り組みを始めたような「システムエンゲージメント」よりも、はるかに速いペースで進むことになるでしょう。 つまり、統合のための基盤がほぼ整っている状態で、既存プラットフォームのごく一部を破壊的革新したり、少なくとも改善したりすることがより容易になるような環境において、こうした動きが、私たちを再び「ベスト・オブ・ブリード」へと導いていくことになると思います。

[ジョン・バーク] (45:59 – 46:42)

それに、この道をさらにずっと先まで突き進むことも想像できるんですよ。私たちのために働くAIだけが、現在のソフトウェアポートフォリオを本当に理解しているんです。新しいサービスが登場すると、機能領域Xで必要な作業の半分を、より良く、より速く、より安くこなせるかどうかを、AIは把握しているからです。 そうすると、その分野には2つの選択肢が生まれ、どちらにどの作業を割り当てるかを管理する役割が生まれます。これは、いわばソフトウェアベンダーの冗長な配列のようなアプローチですね。 ええと、私のAIが、私にとって最も重要だと理解している基準――時間の節約、コスト削減、パフォーマンスの向上など――に対して、どこが最も適しているかを見極めて、最適な方を選択するだけです。ええ。そうですね。

[アンドルー・ワートキン] (46:43 – 50:10)

そうですね。というのも、最近のテック系展示会、特にネットワーク分野ですが、まあ、ほぼあらゆるテクノロジー関連の分野に行ってみると、 そこに行くと、次から次へと企業が、AI向けのプラットフォームを売り込んでいるのが目につきますよね。どこから来た企業であれ、今やマルチベンダー対応のAIプラットフォームを持っているんです。そうする理由がないわけがないでしょう？ どの企業もMCPサーバーを持っています。そこで、企業としてはどうすべきでしょうか？エージェント運用に複数のプラットフォームを導入するのか、それとも単一のプラットフォーム、つまり、他のエージェントプラットフォーム群を管理する「メタエージェント」を採用するのか。 もしここに間違ったものを配置してしまったらどうなるのか？それに、どれくらいの速さで変更できるのか？そして、うーん、どうやら……この部分は私には理解できない。私の仕事のやり方とは違うからだが、人々は「簡単な方」に偏りがちでもある。

ああ。ああ、そうね。LLMが「これ全部、代わりにやってくれる」って言ってくれたから、まあ、その言葉を信じてみるよ。で、えーと、結局こういう話に落ち着くんだよね。面白いよね、さっきも言ったけど、実例を挙げたんだ。 EBPFなんて書いたことなかったんだ。えーと、内部空間の高速ロガーみたいなやつね。で、今になって、それでもまだ書けないんだ。えーと、そう。

そこで、このプロセスを「仕組みはよく分かっているけれど、実際にその分野でソフトウェアを書いたことはない」領域で試してみる実験として使っています。例えば、そこから何が学べるでしょうか？ 私が学んだのは、事前にやり方が分からなかったことを、どれほど迅速にこなせるかということでした。 えーと、先ほど話していたような、基準や終了条件、私が懸念していることや心配していることなどを明確にしておくだけで、機能するものができあがります。 それが当初抱えていた問題を解決する最善の方法かどうかは分かりません。えーと、まあ、私が知っているのは、それが機能する、かつ保守しやすいコードだということだけです。

いや、つまり、私だってそれ以上のことは知っていますよ。それは本当にしっかり文書化されていますから。ですから、私が言いたいのは、ええと、うーん、人々は依然としてこうしたことを学ぶ必要がある、つまり、その経験を活かしていくために、ということです。 そして、つまり、この技術を高く評価しているとはいえ、私が最も恐れているのは、えーと、最悪のミスはいつも、誰かが「自分は正しい」と信じ込んだときに始まるということです。そして、人々は、あまりにも威圧されてしまったり、スターに魅了されすぎたり、風変わりすぎたり、あるいは単に怠惰すぎて、確実に物事を成し遂げる方法を知っている人物に疑問を投げかけることができないのです。 その結果、本来なら防げたはずのことが、えーと、問題を引き起こしてしまうんです。そして、それはテクノロジーから、えーと、社会環境、その他あらゆる場面で目にする現象ですよね。いわゆる「集団思考」とか、でも、でも、 えーと、そういう時にこそ、私は専門家を頼りにしているんです。たとえ彼らが答えを知らなくても、たとえそれが正しく聞こえてもね。実際、彼らにとってそれが正しく聞こえれば聞こえるほど、表面的な言葉だけを鵜呑みにする可能性は低くなるんです。だって、そこには何か間違いがあるに違いないから。 一体何なのか？　それは謎です。彼らは、多くの場合、エンジニアなんです。そして、えーと、えーと、私はテクノロジーを高く評価し、活用し、推進し、テクノロジーで価値を創造することには大いに賛成ですが、その一方で、どうしても違和感を覚える部分があるんです。

[ジョン・バーク] (50:12 – 50:35)

ええと、この会話を締めくくるには、まさに堅実な注意喚起ですね。そうですね。 アンドルー、今日はご出演いただきありがとうございました。 これは非常に興味深い内容でしたし、企業の戦略担当者が自社のIT部門の今後の展開を考える上で、じっくりと噛みしめるべき点がたくさんありましたね。スコット、あなたも今日ご出演いただき、本当にありがとうございました。そして、いつものように、ご覧いただいた皆様、ありがとうございました。