1. 翻訳されない概念は、なぜすれ違いと手戻りを生むのか
翻訳のやり方をご紹介する前に、翻訳されないと何が起こるのかを見てみましょう。
企業のWebサイト構築には、多様なステークホルダーが関わっています。全員が同じ日本語で話していたとしても、実はそれぞれが扱う言語は、立場によって異なっていることをご存知でしょうか？
経営層・決裁者： ビジョン、事業成長、投資対効果などの「ビジネス軸」の言語で話す
現場担当者：現場で起こっている課題や問い合わせ対応などの「現場課題軸」の言語で話す
制作・開発チーム： 情報構造、UI、実装可能性、ガイドラインなどの「構造・技術軸」の言語で話す
ユーザー： 自身の課題解決、使いやすさ、利便性などの「体験軸」の言語で話す
心当たりはありませんか？これが原因で、それぞれが見ているものによって、微妙な解釈違いが起きてしまうのです。
そのため、調査結果から導き出された抽象的な言葉のまま制作フェーズへ渡してしまうと、それぞれの「解釈のズレ」が一気に表面化します。例えば、リサーチ結果から「より信頼感のあるWebサイトが求められる」という結論が出たとしましょう。この方向性自体に間違いはありませんが、このまま制作に進むのは危険です。
信頼感のあるWebサイトとは、一体どのようなWebサイトでしょうか？ 歴史と伝統を感じさせる重厚なデザイン？専門家の監修や数字的なファクトが明示されたWebサイト？きっと、プロジェクトメンバーが10人いれば、頭の中で思い描くイメージは10通り存在するはずです。
調査結果やコンセプトが翻訳されないまま構成やデザインに着手すると、制作チームは自分たちの解釈で作り始めることになります。そして、提出されたアウトプットを見た決裁者は、自分の解釈と違うために「なんだかイメージと違う」とフィードバックを出します。
同じ調査結果をもとに議論しているはずなのに、解釈のズレによってフィードバックのラリーが続き、プロジェクトが遅延したり、最終局面でデザインがひっくり返ったりする。これが、多くの現場で起きている「断絶」の正体と言えます。
2. 誰と、どう作るのか？ コンセプトをデザインに落とし込む2つのツール
このすれ違いを防ぐために、私は「UXコンセプトツリー」と「ロジックツリー」という2つのフレームワークを組み合わせた翻訳を行っています。具体的なプロセスをご紹介します。
① UXコンセプトツリー（体験のブレイクダウン）
UXコンセプトツリーでは、実現したいコンセプトを最上段に設置し、それを実現するためにはどのような体験や施策が必要なのかを検討し、上から下へとブレイクダウンしていきます。これにより、抽象的だった概念やコンセプトを具象化していくことができます。
(※本来は下から上に積み上げてコンセプトを抽出するフレームワークですが、私は抽出された抽象概念を具象（施策やUI）へ落とし込み、関係者の頭を整理する用途として応用しています)
空欄を埋める内容の根拠として、定量・定性調査結果やクライアント企業からのご要望、ユーザーニーズなどの情報を活用します。以下に一例を示します。
② ロジックツリー（ビジネスゴールとの接続）
どれだけ素晴らしい体験（UX）を設計しても、それが企業のビジネスゴールに寄与していなければ意味がありません。そこで活用するのがロジックツリーです。
ロジックツリーは必ず左（KGI：最終目標）から埋めていきます。
目指すビジネスゴールに対して、何が重要（KSF）で、どの指標（KPI）で測り、どんな施策で実現するのかを左から右へ検討します。
ロジックツリーの内容は、UXコンセプトツリーの内容も踏まえた施策・KSFで設計すると、それぞれがリンクして一貫性が増します。
③2つのツリーを往復させ、矛盾を排除する
もし2つのツリーを並べたときに矛盾が生じていたら、どこかで設計を間違えています。ビジネスゴールにまったく寄与しない体験を設定してしまっているか、あるいはコンセプトからのブレイクダウンに失敗しているのかもしれません。
2つのツリーを反復横跳びするように検証を繰り返し、「ユーザー体験の筋道」と「ビジネス目標の筋道」が矛盾なくつながるまで言葉を精査すること。これが、私が実践している翻訳のプロセスです。
これらのツリーは、提案時こそ自分や制作チームでたたきを作成しますが、プロジェクト全員での共通認識を作ることが目的ですから、クライアント担当者や決裁者にも見てもらい、フィードバックを繰り返して完成させていくのが理想です。関係者を巻き込んだワークショップなどで一気に制作できると、誤認も生まれづらくなってより良いと思います。
3. 翻訳が生み出す最大のメリット：スムーズな合意形成と「手戻り」の防止
2つのツリーを作るのは、正直言って結構大変です。ですが、これをプロジェクトの初期に作っておくことで、後半で大きなメリットが生まれます。
メリット1：好みや主観による「空中戦」が起こりにくくなる
デザイン案の検討段階に入った際によくあるのが「なんとなく色が気に入らない」「もっとインパクトがほしい」といった、個人の好みや主観によるフィードバックです。
翻訳されたツリーが存在していれば、評価の軸が「好きか嫌いか」から「ここで定義したUXコンセプトや施策に合致しているか」に変わります。フィードバックをする側も受ける側も、客観的で建設的な議論ができるようになります。
メリット2：開発終盤での「ちゃぶ台返し」リスクの軽減
初期工程で言葉の定義を構造化しておくことは、一見すると時間とコストがかかるように思えるかもしれません。
しかし、プロジェクト後半や開発最終局面で「思っていたのと違う」と大激震が走り、レイアウトやシステム設計を一からやり直すリスクを考えれば、その差は歴然です。初期の言語化への投資は、プロジェクト全体の手戻りリスクを減らし、結果として最短距離でのゴール達成に近づきます。
メリット3：マルチステークホルダーの巻き込みと社内説明の円滑化
大規模サイトのリニューアルでは、広報、マーケティング、営業、システム、役員会など、多くの部署への説明と合意が必要です。
概念がロジカルに翻訳されていれば、担当者の方は社内プレゼンや決裁の場で「なぜこのデザイン・この構造なのか」を、ビジネスゴールとユーザー体験の両面から根拠を持って説明できるようになります。担当者の方を孤立させず、社内を巻き込む強力な武器になるのです。
メリット4：制作・開発チームの迷いが軽減され、表現のクオリティーが上がりやすくなる
言葉の解像度が上がると、実際に手を動かすデザイナーやエンジニアの迷いが発生しづらくなります。
進むべき方向が示されているからこそ、クリエイターは「どう表現するか」「どう実装するか」という本来のクリエイティブに力を注ぐことができ、結果として、アウトプット全体のクオリティーが上がりやすくなるのです。
4. 翻訳を行う際に気をつけるべきポイント
最後に、この翻訳を成功させるために、実務で気を配っているポイントをお伝えします。
それは、ツリーの下段（具体的な内容）に至るほど、抽象的な言葉を徹底的に排除することです。誰が読んでも同じ情景が浮かび、誰もが納得できるレベルまで言葉を精査する。妥協せずに言葉を吟味する姿勢こそが、質の高い共通認識を作ります。
5. まとめ
今回ご紹介した手法はあくまで一例ですが、適切な翻訳プロセスを挟むことで、調査結果やコンセプトと、実際のデザイン、そして目指すべきゴールが分断される可能性は大幅に低くなります。
Webサイト構築やデジタル体験のプロジェクトを成功させる本当の鍵は、最新のテクノロジーやトレンドのデザイン表現を追いかけることではありません。
プロジェクトに関わる全員の間で認識のズレを最小限におさえ、確信を持って進められる状態を作ることです。
もし皆さんのプロジェクトで、リサーチ結果がうまくデザインに活かしきれていない、関係者の意見がまとまらず迷走しているといった「翻訳」に関する課題やお悩みがございましたら、ぜひ私たちにお声がけください。戦略の言語化から実装まで、伴走者としてサポートいたします。
よくあるご質問
Q1. すでに調査会社による詳細なリサーチレポートがある場合でも、上流工程からの依頼は有効ですか？
A1. はい。すでにレポートがあったとしても、上流工程からのご依頼をおすすめします。
手元にある膨大な調査データやペルソナ設定を「どう解釈し、具体的にどうデザインの与件に落とし込むか」という翻訳部分こそが、プロジェクトの成否を分けるポイントです。既存のリサーチ結果を拝見し、実装や成果につながる形へと再構成いたします。
Q2. 社内の関係部署が多く、それぞれ要望や意見がバラバラな状態ですが対応できますか？
A2. はい。対応可能です。
ワークショップや合意形成セッションを通じて、各部署が抱える想いや背景を丁寧に可視化します。単に誰かの意見を採用するのではなく、全員が納得できる共通のゴール（UXコンセプト）へと統合するプロセス設計からしっかりと伴走いたします。
博報堂アイ・スタジオでは、お客様のWebサイトやサービスが抱える課題に対し、最上流の戦略立案からUI/UXデザインの落とし込みまで伴走してサポートいたします。 「関係者ごとの認識が合わずプロジェクトが難航している」「客観的な評価軸で社内を納得させたい」などのお悩みがございましたら、まずは一度弊社までご相談ください。 さらに、プロジェクトを成功に導くためのステップや合意形成のポイントをまとめた 以下の実践ガイド（eBook）もご用意しておりますので、ぜひあわせてご覧ください。
