この記事では、デザイナーとエンジニアに起きがちな「思考のズレ」の解消法(カップルにも使えるかもw)を紹介します。
カップルが同じ「週末の計画」について話しているのに、なぜか会話がかみ合わない...
「週末どこか行こうよ」
彼女：「どんな場所がいいかな？この前SNSで見た海が見えるカフェ、めっちゃ雰囲気良くて。
夕日がきれいに見えるらしいよ！」（体験・感情から考える）
彼氏：「ん？どこ？距離は？駐車場ある？予約必要？夕方だと帰りが遅くなるけど大丈夫？」（条件・制約から考える）
彼女：「もう、そういう細かいこと考える前に、まずは『どんな時間を過ごしたいか』から話そうよ...」
彼氏：「いや、その理想を実現するために必要なことを確認してるんだけど...」
📝 この記事で得られること
エンジニアとデザイナーの「根本的な思考回路の違い」とその活かし方
プロジェクトの各フェーズで最適な思考法の使い分け戦略
即実践できる！コミュニケーションギャップを解消する4つの実践テクニック
共創を促進するための具体的な言い回しとアプローチ例
👥 こんな方におすすめ
デザイナーやディレクターと一緒にプロジェクトを進めているエンジニア
エンジニアとのコミュニケーションに苦戦しているデザイナー
チーム内での「価値の議論」と「技術的実現性」のバランスに悩むプロジェクトリーダー
MVPを効率的に設計・開発したいスタートアップメンバー
1️⃣思考法の根本的な違い：減点法 vs 加点法
1-1. エンジニアの思考法：減点法
エンジニアは「減点法」で考えることが多いです。
「このコードのここにバグがある」
「この仕様だと○○の場合に破綻する」
「先に必要な機能や要件を決めてから進めよう」
一つのミスがシステム全体を機能不全にする可能性があるため、問題点を先に洗い出し、
ひとつずつ解決していく思考が身についています。これは否定的なわけでなく、
プロダクト品質を担保するために不可欠なスキルです。
1-2. デザイナーの思考法：加点法
デザイナーは「加点法」で考えることが多いです。
「このアイデア、いいね！ここをもっと膨らませよう」
「ユーザー体験を起点に考えると、こんな可能性が広がる」
「アイデアの種を育てるためにユーザー体験を言語化していこう」
完璧でなくても魅力的な部分があれば価値を見出し、それを伸ばす思考回路を持っています。ユーザー体験を起点に、そこから逆算してサービスの要件を考えていくアプローチです。
2️⃣プロダクト開発アプローチの違い
両者のアプローチの違いは開発プロセスにも現れます：
エンジニアのアプローチ：
①要件定義（必要な機能や作業内容など要件を決める）
②画面遷移
③基本設計
④開発/デザイン
デザイナーのアプローチ：
①画面遷移（ユーザー体験に沿ったストーリーを考える）
②要件定義（機能や内容）
③基本設計
④開発/デザイン
この違いが、プロジェクト進行中に様々な摩擦を生み出します：
▣主な課題：
◯ユーザー視点や体験設計なしに要件定義に走るから、全体像を掴まずに要件定義になって、会話が噛み合わない。
◯技術的な詳細に早期に議論が移り、本質的な価値の議論が薄まる。
◯解像度の高いユーザー体験の重要性が理解されにくい。
3️⃣ 共創のための4つの実践的テクニック
効果的な共創のための具体的なテクニックをご紹介します。
テクニック1：共通認識を構築する
プロジェクトの初期段階で以下のポイントを明確にしましょう：
課題と目的の言語化: 何が問題で、どこを目指すのかを全員で共有
サービス設計の方向性: 技術的な議論に入る前に、目指すべき体験の方向性を合意
アイデアの種の扱い方: 初期のアイデアをどう育てるかの姿勢を共有
実践例: AI comic 英単語「コミ単」の場合
【「コミ単」は英単語学習×生成AIを組み合わせたWebアプリです。中高生の「英単語がなかなか覚えられない」「単語帳がつまらない」という課題に対し、入力した英単語からAIが漫画を生成することで楽しく学習できる...と思ったけど、AIが生成する漫画の内容が面白くないので”自分で面白くする”仕組みにすることで、生成AIへの興味喚起と英単語学習の両方を実現しました。】
▼コミ単の詳細は下記の記事で紹介してます
https://qiita.com/GIFCat/items/e84fcbf6b1b53a04ef1c
誤った認識：
「英単語を入力するとAIが英単語を覚えやすい漫画に生成してくれるアプリ」
「開発目的：生成AIに対する興味喚起 < 英単語の学習支援」
正しい認識：
「AIで英単語を漫画化するけど、つまらない内容なので人間が面白くするアプリ」
「開発目的：生成AIに対する興味喚起 > 英単語の学習支援」
このように何を解決したいのかを言語化することで、チーム全体の方向性が明確になります。
テクニック2：フェーズに応じた思考法の切り替え
プロジェクトのフェーズごとに、加点法と減点法を意識的に使い分けることが重要です：
アイデア発散フェーズ（加点法優先）:
「まずは技術的制約を置いておいて、理想のユーザー体験を語ろう」エンジニアも「減点法」を一時的に封印する
実現性検討フェーズ（減点法の活用）:
「理想の体験を実現するために、技術的に何が必要か」デザイナーも技術的制約を理解し、優先順位付けに参加
実装計画フェーズ（両方をバランス）:
ユーザー体験の解像度と技術的実現性の最適解を探る
テクニック3：ユーザー体験の解像度を高める
「ユーザー体験を考える上で大事なのは解像度をどれくらい上げれるか」という重要なポイントがあります：
具体的なシナリオ作り: 抽象的な機能ではなく、具体的なユーザーストーリーで議論
プロトタイピングの活用: 早期に低解像度でも動くものを作り、体験を共有
ビジュアル共有ツールの活用: Figmaなどを使って視覚的に共有
テクニック4：言い回しを工夫する
言葉の選び方を少し変えるだけでも、コミュニケーションの質は大きく変わります：
デザイナーからエンジニアへ：
×「このアイデアでやりたい！」
○「このアイデアの核心は○○なんだけど、技術的に実現可能な形にするにはどうすればいい？」
エンジニアからデザイナーへ：
×「それはできない」
○「その方向性は面白いね。技術的には○○という制約があるけど、代わりに△△という方法なら近い体験が
実現できそう」
「0→1」の流れを全員で理解する
「サービスを0→1で作るフロー」を全員が理解し、互いの思考プロセスを尊重することが重要です：
エンジニアには「ユーザー体験」からの逆算思考を理解してもらう
デザイナーには技術的実装の流れとその意味を理解してもらう
両者の思考プロセスを融合させた新しいプロジェクト進行フローを作る
4️⃣ 実践例：MVPプロジェクトでの成功事例
ステップ1：「課題と目的の”言語化”」から始める（ビジョン共有）
ターゲットユーザーの具体的な課題を全員で言語化
「解決したい課題は何なのか？」「目指すべき方向性は？」を繰り返し確認
エンジニアもユーザーインタビューに同席し、課題への共感を持つ
ステップ2：アイデアの種を育てる（加点法フェーズ）
ユーザー体験を起点にしたブレインストーミング
「このアイデアの核心は○○」と価値の部分を明確に
技術的な懸念点が出ても「いったんパーキング」
ステップ3：技術的実現性の検討（減点法フェーズ）
エンジニアが各アイデアの技術的実現性を詳細に検証
デザイナーも技術的制約を理解し、「この体験の本質は保ったまま、どう実現できるか」を共に考える
「できない」ではなく「どうすればできるか」を全員で考える姿勢
ステップ4：最適解の探索（加点法×減点法の融合）
技術的制約を「創造性を高めるための制約」として捉え直す
MVPとして最小限の機能で最大の価値を生み出す方法を共に考案
デザイナーとエンジニアが一緒にプロトタイピングを繰り返し
5️⃣まとめ：思考法の違いを武器に変える
エンジニアとデザイナーの思考プロセスの違いは、対立ではなく、互いに補完し合うことで大きな力となります：
両者の視点を融合: 「ユーザー体験」と「技術的実現性」の両面から考える
共通言語の構築: 抽象的な価値と具体的な実装の間を行き来できる表現方法
相互理解の促進: お互いの思考プロセスを尊重し、学び合う文化
MVPデザインの本質は、結局のところ「ユーザーにとっての価値」と「技術的実現性」のバランスを取りながら、最小限の労力で最大の学びを得ることにあります。エンジニアとデザイナーがそれぞれの強みを活かし、互いの思考プロセスを尊重できれば、より優れたプロダクトが生まれるはずです。
🔍 詳細なクリエイター×エンジニア共創テクニックについて
エンジニア/クリエイター共創のより詳細な実践方法や成功事例については、「エンジニアとクリエイターの壁をなくす！思考法の違いと共創の実践」もぜひご覧ください。
https://qiita.com/GIFCat/items/c84f13229fe7ee078a2e
特に「加点法」と「減点法」の概念や、共創を促進するコミュニケーション戦略について詳しく解説されています。