アトラシアン本社の情報サイト『Inside Atlassian』より。デザインオペレーションリードのリシラジ・ネオグ(Rhishiraj Neog)が、AIを活用してアイデアを具体的な成果物へと前進させるすべての人に向けて、作業が進む中でも人、文脈、意思決定、そして品質のつながりを保ち続けるための5つの実践的なアプローチについて解説する。

本稿の要約を10秒で

  • AIに十分な前提を与えて丸投げを防ぎ、設計の意図や思考の主導権を人が握り続けることが大切
  • 見た目だけのプロトタイプに惑わされず、エラーや例外処理などの隠れた状態まで検証していく
  • 単に成果物を渡すのではなく、意思決定の背景や未解決の論点をセットで引き継ぐことが大切
  • AIで迅速に試作を重ねながらも、次の人が迷わず判断できる文脈を残すことで品質を高められる

本記事で紹介する内容

AIを使えば、ひらめいたアイデアをすぐに画面や試作品の形にできるようになった。ただ、作業が速く進むほど、なぜそう決めたのか、まだ何が決まっていないのかといった背景は抜け落ちやすい。見た目は整っていても、受け取った人がその意図をつかめなければ、確認や判断はまた一からやり直しになる。本記事は、AIで生まれたスピードを、チームでより良いものをつくる力につなげるための実践ガイドだ。アイデアが形になり、次の人へ渡っていくまでの各場面で使える5つの手法を紹介する。

各手法では、押さえておきたい要点、明日から試せること、そして実際の仕事で役立つ場面をまとめている。最初から順に読んでも、いまの仕事に役立ちそうな手法から読んでもかまわない。

なぜ重要なのか

AIによって、より多くの人がより速くものづくりを進められるようになった。だが、スピードが上がると作業のつながりが分断されやすい。背景情報(コンテキスト)が失われ、意思決定の経緯を追うのも難しくなる。また、生成されたコードが十分なレビューを経ずに進んだり、関係者が関与したときには軌道修正が手遅れになっていたりすることもある。

これを解決するために、新しいプロセスを作ったり、チーム全体に一斉導入したりする必要はない。まずは目の前にある次の業務から始めればよい。これら5つの手法を活用し、次の担当者が重要事項を把握し、思考プロセスを理解したうえで、適切な判断を下せるようにしていこう。

こんなときに活用

  • AIへの指示文(プロンプト)や大まかなアイデア、未完成の概要書(ブリーフ)から作業を始めるとき
  • チームの共通理解が追いつかないスピードでプロトタイプ(試作品)の開発が進んでいるとき
  • デザイン、コード、意思決定の間にズレが生じ始めているとき
  • 別の職能(専門チーム)やチーム、本番の制作フローへ作業を引き継ぐとき
  • 次の意思決定を難しくすることなく、スピード感を持って進めたいとき

5つの実践手法

手法実践内容問いかけるべきこと
AIにデザイン言語を教え込む自社製品らしさを形づくる言語、デザイントークン、デザインパターン、ルールをAIにインプットする。これは自社のデザイン言語を正しく適用できているだろうか?
チームのコンテキスト(背景情報)を統合する概要書(ブリーフ)からデザイン、試作品(プロトタイプ)、コード、そしてリリースへと作業が進む中で、関係者が必要とする知識や業務をつなぎ合わせる。ゼロからやり直すことなく、他のメンバーが作業を引き継いで進められるだろうか?
人間の判断を挟む余地を残す適切なタイミングで関係者を集め、成果物を確認し、疑問を投げかけ、改善する。人間の判断によって方向性を見直すべきポイントはどこだろうか?
引き継ぎの前に成果物を検証する単にコードの生成量を増やすだけでなく、自律型AI(エージェント)やスキルを活用して試作コードの安全性を高め、本番環境の品質に近づける。これを信頼して次に進めるには、どのような条件が満たされている必要があるだろうか?
引き継ぎという協調を再定義する単にファイルやリンクを渡すだけでなく、思考プロセス、決定事項、未確定要素、次に検討すべき課題まで共有する。次の担当者が適切な意思決定を行うために、何を知っておく必要があるだろうか?

