00:00:00従来のビルドプロセスには、もはや存在しない層があります。
00:00:03ほとんどのチームは、それに代わるものを見つけられていないため、
00:00:06今でも慣習的に古いやり方を続けています。
00:00:08今週、Jenny WenがLennyのポッドキャストに出演しました。
00:00:11彼女はAnthropicのClaudeのデザイン責任者であり、以前はFigmaのデザインディレクターを務めていました。
00:00:16Figmaでの経歴もあります。
00:00:17エピソードの中で、彼女はデザインプロセスの終焉と、実際に何がそれに取って代わっているのかについて語りました。
00:00:21その実態についてです。
00:00:22そこで今回は、何がなぜ変わったのかを分析し、
00:00:26それに代わる具体的なプロセスを詳しく見ていきます。
00:00:27何が代わりになったかを知るには、なぜそれが存在したのかを理解する必要があります。
00:00:31古いプロセスでは、まず要件を定義し、次にデザイナーがそれをFigmaに取り込んで、
00:00:35アプリの完成予想図であるモックアップを作成していました。
00:00:38そのFigmaファイルは、要望と構築内容をつなぐ「受け渡しドキュメント」だったのです。
00:00:43フロントエンドエンジニアは、そのファイルをコードに変換していました。
00:00:46その間、バックエンドエンジニアは並行して開発を進めていました。事前にAPI仕様が定義されていたため、
00:00:51双方が同時に動き、最後にすべてが連結される仕組みでした。
00:00:55Jennyは、これをデザイナーが儀式のように扱っていたプロセスだと表現しています。
00:00:58これが業界の標準でした。
00:01:00変化の理由を説明する人の多くは、そもそもなぜそのプロセスが存在したのかという本質を見落としています。
00:01:05技術ブログの執筆者として広く知られる開発者のSimon Willisonは、
00:01:091月のJennyのベルリンでの講演について執筆し、彼女が直接は言及しなかった洞察を付け加えました。
00:01:14彼女の話が示唆している内容です。
00:01:16AIを活用した構築により、「間違ったものを作るコスト」が大幅に削減されました。
00:01:19AI以前は、方向性が間違っていると、数ヶ月のエンジニアリング時間が無駄になっていました。
00:01:23フロントエンドの小さなミスが、実装段階では10倍の作業量になることもありました。
00:01:27そのため、チームはあらゆるステップを正当化してきました。
00:01:28リサーチ、ペルソナ、ユーザージャーニー、ワイヤーフレーム、仕様書。
00:01:33これらすべては、大規模な開発で「間違ったもの」を作らないための防御策だったのです。
00:01:36では、プロセスにおいて実際に何が変わったのでしょうか？
00:01:38まず変わったのは、エンジニアリングのスピードです。
00:01:40そしてそれは、多くの人が認識するよりも早く変化しました。
00:01:42Jennyによれば、数年前はデザイナーとしての時間の60〜70%をモックアップやプロトタイプ作成に費やしていました。
00:01:48それが今では30〜40%になっています。
00:01:49彼女が意識的に働き方を変えたわけではありません。
00:01:51周囲のエンジニアが複数のエージェントを並行して動かし始め、
00:01:55突然、エンジニアリングがボトルネックではなくなったのです。
00:01:58エンジニアリングが先に変わり、デザインがそれに追随せざるを得なくなりました。
00:02:00ビジョンのタイムラインも変わりました。
00:02:02以前のデザインは2〜5年先のビジョンを掲げていました。
00:02:04今はテクノロジーの進化が速く、3〜6ヶ月先が現実的なスコープです。
00:02:09しかも、それは必ずしもスライド資料である必要はありません。
00:02:11人々を導く「プロトタイプ」そのものがビジョンになります。
00:02:13「変換」のステップにも同じことが起きました。
00:02:15エージェントが要件定義書から動作するインターフェースを構築できるなら、
00:02:19中間の翻訳レイヤーは不要です。
00:02:20エージェントが直接コードを書きます。
00:02:22最初からFigmaファイルが存在しないため、それを変換する必要もありません。
00:02:25また、私たちのコンテンツを楽しんでいただけているなら、ぜひ「ハイプ」ボタンを押してください。
00:02:29より多くの人にリーチし、継続的に制作する励みになります。
00:02:33クライアントワークを受ける際、私たちはまさにこのシフトを経験してきました。
00:02:36デザインプロセスは変わりましたが、変わっていないのは「要件」の部分です。
00:02:40不適切な要件は、構築作業すべてを無駄にします。
00:02:42しかし、多くのチームがいきなり詳細な仕様作成に飛びついてしまいます。
00:02:44それは順序が間違っています。
00:02:45プロトタイプを作る際、技術スタックやAPI仕様はすぐには必要ありません。
00:02:48本物の製品のような見た目と操作感を持つものを作り、
00:02:52誰かに見せて「YES」か「NO」の判断をもらうのに十分な情報があればいいのです。
00:02:56プロトタイプに触れる前に、まずは「アクター（実行者）」から始めましょう。
00:02:58アクターとは、システムと対話する人のことです。
00:03:01特定の目的を持った、特定の人物です。
00:03:03「誰が使うか」によって、何が必要かが決まります。
00:03:06コンテンツを投稿する人と、それを承認する人がいる場合、
00:03:10それらは2つの異なるインターフェース、2つの異なる最初の画面になります。
00:03:12次に、ビュー（画面表示）がどこで分かれるかを確認します。
00:03:13ほとんどの製品では、異なるアクターが同じURLにアクセスしても、
00:03:18全く違う内容を目にするポイントがあります。
00:03:19管理者は管理パネルを見ます。
00:03:21一般ユーザーはダッシュボードを見ます。
00:03:22最後は「制約事項」です。
00:03:24エージェントに「どのツールを使うべきか」を指示しないでください。
00:03:26「何をしてはいけないか」「コストをどこまで抑えるべきか」を伝えます。
00:03:28これにより、後々の技術的な決定も格段に容易になります。
00:03:32私たちはこれら特定のルールを「PRD作成プロンプト」に実装しました。これは、
00:03:37あなたにインタビューを行い、ルールに従って一連の質問を投げかける
00:03:42PRDインタビュアーとして機能します。
00:03:44最終的にはPRDのMarkdownファイルが完成し、
00:03:48それが後続の工程で使用されます。
00:03:49そのPRDファイルこそが、すべての基盤となります。
00:03:52次のステップは、それをフロントエンドの構造に変換することです。
00:03:55ここでは「レイヤープロンプト」を使い、エージェントにPRDを参照させます。繰り返しになりますが、
00:04:00すべての技術要件を含んだ完全なPRDではなく、2つのものを生成させます。
00:04:04プロトタイプに必要なページとモーダル、
00:04:08そしてユーザーフローの作成を依頼します。
00:04:09ページとモーダルは構造上重要です。これにより、フロントエンドに実装すべき内容が
00:04:14事前にもれなく計画されます。
00:04:17「実行前の計画」の重要性と、それがエージェントやコンテキストウィンドウにどう影響するかについては、
00:04:21常々お話ししているので、ここでは深く掘り下げません。
00:04:24ユーザーフローについては、各アクターのアクションを定義することが不可欠です。
00:04:28機能ではなくアクター自身に焦点を当てているため、
00:04:32適切なインタラクション状態やナビゲーションを実装するために、
00:04:36ユーザーフローを定義しておく必要があります。
00:04:40最終的に、ページ、モーダル、ユーザーフローを含む
00:04:45architecture.mdなどの2つのファイルが出来上がります。
00:04:46その後、私たちが普段使用している技術スタックである
00:04:50Next.jsとSupabaseをインストールするよう指示しました。
00:04:53そして、実際に生成されたのがこれです。
00:04:55全体としてデザインは非常に優れていますが、それには明確な理由があります。
00:04:58言い忘れていましたが、今回の構築対象はチャンネル、商品、
00:05:03コースを備えたコミュニティプラットフォームです。
00:05:04アクターは主に「メンバー」と「クリエイター」の2人です。
00:05:08クリエイターには、チャンネル作成、商品の追加、コースのアップロード、
00:05:12各種統計の確認といったすべての管理機能があります。
00:05:15最初に作られたプロトタイプとしては、デザインは本当に素晴らしいと思います。
00:05:19ただ、UXはあまり良くありません。通常、このようなダッシュボードは望まないからです。
00:05:23しかし、これこそが重要なポイントなのです。
00:05:24以前ならこうした修正に数日かかっていましたが、今では数分で済みます。
00:05:27AIなら、これらの変更を非常に素早く行えるからです。
00:05:30バックエンドが存在しないため、余計な手間をかけずに、
00:05:34フロントエンドのプロトタイプに集中できます。
00:05:36通常、AIはこれほど見栄えの良いインターフェースをすぐには作りません。
00:05:40今回うまく見えている理由は、Anthropicがブログで公開した
00:05:44「汎用フロントエンド・スキル」を使用しているからです。
00:05:46UIを実装する前に、これを利用することを強くお勧めします。
00:05:50スラッシュコマンドやスキルとして保存しておけば、エージェントがすぐに利用できます。
00:05:53クライアントワークであれば、このプロトタイプを見せるだけです。
00:05:57現時点ではデータベースは繋がっておらず、モックデータを使用していますが、
00:06:01機能的には完全に動作します。
00:06:02これをクライアントに見せて承認を得、必要なら修正を加え、
00:06:06その後の本構築へと進みます。
00:06:08こうしたタスクリストのおかげで、エージェントに
00:06:12完全に機能するプロトタイプの作成を依頼できるようになりました。
00:06:14タスクリストの活用、タスクの永続性、そしてすべてが構造化されているからです。
00:06:17構造化されていることが重要です。
00:06:18architecture.mdを作成したことが非常に重要だったのは、
00:06:23エージェントがハルシネーションを起こさないよう、完全に最適化されたタスクリストを作成できるからです。
00:06:28その後、バックエンドの実装に移ります。
00:06:30通常、2つのアプローチが考えられます。
00:06:32一つは、Next.jsをフロントエンドとして使い続け、
00:06:36バックエンドを独立したPythonサービスとして実装する方法です。
00:06:39これは開発しているアプリケーションの種類によります。
00:06:42皆さんが作るプロジェクトの多くは、Next.jsだけで十分でしょう。
00:06:46独立したPythonバックエンドが必要になるのは、Next.jsでは利用できない広範なライブラリが必要な場合や、
00:06:50サイトや機能の最適化のために
00:06:55本格的なバックグラウンドジョブのオーケストレーションが必要な場合です。
00:06:57その場合には、専用のバックエンドが必要かもしれません。
00:06:59そうでなければ、Next.jsのバックエンドで事足ります。
00:07:03バックエンドに着手する前に、フロントエンドが何を求めているかを知る必要があります。
00:07:07そこでエージェントにフロントエンドのコード、PRD、設計ファイルを確認させ、
00:07:11API仕様書を作成させました。
00:07:12その後、これら3つのドキュメントを使用して、Supabaseの完全なスキーマを作成するよう指示しました。
00:07:17フロントエンドにはSupabaseとNext.jsを使用しているからです。
00:07:20アプリのデータを格納するためのスキーマを作成する必要があります。
00:07:25普通にエージェントに頼むと、データベースからAPIキーを取得し、
00:07:28手動でSQLクエリを貼り付けてテーブルを作成するよう指示されるでしょう。
00:07:33しかし、その代わりにSupabase MCPを使用すべきです。
00:07:36利用するサービスにMCPがある場合は、常にそれを使ってください。
00:07:40多くの作業を自動化できるからです。
00:07:41例えば今回、プロジェクトの中身をわざわざ確認する必要すらありませんでした。
00:07:43自動的にプロジェクトが作成され、スキーマ作成のクエリが実行され、
00:07:48マイグレーションまで自動で行われました。
00:07:49私たちは実質的に何もする必要がなかったのです。
00:07:51データベースの設定が終わったら、フロントエンドを接続します。
00:07:55ここでも明確な違いがあります。
00:07:57バックエンドをデータベースに接続する必要はありません。フロントエンドに
00:08:00すでに統合されているからです。
00:08:01フロントエンドが直接データベースと通信するため、統合の手間が省け、
00:08:06全体の複雑さも大幅に軽減されます。
00:08:07さて、今回の動画はWarpと提携しています。彼らは最近、
00:08:11クラウドエージェントのオーケストレーション・プラットフォームである「OZ」をリリースしました。
00:08:14これらのクラウドエージェントは、エージェントが自律的に完了できると分かっているタスクを
00:08:19委任するのに非常に便利です。
00:08:21これまでの工程で、エージェントはフロントエンドとデータベースを接続し、
00:08:26アプリは基本的に動作する状態でした。
00:08:27しかし、支払い処理、通知機能、レート制限、アナリティクスなどを追加するには、
00:08:32それらを統合するための専用のバックエンドAPIレイヤーが必要です。
00:08:37そのためにOZで環境を構築し、クラウドエージェントを実行して、
00:08:41専用のバックエンドレイヤーの構築を依頼しました。
00:08:43約15分後、タスクは完了し、すべてが整いました。
00:08:47実用化してユーザーを受け入れるために残された作業は、
00:08:51Google認証、Stripeの統合、そしていくつかの細かな修正だけでした。
00:08:56全プロセスとプロンプトは、画面上にすべて表示してきました。
00:09:00もし、これらのプロンプトをご自身のプロジェクトで活用できるステップバイステップのワークフローとして欲しい方は、
00:09:04「AI Labs Pro」にまとめてあります。
00:09:06ご存知ない方のために説明すると、これは今回の動画や過去の動画で使用したテンプレートを
00:09:10そのままプロジェクトにプラグインできるコミュニティです。
00:09:14私たちの活動に価値を感じ、チャンネルを支援したいと思ってくださるなら、
00:09:18これが最善の方法です。
00:09:19リンクは概要欄にあります。
00:09:20これで今回の動画は終わりです。
00:09:22チャンネルを支援し、このような動画制作を続けてほしいと思ってくださる方は、
00:09:26下の「スーパーサンクス」ボタンから支援をお願いします。
00:09:28いつものように、ご視聴ありがとうございました。また次の動画でお会いしましょう。