プロジェクトは、正しい答えより「翻訳」で動き出す｜共創とプロジェクトデザイン

プロジェクトが前に進まないとき、足りないのは「正しい答え」ではないことがあります。

目的もある。予算も、協力してくれる人もいる。必要な技術についても、ある程度は調べている。それでも話がまとまらず、なかなか実行に移れない。

そんな場面に出会うたびに、僕はプロジェクトに必要なのは、答えを増やすことよりも、それぞれの考えを「翻訳すること」なのではないかと思います。

同じ言葉でも、見えている景色は違う

たとえば、行政が言う「安全に進めたい」と、技術者が言う「安全に運用できる」は、似ているようで少し違います。

行政にとっての安全には、住民への説明、個人情報の扱い、公平性、前例、組織内の合意などが含まれます。一方、技術者はセキュリティやシステムの安定性、権限管理、障害への備えを考えています。

どちらも間違ってはいません。ただ、同じ「安全」という言葉を使いながら、見ている範囲が違うのです。

「使いやすいものにしたい」という言葉も同じです。利用者にとっての使いやすさ。運用する職員にとっての使いやすさ。更新する担当者にとっての使いやすさ。立場が変われば、使いやすさの意味も変わります。

だから、言葉が一致しただけでは、本当に認識がそろったとは限りません。

プロジェクトには、さまざまな専門性が必要です。企画、デザイン、Web、アプリ、映像、音楽、AI、法律、広報、地域との調整。

それぞれの分野に詳しい人を集めれば、よいプロジェクトになりそうに見えます。けれど、専門家が増えるほど、その間にある言葉の違いも増えていきます。

技術者には明確な仕様が必要です。デザイナーは、利用者がどう感じるかを考えます。現場は、日々無理なく続けられるかを気にします。経営や行政は、成果や説明責任を求めます。

それぞれが自分の専門分野から正しいことを話していても、そのままではひとつの方向に進まないことがあります。

専門家を集めることと、
チームをつくることは、同じではない。

それぞれの知識や判断をつなぎ、ひとつのプロジェクトとして動ける形にする必要があります。

ここでいう翻訳は、難しい専門用語を簡単な言葉に言い換えることだけではありません。

それぞれの立場から出てきた言葉の奥にある意図を読み取り、別の立場の人にも判断できる形へ組み直していく。

抽象的な構想を、具体的な体験へ。現場の困りごとを、実装できる要件へ。技術的な可能性を、組織が判断できる選択肢へ。

この往復が、プロジェクトにおける翻訳なのだと思います。

生成AIによって、情報を集め、整理し、案を出す速度は大きく上がりました。企画書のたたき台をつくる。議事録を要約する。アイデアを広げる。複数の選択肢を比較する。これまで時間がかかっていた作業を、AIが支援できるようになっています。

けれど、答えを速く出せることと、プロジェクトが前に進むことは同じではありません。

その土地にどんな背景があるのか。組織の中で、誰が不安を感じているのか。言葉になっていない期待や違和感は何か。どこまで進めれば、関係者が納得できるのか。

こうしたことは、資料だけでは見えません。人と話し、現場を見て、ときには沈黙や表情から受け取ったものまで含めて考える必要があります。

AIが多くの答えを提示できる時代だからこそ、その答えを現場の文脈につなぐ人間の役割は、むしろ大きくなっていくのではないでしょうか。

プロジェクトを進める人は、最初からすべての正解を知っている必要はないと思います。

必要なのは、それぞれの人が持っている知識や思いを持ち寄り、違いを見つけ、ひとつずつ確かめながら形にしていくことです。

ときには、技術の言葉を現場の言葉へ。現場の違和感を、意思決定者が判断できる言葉へ。まだ輪郭のないアイデアを、試せる小さな形へ。

その間を行き来しながら、関係する人たちが同じ方向を向ける状態をつくる。

プロジェクトは、正しい答えより、
「それなら一緒に進められそうだ」で動き出す。

異なる人たちの間に橋が架かり、「それなら一緒に進められそうだ」と思えた瞬間に、プロジェクトは初めて動き出す。

僕は、その橋をつくる仕事を「翻訳」と呼びたいと思います。そして、それもまた、これからの時代の「つくる」という行為のひとつなのだと思います。