AIチームメイトと一緒にこのガイドを活用する

ここだけの話だが、このガイドを最初から最後まで通して読む必要はない。代わりに、普段使っている自律型AI(エージェント)に渡してみよう。以下のプロンプトを利用中のAIツールにコピーし、このページのリンクを添えて入力すれば、自身の実際の業務に合わせて5つの実践手法を順を追って案内してくれる。

プロンプト例:このガイドを最後まで読んでください。私がいま取り組んでいる実際の仕事を一つ取り上げ、その内容と進み具合について、一度に一つずつ、最大5つまで質問してください。そのうえで、最も役に立ちそうな手法から始めて、5つの手法を順に案内してください。進めながら、作業記録を一つにまとめて残してください。推測はしないでください。推測した内容、不足している情報、私が判断すべき事項は、それとわかるように示してください。手法を一つ終えるごとに、いったん止まってください。私が途中でやめた場合は、続きから再開できるよう要約を示してください。最後に、明日試せることを一つ挙げてください。

STEP 1:AIにデザイン言語を教え込む

AIには適切なコンテキスト(背景情報)を与えよう。それが抜けていると、AIは一見それらしく見えても自社製品にはそぐわないインターフェースを作ってしまいかねない。単にどのコンポーネントを使うかだけでなく、自社製品が情報階層、操作感(インタラクション)、トーン、アクセシビリティ、そしてデザイン上の意思決定をどのように扱っているかを示すために、デザインシステムを活用していきたい。

具体例

  • シナリオ:
    デザイナーが新しいアカウント設定フローを早急に検討する必要がある。一般的なプロンプトで指示を出すと、一見完成度の高い画面は生成されるものの、使われているコンポーネント、余白、コンテンツパターン、インタラクションの状態(操作時の挙動)が本来のものとは異なってしまっている。
  • AIツール、スキル、または機能:
    チームのデザインシステムライブラリ、デザイントークン、実装例、ガイドラインドキュメントと連携したAIプロトタイピングツール。
  • 果たすべき役割(Job to be done):
    独自に新しいパターンをでっち上げるのではなく、本来のデザイン言語を用いて初版(ファーストパス)を作成し、不足している要素があればフラグを立てて明示すること。
画像: STEP 1:AIにデザイン言語を教え込む

明日試すこと

  1. 信頼できる基準を渡す:AIツールには、簡潔で信頼できる基準となる情報を渡そう。たとえば、デザインの基本原則、デザインの基本定義値(トークン)、再利用できるUI部品(コンポーネント)、画面設計の定型(パターン)、文章や文言のルール、そして実例だ。
  2. 作り出してはならないものを明示する:AIが勝手に作り出してはならないものを、はっきり伝えておこう。具体的には、色の役割、余白、文字の書体や組み方、操作に応じた表示状態、誰にとっても使いやすくするための要件(アクセシビリティ)、画面サイズに応じた表示の切り替えなどだ。
  3. 推奨例と例外を並べて示す:推奨するパターンと、例外的なケース(エッジケース)の両方を見せよう。2つを比べることで、AIはどこまでが許容範囲なのか、その境界をつかみやすくなる。
  4. 使った要素を説明させる:完成した結果を見るだけで終わらせず、どのトークンやコンポーネントを使ったのかもAIに説明させよう。
  5. 修正をチームの共有情報に反映する:役に立った修正は、チームで共有している前提情報に書き足しておこう。そうすれば、プロンプトを書くたびに同じ間違いを直す手間がなくなる。

望ましい兆候:
出力結果が自社製品にしっかりと馴染んでおり、適切な構成要素(コンポーネント)が使われ、不要な新たな意思決定が避けられている状態。

注意すべき兆候:
一見それらしく見えても、適当な数値が使われていたり、コンポーネントが重複していたり、重要な操作状態が抜け落ちていたり、コントラストが不十分だったりする画面。

