本動画は、マイクロソフトのチーフ・デベロッパー・アドバイザーであるスザンヌ・ダニエルズをゲストに迎え、AI時代のソフトウェアエンジニアリングの未来について議論したものである。コーディングそのものの価値が低下し、問題解決や要件定義といったソフトウェアの全体設計こそが重要になるという視点から、AIツールの進化が開発者の生産性や役割に与える影響を分析している。さらに、ジュニアエンジニアがAIの普及を牽引する可能性や、プラットフォームエンジニアリングの重要性、オープンソースの未来、そして開発者が今後どのようにスキルを磨きキャリアを構築していくべきかについて深く掘り下げた解説が行われている。
ソフトウェアエンジニアリングにおけるAIと生産性の真価
あぁ、これで55倍も速くコードが書けるぞ、なんて言いますけれど、開発者として1日に何時間コーディングしているんですか？価値はコーディングそのものにあるのではなく、解決策を見つけることや、その解決策を定義することにあったんですよ。若手のエンジニアの方が、AIを受け入れる可能性が高いですね。彼らはこのテクノロジーに対してよりネイティブですし、まだそれについて強いこだわりを持っていませんから。彼らこそが変革の推進者なんです。
もしあなたが日々の業務、つまり仕事の中で実験的な試みができないのであれば、それは環境を変える十分な理由になるかもしれませんね。とにかく視野を広げてみてください。あらゆることに少しずつ目を向けるようにするんです。これは非常に変化の速い技術分野です。コーディングは安価ですが、ソフトウェアは高価なんですよ。
本日は、マイクロソフトのチーフ・デベロッパー・アドバイザーであり、30年近くの経験を持つスザンヌ・ダニエルズさんにお越しいただきました。彼女はおそらく、あなたと私の経験を合わせたよりも長いキャリアを持っています。今回は、エージェント型ツールを用いたソフトウェアエンジニアリングの未来や、私たちが現在手にしている技術、そして何より、ソフトウェアエンジニアとして皆さんがどのようにこれらを乗りこなしていくべきかについて語り合います。それでは、この対話をお楽しみください。
最近の大きなテーマとして、特に生産性向上技術やエンジニアに焦点を当てたトレンドがあると思います。これは過去にもよく言われていたことですが、今では「本当に実現するかもしれない」と人々が言い始めていますよね。この生産性への強調について、どのような見解をお持ちですか？
ええ、それは少し面白い質問ですね。AIの初期の頃は、主にコード補完やエージェントに作業を依頼することについて話していました。タスク、エージェント、人間といった関係ですね。当時の焦点は、それが実現可能なことだったので、生産性に当てられていました。でも、そのマーケティングがとても上手くいったので、私たちは「55倍も速くコードが書ける」なんて話をするようになったんです。
でも考えてみてください。開発者として1日に何時間コーディングしていますか？全体のうちのどれくらいの割合でしょう？14%くらいですかね。1時間と言う人もいれば、2時間と言う人もいるでしょう。確かにそれはとてつもないメリットですが、誤解しないでほしいのは、問題は「生産性だけが全てなのか」ということなんです。
今では、これらのエージェントやモデルがより強力になり、私たちがその操作方法をより深く理解するにつれて、品質の向上についても議論できるようになりました。私たちが望む成果の向上についても話せますよね。生産性の代わりに、イノベーションのペースについて話すこともできるわけです。だから、そこにはもっと多くの意味が含まれているんです。生産性というシナリオは非常にうまく機能したと思いますが、私たちはすでにその先へと進んでいます。
生産性はAI導入の最初の段階に過ぎないのかもしれません。少し時間が空いたから、その時間を使ってより多くを学び、エージェントについて、そしてそれらがどのように役立つかについてさらに理解を深めようとする。そうやって、どんどん価値を加えていくわけです。でも確かに、以前のマーケティングの観点から見ると、それはとても根強いイメージですね。もしかするとそうかもしれませんが、それが物語の全てではありません。
コーディングの価値から課題解決の価値へ
価値を生み出すことに重点を置くというあなたの考え方が好きです。私が常に喜びを感じてきたのは、必ずしもソフトウェアを作成する行為そのものではありませんでした。もちろんそこにも大きな達成感はありましたが、今一番進化しているのは、自分が目指している成果のほうだと思います。少なくともエンジニアとしては、そういった部分が私の原動力になっています。
ただ、エンジニアにもいろいろなタイプがいますよね。実際に手を動かすのが本当に好きな人もいれば、コードを書くという技術そのものに大きな情熱を持っている人もいます。「これはエレガントなコードだ。リファクタリングして本当に綺麗になった」と言うような人たちです。そういった職人的な部分が、今のところ最も影響を受けていると思います。
ええ、ソフトウェア開発を振り返ってみると、少なくとも私の意見では、かつて私たちがやっていたのは、問題や課題があって、解決策にたどり着くためのアルゴリズム、いわゆるコーディングの方法を考え始めることでした。でも、時間の経過とともにソフトウェア開発は大きく変わりましたよね。例えば、適切な要件を定義することは非常に多くの労力を要するため、それ自体が専任の仕事になりました。
ソフトウェア開発の他の部分を見ても、それが仕事になり、役割になり、他の人が担当するタスクになっていきました。つまり、ソフトウェア開発の本質を見てみると、その多くが実質的に剥ぎ取られてしまったんです。なぜかというと、私たちは人間だからです。大きな組織や大きなチームを抱えると、プロセスを考える必要があります。フローを維持し、次の人やタスクを引き継ぐ役割の要件を満たすために、引き継ぎが必要になります。
でも、それって本当にソフトウェアエンジニアリングなのでしょうか。私にはそうは思えません。私がソフトウェアエンジニアリングを始めた頃、その仕事の何が好きだったかというと、問題をしっかりと理解し、顧客が誰であるかを知り、それをビジネスからの目標とすり合わせて、どうすればすべてうまくいくかを考えることだったんです。
確かに、そのためにコードを書くことにも多くの時間を費やしました。しかし、価値はコーディングそのものにあったのではなく、解決策を見つけ出し、それを定義することにあったんです。フィードバックを得て、それを技術的な解決策に翻訳することに価値があったんですよ。そして今の状況を見ていると、私たちは再び初期の段階により深く関わるようになっているのがわかります。
これはますます進んでいくでしょう。ある時点で、製品づくりとソフトウェアエンジニアリングの境界線は存在しなくなると思います。もちろん、特定の役割を持つ人がいたり、あるタスクが他のタスクよりも得意な人がいたりして、コントロールを維持し責任を持つことはあるでしょうが、それはシームレスであるべきです。
成果を出すための運用に関わる追加のプロセス、つまり私たちが実際に取り組んでいるそのアルゴリズムは、AIによって解決されるようになるでしょう。AIが私たちの代わりにその作業を処理してくれます。そして、それがうまくいかない時には、私たちはまだコードの奥深く、細かい部分に潜り込むことができます。エージェントが理解するにはあまりにも最先端すぎることもありますからね。
でも、それはどちらかというと一部の作業になります。システム内部の仕組みをセットアップするように求められるような作業ですね。そして分かってきたことの一つは、実はそれこそが開発者の楽しんでいる仕事だということです。解決策を導き出し、成果を見つけ出すこと。ですから、状況は移行しており、変化しています。
コードを書くのが好きなコーダーにとっては、それは素晴らしいことだと思います。今でもLinuxのカーネルを書いている人たちはいますし、アセンブリ言語を書くことに熱中している人も、COBOLを書いている人もいます。それはすべて素晴らしいことです。状況は変わっていくでしょうけれど、それぞれの居場所でやるべきことはまだあるはずです。
若手エンジニアがAI導入の牽引役となる理由
おっしゃる通り、チームがこの新しい働き方を模索している今、私たちは本当にエキサイティングな時代にいると思います。私にとっては、自分の技術という領域でこれほど大きな影響を目の当たりにするのはおそらく初めてのことです。私はここでお聞きの方々やベテランの方々ほど長年の経験はありませんが、この変化を体験できるのは本当にクールなことだと感じています。
同時に恐れもあります。個人の能力が拡張され、生み出す価値がこれまでとは違うレベルへと進化しているからです。また、「シニア層は境界線を理解しており、これを活用して加速するための知識を十分に持っている」と評価する組織も見てきました。あるデータでは、シニアの求人は増えているのに、ジュニアの求人は実際に減少しているとされていました。
最近Redditで読んだ書き込みでも、「学位もあって学校の成績も良かったのに、何千件も応募してまだ仕事が見つからない」と嘆いている人がいました。これから市場に出てくるキャリアの浅い若手にとっては、少し懸念される状況ですよね。あなたは多くのエンジニアリングリーダーと関わっていると思いますが、これについてどう見ていますか？
ええ、興味深いですね。私たちがゆっくりと目撃しているこの状況に対して、研究結果は矛盾しているんです。AIのポジショニングに関する問題もあるかもしれないので、そこを批判するつもりはありませんが、多くの誤解があると思います。「AIがジュニア開発者の仕事をこなせるから、もうジュニア開発者は必要ない」という考え方ですね。
でも、これにはいくつか考えるべき点があると思います。最も重要なのは、ソフトウェア開発というスキルの性質上、その考え方は理にかなっていないということです。シニアエンジニアだけを雇うなんて不可能です。数が足りていませんから。今後数年間で予想されるエンジニアの数を見ても、実際に必要とされる数には全く届きません。だから、その考え方は少し直感に反していると思うんです。
もう一つの考え方は、実際のAIの普及状況を見ると、研究ではジュニアエンジニアの方がAIを導入する可能性が高いと示されていることです。彼らはこのテクノロジーにより馴染んでいて、従来の一部の人々が考える「古典的な開発者の仕事」の枠を超えていける能力が高いんです。彼らはまだ特定のやり方に固執しておらず、本来の職務記述書にある枠を超えてAIを活用することに意欲的です。彼らこそが変革の推進者なんです。そういう見方もできますよね。
私にはそれが完全に理にかなっていると思えます。そして私の予想では、いずれどこかの時点でこの傾向は崩れるだろうと見ています。ジュニアエンジニアがより柔軟にこの状況を乗りこなすことができるため、彼らの需要は高まっていくはずです。彼らは、ソフトウェアエンジニアリングに確実に存在するであろう多くの曖昧さにも対応できます。
一方でシニアエンジニアは、彼らの暗黙知やベストプラクティスを体系化する役割を担うことができます。そうすることでエージェントと人間の両方がそれを活用できるようになりますし、ジュニアエンジニアを育成するためにも彼らの存在が必要です。キャリアのどこかの時点でシニアソフトウェアエンジニアになれる人材を、安定して供給し続ける必要がありますからね。
さらに、プロファイルの変化もあります。専門分野を一つ持つ「T型エンジニア」だけでなく、異なる複数の領域に適性を持つエンジニアも増えていくでしょう。これは今起きている面白い現象です。しかし、スキル文化や現場の曖昧さなど、すべてを総合して考えると、今後数年間でおそらくそのような変化が見られるようになると思います。
私自身のキャリアの多くは若手としての立場でした。これまで、自分よりかなり若いチームと深く関わる機会はあまりありませんでした。私は今30歳ですが、最近、自分より若い人たちばかりのチームと一緒に仕事をする経験がありました。彼らは本当に良いエネルギーを持っていて、自分たちで色々と実験し、プロジェクトを前に進めようという強い意欲を持っていました。
それを見て、「ああ、私も昔はああだったな。まだこういう人たちがいるんだな」と思いました。経験を積むと、少し懐疑的になったり現実的になったりしますよね。何度か火傷をした経験があれば、それは当然のことです。でも、私はあのエネルギーが好きですし、あのエネルギーが懐かしいとも思いました。もし組織がそういうエネルギーを持たなければ、そこにいる人たちを本来あるべきレベルにインスパイアすることもできなくなってしまう気がします。
まさにその通りです。コーディングというのは、ツールについてだけの話ではなく、人についての話だけでもなく、文化についての話でもあるんです。そしてそれこそが、若手たちがもたらしてくれるものでもあります。彼らは、そのような文化を築くための変革の推進者になり得るんです。テクノロジーもまた、その点で私たちを助けてくれます。
AI時代におけるチーム文化とプラットフォームエンジニアリング
例えば、多くのお客様が実験している「3人」という数字を頭の中に思い浮かべてみましょう。それはプロダクトマネージャー1名と若手2名という構成かもしれません。よく逸話として、「それは悪夢のシナリオだ。彼らが何を作り出すか分かったものじゃない」と言う人がいます。エージェントが彼らの熱意と知識不足のせいで暴走し、最適とは言えないものや基準以下のもの、あるいは何かネガティブなものを作り出してしまうかもしれない、と。
でも、それは必ずしも真実ではありません。なぜなら、そのモデルをよく見てみると、これはもっと大きな変化、つまり文化に関わることだからです。先ほど、専門家たちが自分たちのベストプラクティスを体系化するという話をしましたね。私たちがプラットフォームエンジニアリングを正しい方法で導入し、コラボレーションや創造性、そして不確実性を受け入れるという原則がDNAに組み込まれているような文化を持っていれば、なぜ彼らがスクリプトから外れて暴走するでしょうか？
適切な成果を定義し、適切なガードレールや制約を設けて成功に向けたお膳立てをすることができれば、チームもエージェントもそこまで大きく道を外れることはありません。彼らが成功するための準備を整えてあげるんです。そして、そこには「どうすれば他者を成功させることができるか」という意識の転換があると思います。
マイクロソフトのハイパフォーマンス文化でもう一つ言えるのは、高いパフォーマンスというのは、誰か一人がスーパーマンのように一日中マントを羽織って活躍することではないということです。他者が成功できるように支援し、他者が次の素晴らしいものを構築できるように後押しする人こそが、ハイパフォーマーなんです。
それはごく自然な理屈だと思います。「エンジニアをAIに置き換えよう」と考えるのではなく、そのような視点から見るべきです。人間のやるべき活動が物理的に全くなくなってしまった場合を除いて、むやみに人をAIに置き換えるべきではありません。
強力な規律やガードレール、そして人々が開発を加速できるプラットフォーム。これらはプラットフォームエンジニアリングがもたらす多くの要素であり、摩擦があったり技術がバラバラだったりする環境で生じる問題の多くを解決してくれます。そして今のプラットフォームエンジニアリングは、これをエージェントを活用した働き方の中で機能させることに重点を置くべきだと感じています。これは本当に素晴らしいことです。
シニアが違いを生み出せるのは、このビジョンの中かもしれません。「私たちの知識に基づけば、これがベストプラクティスであり規律だ。これが価値を提供する小規模なチームの効果を高める要因だ」と提示できる場所ですね。他の組織でも、チーム内のシニアリティのバランスを含め、この働き方を実験しているところがあるのは非常に興味深いです。
ということは、今これを聴いている若手の人たちは、そういった組織を見つければいいということですね。
ええ、諦めないでください。これはキャリアの浅いすべての人へのアドバイスですが、とにかく視野を広げ、あらゆることに少しずつアンテナを張っておくようにしてください。この分野は変化が非常に激しいクラフトです。適切なUXについて知っておくことや、それを理解できることは決して無駄にはなりません。
セキュリティやプロダクトマネジメントなど、あらゆるトピックについて少しでも知っていれば、それはあなたがもたらす付加価値になります。だから諦めないでください。規模の経済を考えれば、今のままのモデルが持続可能ではないことは分かっていますから、いずれ状況は変わると私は見ています。
私の初期のキャリアでのインパクトの多くは、コミュニケーション能力や協調性があり、人と人との橋渡しができたことにあったと思います。ただ、少し恐れているのは、私がプロジェクトに入って一人で統合システムを構築しなければならなかった時のように、それは自分一人でできて楽しかった反面、ワンマンアーミーのようなタスクだったのでチームの他のメンバーとのやり取りがあまりなかったということです。今後、そういう働き方の選択肢がますます増えていくような気がします。
そうなると、大規模なチームとの相互作用は減るかもしれませんね。先ほど、3人が適正な規模かもしれないとおっしゃっていましたが、それは良いことでもあり悪いことでもあると感じています。ソフトスキルやコラボレーションの側面は依然として重要で、人と人との対話は多く残ると思います。しかし一方で、複雑さの一部はエージェントとの連携作業へと移行し、それが別の次元で増幅されているとも感じます。
今後身につけるべき知識と基礎原則の再評価
もしあなたが、キャリアの浅い人や、すでにエージェント型のワークフローを試している現役のソフトウェアエンジニアにアドバイスをするとしたら、彼らは今、ソフトウェアエンジニアリングの第一原理を見据えた上で、どのような知識に焦点を当てるべきでしょうか。あなたの視点を教えてください。
それは素晴らしい質問ですね。知識という観点では、もちろんコーディングそのものやエージェントを理解すること以外にも、良いアプローチがあります。私が実際に目の当たりにしているのは、私が生まれる前から存在するような多くの原則やフレームワーク、ベストプラクティスが、今になって再び脚光を浴びて磨き直されているということです。
ずっと昔からある原則やベストプラクティスはたくさんあります。特に仕様設計の部分、つまりソフトウェア開発ライフサイクルの初期段階において、それを目にすることが増えています。私がお勧めしたいのは、そういった原則をもう一度見直してみるということです。
ドメイン駆動設計についてすべてを深く理解する。それは素晴らしいことですよね。システムについてもっと理解を深める。あるいはSOLID原則など、今こそ身につけるべき知識のリストは山ほどあります。これらを学ぶことは今や難しくありません。しかし、これらの原則を理解していれば、仕様を定義したり制約を設けたりする際、つまり単なるコードではなく実際のソフトウェア製品を作る際に、極めて大きな助けになります。
あるマネージャーの言葉がとても素敵だったので紹介させてください。彼女も「コーディングは安価で、ソフトウェアは高価だ」と言っているんです。これは、ただコードを出力するのと、自分のやっていることに本当に意図を持ち、先人たちが何年もかけて研究してきたベストプラクティスや歴史を知っていることの違いです。
そういったものを学び、使いこなせるようになりましょう。「この方法の代わりに別の方法論を使ったらどうなるだろうか」と提案できる人になってください。それは本当に素晴らしいことだと思います。
強固な原則や基礎的な知識が、最終的には今でも役に立つと聞いて嬉しく思います。私たちはエンタープライズ規模でただ「バイブコーディング」をしているわけではありません。大抵の場合、何年にもわたって使われ続けるソフトウェアを作っているんですからね。
何かを作ることはずっと簡単になりました。正しい方法で作るという点でも私たちは上達していますが、これからは「作る」という行為自体が溢れかえるモードに突入していくでしょう。だからこそ、正しいものを正しい方法で作り、それが長く使えるようにしていく必要があります。
私がGo言語をとても気に入っていた理由の一つは、作成プロセスや最終的にコードとして目に見えるものが非常にシンプルだったからです。バージョンもいまだに1.x系で、今はたぶん1.20台くらいだと思いますが、メジャーバージョンは1のままです。つまり、コードを大きく移行する必要がなかったんです。アップデートがあってもシームレスで、そのプロセスは常にシンプルでした。他の言語と比べて、Goでは色々なやり方ができるわけではなく、そのシンプルさが好きでした。
また、Goは可読性が非常に高いのですが、生成されたソフトウェアを扱う上ではこれは素晴らしい特徴です。読みやすい言語であれば、今の時代、読む量ははるかに増えると感じるからです。これはプログラミング言語全般について話すときに面白い点ですが、エージェントによるソフトウェアエンジニアリングが、最終的に私たちが選ぶ言語にも影響を与えるのではないかと考えています。
なぜなら、私たちはエージェントが事前レビューしたものを、最終的にループの中にいる人間としてかなりの量レビューすることになるからです。これがどう発展していくかは分かりませんが、どう転ぶかを見るのは非常に楽しみです。
プログラミング言語の未来と自然言語による開発
これは、「すべてがJavaScriptになるのか」という質問に対する長い前置きですか？そうならないことを願っていますが（笑）。それについてどう見ていますか？
そうですね、もちろんあちこちで何らかの影響はあると思います。なぜなら、もしあなたがチェックしなければ、エージェントが選んだものをそのまま使うことになりますからね。でも一方で、エージェントが何を構築すべきかを定義しているのは誰でしょうか。通常は、依然として私たち人間です。だから、私はそれほど悲観してはいません。
少し仮説の域を出ないかもしれませんが、10年後などにデフォルトのプログラミング言語がJavaScriptになっているかどうかという話ではなく（それについては1時間でも議論できそうですが）、そもそもソフトウェアの未来はどうなるのか、プログラミング言語の未来はどうなるのか、ということが問題なんです。
数年後には自然言語を使ってアプリケーションを作成し、それがコンパイルされるようになるという考えは、飛躍しすぎでしょうか？それがどのようにコンパイルされ、どの言語が使われているかなんて、誰が気にするでしょう。それが一つの考え方です。
もう一つは、「アプリケーションとはそもそも何なのか」ということです。私はお客様と一緒にアプリケーションのあり方について考えていますが、彼らは「でも、顧客は今はウェブサイトに来てくれる」と言います。確かに今はそうです。でも、もし顧客が何らかのエージェントの中にいて、例えばChatGPTやClaudeのようなものを使っていて、「どうやって生命保険を選べばいいですか？」と質問したとしましょう。
なぜそこから直接、適切な生命保険を提案してもらって、そのまま契約を済ませてしまわないのでしょうか？あるいは、私が生命保険に入りたいと言ったら、私の代わりにエージェントが起動して交渉に行き、適切なプランを提示してきたものを選ぶ。食材の買い物でも同じことが起きる。そう考えるのは飛躍しすぎでしょうか？
これは本当にエキサイティングなことです。もちろん、今の私たちがソフトウェア開発について持っている常識や信念はたくさんありますが、それらは大きく変わっていくと思います。プログラミング言語については、過去にはなぜか紫色の好みが反映されることがありましたね。誰かがウェブアプリを作ると紫色が使われる。なぜか紫色なんです。何かの研究データの影響だったのかもしれませんが、とにかく何でも紫色になる。もし次のトレーニングが行われたら、今度は全部が紫色になるかもしれませんし、それについては色々と言えることがあります。
Redditのインタビューを読んでいたのですが、誰かが「Redditで発言したことはすべて、未来のトレーニングデータになる」と言っていました。それが良いことなのか恐ろしいことなのかは分かりませんが。トレンドは自分がどのサブレディットにいるかによりますからね。でも、そこには多くの意味が含まれています。
AI生成コンテンツと人間の付加価値
最近、RedditやYouTubeのコメント欄を見ていると、「他のコメントが全部ボットみたいに見える」という書き込みを見かけることがあります。「今、自分が一体誰と話しているのか全く分からない」と。それが真実かどうかは別として、私もそうしたコメントを見ると「何か匂うな」と感じることがあります。
そうですね、それもエージェントの仕業だと思うかもしれません。でも一方で、私は昔「コンマを使いすぎる」と指摘されたことがあるんです。それでどうしたかというと、全部削除しました。それが私のコミュニケーションのスタイルだったんですが、しばらくの間、「もう全部消してしまえ」という時期がありました。だから、もしかするとそういうことかもしれません。ある時点を超えると、もう見分ける方法はないのだと思います。
本当にそうですよね。私も全く同感です。LinkedInを見ていても面白いんですよ。以前はダッシュ（—）を使うのがクールだと思っていた人たちが、今では「AIが書いた記事みたいだ」と批判されたりしています。これも良い流れとは言えませんが、面白いですよね。
ええ、それが人間というものです。重要なのは、人間として、私たちが自然な人間としてコミュニケーションをとることに価値を見出しているということです。本物の、リアルな人間であることに。一方で、コーディングに関してはAIが代わりにやってくれることを私たちは歓迎しています。
でも同じことなんです。私たちは依然としてコードを所有し、書いているものに対する責任を持っています。もし私がコードの80%、いや顧客によっては90%をAIに書かせたとしても、エンジニアはその90%に対しても依然として責任を負うんです。ループの中にいるのは人間ですから。ソフトウェアから人間を排除しようとしていますが、それは理にかなっていません。
最終的に世に出るものに責任を持つのは人間です。もし私が自分のアイデアをAIに翻訳させて、それが実際に読めるレベルのものになるなら、自分で長い時間をかけて書いた文章を人に読まれて「彼女、ちょっとおかしいんじゃない？」とか「まとまっていない」「途中で終わってる」と思われるよりも、はるかに良いと思います。だからそこには常にトレードオフがあるんです。
ええ。このポッドキャストでGregor Hopeと対談した時も、彼のスタンスは明確でした。AIによってアウトプットの基準値（ベースライン）が上がったのなら、その上にあなた自身の付加価値を乗せなければならない。そうしなければ誰でも同じことができるようになってしまうからです。推論やプロンプトの工夫、少しの味付けの違いはあるかもしれませんが、自分の付加価値を乗せなければ、他の誰にでもできてしまいます。あなたの価値はその「付加価値」にあるのだから、それをやり続けなさい。さもなければあなたのやっていることは無意味になってしまう、と。
それは素晴らしい指摘ですね。全員がAIを使って同じようなものを生み出しているなら意味がありません。一番顕著なのはLinkedInでしょう。19件も同じようなAIが書いた記事が並んでいて、ほとんど同じで何も編集されていないとしたら、その目的なんてあるんでしょうか。ソフトウェアについても同じことが言えます。
一方で私たちは、AIという技術と適切な文化があれば、全員がその技術から最大限のものを引き出せるように支援できます。顧客からの意見、ビジネス側のアイデア、プロダクトマネージャーやエンジニアの経験、これらがすべて合わさって素晴らしいものを生み出すことができます。
オープンソースの未来とマネタイズの課題
しかしその反面、製品を作ったものの、大した付加価値を加えられずに苦戦しているソフトウェア企業も多く見かけます。名指しは避けますが、オープンソース製品の例を考えてみてください。オープンソースでのマネタイズは常に課題でした。一つのシナリオとしては、プレミアム機能をリリースしてそれを維持するという方法があります。そして、セキュリティを求めるエンタープライズの顧客が、オープンソースプロジェクトにお金を落としてくれる。誰もがそう考えてくれればと願っています。
しかし、「製品の仕様書とデモの録画を使って自分のためにこれを作ってみたら、90%は再現できた。これで十分だ」と言う人も出てくるかもしれません。もちろん、誰もがオープンソースに対価を払うべきだと思いますし、制作者やコントリビューター、そして時間とリソースを投じている企業を支援すべきです。しかし、やはり何か本当に特別なものを付加する必要があるんです。そうしなければ、もう十分とは言えなくなってしまいます。
オープンソースの価値とマネタイズのモデルは常に難題でした。成功したオープンソースプロジェクトはそれを上手くやり遂げ、繁栄しています。しかし、それを単なるアドオンとして追加したようなプロジェクトは、人々がコピーしてマージできるようになった今、最も影響を受けていると思います。もしそのインセンティブがなくなってしまえば、人々が自由に使えるものがどんどん減っていくサイクルに入ってしまうのではないかと心配しています。
私はオープンソースソフトウェアが大好きですし、率直に言って、この業界で最も素晴らしいことの一つは、人々が創造し、見返りをほとんど求めずに共有してくれることだと思っています。マネタイズしているオープンソースプロジェクトでさえ、それは通常ほんの一部に過ぎず、メインのものではありません。メンテナンスしている人たちはフルタイムの本業を持っていて、これは彼らにとってサイドプロジェクトなんです。
だから、オープンソースがどんどん減っていくような状況にはならないでほしいと願っていますが、確かにそのリスクはありますよね。
私は逆であることを願っています。もっと多くのオープンソースが生まれることを期待していますが、それは私たちが実際に取り組むべき課題でもあります。世界はオープンソースに依存していますからね。当面の間、私たちが作るあらゆるものは何かの基盤の上に成り立っています。どれだけ多くのプラットフォームを構築したとしても、そこには必ず、パッケージをメンテナンスしているたった一人の存在のようなものが影響しています。それが現実なんです。
私はたくさんの創造性が生まれているのを目の当たりにしていますし、オープンソースは今後も存在し、ブームは続くと予想しています。ただ、大規模なプロジェクトがどうなるかは分かりません。「別の方法でやりたい」「特定のことにとてもこだわりがある」と簡単に言えるようになりましたから。私にその答えはありませんが、これは業界全体で解決すべき問題だと思います。オープンソースとは何なのか、なぜこれらのプロジェクトに貢献し、協力することが重要なのかを人々に伝えていく必要があります。
開発ツールの変遷と組織の選択
最後にもう一つ考えがあります。ソフトウェアエンジニアが現在利用できるツールに関する話に繋がると思うのですが。スタートアップや小さな組織では、さまざまなツールが実験的に使われています。例えばCursorを気に入る人もいるでしょう。でも、もし彼らが大きな組織に移った場合、愛用していたツールにアクセスできなくなるかもしれません。代わりに組織内で提供されているツール、例えばOpenAI関連のものやClaude、GitHub Copilotなどを使うことになります。
結局のところ、仕事を変えた時にはツールも変える柔軟性が求められるわけですが、これは少し面白い状況だと思います。私はツールを極めるのが好きです。なぜなら、それを活用してより早く成果を出せる気がするからです。IDEでもそうでした。ホットキーやバインディングを活用して、コードを実行する際に効率よく行うのが好きです。自分のやっていることで高い効果を出したいからです。だから、一つのツールを手放して別のツールをまた極め直すというのは、あまり気が進まないんですよね。
エージェント開発について話すとき、プロンプトの出し方、コンテキストの管理方法、エージェントの並列化の仕方、特定の構造のナビゲート方法など、基礎となる原則がたくさんあると感じています。私たちはコンテキストの構造化についてもまだ学び、進化している最中です。スキルやエージェントに関する議論もありましたが、エンジニアリングのリーダーに対して、部門やチーム、組織で利用可能にするツールについてアドバイスをする際、どのような要素が揃っているかを確認しますか？
これをお聴きの方々の中には、自分が望むツールを持っていないものの、やるべきことに対しては今のツールで効果を出せるかもしれないと考えている人もいると思います。どのように考えていらっしゃるのか、ぜひお聞きしたいです。
それは素晴らしい質問ですね。率直に言うと、これらのツールの多くはそこまで大きく違うわけではありません。どのツールを使っても80%は同じ結果を得られるのではないでしょうか？おそらくそうだと思います。私は実際に全てをセットアップして比較研究したわけではありませんが、一般的に言って、これらのツールには違いはあっても、それほど大きな違いはありません。
テクノロジーの種類に関わらず言えるのは、ツールをただ導入して開発者にポンと渡すだけではダメだということです。特に、AIやアシスタント、あるいは何かを実行するためのエージェントのような高度に洗練されたツールの場合はなおさらです。ですから、私がリーダーたちにアドバイスするのは、少なくとも開発者がそれを活用できるように支援（イネーブルメント）してほしいということです。
この支援というのは、「これがライセンスの取得方法で、ここで署名します」といったことではありません。もちろんそれは良い第一歩ですし、ライセンスを渡して「幸運を祈る」とだけ言うような会社の半数よりはすでにマシです。でも、トレーニングが必要です。どこに制約を設けるべきか、その制約とは何なのかを理解する必要があります。エージェントという概念など、把握すべきコンセプトがたくさんあります。
「自分でエージェントを書けるんだ」と思っても、その方法や場所を知らなければなりません。これらのツールの特性や、情報の処理方法を理解する必要があります。幸いなことに、私たちはどんどん標準化を進めています。業界として「これらの指示はどこに置くべきか」「これらのスキルを採用しよう」「役立つ特定のプロトコルに目を向けよう」と模索しているんです。
MCP（Model Context Protocol）は素晴らしい例です。競争の激しいペースの速い業界が、一般化のために互いに協力しているんです。「これを基準にしよう。標準を見つける必要がある」と。MCPについてどう思おうと、それが標準になりつつあります。でも、人々はMCPとは何か、どう機能するのか、どうやって安全に構築するのか、どうスキルアップするのかを学ぶ必要があります。
ソフトウェア開発者であれば、様々な役割を見渡しても、ネット上にたくさんの情報がありますから恵まれています。ツールを活用して理解する方法を教える必要があります。しかし、データサイエンティストやテストエンジニア、プロダクトマネージャーなど、コーディング全体に関わる人は他にもたくさんいて、彼らもまた、使っているツールから最高の結果を引き出す方法を理解し、支援される必要があります。
モデルについても同じです。「あるモデルの代わりに別のモデルを選んだらどうなるか」といったことや、社内でベストプラクティスを共有したり、インナーソースの文化を立ち上げたり。常にすべてをやらなければならないわけではありませんが、成熟していくための軌跡があり、それぞれのフェーズで少しずつ追加していくことで、ツールを活用して成功を収めることができるんです。
そしてツールを切り替える必要が出た時、「違うから使い心地が悪い」とか「別のエディションだ」「専用のIDEがない」「突然CLIになった」と感じるかもしれません。でも本質を見れば、それは単なるレンズ（インターフェース）に過ぎません。マイクロソフトで働いている立場から言えば、もちろん自分の使っているLLMにレンズを切り替えることができます。最も人気のあるものはすでに入っていますし、今後さらに増えていくでしょう。もし入っていないものがあれば、組織がそれを追加することも、自分で書くこともできます。
この部分はさらにコモディティ化していくでしょうし、すでにその兆候は見られます。現在GitHubで私たちが何をしているかというと、プラットフォームとしてオープンに歓迎しているんです。もしClaudeをエージェントとして使いたいなら、どうぞ使ってください。あなたの環境でそれが可能なら、それは素晴らしいことです。別のインターフェースがあっても、エージェントはそこにいます。慣れ親しんだレンズを使い、慣れ親しんだエージェントを使う。この議論は今後も続くでしょうし、誰もがその恩恵を受けると思います。しかし、「開発者に丸投げする」というやり方では、導入は進みません。
「ツールが同じようなものだ」という適当なパーセンテージでおっしゃっていただいたのは良かったです。面白いことに、私もそう思っていました。もし今同じでなくても、数週間、数ヶ月のうちには同じようなことができるようになるはずです。みんなお互いのことを見ていますからね。もし私の使っているツールに何か特別な機能があれば、他のツールも同じ結果を達成するためにすぐに似たような機能を取り入れるでしょう。それは当然のことです。
消費者としては、最終的に一番良い製品が手に入るわけですから、競争があるのは良いことですね。
ええ、私もそう思います。競争によって起こっていることを愛しています。もちろん、YouTubeやTikTokで人々が製品を見せびらかしたり、どのように使っているかを語っているのを見に行くのも好きです。彼らがどう製品を使い、どう語っているかを見ることで、何が重要なのかを理解する助けになります。
いくつか素晴らしいイノベーションが世に出ていますね。すべてに対して「これは素晴らしい実装だ」とか「驚きだ」と言うわけではありませんが、最終的には競争こそがソフトウェアをより良く、素晴らしいものにしてくれます。そして、今の時代にこの分野にいることをインスピレーションに満ちたものにしてくれています。
適切な環境を求めて組織を変えるべきか
これをお聴きの方々の中で、もし今、あなたが「少なくともこれくらいのツールは持っておくべき」と考えるレベルの環境や支援が提供されていない場合、それは組織を変える十分な理由になると思いますか？
私はほぼそうだと思います。組織を簡単に変えられるという前提であればの話ですが。現在、私たちの技術は非常に速いスピードで進化し、加速していますから、もし日々の業務、つまり仕事の中で実験的な試みができないのであれば、それは本当に環境を変える良い理由になるかもしれません。
ええ、完全に同意します。IT組織や、才能ある人材のトレーニングと定着に関する戦略を見ていると、やるべきことはたくさんあると思います。良い文化を築くこと、成熟したツールを導入すること。これは日々のソフトウェア開発から、プラットフォームをどれだけ簡単に構築できるか、どのようにスキルを磨くか、どうやって変更を加えるかといった、プラットフォームエンジニアリングの導入に至るまで幅広く関わってきます。
選択肢はどんどん増えていくでしょう。だからこそ、組織はこれを真剣に考え抜く必要があります。私はプラットフォームエンジニアリングの話題が今後さらに増えていくと確信しています。これまでプラットフォームエンジニアリングの定義をうまくできていたかは分かりません。エンジニアリングに焦点を当てすぎて、色々なものを詰め込みすぎたかもしれませんから。だから、そのアプローチについてもう一度見直す時期にきているのかもしれません。
でもそこには、顧客を助けるエージェントのため、私たちがコードを書くのを助けるエージェントのため、そして本番環境にデプロイし、管理し、監視してくれるエージェントのために必要なものがたくさん詰まっています。私たちはそのすべてを必要としています。
これを聴いている、あるいは見ている人たちは「ええ、でもそれは常にそうあるべきだったんじゃないですか？」と言うかもしれません。確かにそうです。でも、そのようなプロジェクトに「AI」という言葉を絡めると、予算やリソースを獲得できる可能性が少し高くなるのも事実なんです。
ですから、自分のためにプラットフォームエンジニアリングを導入してください。最高の文化を持っているか確認してください。コラボレーションモデルやオペレーションモデルについてクリエイティブになり、少し実験をしてみてください。成功を祝い、人々がAIを使い、そして失敗することが奨励され、支援される環境を作ってください。それを正しく行えば、基盤は盤石になり、他の会社よりもうまくやれるはずですし、才能ある人材も集まってくるでしょう。
素晴らしいですね。本日はお越しいただき、これらの質問にお答えいただき本当にありがとうございました。とても楽しかったです。
ええ、ありがとうございました。本当にクールでした。
まだ最後まで聴いてくださっている皆さんは、ぜひこのエピソードの感想をコメント欄で教えてください。それでは、次回のコーディングでお会いしましょう。
コメント