「ゴミを入れれば、宝が出てくる」――Anthropicのチーフデザイナーが語るCoworkの製品哲学と、10日間でのリリースの真実
TechFlow厳選深潮セレクト
「ゴミを入れれば、宝が出てくる」――Anthropicのチーフデザイナーが語るCoworkの製品哲学と、10日間でのリリースの真実
「Claude Code はすでにコード関連のタスクを非常に優れたレベルで処理できるようになりましたが、当社の目標はあらゆる知識労働のシナリオをカバーすることです。」
Web3業界の深掘り報道に専念し潮流を洞察編集・翻訳：TechFlow
ゲスト：Jenny Wen（Cowork デザイン責任者）
司会：Peter Yang
ポッドキャスト元：Peter Yang
オリジナルタイトル：Claude Cowork Tutorial from Cowork’s Design Lead (40 Min) | Jenny Wen
放送日：2026年3月29日
要点まとめ
JennyはCoworkのデザイン責任者です。彼女は、Anthropicの内部運営について、自らがCoworkを用いて製品を設計・開発する方法や、Cowork誕生に至る実際の経緯など、深く掘り下げて解説してくれました。Anthropicではほぼ毎日新機能がリリースされており、その働き方には本当に驚かされます。
注目すべき見解の要約
日常の業務スタイルについて
- 私が時間を費やす大部分の作業は、製品を世に出すことです。ただし、これは1～2年前と比べるとかなり様変わりしているかもしれません。その大きな部分は、エンジニアやプロダクト担当者などと、あまり形式ばらない形で「jam（即興的協働）」することです。通常は、皆でプロトタイプを見ながら、それがどのように進化できるかを指摘・検討します。
「ゴミを投入し、宝を出力する」使用哲学について
- Coworkが私に最も強く印象付けた点は、情報整理能力です。私はこれを「ゴミを投入し、宝を出力する」と呼んでいます。Coworkはさまざまなソースから情報を収集し、素早くキーポイントを抽出・価値あるコンテンツへと凝縮し、実践的な成果物へと変換します。
CoworkとClaude Codeの違いについて
- 非常に細かい本番コード（production code）作成作業を除けば、現在私はほぼすべてのタスクにCoworkを使っています。特定のコードの詳細に集中する必要がある場合は、依然としてClaude Codeを使います。しかし、日常的なコミュニケーションやコラボレーションについては、今や完全にCoworkに依存しています。
Coworkの誕生ストーリーについて
- 「彼らは10日間で完成させた」という話は、どこかのインタビューまたはメディア報道から切り取られたものです。実際には、私が1年前にAnthropicに加入した時点で、すでにCoworkという方向性について構想を練っていました。私たちが常に考え続けてきたのは、「すべての汎用知識労働者を支援する『思考パートナー（thinking partner）』をどう創り出すか？」という問いです。
- Claude Codeは既にコード関連タスクを十分に処理できますが、私たちの目標は、あらゆる知識労働のシナリオをカバーすることです。真の課題は、「このアイデアをどう実行するか？」「どんなアーキテクチャが最適か？」「どんなユーザーエクスペリエンス（UX）が正しいのか？」という点にあります。
デザインプロセスの進化について
- Figmaは引き続き使います。しかし、仕様書（spec document）を作成することはほとんどなく、また作成しても非常に詳細なものではありません。優先順位付けは依然として行いますが、それはドキュメントとして存在するものの、通常は数個の箇条書きにすぎず、過剰にデザインされた美しい表ではありません。
計画とビジョンについて
- 私たちが属する技術分野は極めて変化が速く、新しいモデルが次々と登場し、更新頻度もどんどん高まっています。そのため、1年単位のビジョンを策定することさえ現実的ではなく、ましてや2～5年のビジョンなど到底不可能です。不確実な要素が多すぎるからです。
デザイナーの将来について
- もし足元の地面が動いていると感じたら、それは実際に動いているのです。それを認め、適応を学び、同時に既存のワークフローをオープンな姿勢で再検討することが求められます。
- 自分の職業が挑戦されていると感じたとき、私はいつもエンジニアの同僚たちのことを思い出します。彼らの仕事はすでにかつてないほど大きく変化しており、それらに適応しただけでなく、大きな勇気と謙虚さを持って挑戦を受け入れ、より効率的で優れた成果を生み出してきました。彼らこそ私のインスピレーションの源です。「私がとても尊敬するこれらの同僚ができたのなら、私も必ずできる」と自分に言い聞かせます。彼らは、変化への適応の模範です。
オープニング
Peter Yang：こんにちは。本日は、Anthropicのデザイン責任者であるJennyを大変嬉しくお迎えします。Jennyは、Claude CoworkおよびClaude Codeを用いた製品の設計・リリース方法を紹介してくださるほか、Coworkの内部ストーリーや、今後の製品展開についても語ってくださる予定です。
Jenny、あなたの典型的な1日の業務はどのようなものでしょうか？どのタスクに最も多くの時間を費やしていますか？
Jenny：
「典型的な1日」というものが果たして存在するのかは分かりませんが、私が時間を使う大部分の作業は、製品を世に出すことです。ただ、これは1～2年前とはまた違った形になっているかもしれません。その大きな部分は、エンジニアやプロダクト担当者などと、あまり形式ばらない形での「jam（即興的協働）」です。通常は、皆でプロトタイプを見ながら、それがどのように進化できるかを指摘・検討します。時には機能の表現方法について議論したり、時には自分が何かを実装したりします。それでも、自分でデザインしたりプロトタイピングしたりする時間はまだ多くありますが、今のデザイン作業のやり方は、とても緩やかで柔軟です。
Peter Yang：つまり、あなたはClaudeなどを用いて大量のプロトタイプを生成し、それをエンジニアとともにjamしながらフィードバックを与え、プロンプトでAIに改善を指示している、ということですね？
Jenny：
実は、それらはしばしばプロトタイプでさえなく、すでに社内で構築され、ClaudeやCoworkのインスタンス上で動作中の「実用可能なプロトタイプ」です。私は通常、この機能を使ってみたり、推進したり、その能力を確かめたり、意見を形成したりします。次の反復ステップでは、エンジニアにこう言います。「こんなふうに考えてみました。ここを変えるべきだと思います」。それでも、デザインツール内で反復・磨き上げ・精緻化する時間が、まだまだ非常に重要であることに変わりはありません。だからその部分は消えていません。ただ、複数のプロジェクトを同時に進めているため、より効率的にするために、非常にカジュアルで非公式なやり方が自然と選ばれているのです。
Peter Yang：私は、デザイナーとエンジニアを一緒に集め、製品を一緒に反復していくプロセスが、プロダクトマネージャーやデザイナーとして最も楽しんでいる部分です。では、今では仕様書やFigmaファイルなどの計画ドキュメントはあまり作成しないのでしょうか？それとも、コード内でのプロトタイプ反復に移行したのでしょうか？
Jenny：
私は依然としてFigmaを使います。しかし、仕様書を作成することはほとんどなく、また作成しても非常に詳細なものではありません。はい。優先順位付けは引き続き行いますが、それはドキュメントとして存在します。実際、これはセキュリティや法務チームに渡す際にも非常に役立ち、彼らがリリース内容を把握できるようになります。とはいえ、通常は数個の箇条書きにすぎず、過剰にデザインされた美しい表ではありません。私たちのFigmaファイルも同様です。
Cowork 実践デモ
Peter Yang：Coworkや他の製品を実際にどのように使っているか、あるいはそれぞれの製品を何に使っているかを、ぜひご紹介ください。
Jenny：
もちろんです。まず、私がCoworkをどのように使っているかをお話しします。実はちょっとした秘密がありますが、非常に細かい本番コード（production code）作成作業を除けば、現在私はほぼすべてのタスクにCoworkを使っています。特定のコードの詳細に集中する必要がある場合は、依然としてClaude Codeを使います。しかし、日常的なコミュニケーションやコラボレーションについては、今や完全にCoworkに依存しています。
私がCoworkに最も強く感銘を受けた点は、その情報整理能力です。私はこれを「ゴミを投入し、宝を出力する」と呼んでいます。Coworkはさまざまなソースから情報を収集し、素早くキーポイントを抽出・価値あるコンテンツへと凝縮し、実践的な成果物へと変換します。
例えば、私は現在、ユーザーインタビュー記録が保存されたフォルダーに接続しています。Coworkチームはユーザーとの密接な関係を非常に重視しており、それが一定の成功を収められた鍵の一つでもあります。従来のユーザーエクスペリエンス研究（UXR）を通じて直接ユーザーと対話し、さらに社内での自社利用にも力を入れています。例えば、フィードバックを収集する専用Slackチャンネルを設けています。また、ソーシャルメディア上の議論にも注目し、熱心なユーザーの声にも耳を傾けています。このようなユーザーとの緊密な関係を維持し、迅速にプロダクトを反復できることが、継続的な改善と今日の成果につながっています。
そこで、私は現在こうしています。Claudeにこう伝えます。「このインタビューのフォルダーがありますが、SNSやReddit、その他Coworkの顧客レビューも調べて、最大のインサイトを教えてください」。少し時間がかかる場合もあります。なぜなら、膨大なデータを本当に処理・加工する必要があるからです。しかし、Coworkは時としてサブエージェントを派生させて並列処理を行ったり、ネット検索に時間をかけたりもします。
Peter Yang：実際の業務では、週単位のインサイトレポートのようなものを自動でまとめて、あなたやチームに配信していますか？
Jenny：
実は、今すぐにCoworkでそのようなレポートを作成できます。私たちのリサーチャーの一人が定期的に配信しており、またSlackでチームに通知するバージョンも存在します。さらに、内部Slackチャンネルの投稿も直接確認しています。私たちは、内部スタッフや最も強力なユーザーからの最先端のフィードバックに非常に依存しています。なぜなら、内部スタッフは正直に意見を述べてくれることが多く、機能を限界まで押し広げて試してくれ、また追跡も容易だからです。
Peter Yang：まさにこれが起こるべきことであり、多くの企業ではチーム間の壁が厚すぎますが、Anthropicはまったくそのような状況ではないと感じます。
Jenny：
これもまた、Claude Codeの成功における重要な一因だと考えます——すなわち、現場のユーザーの声に耳を傾けること。また、Figma時代からずっと、社内でのdogfooding（自社製品の率先利用）を大規模に行ってきたことも関係しています。特にインタラクションデザインや微調整といった領域では、内部スタッフが本当に細部まで突っ込んで検証してくれるため、外部ユーザーが与える「その機能がユーザーのワークフローに適合するか？」というレベルのフィードバックとは、全く異なる次元の洞察を得ることができます。
Cowork vs Claude Code のユーザー境界
Peter Yang：Anthropicのマーケティングやプロダクトマネージャーは、Coworkが利用可能になって以降、基本的にClaude Codeを活用していると聞いています。異なるユースケースや、CoworkとClaude Codeの使い分けについて、どのようにお考えですか？
Jenny：
私たちは、Coworkの全体的な適用範囲が徐々に拡大しており、かつてClaude Codeの先進的ユーザーが試行していたようなシナリオにも、今や適用され始めていることに気づきました。Coworkの開発当初、主要な情報源は社内の営業チームでした。その中には、Claude Codeのヘビーユーザーが何名かおり、潜在顧客リストの作成や電話用スクリプトの作成などに活用していました。初めてこれらのユースケースを目撃したとき、私は非常に驚きました。当時は、Claude Codeがこうしたタスクにも使えるとはまったく思いもしませんでした。そして今では、これらのユーザーはほぼ全員Coworkへと全面的に移行しており、その同僚たちもCoworkを頻繁に使うようになりました。
理由の一つは、今や洗練されたUIが備わったことです。これがまさに必要なものだったのだと思います。もう一つの理由は、Coworkが彼らが日々行っている他の作業と非常に近い場所にあることです——彼らはもともとチャット機能を多用しており、このデスクトップアプリケーションからもClaude Codeをそのまま利用できるため、コマンドラインを開くよりも、彼らの既存のワークフローに自然に溶け込むのです。
インサイトから実行可能な成果物（Artifact）へ：完全なプロセス
Jenny：
ここには7つの異なるトピックがあり、毎週変わっています。私は基本的にこう伝えます。「このドキュメントXを作成してください」と。そして、それはすでに私のパソコン内のフォルダーに自動的に保存されています。さらに、2つの並列タスクを同時に開始することもできます。例えば、「これらのインサイトは素晴らしいですが、これらに基づいて実際にどの製品機能を構築すべきでしょうか？」と尋ねることもできます。また別の並列タスクとして、「先ほど作成してくれたインサイトドキュメントを基に、今週のキックオフミーティングでチームと共有できるプレゼンテーション資料に変換してください」と指示することもできます。
そして最終的には、ここでデザインプロセスを開始できます——Coworkはさまざまな機能オプションを提示してくれます。そこからさらに、Claudeにこれらの機能のワイヤーフレームを作成してもらうこともできます。すると、多数の異なるオプションが提示されるので、それらをFigmaに持ち込んで本格的に精緻化したり、Claude Codeに持ち込んで、実際のデザインシステムコンポーネントを使ってリアルなものを構築したりできます。
さらに、これら2つのタスクをスケジュール化することも可能です。つまり、毎週月曜日の午前10時に自動実行するように設定できます。そうすれば、毎週月曜日の午前10時になると、プレゼンテーション資料と、3～4つの異なる製品アイデアを手に、その週のキックオフを始められます。これは、フィードバックから具体的な成果物やチームが共有できるアイデアへと至る反復サイクルを極めて短縮し、製品の迅速な反復と品質向上を実現します。
Peter Yang：すべては反復であり、すべては反復です。私も最近は怠け気味で、常にAIに第一版を作ってもらい、その後で私がフィードバックするというスタイルです。
Jenny：
はい。ですから、本当にゼロからこれらのインサイトを機能の優先順位付けへと整理してほしいと頼むと、今では以前よりもずっと時間がかかるようになっています。
私も同じようにしています。例えば、あなたが送ってくれたこのポッドキャストノートについて、私は個人ノートフォルダーを持ち、そこには1対1ミーティングの内容やランダムなアイデアなどが入っています。そして私はこう言います。「私の個人ノートを読んで、このポッドキャストの発言の要点を考えて、ここで何を話したいかも考えてください」。もちろん、一字一句そのまま読むわけではありませんが、本当に私の思考のきっかけになり、思考を進化させる助けになります。行き詰まるのを防いでくれるのです。
Skills と個人知識ベース
Peter Yang：あなたはどのようなskillsを使っていますか？あるいは、これらのドキュメントやプレゼンテーション資料作成のために、個人専用のskillsを独自に作成していますか？
Jenny：
社内には、ドキュメントやプレゼンテーション資料作成のための専用skillsがいくつかあります。これはブランドの一貫性を保つのに役立つからです。私は個人用のskillsライブラリーは持っておらず、ほとんどの場合、社内で既に存在するskillsを借用し、さまざまな用途に応じて使い分けています。
Peter Yang：例えば、私は「writing skill」というものを持っています。これはAIが陳腐な表現（AI slop vocabulary）を使わないよう指示するものです。
Jenny：
しかし、実際には、Coworkのフォルダー機能——そこにすべての個人ノートなどを保存しています——が、私のことを理解する手段として非常に役立っています。私にとっては、すでに十分に有用なのです。むしろ、memoryやskillsの必要性は、どんどん減っていると感じます。なぜなら、Coworkがすでに私の知識ベースを持っているからです。もちろん、skillsには確かに有効な活用シーンがありますが、私の現在のユースケースでは、その需要はそれほど高くないと感じています。
Peter Yang：それは、日々の会話に基づいて自動的にメモリーを更新してくれるからですか？
Jenny：
はい、それは基本的に私が自分で管理するメモリーです。なぜなら、私は常にそこにノートを書き続けているからです。
チームコラボレーションの節目
Peter Yang：では、この一連のプロセスにおいて、チームをいつ巻き込みますか？つまり、AIと反復し、その後チームと反復し、交互に切り替えるのでしょうか？
Jenny：
私の場合、本格的なUXRインタビューなどは自分で行いません——それはプロダクトマネージャーやチーム内のリサーチャー、あるいは他のメンバーが担当します。そして、その結果得られた成果物（artifact）を直接共有し、チームを巻き込むことで、それがチームの実際の活動の根拠となります。
私たちのチームは、少なくとも相当にボトムアップかつ民主的であり、私たちの活動スタイルは、インサイトや目標をチーム全体に提示し、各自がプロトタイプを作成したり、様々なアイデアを試行したりすることです。アイデアは四方八方に湧き出てきます。デザイナーである私がすべての解決策を考案するのではなく、「ほら、こういうインサイトがあります。今月達成すべき目標はこれです。みんなでどうやって達成しましょう？」というスタイルです。
しかし、こうしたプロセスがあっても、すべてをClaudeに任せてしまうことはありません。我々自身による判断や、実際に構築すべきもの・すべきことの管理・決定能力に、依然として強く依存しています。
Peter Yang：オンラインで「品位（taste）」や「判断力（judgment）」について語られるとき、それらを育てる方法は、内部および外部から継続的に大量の製品フィードバックを得ることにあると私は思います。その過程で、問題がどこにあるのか、どこを修正すべきかという直感が徐々に養われていきます。なぜなら、日々フィードバックを聞き、処理しているうちに、問題に対する鋭い判断力が身についていくからです。
Jenny：
デザインに関して、Claudeの機能の一つは、ワイヤーフレーム（wireframe）に似たスケッチを生成し、複数のデザインオプションを提示できることです。デザイナーとして、私はこの方式を非常に気に入っています。これらのスケッチの精緻度は必ずしも高くないかもしれませんが、自分の想像力に頼らずに、さまざまな可能性を直感的に視認できる点が魅力です。これにより、次のデザイン方向をより迅速に決定できます。
したがって、Claudeに初期のオプションを直接生成させることで、手作業でスケッチを作成する時間と労力を節約できます。そこから私は一つの方向を選択し、小規模な反復を始めます。次に、コードを用いてその方向性で初期プロトタイプを作成し、それを基にデザインをさらに最適化・精緻化していきます。
Cowork 誕生の真実の物語
Peter Yang：では、Coworkがいかにして誕生したのか、お話ししていただけますか？外では「10日間で完成した」という話がよく語られていますが、実際にはそれ以前から多くの反復があったのではないでしょうか？
Jenny：
「彼らは10日間で完成させた」という話は、どこかのインタビューまたはメディア報道から切り取られたもので、それがずっと話題になっています。しかし実際には、私が1年前にAnthropicに加入した時点で、すでにCoworkという方向性について構想を練っていました。私たちは常に、「すべての汎用知識労働者を支援する『思考パートナー（thinking partner）』をどう創り出すか？」という問いを考え続けてきました。Claude Codeはすでにコード関連タスクを十分に処理できますが、私たちの目標は、あらゆる知識労働のシナリオをカバーすることです。真の課題は、「このアイデアをどう実行するか？」「どんなアーキテクチャが最適か？」「どんなユーザーエクスペリエンス（UX）が正しいのか？」という点にあります。
過去1年間、私たちは多くの異なるプロトタイプを試作し、その中には現在の目標よりもさらに壮大なアイデアもありました。また、さまざまなAIエージェントフレームワークをテストする技術実験も多数行いましたが、その中には失敗したものもありました。最終的に、現在の方向性を徐々に確定しました。私たちは、研究所チームが開発したプロトタイプを参考にしただけでなく、プロダクトチーム自身が構築したプロトタイプも研究しました。そして、タイミングと実行力が鍵となり、まさに雷が的確に落ちたような瞬間でした。
製品のリリースを決めたとき、そのプロセスは非常に迅速でした——「リリースすべきだ」と決断してから「製品が公開された」まで、わずか10日間でした。これは主に、Claude Codeの休暇期間中にその潜在的可能性を発見したからです。休暇中、多くの人がついにClaude Codeを試す時間ができ、技術者でないユーザーも含めて、ポッドキャストの文字起こしを解析したり、複雑なデータ分析を行ったりするなど、幅広く活用し始めました。私たちは、Claude Codeのエージェントフレームワークが、技術者でないユーザー層においても、初期のプロダクト／マーケットフィット（PMF）を示し始めていることに気づきました。実は、当時すでに稼働可能なプロトタイプが社内で存在しており、本来はもう少し後でリリースする予定でした。しかし、これらのフィードバックから「今こそが最良のタイミングだ」と判断し、その機会を捉えて、あの狂気じみた10日間を経てリリースに至りました。
Peter Yang：私の理解が正しければ、過去1年間、社内のSlackで多くのプロトタイプを共有し、大量のフィードバックを収集し、最終的に実現可能なプロトタイプを確定した。その後、市場の需要を確認し、迅速なスプリントで製品をリリースした、ということですね？
Jenny：
はい、その通りです。本来は数週間後にリリースする予定でしたが、「今こそが最良のタイミングだ」と感じたため、時間的制約の中で製品の範囲をより現実的かつ実行可能な規模に絞り込み、全精力とリソースを投入して、最終的にリリースを成功させました。
初期のデザイン反復：workflowツールから極簡のチャットへ
Peter Yang：初期の反復に関する経験や、開発中のコンテンツをいくつかご紹介いただけますか？
Jenny：
もちろんです。私は特別に初期のスクリーンショットをいくつか用意しました。それらを通じて、当時のデザインの考え方や反復プロセスをご覧いただけるでしょう。
今年初め、私と別のデザイナーが共同で早期のプロトタイプを作成しました。当時、私たちはこのツールを、タスク志向（task-oriented）またはワークフロー志向（workflow-oriented）に設計しようとしていました。なぜなら、Coworkのような製品を使用することで、ユーザーが明確なタスクを完了したり、明確な成果（outcome）を得たりできるかどうかを心配していたからです。例えば、ダッシュボードの作成や、異なるソースからのデータ統合などです。そのため、当時のユーザーインターフェースは非常に構造化されており、ほぼワークフロー向けツールのようになっていました——例えば、「これらのコンテンツを追加してください。これが入力（inputs）、これがアウトプット（outputs）です」。一方、チャット機能は二次的な位置付けでした。
しかし、2025年という時代において、なぜこんなに多くのステップを踏む必要があるのでしょうか？Claudeに任せておけばいいのでは？
これは私たちの初期のデザイン方向の一つでしたが、その後、よりシンプルな「チャットボックス（chat box）」のような形に方針転換しました。この方法で、ユーザーが分析やドキュメント生成といったより具体的な目標を達成できるように導こうとしたのです。また、機能的なプロトタイプも設計しました——ユーザーがクリックすると、ドキュメントの長さや、メモやプレゼンテーション資料といったドキュメントタイプを選択できるボタンが表示されます。しかし、このデザインは最終的にユーザーにとって複雑で圧迫感のあるものと感じられました。
そのため、何度も探求と試行を重ね、常にバランスを探し続けてきました：「使用シナリオをより明確に定義すべきか？それとも、チャットボックスのような自由な形式を維持すべきか？」
最終的に、数週間前にリリースしたバージョンが現在の形です。私たちは、ユーザーがクリックすると「3～5ページのドキュメントを作成してください」などとガイドする「ウィザード型（wizard-like）」のユーザーエクスペリエンスを試行しました。
当時、私たちはインターフェースに多くの要素を盛り込み、普通のチャットボックスとは一線を画そうとしていました。しかし、後にこのデザインがインターフェースを過度に複雑にし、視覚的要素間の競合が激しくなっていることに気づきました。そこで、不要な要素を大幅に削除し、デザインを簡素化することに決めました。
現在ご覧いただけるユーザーインターフェースは、大幅に簡素化されています。重厚なサイドバー（sidebars）を撤去し、伝統的なチャットボックスに近づけました。ただし、ホーム画面には変更を加え、それが単なる複雑な提案やガイドが満載のチャットツールではなく、私とClaudeが共に共有する「タスクリスト（to-do list）」のように見えるように工夫しています。
Peter Yang：将来的には、複数のエージェント（agent）をサポートし、タスクをドラッグ＆ドロップでワークフローを管理できるようになるかもしれませんね。
Jenny：
将来的にはその可能性もあるかもしれません。しかし強調したいのは、UIデザインは約4～5週間前とはまったく異なり、私たちは常に学び続け、何が最も効果的で、何がそうでないかを探究し、この技術をユーザーに最も良い形で提示する方法を模索し続けているということです。
Cowork と Claude Code の差別化戦略
Peter Yang：Claude Codeの使用中、私はTwitterでしばしばフィードバックを共有しています。Claude Codeには、ユーザーが少しずつ学習する必要のあるスラッシュコマンド（slash commands）が多数内蔵されています。この体験は、コストコ（Costco）で「宝探し（treasure hunt）」をするようなもので、いつ何が見つかるか予測できません。
しかし、初心者にはあまり親しみやすくありません。それはむしろゲームのようなもので、使い続けることで徐々に慣れて、マスターしていくものです。私は、Coworkは、普通のチャットツールとClaude Codeの中間地点を探ろうとしているのではないかと感じています。すべての機能を隠すのではなく、何らかの方法でユーザーがより良く使えるように導こうとしているのです。
Jenny：
はい。Coworkでもスラッシュコマンド（slash commands）は引き続きサポートされていますが、それらは主要なインタラクション方法ではありません。個人的には、Coworkは少なくともプロフェッショナル向けのツールであると考えています。私たちは、多くのユーザーがすでに高度なユーザーとしてCoworkを使いこなしていることに気づきました。また、コミュニティ内にはすでに高度なユーザーが現れ始めています。こうしたユーザーは、スキル（skills）の自作やチームへの共有、あるいはショートハンドコマンド（shorthand commands）の利用など、より複雑な機能を学ぶことに時間を費やすことを厭いません。
ただし、私たちの目標は、こうした機能を補助的なインタラクション手段とし、必須の学習項目とはしないことです。つまり、ユーザーがすべてのコマンドを知らなくても、Coworkを簡単に使えるようにしたいのです。Claudeとのインタラクションは、自然で直感的であるべきであり、一連のコマンドを暗記しなければ操作できないようなものであってはならないのです。
計画プロセスとビジョン
Peter Yang：Anthropicの計画プロセスはどのようなものですか？年次計画や目標設定は行っていますか？それとも、プロトタイピングと継続的な試行に依存しているのでしょうか？
Jenny：
私たちの計画方法は、毎回異なります。私が所属するチームでは、月次計画を行っています。Cowork関連の部分については、少なくとも12個程度のタスクをExcelシートにリストアップし、これらを最高優先度（P0）としています。各タスクには直接責任者（DRI）が割り当てられており、毎週チェックインを行い、「我々は依然として正しい軌道に乗っているか？」を確認します。また、四半期や半年ごとの計画も行い、通常は責任者が「我々はこの方向に進むべきであり、これらが注目すべき事項である」と指摘します。しかし、これらの計画は、特定のプロジェクトを実行しなければならないほど厳格なものではありません。むしろ、チーム全体に全体的な方向性を示すための、比較的柔軟なものです。
Peter Yang：つまり、柔軟性が高いということですね？興味深いことに、最も革新的な企業は、年次計画をあまり行わず、代わりに継続的な反復とユーザーからの学びに重点を置いているようです。あなたのキャリアの中で、North Starビジョンの資料（deck）を作成したことはありますか？それらは有効でしたか？
Jenny：
はい、私は実際に作成したことがあります。昨年、North Starビジョンの資料を作成しました。ビジョンには確かに価値があり、チームに方向性を示し、これから取り組むべき作業を明確に保つのに役立ちます。しかし、私たちが属する技術分野は極めて変化が速く、新しいモデルが次々と登場し、更新頻度もどんどん高まっています。そのため、1年単位のビジョンを策定することさえ現実的ではなく、ましてや2～5年のビジョンなど到底不可能です。不確実な要素が多すぎるからです。
しかし、ビジョンの真の価値は、特に誰もが自由にさまざまなプロジェクトを構築できる環境において、皆が同じ方向を向いて進むことを促すことにあるのです。したがって、私は今やビジョンの時間軸を最大でも3～6ヶ月とし、ドキュメントの形で表現することを推奨しています。また、ビジョンが可視化されたときに、その影響力はさらに高まります。これこそがデザインの大きな価値の一つです——さまざまな要素を統合し、特定の期間内に一貫性のある物語を語ることです。もちろん、ビジョンは静的な資料（deck）ではなく、プロトタイプの形をとることも可能です。これにより、特に5つのチームが非常に類似した、あるいは衝突しうるプロジェクトに取り組んでいる場合に、チーム間の協調を図ることができます。デザインは、こうしたアイデアをキュレーションすることで、それらを一致させ、理想のユーザーエクスペリエンスへとつながる道筋を示すことができます。分散した体験ではなく、一貫した体験へと導くのです。
Peter Yang：では、プロダクトマネージャーによるレビュー、あるいは関係者によるレビューは行われますか？これらのレビューは正式なものでしょうか？それとも、彼らもプロトタイプ設計に参加するのでしょうか？
Jenny：
レビューは確かに実施しますが、私が以前勤めていた会社のように、すべての機能に対してレビューを行うわけではありません。レビューは、規模が大きく、優先度の高いプロジェクトに対してのみ行われます。レビューの目的は、膨大な時間を準備に費やすことではなく、プロジェクトの可視性を高め、フィードバックを得ることです。クロステーム間で、会社全体に影響を与える重要なプロジェクトの場合に、レビューを実施します。
デザイナーへのアドバイス：AI時代における立ち位置の見つけ方
Peter Yang：自分の職業環境が急速に変化していると感じているデザイナーの方々へ、何かアドバイスはありますか？彼らはコードのプルリクエスト（PR）の提出を学び始めるべきでしょうか？それとも、デザイナーは他の方法で適応すべきでしょうか？
Jenny：
もし足元の地面が動いていると感じたら、それは実際に動いているのです。それを認め、適応を学び、同時に既存のワークフローをオープンな姿勢で再検討することが求められます。現在の変化がデザイナーに与える影響は特に大きく、なぜなら我々はまさにこの波の第2弾に直面しているからです。他の職種はすでに同様の変革を経験しており、今度は我々の番です。同時に、私たちのデザインツールも絶えず進化しています。
自分の職業が挑戦されていると感じたとき、私はいつも少し不安になります。「天哪、私の仕事は大きく変化している。人々はもはや私の仕事を以前ほど重んじなくなるかもしれない」と。しかし、そんなときはいつも、エンジニアの同僚たちのことを思い出します。彼らの仕事はすでにかつてないほど大きく変化しており、それらに適応しただけでなく、大きな勇気と謙虚さを持って挑戦を受け入れ、より効率的で優れた成果を生み出してきました。彼らこそ私のインスピレーションの源です。「私がとても尊敬するこれらの同僚ができたのなら、私も必ずできる」と自分に言い聞かせます。彼らは、変化への適応の模範です。
Peter Yang：ある意味で、こうした変化はデザイナーを、枠の調整など煩雑な反復作業から解放し、より高度な思考や創造的作業に集中できるようにしてくれているのではありませんか？
Jenny：
はい、あるいはこうした変化によって、より多くの仕事をこなせるようになったとも言えます。例えば、私のエンジニアの同僚たちが、かつて数週間かかっていた機能を、今ではわずか数日で完成させているのを見るとき、本当に驚かされます。ですから、はい、こうした変化は、より多くの可能性をもたらしています。
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
深潮TechFlow