プロンプト例:[自社のデザインシステム]を読み、この作業ではそこに定められたトークン、コンポーネント、パターン、文章や文言のルールだけを使ってください。デザインシステムの内容を確認できない場合は、推測せずに私に共有を求めてください。新しいトークンやコンポーネントなどを独自に作り出すことは、決してしないでください。当てはまるものがない場合は、作業をいったん止めて、私が選べる選択肢を示してください。最後に、推測した内容、不足している情報、私が判断すべき事項を一覧にして示してください。

STEP 2:チームのコンテキストを集約する

コンテキストは常に業務そのものと紐づけておこう。すべてをひとつの巨大なリポジトリに詰め込む必要はない。要件定義からデザイン、プロトタイプ作成、コーディング、そしてリリースに至るまで、途中で検討プロセスや思考の流れを見失わずに進められるよう、メンバーが必要とする厳選された情報源同士をつなぎ合わせることが肝要だ。

具体例

  • シナリオ:
    プロダクトマネージャー、デザイナー、エンジニアがオンボーディング施策に取り組んでいる。要件定義書、リサーチ結果、プロトタイプ、決定事項、コードがそれぞれ異なる場所に散らばっているため、メンバー各自が同じコンテキストを把握し直す作業に時間を費やしてしまっている。
  • AIツール、スキル、または機能:
    チームの最新の要件定義書、リサーチ結果、決定事項、プロトタイプ、コードと連携したAIアシスタントや検索ツール。
  • 果たすべき役割:
    最新のコンテキストを集約し、決定事項の経緯や根拠を明確にした上で、何が決定済みで何が未解決のまま残っているのかを次の担当者に引き継ぐこと。

一連の流れをつなぐ

課題と意図 → 要件定義 → デザイン言語 → プロトタイプ → 実装 → 検証結果 → リリースからの学び

画像: STEP 2:チームのコンテキストを集約する

各段階において、直前の決定事項と次に検討すべき課題へのリンク(参照先)を必ず残しておこう。プロトタイプを見るだけで一からすべてを説明しなければならないような状況は避けるべきだ。コードを見て初めてそのインタラクションの仕組みを知る、というのも本来あるべき姿ではない。また、リリースの報告には、成果の裏で判断を左右した未知の要素や不確実性も隠さず記載しておくべきだ。

明日試すこと

  1. 前提情報を冒頭にまとめる:作業の冒頭に、解決すべき課題、対象読者、目指す成果、制約、未解決の論点を簡潔にまとめた前提情報を書いておこう。
  2. 成果物をリンクでつなぐ:重要な成果物どうしをリンクでつなごう。つながりのない書き出しファイルを大量にフォルダに詰め込むより、常に最新に保たれた少数の情報源をつなぐほうが役に立つ。
  3. 決定事項はすぐに書き留める:決めたことは、記憶が新しいうちに書き留めておこう。重要な制約や判断の理由を説明するのに役立つなら、採用しなかった選択肢も残しておく。
  4. 形式が変わっても考え方を残す:成果物をある形式から別の形式に移すときは、元の考え方を残すようAIツールに指示しよう。引き継げないものがあれば、それも示してもらう。
  5. わからないことを明確にする:まだわかっていないことを、はっきりさせておこう。決定済みのこと、推測にもとづくこと、検証中のこと、まだ安心して再利用できないことを分けて示しておく。

望ましい兆候:
新しく参加したメンバーでも、その取り組みが存在する理由、これまでの決定事項、そして自分がどこで貢献できるかを数分で理解できる状態。
注意すべき兆候:
解決すべき課題が不明確なまま作り込まれたプロトタイプ、スクリーンショットへのリンクしかないチケット、結論だけが示されていて背景にある検討プロセスが見えないドキュメント。

プロンプト例:[概要書とメモ]を読み、1ページの作業記録を作り始めてください。記録には、解決すべき課題、決定済みの事項とその理由、誰が決めたのか、まだわかっていないこと、そしてそれぞれの項目の根拠を記載してください。推測した内容、不足している情報、私が判断すべき事項は、それとわかるように示してください。最後に、初めて読む人が5分で内容を理解できるかを確認してください。

