Google DeepMindでAI Studioのプロダクトリードを務めるローガン・キルパトリック氏が、AI時代におけるソフトウェアエンジニアリングの新たなルールについて語る。開発者ツールの統合やCLIの重要性、AIエージェントの台頭によるIDEの役割の変化、そしてボトルネックがコード生成からコードレビューやテスト実行へと移行している現状を指摘する。また、AIツールの進化によって数か月かかっていた環境構築やコード変更が数時間で可能になるなど、開発のあり方が激変する中で、エンジニアに求められる「センス」や「問題解決能力」といった普遍的なスキルの重要性を強調。さらに、数か月ごとに可能性が更新される現代において、自らの野心の基準をリセットし、知性を外部化しても理解までは外部化しないことの重要性を説く。
開発者ツールの統合とCLIへの回帰
ソフトウェアの構築方法を学ぶことに興奮したきっかけは、問題を解決できる能力でした。こちらはGoogle DeepMindでAI Studioのプロダクトリードを務めるローガン・キルパトリックです。今、この分野では3年前には起きていなかったような、本当に興味深いイノベーションがたくさん起きています。2週間ごと、3か月ごと、6か月ごとに、何が可能かが変わっていくのです。自分の野心のレベルをリセットしなければなりません。誰かがその会社を立ち上げるべきです。今の時代、本当に重要なスキルとは何でしょうか。ソフトウェアエンジニアリングのルールは変わりました。それではフルエピソードをお届けします。
昨日の基調講演、素晴らしかったです。
ありがとうございます。
反重力CLIを見て、とてもワクワクしました。
ええ、そうですね。
ますます多くのエンジニアが、CLIファーストへと移行しているように感じます。
私たちは、開発者が実際に活動している場所で彼らを迎え入れようとしているのだと感じています。そして、開発者の好みに関するこのようなストーリーは、今ほど重要視されているときはありません。これまで開発者のいる場所にアプローチするのは、実は難しかったと思います。SDK、CLI、IDE、エージェントマネージャー、そしてマネージドサービスをすべて構築するのはコストがかかるからです。反重力のストーリーが、まさにその全域にわたって具現化していくのを見られたのは素晴らしいことでした。IDEでも使えますし、エージェントマネージャーでも使えます。CLIも使えますし、Gemini APIのマネージドエージェントを通じて利用することもできます。これは本当にクールなことです。これまで実現できなかった、非常にユニークなストーリーだったと思います。そしてこれは、Googleが開発者向けに提供している50もの異なるAI製品のエコシステムをかき分けて進みたくない、単一の製品を提供してほしいという開発者からのフィードバックに基づいているのです。ですから、統合されたCLIへと移行していくGemini CLIの整理統合も、すべてそのフィードバックに基づいています。
なるほど。Gemini CLIはオープンソースでしたよね。反重力のものはオープンソースではないことに気づきました。
ええ、これは興味深いテーマですね。私たちは皆、反重力のチームとも、Gemini CLIのチームとも非常に緊密に連携しています。これが時間の経過とともにどのように落ち着くかは興味深いところです。私の感覚では、今は深く戦略的な選択としてそうしているわけではありません。ただ、オープンソースにするにはコストがかかるというだけの話です。当然、オープンソースにしないほうが、今ははるかに速く動くことができます。ですから、もし彼らがオープンソース化することを決定し、そこに注力したいと考えればそうするでしょう。しかし、私の感覚では、何か秘密にしたいことがたくさんあるから隠しているというような思考空間ではないと思います。ほとんどは運用上の問題です。そもそも、そのチームにそれを実行する専門知識や意欲があるかという問題もあります。Gemini CLIに取り組んでいたチーム、そして今では反重力の取り組みに多く携わっているチームにとっては、もしかしたらこれまであまり経験がなく、専門知識を持っていない分野なのかもしれません。ですから、どうなるか見守りましょう。どう落ち着くかですね。ただ、オープンソースのバリアントを求める人々のフィードバックは確実に目にしていました。
IDEの未来とAIエージェント時代のコードレビュー
ネット上のスレッドでも、IDEは死にかけているという議論を見かけました。エージェントがコードを生成し、適切なガードレールや、ハーネス（検証環境）の周りに適切なハーネス機能をエンジニアリングできていれば、生成されたコードを必ずしも見る必要はないからです。
そうですね。
プルリクエストで確認するかもしれませんし、仮にそこがボトルネックになったとしても、それはエンジニアとして解決すべき問題です。しかし、人々は本当にそうしているのでしょうか。IDEが死にかけているという説について、どう思われますか。
私の捉え方としては、必ずしもIDEが死にかけているわけではないと思います。ソフトウェアの構築方法が進化しているのだと思います。そして実際、ある意味では、関与するツールがさらに増えているというのは興味深いことです。ある意味ではツールが減り、別の意味ではツールが増えています。歴史的に以前よりもプルリクエストでのコードレビューに多くの時間を費やすようになるというあなたの例はまさにそうで、人間がコードを書くことを前提に作られた今日のコードレビューツールとは異なる、素晴らしいコードレビューツールをどのように構築するかという点に、より多くのイノベーションと焦点が集まるようになるだろうと想像しています。エージェントがコードを書く時代ですからね。ですから、焦点は確実に移動します。それでもエディタは必要です。ですから、反重力においてもエディタは存在しますし、今では好みのエディタに接続することもできます。お気に入りのエディタがあるなら、それを使い続けることができます。そして、開発者はいくつかの作業を行う必要があります。これこそが、バイブコーディングとジェネレーティブエンジニアリングの最大の違いだと思います。エンジニアはIDEに入ってコードを編集できる必要があります。多くの場合、おそらく主に何らかのエージェントマネージャーを使用することになるでしょうが、いざという時にはコードを編集し、エディタにしか存在せず、エージェントマネージャーの文脈には存在しないような豊富なデバッグツール群に目を通し、使用する能力が依然として必要です。ですから、IDEがなくなることはないと思います。ただ、開発者がIDEの外で過ごす時間は増えるでしょう。私にとってそれは、開発者ツールが変化し続けるという非常に自然なことに思えます。今日の開発者ツールは、10年前や15年前のものとは大きく異なっています。ですから、その部分についてはそれほど驚くことではありません。
同感です。ボトルネックは非常に近いうちにプルリクエストになるだろうと感じています。
そうです。これはGoogleの内部でもすでに感じています。私は今でも常にコードを書いていますが、そのコードは実際にまともなものです。負担は今、私が書いたコードをレビューし、フィードバックを与えるなどしなければならない、Google内の多くのエンジニアに移っています。ですから、負担は急速にさまざまな場所へとシフトしていると思います。コードレビューをスピードアップできれば、次はツール実行へと負担が移る、と数週間前にジェフ・ディンが私にコメントしてくれました。モデルが速くなり、仮にあなたのコードをすぐに瞬時にレビューしてくれる人間がいたとしても、今度はCI（継続的インテグレーション）の時間が問題になります。一連のテストをすべて実行しなければならず、あなたが優れたエージェントエンジニアで思慮深く進めているために多くのテストを用意しているとしたら、今度はそれが負担になります。ですから、ボトルネックはいたるところに分散していくでしょう。開発者や企業が、ソフトウェア作成プロセスのどこにボトルネックが移動したかをどのように測定しているかを見るのは興味深いことです。Googleには歴史的に素晴らしい文化があり、社内のエンジニアがソフトウェアを構築する際のボトルネックを取り除くために、この問いに答えるための膨大な計測機能が備わっています。
生産性の測定とAIモデルの進化
本当に日々解決すべきパズルですね。生産性をどのように測定するかという。なぜなら、それこそがマーケティングだからです。より効果的になれると、エンジニアはそれを実感します。しかし、コストも上昇しています。だからこそ、特にGPT-4o mini（3.5 Flash）のようにコスト効率が非常に高いモデルが登場したとき、これこそが私たちの目指す方向だと、とても興奮しました。たとえば、Cloud Codeには、よりハイエンドなモデルで推論して計画を作成し、より軽量なモデルで実行するというOpusプランのようなものがあります。3.5 Flashでの野心は、同じモデルを使ってその両方を行うことだと思います。それがゴールです。
ええ。そして、それがどこに着地するかについてのフィードバックが大好きです。これは間違いなく3.5ファミリーの最初のイテレーション（反復）であり、私たちがこのモデル・プロダクト・ハーネスの共生を行った最初のイテレーションでもあると感じています。私たちがハーネスを使用しているのと同時にモデルがトレーニングされ、それが実際にどのような影響を与えるかを考えています。歴史的にGeminiモデルについては、紙の上では素晴らしく見えても、現実世界のユースケースではあまり良くないというフィードバックがたくさんありました。私たちはこの1年以上、そのフィードバックを非常に真剣に受け止め、ベンチマークだけでなく製品自体の中でも同じように機能を発揮できるように努めてきました。ですから、そのフライホイール（弾み車）が実際に回り始め、すべての進歩が起きているのを見るのは素晴らしいことです。
少なくとも私のコミュニティにおいて、これを聞いているエンジニアにとっては、非常にハイエンドな領域にいる人もいれば、まだ足を踏み入れてさえいない人もいるかもしれません。聞いている人にとって、スキルは進化しています。あなたの視点から見て、今の時代に本当に重要なスキルとは何でしょうか。
良い質問ですね。それは、あなたが何をしたいのか、そして実際の仕事が何であるかによって異なると思います。ただ、間違いなく普遍的なスキルは存在します。つまり、「センス」が重要だと思います。ユーザーのバグ報告を見て、「ああ、この問題はこうやって解決すべきだ、そして私のエージェントにこのように問題を解決させるべきだ」と理解できるエンジニアであれば、そこにアルファ（優位性）があります。構築すべきソフトウェアは非常にたくさんあるため、エンジニアがそのソフトウェア構築の負担を引き受けてどんどん進められるようになればなるほど、大きな価値が生まれます。そして、ここでもボトルネックがどこにあるかを測定する話に戻りますが、ボトルネックの多くは、誰かが問題を報告したり、こういう機能が欲しいと言ったりした後に発生する、この人間同士のコミュニケーションループの中にあります。誰かが計画を立てて実際に構築し、ユーザーに届ける前に、人間がそのことについて話し合う長いピンポンゲームが存在します。そのピンポンのほとんどは、いくつかのケースでは非常に有用ですが、センスという側面は、いつピンポンをする必要があるかを知ることです。多くの場合にそれを理解しており、いつピンポンをする必要があり、いつ必要ないかを高い精度で知っていれば、プロセスは大幅にスピードアップします。それを実行できることには巨大なアルファがありますし、私が一緒に働く最高のエンジニアたちは、その問いに答える素晴らしい感覚を持っています。
AIエージェントと開発環境の構築
それはとても気に入りました。これから始める人、あるいはすでにジェネリックなツールを使って仕事をしている人が、このようなセンスを身につけるまでにどれくらいの時間がかかるのだろうかと思います。なぜなら、最初は一種の生産性の低下があると思うからです。新しいことに挑戦するときはいつでも投資が必要であり、その見返りは3か月後かもしれないし、6か月後かもしれません。それは好奇心や熱意、意欲にも大きく依存しますが、人それぞれです。人々がすべき最小限の投資とはどのようなものでしょうか。
ええ、確かに人それぞれです。そして、チームがどのようなセットアップをしてくれたかによっても異なると思います。たとえば、私たちはスタジオのエンジニアリングチームと多くの会話を重ねてきました。その会話の中で、私はエンジニアリングチームにこう言いました。「エージェントがスタジオのコードベースでたくさんの変更を行えるようにするために、人間の力で可能な限り最小限のセットアップで、必要なすべてのエンジニアリング情報の完全なコンテキストを取得したい」と。彼らは「わかりました」と言って、文字通り一連のスキルをすべてセットアップしてくれました。私は文字通り1つのコマンドを実行しただけで、実際にはそれだけで、チームのすべてのエンジニアが持つべき情報と同等のコンテキストを私のエージェントが持つことができました。もちろん完全ではなく、多少の損失はあります。しかし、文字通りその同じ日に、私はAI Studioのコードベースでプロダクションコードの変更を行っていました。ですから、セットアップがどうなっているかによっては、数か月かかる場合もあると思います。また、数日や数時間で済む場合もあります。興味深いのは、自分がどの状況に置かれているかを特定しようとすることです。どこにでも素晴らしいエンジニアはたくさんいるでしょうから、私たちがただそれをこなすのが得意な最高にスマートなエンジニアを抱えているからというわけではないかもしれません。私たちのテックスタックが、単にうまく機能しているだけかもしれません。私たちはすでにエージェント用のレール（制御仕組み）のようなものを持っていました。私たちが望むAIツールを追加するために必要なガバナンス構造がセットアップされていたのです。他の会社ではそれがもっと難しいかもしれませんが、最良のケースでは、文字通り私たちの時のように、それを実際に手に入れることができます。私はGoogleに入社する前に膨大なソフトウェアエンジニアリングの仕事をしていましたが、当初はプロダクト職のラダーでGoogleに入社したため、実際のエンジニアリングの仕事を多くやめていました。というのも、2年前のGoogleの社内インフラは、世界の他の開発者インフラとは本当に異なっていたからです。そのため、学習曲線が非常に厳しかったのです。ツールのいくつかは、10億人のユーザーを抱える製品にスケールするように設計されているため、たとえ10億人ユーザーの製品を使っていなくても、使用するのがいくらか困難でした。そして、このAIコーディング時代が、私を本物のプロダクションソフトウェアの変更作業へと引き戻してくれました。私はソフトウェアエンジニアであり、ソフトウェアを構築するのが大好きなので、これには本当に感謝しています。その意味で私は幸運だったと思います。しかし、それが起きるのを見るのは素晴らしいことでした。繰り返しになりますが、最良のケースでは、彼らがその日にスキルを構築し、私はその恩恵を受けてコード変更を送り始めることができたのです。
私が知っている最高のエンジニアたちは、組織から複数のチームにまたがるような大きな変革など、包括的なベンチャーを信頼されて任されています。チームに飛び込んでリサーチを行ったり、インパクトを与えたりする能力は信じられないほど価値があります。組織内でリスクが高い局面において、私たちは抱えている最高のエンジニアにそれらの権限を与えます。そしてその一部として、私が最近考えているのが「エージェントのエクスペリエンス（経験・熟練度）」です。コードベース内やチーム内で、何らかの形の経験を測定することはできるでしょうか。私が自分のスタックを持って入ってきたとき、どれだけうまく環境に慣れ親しむことができるか、そしてリポジトリ内の何がそれを可能にし、かなり迅速に生産性を上げることができるようにしているのか。
「エージェント・カバレッジ」という新しい概念
このことについて考えていたとき、チームにこのフレームワークを提示しました。他の人々がどう考えるか非常に興味深いですし、ぜひこの動画のコメントを読んで人々の反応を見てみたいと思っています。コードのテストカバレッジという概念は昔から存在しています。それと同じものをエージェントにも求めるということです。つまり「エージェント・カバレッジ」です。エージェントがオーケストレーションしているシステムについて、どれだけのコンテキストを持っているかをどのように測定できるでしょうか。驚くべきことに、これらのモデルは、そうしたコンテキストがまったくなくても、非常にスマートなことを数多くこなすことができます。しかし、もしコンテキストを与えたらどうなるでしょうか。「なぜこのシステムがこのように構築されたのか」「エンジニアが設計のトレードオフについて話し合ったチャットのスレッド」「このUI機能の設計レビューのミーティングノート」などです。そうしたコンテキストがあれば、実際のソフトウェアに対してそのコンテキストとカバレッジが存在すればするほど、より速く動くことができます。そして最良のケースでは、ソフトウェアについて作成されるコンテキストを継続的に更新するシステムが実際に必要になります。これは新しい領域だと思いますし、これについて考えているスタートアップはそれほど多くないと思いますが、誰かがその会社を立ち上げるべき非常に興味深い分野だと感じています。
それに、それはコード内にも存在する必要があります。それがもう一つの点です。なぜなら、エージェントはそこに行く必要があるからです。一つの簡単な例を挙げると、エージェントがより多くのソフトウェアを作成するにつれて、反重力の中などで作成される成果物は、この計画やウォークスルー、そして「私がやった50のことのリスト」「実行したテスト」といったチェックリストのようなものになります。しかし、実際にコードをコミットすると、それらはすべて消え去ってしまいます。ですから、レビューする立場として、ボトルネックがどこに移ったかという話に戻ると、コードレビューのプロセスは、成果物を作成したという事実とはまったく異なるものに見えます。仕事の証明（プルーフ・オブ・ワーク）が今や変わってしまったのです。開発者にとっての仕事の証明とは、かつてはコードを作成し、CIで実行されている一連のテストをパスすることであり、それだけでした。しかし、ボトルネックがコードの作成ではなくなったため、仕事の証明は今や異なっていると思います。
仕様駆動開発のフレームワークを実験している人々を見たことがあります。彼らは最終的に、エージェントだけでなくハーネス機能の周囲に構築したプロセスとガードレールを信頼し、具体的に望むものを明示しています。そしてレビューにおいては、変更の一部としてコミットされた仕様（スペック）をレビューするのです。これは魅力的で、とても気に入っています。
外部化できない「理解」とエンジニアの本質
私の主な収穫としては、この方法で非常に興味深いイノベーションがたくさん起きており、それは3年前には起きていなかったということです。私たちは皆、ある意味で、これがソフトウェアの構築方法だと思い込んでいました。会社がどのように運営されていようと、それがソフトウェアの構築方法だったのです。しかし、これほどの破壊が起きている現在、人々は「よし、10個の異なる方法を試して、どうなるか見てみよう」となっています。そして、もしかしたら仕様駆動開発が主流になるかもしれませんし、他の何かになるかもしれません。ですから、このレベルの実験が行われているのを見るのは素晴らしいことです。チームが物事を試すために何をしているかを読むだけで、とても楽しいです。
まるでお菓子屋さんにいる子供のような気分です。数年前、私はプロダクトの責任者をしていました。ビジョンや、より高い視点から責任を持つその役割をずっと望んでいました。しかし、物事が急加速したため、最大のFOMO（取り残される恐怖）を感じ、現場に戻らざるを得なくなりました。そして今、私の新しい役割は、どちらかというと生産性をベースにしたもので、エンジニア全体をどのようにレベルアップさせるかというものです。そこには異なる課題がありますよね。あまり気にせず、むしろそれを好む人もいれば、自分が築き上げてきた職人技に本当に誇りを持っている人もいます。コードを書くことはその大きな構成要素であり、それがゆっくりと失われつつあります。
彼らに対して、私はこう言います。個人的なホビープロジェクトという部分がまだ残っており、そこではいつでもそれを実行し、充実感を得ることができます。しかし、強力なストーリーが存在します。生成こそがまさにエージェントが得意とするものであり、エンジニアリングの能力はより高い視点へと移行しており、私たちはこれを機能させるために物事を積み重ねています。エージェントがあり、ハーネスがあり、その周りを構築しています。ですから、魅力的な時代です。
本当に魅力的です。私自身もこれを実感しています。私がソフトウェアの構築方法を学ぶことに興奮したきっかけは、問題を解決できる能力でした。コンピュータサイエンスの教育に立ち戻ってみると、キーボードのキーをたくさん叩くこととは独立して、それは世界を見る一種の方法なのだと思います。実際、私はこれについて法制度との類似性を引いています。法制度を勉強したことがなく、法律がどのように機能するかについて深い理解がない場合、世界は別の見え方をします。「真空の中にたくさんの法律があり、あちこちで速度制限に従う必要があり、税金を払わなければ何かが起きる」というように見えます。しかし、実際にはこれらすべての複雑なシステムがどのように機能しているのかという、深い感謝や理解の念を持つことはありません。そして、その理解を持っているとき、人は特定の方法で世界を歩み、特定の方法で世界を見ます。ソフトウェアも同じだと思います。私はコンピュータサイエンスを学び、システムがどのように機能するかを理解しているからこそ、世界を特定の方法で見ているのです。今日、私がキーを叩いている本人ではないという事実は、多くの場合、世界をそのように見ることにアルファがあるという事実を少しも損なうものではありません。抽象化レイヤーは変わります。しかし、問題を解決するスキル、そしてまさに、ソフトウェアを構築する技術とは、コードが走らない、問題がある、バグがある、といった状況において、本当に複雑な問題のすべてに取り組み、興味深い方法で物事を考えようとするソフトウェアエンジニアの中にレジリエンス（回復力）を構築するようなものです。それこそが考える技術であり、問題を解決する技術なのです。それは非常に有用なスキルです。ですから、私はコンピュータサイエンスの教育に対しても、世界でこの能力を持つ人々に対しても、非常に強気（強気な見通し）を持っています。問題を解決できるのであれば、世界は解決すべき問題で溢れており、それはエキサイティングなことだからです。
最近、デモブースの一つを見て、このことを考えました。そのデモは、自分自身のゲームを持てるというもので、私は裏側で何が起きているのかについてたくさんの質問をしました。彼らは1か月ほどでオープンソースとしてリリースするので、自由に遊べると言っていました。しかし本質的には、自分の考えを紙に書き出すだけでゲームが出来上がったのです。多少のやり取りは必要でしたが、結果はそこにありました。その時、私は自分のキャリアの進み方に満足していますし、今の自分の立ち位置にも満足していますが、この新しい世代に対して少し嫉妬を覚えたのです。なぜなら、私は制約の中で考えてしまうからです。子供の頃は、そのような制約はどんどん少なかったはずです。もし突然、たとえば私の弟やいとこたちをシステムの前に座らせて「ゲームをデザインしよう」と言ったら、彼らは私よりもはるかにクリエイティブになるだろうと確信しています。なぜなら、私は今や制約の中で考えてしまうからです。これこそが、私たちがリセットしなければならないことです。
そして、これは人間として最も難しいことだと感じています。私は自分自身にこれを言い聞かせるために、あなたにこれを言っています。しかし、2週間ごと、3か月ごと、6か月ごとに、何が可能かが変わっていくのです。私は人々にこう表現しています。「自分の野心のレベルをリセットしなければならない」と。これには両刃の剣があり、個人のプロジェクトを例に挙げましょう。私は個人のプロジェクトにおける野心のレベルを非常に高くリセットしたため、現在の私の基準はこうなっています。基本的には会社を設立するようなものです。もしこれがあちこちにあるミニ会社、自分が追いかけようとしているミニ会社にならないのであれば、やるべきではないかもしれない、なぜなら十分な野心がないからだ、と。しかし、それこそが実際に持つことができる野心のレベルだと思います。そしてクレイジーなのは、私自身、あなたもきっとそうでしょうが、常に野心的な何かを構築したいと願っていた人間だったということです。しかし、私にはどうしてもできませんでした。十分な時間がなかったり、実際、十分に優れたソフトウェアエンジニアではなかったり、適切なチームがいなかったり、理由は何であれ。それが今、完全に変わったのです。そして、それは非常に力強いこと（エンパワリング）だと感じられます。
そうですね。人々にとって優位性（エッジ）となるのはそこです。突然、仕事を探しているとき、あるいは特に今ポートフォリオをレベルアップさせようとしているとき、本当にクールなことを行うことこそが、あなたに優位性を与えてくれます。より簡単に足がかりを得られると感じます。採用側の視点や、これまで関わってきた事柄からも、それを実感されますか。
ええ、私はこの仕事の証明（プルーフ・オブ・ワーク）というセットアップが大好きです。この仕事の証明があるときは、いつでも採用が少し簡単になります。そして、私たちの会話の最初のテーマに戻ると、歴史的にオープンソースは常に素晴らしい例だったと思います。私がオープンソースコミュニティを愛し、初期のキャリアの多くをオープンソースに費やした理由は、それが多くの意味でパーミッションレス（許可が不要）だったからです。仕事を得ることや、インターンシップを得ること、ソフトウェアエンジニアリングの最初のインターンシップを行うことは、誰かを説得して彼らのコードベースに貢献させてもらうようなものです。そして世界で最もクールなことは、オープンソースであれば、誰のコードベースにでも、理想的には迷惑にならない方法でただ現れて、意味のある貢献をし、彼らに採用してもらう必要なく、実際にこの一部になれるということです。私は今でも、それが非常に強力な原動力であると考えています。そして今では、それ以上に重要なこととして、他人のところへ行く必要さえありません。もちろんオープンソースプロジェクトに行くこともできますが、実際にはただ自分でプロジェクトを構築すればよく、全体の主導権を握り、ストーリーやナラティブ、解決したい問題、そしてそれを市場に送り出す方法を自分でコントロールできるのです。その移行を見るのは非常に興味深いです。そして、本当に力強く感じられます。
それをどのように行うかが、私にとっては信じられないほど重要です。なぜなら、私はそこから多くを学ぶと感じるからです。しかし、私はとても好奇心が旺盛なので、複雑な中身を知りたくて質問をしますし、そこで知識を得ます。ただオートパイロット（自動操縦）で進めることもできてしまいます。違います、何かを構築しても、それが何であるか分かっていない状態になります。オートパイロットで進めることは可能です。
そこで、今の時代の最高の引用、私がTシャツにするかポスターにして掲げようと思っている最高の引用を紹介して、これで締めくくりましょう。私の部屋のポスターのマスコットになるような言葉です。「知性を外部化することはできても、理解を外部化することはできない」。ですから、非常に多くのことがあります。どのようなケースにおいて、両方を外部化してしまっても実際に問題がないようなものを構築できるのか、という歩むべき境界線のニュアンスが存在します。しかし、製品を構築し、実際のユーザーを抱えているにもかかわらず、それがどのように機能しているのか理解していないとしたら、それはおそらく悪いことが起きるレシピ（原因）になります。ですから、知性を外部化できるという事実を利用しつつも、理解までは外部化しないようにすべきです。そこにはまだ、膨大なアルファが存在すると思います。
ローガン、来てくれて本当にありがとうございました。とても楽しかったです。
I/Oに来て、この会話をしてくれてありがとうございました。
呼んでくれてありがとう。最高に楽しかったです。
いいですね。それでは。
コメント