エンジニアリングリーダーは何を気にしているのか？

What is the concern of an engineering leader?

先週、私たちはBayエリアで初めてのEngineering Leaders Forumを開催しました。Bayエリアの主要企業から100人以上のEngineeringのVPおよびSVPが登録しました。途中で、待機リストを開く必要がありました。良い問題です。

私はかなり長い間、このようなイベントを開催したかったです。他のペルソナとは異なり、Engineeringリーダーは非常に安全な環境で自分たちの課題を共有し、他の人たちの視点を聞く機会がありません。先週の部屋には何千年もの経験がありました。フィードバックに基づいて、ラウンドテーブルの形式は非常に好評でした。私は、Kubiya.ai、Devzero、Turing、Uplevel、およびAWSがイベントをスポンサーし、実現させたという事実に本当に感謝しています。再び、機密情報を共有しないように、部長たちから得たいくつかの洞察について少し話したいと思います。

部長たちから聞いた2つの重要なポイントは、AIと測定に集中していました。

エンジニアリングリーダーは、AIとChatGPTについてどのように考えているのでしょうか？

感じるのは、興味深い時代にいるということです。クラウドで10年、15年前に起こった同じ変革が、今日はAIで起こっています。みんなAI周りで「何か」をしたがっています。私たちの顧客や見込み客からも同じことを聞きます。しかし、多くの人々はまだ、AI周りで具体的に何をしたいのか、どのようなユースケースがあるのかを把握しきれていないということです。データプライバシーに関する懸念が多く寄せられました。ChatGPTのようなツールを使用する際には、データがどのように保存され、何が保存され、誰がアクセスできるかが本当にわからないということをメンバーが話しました。一人の部長は、彼の会社がAIを使用することでエッジを得ることができるように、彼らのデータを使用することで競合他社にエッジを与えることもできると述べました。ほとんどのリーダーは、AIを使用するためのベビーステップを踏んでいます。部屋の中の数社は、例えばCopilotやChatGPTを使用してコードを生成することを実際に試みていると言及しました。

• H1Bビザはデータ分析の洞察に基づいて承認されますか？
• データアナリストの仕事内容はどのように見えますか？
• 言語学習モデルにおけるOpenAIの関数呼び出しの力：包括的なガイド

もう一つ、私たち自身もその中にいるので、AIが今日非常に一般的であり、文脈的な組織が欠けていることを非常に強く感じました。したがって、一般的なコードスニペットを提供する代わりに、AIが組織的なリポジトリを見て、より文脈的な推奨事項を行うことができれば、またはKubiyaの場合、AIが組織が使用しているエンジニアリソースやプラットフォームを実際に特定し、そのプラットフォームに基づいて環境を展開したり、Terraformモデルをレンダリングしたりできれば、非常に強力になると思われます。

初期採用者は、ほとんどAIをコードレビューに使用していると述べました。開発者は、コードレビューが生産的でないと感じているため、別のセットの「目」を持つことでプロセスを迅速化し、依存関係を解消できます。

再び、何かしらAIは破壊者であり、誰もがゲームに参加してエッジを得るためにそれを使用したがっていますが、ユースケースはまだありませんし、データプライバシーは大きな問題です。

議論されたもう一つのアイテムは、組織内でChatGPTを使用することでした。一方、組織はドメインをブロックしない限り、組織内の人々がどのようにChatGPTを使用するかに対しては制御できません。使用を制限するポリシーを作成することはできますが、それを執行することは難しいです。ChatGPTを使用してコードを作成したり、ドキュメントを作成したりすると、個人情報を共有したり、ライセンス権を侵害したりするリスクがあります。組織は現在、従業員にAIとChatGPTの使用方法について明確な方針を持っておらず、従業員に明示していません。Copilotやその他のAIコード生成ツールの場合、コードスニペットを使用してLMMをトレーニングしたため、出力がいつか著作権を侵害する可能性があり、彼らを法的行動のリスクにさらすことになるということが、特に言及されました。

エンジニアリングリーダーは、チームをどのように測定しているのでしょうか？

エンジニアリング組織のスケーリングと速度向上に関する多数のラウンドテーブルがありました。私の同僚Debo Ray氏は、Devzeroの “Impact of AI、Product Velocity、and More: Learnings from Engineering Leaders Forum”でそれについて書いています。最終的に、議論はすぐにエンジニアリング組織をどのように測定するかというテーマに戻ってきました。部屋の中のリーダーの中には、他の人たちほどDORAに詳しくなかった人もいました。したがって、エンジニアリング組織を管理および測定することは、科学と同じくらい芸術的な側面があると感じられます。リーダーの一人は、エンジニアごとの週ごとのコミット数を測定しており、そのエンジニアが病気だったり、面接中だったり、会議中だったり、別のことをしていたりするかどうかについての文脈と一緒に、時間の経過とともにチームのパフォーマンスをよく把握していると述べました。

リモートワークとRIFs

ラウンドテーブルの前に、メンバーと一対一で話をする機会がありました。すぐに2つのトピックに絞られました：レイオフとリモートワーク。多くのリーダーがチームを再編成し、優秀な人材を解雇しなければならなかった。現在のリーダーは、規模よりも効率に重点を置いています。

リモートワークに関する意見を聞くのは興味深かったです。12〜18ヶ月前、企業はリモートワークを新しい常態として議論していました。多くのメンバーは、リモートチームを管理するオーバーヘッド、可視性の欠如、文化への影響が主な理由として、開発者に週に2〜3日オフィスで働くよう求めていました。特にレイオフの場合、文化とコミュニケーションが重要になり、オンサイトでチームとコミュニケーションを取り、文化を築く方が簡単です。自宅のオフィスからリモートで働くことは、エンジニアリーダー自身にも影響を与えるようです。長時間働き、十分に社交的でなく、仕事と生活のバランスが取れていないと感じるようになりました。

まとめ

メンバーたちはこのフォーマットをとても楽しんで、お互いに知識や経験を共有する機会を得られたことを喜んでいました。議論は率直で透明性があり、個人的な一対一の会話と10〜12人のラウンドテーブルの組み合わせは、多くの洞察と考える材料を提供してくれました。

次回のELFでお会いしましょう。

We will continue to update VoAGI; if you have any questions or suggestions, please contact us!