STEP 3:判断の余地を残す

自動化を活用してスピードを上げつつも、人間の判断によって成果物の質を高められる場面では必ず人を介在させよう。単なる進捗報告のためだけのミーティングは省いて構わない。適切なメンバーが実際の成果物に目を通し、前提となっている考え方に疑問を投げかけ、次にとるべきアクションをより良いものへとブラッシュアップできるような場や機会を意図的につくり出そう。

具体例

  • シナリオ:
    AIが生成したプロトタイプは一見完成しているように見えるが、主要なユーザーニーズ、対応が難しいエッジケース、あるいは許容すべきトレードオフについて、チーム内での合意がまだ取れていない。
  • AIツール、スキル、または機能:
    現在のアプローチを要約し、前提となっている仮定を浮き彫りにした上で、短時間のワーキングセッションに向けた論点・未解決事項を整理してくれるAIレビュー機能。
  • 果たすべき役割:
    ミーティングを進捗共有に費やすのではなく、人間の判断が不可欠な意思決定にチームが集中できるよう支援すること。

進捗共有のミーティングではなく、判断の場を設ける

段階持ち寄るもの判断すべきこと
構想課題、初期段階の成果物、そして多角的な視点何を解決し、何を対象外(スコープ外)とするか?
検証動作するプロトタイプやコード(まだ不完全・未調整な状態も含む)さらにリソースを投じる前に、何を変更すべきか?
準備提案するアプローチ、想定されるリスク、本番環境の制約条件何をそのまま次の工程へと進めて問題ないか?
振り返り結果、根拠となるデータ、そして予想外だった発見や気づき何を継続し、何を変更し、何を止めるべきか?

明日試すこと

  1. 関わる3人を集める:課題に責任を持つ人、体験を設計する人、そしてそれを実際に形にする人を招こう。
  2. 成果物をその場で一緒に見る:成果物は、参加者全員でその場で一緒に見よう。開かれないかもしれない事前資料に頼らないこと。
  3. 3つの視点で一人ずつ話してもらう:参加者一人ひとりに、はっきりしていること、まだ不確かなこと、自分なら変えたいことを1つずつ挙げてもらおう。
  4. 次につながる結論で終える:最後は、決定事項、責任者、または検討を続ける明確な理由のいずれかを示して締めくくろう。

望ましい兆候:
共に作業を進めることで成果物が実際にブラッシュアップされ、参加者全員が「次に何を判断・決定すべきか」を理解してその場を終えられる状態。
注意すべき兆候:
成果物がほぼ完成したように見えてから初めて行われるレビュー、実際の作業内容に紐づいていないフィードバック、あるいは全員が合意しているものの「次に何が進むのか」を誰も把握していないミーティング。

プロンプト例:[この成果物]のレビューを計画するのを手伝ってください。レビューは進捗報告で終わらせず、意思決定で締めくくりたいと考えています。まず、誰が関わるのかを私に質問してください。そのうえで、参加者一人ひとりに、その人が答えるのに最も適した質問を2〜3つずつ挙げてください。短い議題案も作成してください。判断はすべて私たちに任せてください。レビューの後は、私のメモをもとに、決定事項、責任者、次のアクションをまとめてください。

STEP 4:引き継ぎの前に成果物を確認する

アイデアを目で見て実際に試せるレベルまで具現化するために、プロトタイプのコードを活用しよう。しかし、開発スピードを優先するあまり、未検討の思考、脆弱なコード、アクセシビリティ上の問題、あるいは誰も責任を持たない本番環境への移行パスが見過ごされてしまうような事態は避けなければならない。

AIが生成したコードは大いに活用すべきだが、最初から無条件に信用してはならない。レビューを行い、テストを重ね、一歩ずつ安全性を高めていくことが不可欠だ。

