三人同時進行で価値を瞬時にカタチにする文殊の知恵開発:デザインエンジニア目線
こんにちは！日本発のプライバシーテックで世界に挑戦するスタートアップ Acompanyで リードエンジニアを務めているO-Hideです。
この機会に、最近チームで行なっている仕事の進め方について書いてみたいと思います。
今回の記事は、Acompany Advent Calendar 2024の13日目としてお届けします。個人的スタートアップの良さは6日目の記事で水元さんから語られています。
我々スタートアップはプロダクト開発のスピードが競争力を左右します。「どうすれば、より早く、より確実にユーザへ価値を届けられるか」を模索してチームで勝つために奔走する日々です。そこで実践したのが、PdM、デザインエンジニア（私）、そして実装担当のエンジニアが密接に連携する、いわば「三人よれば文殊の知恵」方式の開発手法です。
『文殊の知恵開発』良いよ！と言うためだけに、よく見られがちな課題をピックアップしたいと思います。
噛み合わないチーム、空回りするプロセス
「この機能があればユーザの体験はぐっと良くなるはず。」
PdM（プロダクトマネージャー）はビジネスの勝ち筋を信じ、要件をまとめる。
「使いやすく、直感的なUIにしなければ価値は伝わらない。」
デザイナーはユーザ体験を守ろうと、理想のデザインを追求する。
「この画面構造だとバックエンドを大幅に作り直す必要がある。」
エンジニアは現実的な開発コストを見極め、慎重に首を振る。
全員プロダクトを成功させたい気持ちは同じ。しかし、ビジネス要件・デザイン理想・技術的制約が交わる場面で、意図せず足並みが乱れることがある。
それぞれがプロダクトで勝つことを目指しているのに、互いの目線がかみ合わず、結局「どう実現する？」が決まらない。結果としてユーザに価値提供するスピードが落ちる。
このもどかしい状況から脱するには、どうすればよいのでしょうか。
ここで「文殊の知恵」、つまり複数の専門知識を同時に掛け合わせる知恵が威力を発揮します。PdM・デザインエンジニア・実装担当のエンジニアが最初から横並びで話し合い、情報を即時共有することで、問題や手戻りが起きる前に気付ける。全員でイメージを共有しながら進めることで、スムーズな合意形成とスピーディな価値創出が可能になります。
三位一体のチーム：PdM・デザインエンジニア・実装エンジニア
文殊の知恵開発の役割分担は以下の通りです。
PdM：ビジネス視点で「何を作るべきか」を示し、機能要件を整理
デザインエンジニア：ユーザ体験と実装のしやすさを念頭に、低クオリティのデザインで価値イメージを即スケッチ
実装エンジニア：技術的観点から実現可能性やデータ構造を検討
この3者が初期から並行して議論し、即座に形にしていくことで「チーム内で価値イメージが共有できる」状態が一気に生まれます。誰かが言い出したアイデアが、その場でUI案として可視化され、同時に実装上の懸念点が洗い出される。これが可能になると、要件定義・デザイン検討・技術設計が“同時並行”で進みます。全員が主役であり、全員がサポーター。まさに三人よれば文殊の知恵です。チームで成果を最大化できるアプローチの一つと言えるでしょう。
低クオリティデザインの勘所
「価値イメージを共有する」ことは、必ずしも美しいUIを作ることを意味しません。むしろ初期段階では、手早く、粗くてもいいから、チーム全員が「これならユーザにとって価値がありそう！」と納得できるイメージを示すことが重要です。これこそ低クオリティデザインが効く場面です。極論を言うと伝われば手書きでも良いです。
恐らく前提として重要なのは、手書きでも伝わるくらい日々情報共有を行い、3者がコンテキストを理解できることではないでしょうか。
完成度よりスピードを重視することで、要件定義書考えがまとまらない「空中戦」から「視覚化された合意形成」へとシフトできます。
私のチームではFigmaとNotionを併用して、要件定義書を読み、話し合いの最中にデザインエンジニアがFigmaで画面モックやエッジケースをざっくり描き、決まったポイントを要件定義書へ即座にメモしました。こうしたリアルタイムの記録は、後から誰が見ても最新で正しい情報源となり、無用な手戻りを防ぎます。
「ちょっと微修正が必要かも」と思ったら、その場でUIを作り直し、テキストを差し替えるだけ。議論とビジュアル化と記録が常に並走するので、チームは価値イメージの共有から具体的な仕様決定までを、ストレスなく高速で行うことができます。
文殊の知恵開発は「速い」し「安い」。さらに「おいしい」
文殊の知恵開発の良さは、「素早く最小限のコスト」だけではありません。
メンバー全員がクリエイティブなプロセスに関われるので、エンジニアがデザイン的提案をし、デザインエンジニアが技術的提案をし、PdMがデザイン草案に触発されて要件定義所がブラッシュアップされるので、領域横断が容易で「おいしい」のです。（領域横断おいしい状況どうかは個人によりますが・・筆者目線です）
なぜ「デザインエンジニア」なのか？
ここまで紹介してきた「文殊の知恵開発」がスムーズに機能する背景には、デザインエンジニアの存在があると考えています。もし、ここにいるのが完全にUI/UX特化のデザイナーのみだとどうでしょうか？美しい画面設計と共にユーザ体験を描くことはできても、コードベースとの整合性や実装難易度、開発プロセス全体を考えた上で即席のプロトタイプを作ることは難しいかもしれません。一方、エンジニアがUIをゼロから考えるとなれば、ユーザビリティを的確に反映するのはハードルが高くなるでしょう。
デザインエンジニアは、
PdMからのビジネス要件を受け取りながら、ユーザが求める価値を素早く視覚化し、
デザイナーが得意とする体験設計の発想を取り込みつつ、
エンジニアリングの現実性も同時に吟味して、実現可能な形へと導く。
この「いいとこ取り」があるからこそ、議論が単なる理想論で終わらず、実行可能な計画へとスピーディに収束させることができます。
まとめると、デザインエンジニアがいることで「価値イメージ共有→合意形成→実行可能な計画策定」という一連の流れが加速します。煩雑な調整や手戻りが減り、ユーザへ価値を届けるスピードが着実に向上する。それが、このロールがチームにもたらす最大の意義なのです。
断りを入れておくと、デザインエンジニアがUI/UX特化のデザイナーより良いと言うわけではありません。私の業務範囲の特定のプロダクト状況では上手く機能したということです。そして専任デザイナーの方が作ってくれたカラーやコンポーネントを参考にしているからこそ迷わずそれっぽいUIをFigmaで作れるのです。
さらに言うと、この土台を支えているのは、PdMやユーザの声を現場まで正しく届けてくれる営業（ビジネスサイド）の存在です。彼らがユーザヒアリングや顧客との対話を通じて得た洞察を社内にフィードバックし、整理してチームに共有してくれるからこそ、開発側は適切な方向性で価値創出に臨めます。チームで成果を最大化しなければチームで勝てません。
巷ではチーム開発のデザインエンジニアプラクティスを見つけることが中々難しいので、この記事を読んでくれたデザインエンジニアのプラクティス記事をお待ちしています。
また、文殊の知恵開発で世界一のプライバシーテックカンパニーを実現するための仲間も募集中です！ぜひカジュアル面談でお話ししましょう！