Transcript
00:00:00こんにちは。Figmaでソフトウェアエンジニアを務めているエヤル・ブラムです。
00:00:17本日の講演では、コードベースの高い品質を維持しながら、
00:00:25FigmaのワークフローにAIエージェントをどのように適応させてきたかについてお話します。
00:00:32ご存知のとおり、Figmaはデザイン、エンジニアリング、そして今や
00:00:40AIエージェントが協働してコードをリリースするブラウザベースのエディタです。
00:00:44Figmaは従来のツールからAIファーストのツールへと大きく舵を切りましたが、
00:00:52本日の講演ではプロダクト自体の話ではなく、
00:00:55社内の組織やエンジニアリング部門がAIエージェントにどう適応してきたかについてお話しします。
00:01:04社内でわかったこととして、組織、企業、個人のいずれにおいても、
00:01:11AIの導入にはある種の3幕構成のプロセスが存在します。
00:01:16まず何かを手にして始めることから始まります。この部屋にいる多くの人たちのように、
00:01:21皆さんはAIに精通しており、すでにしばらくAIを使っていて、何かを試して
00:01:27簡単なタスクを非常にうまくこなし、10倍速く作業できるようになります。
00:01:30次に、同じプラクティスをもっと大きな問題に応用し始めますが、AIはその点ではかなり失敗しやすく、質が低く
00:01:40バグだらけの結果を生み出します。
00:01:41築き上げた信頼が崩壊し、その時点から真のスキルの習得が始まります。それはすなわち、
00:01:50AIを正しく使いこなし、適切なガードレールやプロンプティング、そして適切な
00:01:55コンテキストなどを設定する方法を学び、真のスキルを構築することです。
00:02:02社内で起きていることの1つとして、チームや個人による導入が進む一方で、その普及度合いには偏りがあります。
00:02:12AIに非常に前向きでワークフロー全体をすでに変革したチームがある一方で、初期の段階でまだ実験中だったり、自信をなくしたりしているチームもあり、プロダクトをリリースするためにはこれらすべてが協調して働く必要があります。
00:02:28そのため、組織内でそれらが共存できるようにし、全員をそのストーリーの第3幕へと導きながら、同時に全員をサポートする方法を見つける必要があります。
00:02:44この主な摩擦点のほかにも、AIを導入する中で他の摩擦点にも気づきました。
00:02:54開発者やマネージャーの間でよく耳にするのは、開発者の主体性が低下することでエンジニアのやりがいが損なわれているという点です。
00:03:04多くの人々はコードを書き、フロー状態に入ることに大きな誇りと楽しみを感じていましたが、それが失われた、あるいはその要素が失われつつあると感じており、AIからの出力を待ってAIと対話するだけのプロンプトサイクルに陥り、以前ほど楽しくなくなっているのです。
00:03:22もう1つ興味深いことに気づきました。優秀なエンジニアほど、すべてのコンテキストを頭の中に留めておこうとし、その負担を抱え込んでしまいます。その結果、どこに落とし穴があるのかを把握し、エージェントがうまく機能しない部分を精神的なダクトテープでつなぎ合わせ、本当に酷い問題が入り込むのを防いでいます。あるいは、まだ文書化されていない組織的なコンテキストをすべて頭の中に保持しているため、
00:03:52膨大な負担を抱えてボトルネックになり、ひどくフラストレーションを感じるため、実際には問題の深刻さを真っ先に目の当たりにするがゆえにAIの導入が遅くなってしまうのです。
00:04:04これは私たちが直面しているもう一つの大きな課題であり、ここにいる誰もが共感できること確信していますが、ある日突然、すべての設計ドキュメント、Slackのメッセージ、メールの長さが3倍から4倍になり、メールの数も2倍か3倍に増えたにもかかわらず、伝えている内容は以前とほとんど変わらないという状況になりました。
00:04:28その結果、コミュニケーションが非常に非効率になり、何が高品質で重要であるか、そうでないかを見極める基準のナビゲートが難しくなっています。
00:04:40そこで次の数分間では、私たちが学んだ教訓の一部と、それをどのように応用しようとしているのかについてお話しします。
00:04:50これはまだ途上の旅路であり、完全に解決したわけではありませんが、多くの面で非常に興味深い進展が見られます。
00:04:57ここでの多くのスピーカーも触れていましたが、検証への投資はおそらくコードベースにおいて私たちが実行できる最も価値の高いことです。
00:05:11ワークフロー内のあらゆるタスクにおいて、人間が行う必要のある作業から、エージェントが検証できる作業へと、可能な限り左シフトすることです。
00:05:19例えば、Playwright MCPが登場した際、人間が手動でコードを操作する代わりに、エージェントがコードを探索できるようになり、多くのチームで生産性が大きく向上しました。
00:05:33それは私たちにとって常により大きな成果となります。
00:05:37さらに良いことに、エージェントが有用だと判断した機能を見つけたら、時間をかけてそれを決定的（デテミニスティック）なフローに落とし込むことです。
00:05:51容易に繰り返すことのできる決定的フローは、トークンと時間を節約し、LLMが必要とされる場面でのみLLMを使用しているという確信を得ることにもつながります。
00:06:01しかし、すでに既知であり、基本的にテストへとコード化できるものがある場合、そこに時間を費やすことは常に大きなリターンをもたらします。
00:06:11もう一つのコツとして、スキルやエージェントにコードを記述させる際、TDD（テスト駆動開発）スタイルの赤から緑へのアプローチを指示すると、ほぼ確実に良い結果が得られます。
00:06:26なぜなら、最初にゴールを設定し、そのゴールに向かって努力するようエージェントに指示することになるからです。
00:06:30後からテストを書くよりも、その方が圧倒的に良い結果を生みます。検証基準をパスするようにコードを合わせるのではなく、コードにテストを適合させることができるためです。
00:06:42これはテストピラミッドであり、従来のエンドツーエンドテスト、結合テスト、ユニットテストといった古典的なテストピラミッドに似ています。
00:06:54リント、コンパイラ、ユニットテスト自体といった決定的解析へと、できる限り下方向にシフトさせ、簡単にカバーできるものであれば何でも、基準に基づいたレビューをエージェントに実行させることができます。
00:07:12そして、容易にエンコードされた建築基準。
00:07:15コードベースに簡単に組み込めるアーキテクチャ標準も、エージェントに移行させることができます。
00:07:19そして最上層にのみ、通常は機能性に関する何らかの人間のレビューを残します。これは実際に人間が関与する必要のある作業だけを人間に任せるというアプローチです。
00:07:31もう一つの非常に重要な要素は、プロンプト作成と計画立案の対比です。これは開発者に主体性を返し、コードを書くという職人技の代替を見つけることと深く結びついています。
00:07:50そのため、計画の立案に多くの時間を費やし、それを実装として自動的に実行できる形でエージェントに渡すことは、ものづくりの喜びをプロセスに再び呼び戻す上で非常に有効であると私たちは感じています。
00:08:07したがって、非常に詳細な計画を1週間かけて書き上げ、すべての決定を下し、内容を詰めて反復し、チームメイトに送ってレビューしてもらうことは珍しくありません。
00:08:17そして、準備が整い、すべての意思決定を明確にした段階でのみエージェントに送ると、エージェントが実装を完了させて送り返してくれます。
00:08:26このアプローチは、開発の加速だけでなく、開発プロセスにおける喜びの回復にも大いに成功しています。
00:08:36では、優れた計画とはどのようなものでしょうか。冒頭に「なぜ（Why）」を書くことが非常に重要です。
00:08:43設計ドキュメントを書くときのように、太字で大きなセクションを設けておくと、エージェントのドリフトを防ぐのに大いに役立ちます。
00:08:49エージェントのためにエグゼクティブサマリーをそこに記載しておきましょう。そうしないと、時間が経つにつれてエージェントの方向性がズレ始め、勝手にそれを変更しようとしてしまいます。
00:08:58そのため、「なぜ」から始め、計画をそれぞれ個別に検証可能な小さなパーツに分割できるようにします。
00:09:08適切なサイズを見極める私なりの方法は、その部分に対応するPR（プルリクエスト）をレビューしたいかどうかを考えることです。1回の座りでレビューするには大きすぎる場合、
00:09:18「これを読む前にコーヒーを一杯淹れる必要があるな」と思うようなテストになります。
00:09:22それは大きすぎるということであり、さらに細かく分割したいと感じる基準になります。
00:09:26そして、各パーツが個別に検証できるようにします。避けたいのは、5つのステージがあり、最初のステージが書かれたものの検証されず、その上のすべての前提に基づいて残りが構築されてしまう事態です。
00:09:41そのため、各フェーズに検証ゲートや例外条件を設けることで、計画をドリフトに対して強固なものにすることができます。
00:09:51コンテキストを管理する技術的な方法や、その上にソフトウェアファクトリーを構築する方法などもあります。
00:09:58しかし、計画さえあれば、それを実装するためにどのようなループやワークフローを使用しても構いません。
00:10:05これは私がランダムに選んだ計画のスクリーンショットですが、通常私が探すのは次のような要素です。
00:10:12トップにあるエグゼクティブサマリー。
00:10:14フェーズごとに細分化し、サブエージェントにそのまま組み込めるようにそれぞれに多くの詳細を盛り込むことです。
00:10:20これにより、サブエージェントがその部分を独立して処理し、他の心配をする必要がなくなります。
00:10:24他にも機能するワークフローや、計画の異なる構造が存在します。
00:10:29AIワークフローの素晴らしい点の1つは、誰もが自分に最も適したセットアップを行えることにあると私は考えています。
00:10:41結構です。
00:10:43誰もが自分にぴったりのワークフローを非常に簡単に構築できます。
00:10:47ですから、全員を1つの方法に中央集権化しようとすることは、かえって効果が薄れます。
00:10:51個人のフローに機能し、他のメンバーと反復作業ができる限り、全体として非常にうまく機能すると感じています。
00:10:58これは計画から得られる成果の一例、いわば自慢のようなものです。
00:11:04ここにはおそらく20個ほどのPRがあります。
00:11:0710行程度のものもあれば、100行程度のものもあるかもしれませんが、おそらくそれより大きいものはありません。
00:11:12これにより、AI以前の世界ではこの計画に1週間ほど取り組んでいたところを、
00:11:19さらに別の3つのチームと1週間すり合わせを行い、その後夜間にエージェントに実装を依頼するだけで済みます。
00:11:26そして戻ってきた成果は――これはおそらく1つではなく2つの計画からのものですが――実質6週間分のコーディング作業が、わずか1週間で完了しました。
00:11:36ここから5倍のスピードアップが得られるわけです。
00:11:40最後に、常に忘れてはならないレビューサイクルを考慮に入れたとしてもです。
00:11:45計画の話題から離れて、懐疑派の人々や最も多くの仕事の負担を強いられている人々が抱えていた問題に戻りましょう。
00:11:53彼らを巻き込み、そのフィードバックを真摯に受け止めるようにしてください。
00:11:59彼らが懐疑的なのは、検証の不足している箇所やツールの不具合を目の当たりにしているからです。
00:12:05したがって、彼らのフィードバックは、エージェントやコードベースとの対話を改善するためのロードマップそのものです。
00:12:12AIを使わせる方法を模索するのではなく、彼らを巻き込むようにしてください。
00:12:19組織内でAIを安全にするためのロードマップの責任者を彼らに任せるのです。
00:12:25自分たちが行っている改善によって実際の生活がより良くなっていると実感すれば、彼らも自然と賛同するようになります。
00:12:33ご覧のとおり、彼らは修正すべき点を指摘することを決して躊躇しません。
00:12:37これは、数人のメンバーと共に過ごした1時間足らずの時間の結果です。
00:12:40そしてこれがブレインストーミングの成果です。
00:12:45私自身のチームにおいて特に非常に役立っており、組織全体への導入に向けて取り組んでいるもう一つのことは、
00:12:53注意力を意識したコミュニケーションを徹底することです。
00:12:58AIの時代において、人間の注意力は希少なリソースです。
00:13:01多くの講演でも耳にしましたし、多くの人が同じ結論に至っています。
00:13:06より多くの人間の注意力を獲得することができます。
00:13:08ですから、どこに時間を使い、何を読んでいるのかが本当に重要になってきます.
00:13:13このように非常に貴重なリソースだからこそ、何がAIによって生成され、何が人間によって書かれたのかを明確にすることが、どれだけの時間をかけて読むべきかを知る上で非常に役立ちます.
00:13:24そして、コミュニケーションのこの部分でどの程度のクオリティが期待できるかを把握するのにも役立ちます.
00:13:31それが、そのスタイルのコミュニケーションを中心とした新しい文化の構築につながるのです.
00:13:35それは本当に効果的です.
00:13:36例えば、私のチームでは、プルリクエストの説明は常にこのような形式から始めることに決めています.
00:13:45私が手書きで書いた、何をしているのかを説明する非常に短い文章のあとに、AIによる説明が続くという形です.
00:13:54ただ、私はおそらくそれに目を通すでしょう.
00:13:55おかしな部分を削除するために編集するかもしれませんが、AIがすべての行を書いたわけではありません.
00:14:00ですから、もっと疑いの目を持ち、私が冒頭に書いた内容に注意を払い、必要に応じて上書きすべきなのです.
00:14:05Slackやメールでも同様に、誰もがコミュニケーションを作成するのにAIを使っているという事実を受け入れることが大切です.
00:14:15ただ、どこを読むべきで、どこをあまり注意深く見なくてよいのかを伝えることを恥ずかしがらないでください.
00:14:21初期の頃、おそらく今年の初め頃だったと思いますが、組織内のシニアエンジニアの中に非常に強いAI懐疑派が何人かいて、彼らにアプローチしようと試みました.
00:14:35何が問題なのか、何が起きているのかを知るために、彼らがやり取りしたPRコメントのいくつかを分析してみようとしたのです.
00:14:42もちろん、その分析にはAIを使いました.
00:14:45しかし、私が書いた部分とAIが生成した部分を明確に区別しなかったため、彼らは非常に立腹しました.
00:14:54彼らは、「これほど尊敬している人が、どうしてここまで雑なものを送ってくるのか理解できない」と言いました.
00:15:02そして私は、そのことについて謝罪しました.
00:15:05何を明確にし、自分の意図をしっかりと示すべきだったと気付いたのです.
00:15:08「ここが私が書いた部分で、
00:15:10ここがAIが書いた部分だ。これが雑かどうか判断する文脈が私にはないから、君たちのフィードバックが必要なんだ」と.
00:15:15「だからこそ君たちに頼んでいるんだ」と伝えるべきでした.
00:15:17したがって、このような教訓や文化の変革は、私たちが直面してきたエンジニアリングの課題と同じくらい重要です.
00:15:28導入に関して本当に役立つもう一つのポイントは、導入が進むにつれて多くの非常に高度なツールやワークフローを実装することになりますが、
00:15:41最も効果的な方法の一つは、人々が普段いる場所でそのままAIを使わせることです.
00:15:47これにより、日常業務でのAIの利用が自然になり、摩擦を減らすことができます.
00:15:54そして本当に強力な機能の一つが、Slackのメッセージ内で誰かと一緒にエージェントをメンションし、「これを作ってくれないか？」と頼めることです.
00:16:02そして、エージェントがスレッド内でタスクを完結させてくれることです.
00:16:07そうしたアプローチは本当に強力です.
00:16:09その上で、すべてを自動化し、さらに高度な仕組みを構築していくことも可能です.
00:16:14しかし、まだ完全に納得していない人と会話している場合でも、攻撃的にならない方法でエージェントをメンションし、「試してみよう、今度はエージェントがうまくやれるか見てみよう」と言い合うことができます.
00:16:26それでうまく処理が完了すれば、他の場面でも自分で使ってみようという良いきっかけになります.
00:16:33そして、私たちの旅は続いています.
00:16:37外部向けにAI機能を提供しているものの、社内でのAI活用や常に実験している多くの試みにおいて、自動化の体制はまだ完全に整っているわけではなく、私たちは今も学び続けています.
00:16:50ビルドシステムに関するすべての依存関係を考慮しながら、いつ、どのようにクラウドエージェントを効果的に活用すべきか、いまだに模索しているところです.
00:16:58そのため、私たちは学び続けています.
00:17:01それは文化の変革であり、
00:17:02エンジニアリングの変革です.
00:17:03皆さんはいかがかわかりませんが、私はシリコンバレーで過去15年間働いてきて、文化や技術の面において、これほど桁違いに大きな変化は見たことがありません.
00:17:16ですから、私たちは皆一緒にこの場にいて、手探りで進めているのです.
00:17:19それが今日、皆さんとお話ししたかったことです.
00:17:22ありがとうございました.
00:17:28ありがとうございました.
Community Posts
No posts yet. Be the first to write about this video!
Write about this video