具体例

  • シナリオ:
    プロトタイプによってアイデアの有効性は実証され、チームはその成果を本番プロダクトへ組み込もうとしている。しかし、AIが生成したコードにはハードコードされた値、ロジックの重複、考慮されていない状態(ステート)が存在し、テストも書かれていない。
  • AIツール、スキル、または機能:
    リポジトリのガイドラインに沿って動作し、チームの静的解析(リンティング)、自動テスト、アクセシビリティチェック、セキュリティ検証を実行できるコーディングエージェント。
  • 果たすべき役割:
    プロトタイプを検証・強化した上で、本番環境に耐えうる水準に達していない要素を明確にし、次の工程(実装・本番移行)へ引き継ぐ前に加えるべき「最小限かつ安全な変更」を提示すること。

単に作業の範囲を広げるだけでなく、成果物の質を高めるためにエージェントを活用する

  1. 調査:コードの構造、依存関係、各種ステート(状態)、前提条件、および把握できている不足点・ギャップを整理してマップ化(可視化)するようエージェントに指示しよう。
  2. 制約:リポジトリのルール、コンポーネントAPI、デザイントークンの規則、アクセシビリティ要件、およびテスト実行コマンドをエージェントに提示しよう。
  3. 強化:エラー時、読み込み中(ローディング)、空状態(エンプティ)、キーボード操作、レスポンシブ表示、およびリカバリー(復帰)の各状態を網羅するようエージェントに指示しよう。
  4. 検証:各種チェックを実行しよう。エラーや不合格が発生した場合は、その原因の説明と「最小限かつ安全な修正案」を提示するようエージェントに求めよう。
  5. レビュー:画面(UIの見た目)だけでなく、人間がコードの変更点そのものをレビューしよう。重複コード、隠れたステート、不要な依存関係、および責任範囲が不明確な箇所がないかを確認する。
  6. 記録:本番環境に適用可能なもの、プロトタイプ限定のもの、そして依然として判断・決定が必要なものを明確に記録しておこう。

望ましい兆候:
本番環境へ近づくにつれて、プロトタイプが理解しやすくなり、変更を加えても安全な状態になっていること。
注意すべき兆候:
誰も説明できないAI生成コード、重複したロジック、ハードコードされたコンテンツ、テストの欠落、無視された警告、あるいはデモと実際のプロダクトとの乖離が広がっている状態。

プロンプト例:引き継ぐ前に、[このプロトタイプのコード]をレビューしてください。コードを確認できない場合は、私に貼り付けるよう求めてください。あわせて、このコードの用途がデモ、ユーザーテスト、本番環境のどれなのかも質問してください。レビューでは、抜けている表示状態(読み込み中、データがない状態、エラー)、コードに直接書き込まれた固定の値、アクセシビリティ上の問題、重複したコードがないかを確認してください。見つかった点は、そのまま直してよい修正と、私が判断すべき設計上の論点に分けて示してください。確認できなかったことも伝えてください。私が承認するまでは、何も変更しないでください。

STEP 5:「引き継ぎ」の概念を捨て、新たな「ハンドシェイク」を築く

引き継ぎとは、誰か一人が作業を終えて次の人へ一方的に手渡す瞬間ではなく、共に進める「共有のステップ」として扱おう。AIを活用した協働によって、ものづくりのプロセスはより連続的なものへと変化する。成果物がどのように形作られていくかを左右する意思決定(選択肢)、各種ステート(状態)、品質、そして細部に至るディテールに、最後まで主体的に関わり続けよう。

具体例

  • シナリオ:
    デザイナーが完成したプロトタイプをエンジニアリングチームに共有する。画面の見た目は明快だが、そこに至る意思決定の背景、不採用となった選択肢、エッジケース、そして未解決の論点が可視化されていない。
  • AIツール、スキル、または機能:
    要件(ブリーフ)、設計上の意思決定、プロトタイプの各状態(ステート)、関連システムの参照情報、および未解決の論点を集約し、実装に着手できるサマリーとして整理してくれる「AIハンドオフ機能(引き継ぎスキル)」。
  • 果たすべき役割:
    成果物とともにその「思考プロセス」も引き継ぐことで、次の担当者が推測に頼ったり一からコンテクスト(文脈)を再構築したりすることなく、適切な意思決定を下せるようにすること。

