「両方の世界のベスト：人間の開発者とAIの協力者」
Best of Both Worlds Human Developers and AI Collaborators
ジェネレーティブAIが製品エンジニアリングチームに与える影響 – 第6部 | 後書き
これは、開発者を対象としたGithub Copilot、ChatGPT、Amazon CodeWhispererなどのジェネレーティブAI生産性ツールが、全体的な製品エンジニアリングチームの構造にどのような影響を与えるかを調査する6部作の最終部です。
この最終部では、前の記事で取り上げなかった多くの複雑さ、AIの時代における人間のエンジニアの貴重な価値、そしてリーダーに対して反省し、適応し、革新するよう呼びかけます。
「前回のおさらい」
このシリーズを通じてかなりの旅をしてきましたので、前の5つの記事でカバーした内容を簡単に振り返って、これまで取り上げていない内容を紹介しましょう：
第1部では、CopilotやChatGPTなどのジェネレーティブAIコーディングツールが、エンジニアやデータサイエンティストなどの技術的な役割を持つ人々の生産性を大幅に向上させる可能性があることを示す証拠を見ました。これらのツールは、退屈で繰り返しで時間のかかるタスクを自動化することによって、開発者が行う必要のない作業を削除し、貴重な作業をより迅速かつ容易にします。
第2部では、開発者のタスクの自動化と開発者の生産性の向上が、製品チームにおけるエンジニアとプロダクトマネージャの比率の大きな変化をもたらす可能性があることを考えました。従来、チームごとにエンジニアが5人いてプロダクトマネージャが1人いるのが一般的でしたが、ジェネレーティブAIツールを使用すると、この比率は1:1に近づく可能性があります。
第3部では、ジェネレーティブAIコーディングアシスタントがコードのリファクタリングやテストの作成にだけでなく、長期的な影響を持つ可能性があることを見ました。遺産コードのリファクタリング、テストやドキュメンテーションの作成、および単に技術的なスキルが異なるために作成されたモバイルアプリ開発など、一部のチーム構造の簡素化も探求しました。また、ジュニアエンジニアと彼らの職業的な成長に与える可能性についても考慮しました。
第4部では、この変化により、企業は同じ成果を達成するためにエンジニアの人数を劇的に削減したり、同じ予算で成果を急速に増やしたり、あるいはその組み合わせを選択することができるようになると考えました。成長への投資、予算の維持、コスト削減の選択肢がエンジニアリングとプロダクトの人数にどのように影響するかをモデル化し始めました。
第5部では、これらの利点が異なる種類の企業にどのように影響するかを調査しました。新しいスタートアップは、できるだけ早く新しいツールを使用するべきです。一方、チーム構造を変革するための最も大きな財務的な動機を持つ大企業は、文化的な慣性のために適応が困難ですが、ツールを試して独自の戦略的な決定をすることを今日から奨励されるべきです。また、クライアントが内部の従業員を保護し、他の場所でコストを節約しようとするため、「ボディショッピング」の外部委託企業が最も影響を受ける可能性があることも見ました。
これまでの議論はすべて、「次世代の製品エンジニアリングチームはおそらくはるかに少ないエンジニアを持つ」という仮説の議論を中心にしていますが、その仮説を証明または反証するにはかなりの距離があると言えるでしょう。
「はい、しかし…」
さて、このトピックについての議論で受けた多くの考えを巡らせる課題について、最近の会話で受けた多くの疑問について触れたいと思います。また、元の仮説のために多くの仮定をしていることにも触れたいと思います。
私は多くの潜在的な反論や未解決の問いに触れていませんが、それは私が悩んでいるわけではなく、これらのツールを実験し、チームを本当に支援する方法を見るためにまだ不確実性が多すぎるためです。
以下に、多くの批判や未解決の質問のリストを示します：
AIツールに品質の高いコードを書くことを期待しすぎています。彼らは人間ほど優れているはずがありません。
私はツールの品質に感銘を受けていますが、優れた開発者と同じくらい優れている必要があると主張しようとはしていません。私は技術的な専門知識なしのシナリオを意図的にモデル化していません。なぜなら、私の経験では、これらのツールはまだ大いに監視とガイダンスが必要でした。愚かなことや危険なこと（APIキーをソースコードに書き込むなど）をしていないかを確認するための監視、正しいことをしているかを確認するためのガイダンス（正しい言語やフレームワーク、デザインパターンの使用など）です。
私は、これらのAIツールがソフトウェアエンジニアリングのマクドナルドである必要があると感じています。優れたスタッフを持つ非連鎖店のレストランに行くことは感動的な体験になることもありますが、常にそれが可能ではありません。マクドナルドは普遍的に清潔で、安価で、健康的（つまり、細菌に感染していない）であり、何よりも一貫性があります。私の最も親しいイタリア人の友人の一人が大手チェーンのピザを受け取ったとき、「それはあなたを殺さない」と言ったことがあります。ある程度、これがAIツールに向けて私たちが目指している基準です。
しかし、これが物語の終わりではないとも思っています。今日私たちが見ているツールは、1年後になるほど品質が向上することはありません。私がオリジナルの記事をこのシリーズに編集している最中でさえ、毎日のように改良に関するニュースがありました。UCバークレーはGPT4よりも優れたAPI呼び出しを行うモデルを紹介しました。マイクロソフトは「拡張された注意力」を発表し、LongNetで数十億のトークンにスケールすることができるモデルを開発しました。Stack OverflowはOverflowAIを発表し、バカげた質問に対するより優れた、より有用な検索（すみません、私は意味を伝えるためです）を提供すると約束しました。
たとえツールの能力に対して懐疑的であっても、それらが開発する可能性を無視することは短絡的であると恐れています。
[編集: この記事の最初の草稿から1週間ほど経った間に、Stack OverflowはOverflowAIを発表し、Githubは知的財産問題を防ぐための追加ツールを発表し、StabilityAIはコーディングに特化したLLMを発表しました。市場は驚くべき速さで動いています]
AIツールには知的財産権の問題があります。そしてセキュリティの問題もあります。そして、もしツールが動作しなくなったら、私たちはもう仕事ができなくなります
はい、これらはすべて可能性のある問題です。
しかし、これと同様の問題を解決するのは初めてではありませんし、既にそれらを緩和する方法を持っています。私が話をする多くの企業は、彼らが企業の秘密を漏洩させ、それがLLMのさらなるトレーニングに使用されることを心配して何らかの麻痺状態に陥っています。これは無料の個別の購読に当てはまる可能性がありますが、私は、より大きなプロバイダについて調査を行い、そのリスクとベンダーがこの非常に合理的な懸念に対処するために行っている取り組みを正確に理解するために、あなた、親愛なる読者に強くお勧めします。大手プレーヤーのいくつかのFAQを見て、あなたのユースケースとリスクプロファイルに十分な回答があるかどうかを確認してください：OpenAI、Github Copilot、AWS CodeWhisperer（Google Duetはまだクローズドベータ版であり、データセキュリティの文書が利用できませんでした）。
セキュリティとデータ保護に関しても同様の事例があります。今日、あなたが読んでいるほとんどの人は既にGithub、Microsoft、またはAWSのセキュリティに依存しています。おそらくあなたはコードをGithubに保存しているか、アプリやデータをAzure、GCP、またはAmazonに保存しています。自分自身に問いかけてみてください。なぜハイパークラウドのベンダーのリスクを受け入れることに納得しているのに、コーディングツールのリスクを受け入れることに疑問を感じているのでしょうか。ChatGPTのリスクは無視できないものであり、5月にデータ漏洩が報告され、今週はジェイルブレイキングの可能性が報告され、クラウドセキュリティベンダーのNetskopeによる内部ユーザーからの持続的なデータ漏洩が報告されています。他のどの技術の一部と同様に、単にそれを組織から禁止することを選択することができますが、人々は常に方法を見つけます。セキュリティの問題に適切に対処するには、ユーザーに教育を行い、安全で使いやすい代替手段を提供する必要があります。OpenAIがその任務に対応できない場合、他のベンダーのうちの1つが対応しているかもしれません。
もう一つの心配事は、偶発的な知的財産リスクへの曝露です。たとえば、モデルがクローズドソースの資料で（「偶然に」）トレーニングされ、ツールがあなたの組織に使用することで法律違反になり（違反を修復するためのリスクを伴う）、リスクにさらされる可能性があります。ここに悪いニュースです。もしあなたがこれを新たなリスクだと考えているなら、あなたの組織でのオープンソースの使用方法をもう少し詳しく調べる必要があるかもしれません。多くの企業は、ソフトウェアが持つクローズドおよびオープンソースの依存関係のリスクを適切に管理し理解していません。これらのツールのいずれかが偶然にあなたが他の人の知的財産権に違反するリスクにさらされる可能性について心配する必要がありますが、既にオープンソースソフトウェアと開発者の大きな赤い切り取りボタンに対して使用しているコントロールを拡張する必要があります。
これらのリスクはあなた自身のものであり、これらのツールが提供する機会を真剣に調査するつもりなら、それらからのリスク保護についてのドキュメントを読み、ベンダーと話し合うべきです。自分の宿題をしっかりと行ってください。CopilotのCommon Sense Privacy Reportでは、63％のスコアを獲得し、低い評価（特に「学校」および「保護者の同意」で低いスコアを獲得）を受けています。
これは常に調達プロセスの一部であるべきです。リスクの観点から、本番コードやデータに近づけるツールを常に検討する必要があります。リスクへの食い違いとその軽減策を決定するのはあなた次第です。
よりポジティブな点として、Salesforceの最近の発表は、これらのツールが進む方向を示している良い兆候だと思います。SalesforceのAIデーにおけるマーケティングの重点は、「Einstein Trust Layer」と呼ばれるものに焦点を当てており、これは異なるLLMモデルに対する本当に印象的なラッパーであり、アクセスの保護と顧客および企業情報の保護に大いに役立ちます（コードに関するものではありませんが、このビデオをチェックしてみてください）。
Amazon、Anthropic、Google、Inflection、Meta、Microsoft、およびOpenAIの7つの主要なテック企業が自主的な「責任あるAI」の取り組みに署名しました。これには出力にウォーターマークを付けることも含まれています。この市場で最も大きなプレーヤーであることが合理的であり、私たちのデータとインフラストラクチャの大量の信頼を置いている既存の企業の多くが、知的財産、セキュリティ、プライバシー、LLMの毒性と真実との疑問の関係についての多くの未解決の問題に答えるために同様の信頼性とセキュリティのラッパーをリリースするでしょう。
誰かが依然として全体のソリューションを設計する必要があります。
参照もご覧ください：
- データとデータパイプラインの管理が必要です
- アプリケーション間の重複を管理する必要があります
- 製品のセキュリティを確保する必要があります
- 問題に対応し、対応する必要があります
- チームと製品の依存関係と相互作用を管理する必要があります
そうですね、正しいです。コードを書くだけではなく、まだたくさんの仕事が残っています。
これは素晴らしいです！
それは私たちがしばらくの間まだ人々を必要とすることを意味し、エンジニアに対するトレーニングを提供すべき場所を示してくれます。しかし、ドキュメンテーションが増え、”賢い”コードが少なくなり、インターフェースがクリーンになり、説明可能性が向上し、テストカバレッジが向上することで、これらの種類の課題が少なくなる可能性もあります。
しかし、エンジニアのほとんどの時間は実際にはコーディングに費やされていません。愚かな会議に行くように言われ続けるためです。
はい、その通りです。AIはすべての問題を解決するわけではありませんが、もしエンジニアがコーディングよりも会議に時間を費やしているのであれば、問題は生産性ではなく、組織の運営方法にあります。
おそらくAIがいつかそれを解決してくれるかもしれませんが、短期的には、より小さな、より効率的で自動化された組織は、そんなに多くの会議を必要としないかもしれません。
率直に言って、ほとんどの組織にとって、開発者の生産性を向上させる最良の方法は、仕事の優先順位をより良くし、低価値な成果にノーと言い、チームに高品質な製品の提供に集中するための時間を与えることです。しかし、それができない場合は、AIのコーディングアシスタントを使用することもできるかもしれません。
代わりにAIでプロダクトマネージャーを置き換えることはできませんか？
これは興味深い質問です。
これらの記事に対する驚くべきフィードバックの一つは、「それは本当に興味深いですが、私たちのビジネスではプロダクトサポートが十分にありません」というものでした。私はエンジニアとの比率が5：1であることで無意識の偏見を示していたようですが、多くのテックチームは既にその比率がはるかに高く（10：1以上としましょう）、さらに組織内でプロダクトスキルが十分に評価されていないため、非常に苦労していました。一部の企業はまだエンジニアがコードを書き、プロダクトマネージャーが高価な贅沢品であると考えているようです。
私は顧客からの要件を引き出すことが非常に重要だと考えています。また、効果的で理解しやすい商業的な優先順位付けプロセスを実行することは非常に困難です。ソフトウェアのためのプロンプトデザインをステークホルダーに自分で行ってもらうにはまだ時間がかかるでしょう。
プロダクトマネージャーは素晴らしいプロダクトエンジニアリングに不可欠です。プロダクトマネージャーはエンジニアリソースに焦点を当て、ビジネスが最も価値のある成果物を特定するのを助けます。今のところ、プロダクトサポートの削減は本当に必要なことではないと思いますが、自動化によって彼らの日常的なタスクを支援することは可能かもしれません。
私の疑念は、プロダクトマネージャーとテックリードの役割が、これらの新しいチームで最も重要なものになるということです。
XやYやZについて考えていない
ほぼ間違いないでしょう。しかし、もし考えているなら、それは素晴らしいことです！コメントを残して、議論を始めるか、さらに良いのは、YやZについての考えを説明する新しい記事を書くことです（ただし、Xについては話しません）。
まとめると
このシリーズの記事全体のポイントは、今日、プロダクトとテクノロジーのリーダーが、生成型AIコーディングツールの約束が実現した場合、自分たちのチームに何が起こるかについての議論に積極的に関与していないと感じていることです。私たちは単に開発者の生産性の小さな向上について話しているのではありません。製品の作成方法に変化が起こる可能性があると言っているのです。
私たちが議論したことのいくつかでも真実であるなら、ソフトウェアを構築するチームは、今日とはかなり異なるリソースの割り当て方をされる可能性があり、それは製品とテクノロジーのスタッフ予算に大きな影響を与えるでしょう。開発者の役割の削減を含む、業界全体での混乱のリスクがあります。
企業がますます成果に投資しようとすることで、これは緩和されるかもしれませんが、ビジネスがサポートできる価値ストリームの数には限りがあります。来る変化を理解し、慎重かつ断固とした対応をするために時間をかける企業は、大きな競争上の優位性を得る可能性があります。
この議論には哲学的な側面もあります。私は、人間のエンジニアには言葉では説明できない、かけがえのない価値があるかもしれないと信じていますが、もはやそれが何であるかを自信を持って言えるわけではありません。
開発者がコードを書くことを知っていますし、彼らがコードをどれだけ速く書き、どれだけ頻繁に動作するかに基づいて彼らに価値を置くことができます。しかし、この声明は単にエンジニアの本当の仕事を理解していないのです。長年、熟練した人間のエンジニアがアルゴリズムではできないことをすることができることを示すのは簡単でしたが、もはやそうではありません。人間と機械の間の境界が作成できる解の複雑さのレベルだけであるならば、私たちは危険な移り変わりの砂上にいます。私は以前に書いたように：
エンジニアは単にコーディングする方法を教えられるのではありません。彼らは考える方法を教えられるのです。
私たちは、業界として、この新しい世代のツールによって幅広いエンジニアリングのタスクが簡単に複製されることを認識しなければなりません。それを行うことで、人間が持つまだ簡単に複製できないユニークなスキルも理解するべきです。私たちリーダーの仕事は、それらのスキルを特定し、そのスキルを最適化するために人々に投資することです。
この記事は行動を促すものです。もしプロダクトやテクノロジーのリーダーであるなら、これを自分のチームに対する課題として考え、その質問に答えるために自分のチームを含めるべきです。
これらのツールが彼らをどのように助けるかを考える時間と空間を与えられた場合、最も可能性の高いイノベーションの源は、あなたのチーム自体になるでしょう。しかし、リーダーとして、あなたはまた、クリスマスに投票することにあまり意欲のない人々がいることを認識する必要があります。雇用への非常に現実的な脅威のために、人々は恐れを抱き、参加することをためらうかもしれません。あなたは彼らの才能を活用して、予算削減を行うべきかどうかを理解するために彼らを引きつける必要があります。ボスであることは難しいですが、それよりもあなたよりも目の前を見据えて断固とした競合他社がいるということです。
最も興味深く、混沌とした、非組織的な、影響力のある、エキサイティングな進歩は、それらの小さなスタートアップやテック以外のチームで起こるでしょう。自分の組織内の非技術的な人々や、スタートアップコミュニティの小さな会社が行っていることを軽視しないようにしてください。
まずは自分自身を教育し、そして自分のビジネス内の好奇心旺盛な早期採用者や、テックの巨人や小さなスタートアップが何をしているかを内部的にも外部的にも見て、リスクが本当に何であるかを考えてみてください。これらの進歩は、おそらくあなたの製品エンジニアリングを根本的に再構築するでしょう。そして、好奇心を持って質問し、あなたのチームにも同じことを促すために行動してください。
まだ自分の仮説を反証することはできていませんが、今度は実験を設計するためにあなたの助けを求めています。
このシリーズの他の記事：
- パート1
- パート2
- パート3
- パート4
- パート5
P.S. もしチームに関するこの記事を楽しんでいるなら、私の共同ホストであるアンドリュー・マクラーレンと一緒に、ゲストとの対談を通じてチームがうまく機能する理由について話している私のTeamcraftポッドキャストもぜひチェックしてください。
We will continue to update VoAGI; if you have any questions or suggestions, please contact us!
Was this article helpful?
93 out of 132 found this helpful
Related articles