成果物だけでなく、その背景にある「思考プロセス」も引き継ぐ

次の担当者が迷わず作業を進められるよう、必要な情報を過不足なく渡そう:

  • 意図:何をより良くしようとしているのか?
  • 根拠:何を観察し、テストし、学んだのか?
  • 意思決定:何について合意したのか、そしてそれはなぜなのか?
  • 不確実性:何がまだ未決で、どのようなリスクがあり、何を試行錯誤している最中なのか?
  • 制約条件:実装にあたって遵守すべき制約や前提条件は何か?
  • 品質基準:振る舞い(挙動)、誰にとっても使いやすい設計(アクセシビリティ)、コンテンツ、そしてシステムとの調和において、何をもって「良い状態(合格水準)」とするのか?
  • 次のアクション:次に何を行い、誰が責任を持ち、何を決定する必要があるのか?

明日試すこと

  1. 単に「ファイルを共有します」と伝えるのではなく、「私たちが何を解決しようとしているのか、何を決定したのか、そして何についてまだ判断が必要なのか」を伝えよう。
  2. 見落とされがちなステート(状態)を網羅しよう。具体的には、データが存在しない空の状態(エンプティ)、読み込み中、エラー、権限不足、極端なケース(エッジケース)、そして障害からの復旧(リカバリー)状態などだ。
  3. 成果物がシステム全体とどう接続しているかを可視化しよう。これには、再利用可能なUI部品(コンポーネント)、デザインの基本定義値(トークン)、文章や文言(コンテンツ)、データ、そして実装上の制約などが含まれる。
  4. 当初の意図や思考プロセスが見失われそうなときや、品質の低下が懸念される場面には、最後まで主体的に関わり続けよう。単にファイルを送って終わりにするよりも、そこまで見届けることこそが一段落とするにふさわしい区切りとなる。
  5. 設計方針の変更が難しくなる前に、次の工程を担う別の職種・専門性(クラフト)のメンバーを早めに巻き込もう。

望ましい兆候:
次の担当者が、作成者の意図を推測したり文脈(コンテクスト)を一から再構築したりすることなく、作業をスムーズに前進させられる状態になっていること。
注意すべき兆候:
単にリンクを共有しただけで「引き継ぎ完了」としてしまうことや、設計段階で全く関与する機会がなかった成果物に対して、デザイナーが承認だけを求められるような事態。

プロンプト例:[この成果物とその記録]をもとに、[次の担当者]が推測に頼らずに作業を引き継げるよう、ハンドシェイクノートを作成してください。ノートには、意図、根拠、意思決定とその理由、未解決の論点、制約条件、品質基準、次のアクションを入れてください。私が提示した情報だけを使ってください。推測した内容、不足している情報、私が判断すべき事項は、それとわかるように示してください。ノートを仕上げる前に、私に確認してください。

次に取り組む仕事のための実践ガイド

つくる前:解決すべき課題は何か? ツールにはどのような前提情報が必要か? 勝手に作り出してはならないものは何か?

つくっている最中:いま誰にこれを見せるべきか? 誰の判断を仰げばより良くなるか? 後からの変更が難しくなりつつある決定事項はどれか?

共有する前:決定済みのこと、不確定なこと、実験的な試み、再利用できるもの、そしてまだ準備が整っていないものは何か?

リリースする前:人の手でコードをレビューしたか? コードは強化され、テストされ、本番システムに接続されているか?

リリースした後:何を学んだか? その学びをどこに残しておくべきか?

迅速に進めつつも、着手したときよりも成果物をより明確な状態にして引き継ごう。AIが真価を発揮できるよう十分な前提情報を与えよう。人が自身の判断力を発揮できるよう十分な情報を共有しよう。そして、次の担当者が迷わず作業を進められるよう、必要な情報を過不足なく渡そう。

This article is a sponsored article by
''.