デザインファーム Design & Researchでは、具体的なプロジェクトのデザイン支援と合わせて、開発組織のプロセスをつくることまで支援しています。
例えばとある会社では、私たちの約半年の支援によって、以下のような変化が生まれました。
🔥Before
既存プロダクトの改善が進まない、時間がかかる
複雑なドメインのため、顧客像を誰も解像度高くイメージできていない
新規プロダクト開発の難易度が高く、開発が止まっている状態
✅After
既存プロダクトの改善は、社内メンバーだけで円滑に進むように
既存領域、新規領域ともに顧客の業務や課題がイメージできるように
新規開発の優先度が明確になり、プロダクト開発が進むように
このような結果を生むためのDesign & Researchとしての支援の裏側や、私たちが考えるプロダクトデザイナーの責任範囲についてまとめます。
具体的な実践例の前に、まず私たちが向き合う課題について整理しておきます。
私たちが支援をする開発組織の多くは「日々デザインや開発を続けているけど、ずっと忙しい。」「頑張って開発を続けても、顧客に使われるものができない。」という問題意識を抱えています。
この忙しさを解消するために採用や業務委託を増員し、プロジェクトに入ってもらう対応をしがちですが、それでも状況はなかなか変わりません。
このような「頑張っているけどうまくいかない開発組織」になってしまうのは、知らず知らずのうちに事業成長の中で “落とし穴” にはまってしまっているためです。
急成長する事業の中で、開発組織は「人材の不足」「インサイトの不足」「理想像の不足」「戦略の不足」という4つの落とし穴に陥ります。
そもそも足元の施策を進める人材が足りない、つくる前提となるインサイトを共有できていない、一つ機能をつくった後にどうするかが理想像や戦略がなく見えていない。このような状態ではどれだけ忙しく施策をうち続けてもうまくいきません。
事業は成長の中で複雑になり、当初描いた理想像や戦略の解像度を高めなければハンドリングができなくなります。顧客も増えていき、インサイトも分からない。このような状況に対処できる人材も採用できず、開発組織がだんだん力を失い、プロダクトの価値が失われていく。
この4つのどれか (またはすべて) が重なり合うと、やがて身動きが取れなくなってしまうのです。短期的なアプローチしか動かせなくなり、使われるものはつくれなくなるジリ貧な状態に陥ります。
なので日々の忙しさに目を向けるのではなく、「落とし穴を塞ぐこと」に目を向けることから始めるべきなのです。
本来はこれらの落とし穴に入らないのが理想的ですが、事業成長の中で確実に先手を打つことは難しいでしょう。
そのためDesign & Researchでは、プロジェクトが開始した時点で、クライアントの開発組織がこの落とし穴のどこにハマっているのかを見極め、不足分を埋めにいくような動き方をしています。
私たちの支援の特徴は、「プロジェクトの推進」から「開発組織の穴を塞ぐこと」をゴールにしていることです。
目先の忙しさもある中で、必要なのはコンサルのような戦略設計をする役割ではなく、プロダクトデザイナーとして現場でパフォーマンスできる存在でありながら、プロダクトマネージャーとしてインサイト整理・戦略・理想像まで行える “2つの視点” を持った人材です。
ここからは、どのようにDesign & Researchが4つの落とし穴を2つの視点から塞ぎにいっているか、具体的にまとめてみます。
私たちが支援を始めたタイミングでは、とはいえそもそも目先のプロジェクトの進行から不安定な場合も多くあります。
これは「人材の不足」の落とし穴に陥っているためです。この穴を解消しないことには、別の穴を塞ぐ余裕も出ないため、早急に解決する必要があります。
「人材の不足」の落とし穴に入っている場合、人数が足りないということではなく、適切なプロセスでプロジェクトを推進できるリード人材がいないことを問題視する方が良いと思います。
なので、Design & Researchでは、まず自分たちがリード人材として入り込んでプロダクトデザイナーとしての基準を示しつつ、その後にチームにその基準を広めていくための仕組みを用意していきます。これはハイパフォーマーなプロダクトデザイナー的な視点の動きです。
まず、自分たちがチームにおける開発の進め方の基準値になるように、ハイパフォーマーとして振る舞う必要があります。
例えばDESIGN & RESEARCHでは、企画を渡されたらどれだけ曖昧な要件でも1週間以内には全体のプロトタイプを持ち込み、仕様の調整を行います。
また、プロダクトデザイナーとして担う範囲をプロジェクトの中でも広げていきます。
エンジニアも手一杯な状況なので、簡単な改善はClaude Codeでフロントエンドまで実装し、動的な体験を確かめるとともに、つくったコードは本番環境にも反映するようにします。
こうすることで、エンジニアはより技術的な論点に時間を集中することができ、チームとしての生産性が高まります。
同時に、UIをつくる・品質高いものをつくる、という論点にチームの頭を出来るだけ割かせないことを意識して、より簡単につくれる仕組みを用意していきます。
例えば、UIの中で使われるライティングを自動でチェックできるFigmaプラグインをつくるなど、あらゆるレビューの手順は自動化していくようにします。
また、前述したClaude Codeの動的なプロトタイプ環境をPdMにも共有し、企画段階で誰でもプロトタイプを出せるようにしていくフローも整備します。
このように、自分たちがプロジェクトを推進しながら、楽につくるための仕組みを整えることで、少しずつ「人材の不足」の論点がなくなっていき余白が生まれます。
ただ、ここでもまだ「つくったものが使われない」という論点は残ります。これは大抵の場合、「つくる前にインサイトの整理や共有が不足している」からです。
インサイトの不足が起こっているチームには、以下のような課題が生まれます。顧客像が共有されていないことで、つくってもつくっても使われず、チームの目線がバラバラになってしまうのです。
ここで行うべきことは、既存機能の改善だとしても、新規開発だとしても、常にインサイトが意思決定の基準になるようにすることです。
これは、プロダクトデザイナーやプロダクトマネージャーが責任を持つべき視点です。
Design & Researchは、プロダクトの課題に合わせてこの顧客情報の可視化を行います。
例えば、とあるSaaSプロダクトの既存機能への改善要望フローを構築したときの例をまとめます。
複雑なドメインでさまざまなタイプの企業やステークホルダーが使うプロダクトだったので、チームの誰も具体的な顧客像や業務イメージを分かっていない状態でした。
そこでまず、以下のように10以上の顧客タイプとそれぞれの業務フローをパターンとして可視化することから始めました。
さらに、毎回CSから改善要望をもらったら、その顧客タイプごとの行動や課題を確認して「この要望はどの顧客タイプに当てはまる課題か」「優先的に改善すべきか」を精査できるようなフローを浸透させました。
言われたらつくる、という訳ではなく、プロダクト開発組織側から「これは重要な課題か/そうでないか」を見極められるようにしています。
新規開発においても、同じようにアイデア起点・ビジネス起点・技術起点だけで進んでしまうことを止めるために、「インサイト起点での新機能探索」をフローとして進めておきます。
これまでの要望を取りまとめつつ、既存のプロダクトを利用する方の業務フローや、理想の業務フローを可視化しておきます。
さらに、そこから注力した方が良い体験別に具体的なプロトタイプとセットで企画案をまとめていきます。
これらの体験図とプロトタイプで企画を走り出すことになったら、その後デザインや実装に関わる方の認識をブレないものにするために、狙いやインサイトはドキュメントにまとめて共有するようにしています。
ここまでやると、これまでうまく新機能の案をまとめられなかった社内のPdMやディレクターの方も、あとは何をやるか選ぶだけという状態でうまくプロジェクトを推進できるようになっていきます。
ここまでのアプローチを行うと、プロジェクト単位では素早く顧客に刺さるものを狙えるようになっていきます。
しかし、プロダクト開発から事業成果を持続的に生むためには、「理想像」や「戦略」を可視化し、常に一貫した体験をチームで積み重ねていけるようになる必要があります。
この「理想像と戦略の不足」を塞ぐためには、プロダクトマネージャーの視点が必要です。
Design & Researchでは中でも、デザインの視点から取り組みやすい「プロダクトの成長サイクル」と「理想の体験のプロトタイプ」を可視化することが多くあります。
例えば、プロダクト成長サイクルのイメージは以下のようなものです。
これまで社内になかった体験の新規事業を推進するにあたって、関係者間で1stプロダクトリリースをした後に何をするべきかの認識を揃えるため
「事業としてこのような体験が回り続けることでグルグルと成長していく」というサイクル図をつくり、議論しながらアップデートをかけていきました。
さらに、概念として成長サイクルを可視化するだけではなく、理想的な事業状態をプロトタイプで可視化しておくこともよく取り組みます。
こうすると、チームの中で「ここに向かっている」という同じ目線が生まれていきます。
リード人材としてプロジェクトの推進を行いながら人材の不足を埋め、そこから開発組織の落とし穴を一つひとつ埋めていくことで、少しずつチーム全員が自律的に動けるようになっていきます。
例えば、以下の図はとある支援先の開発組織の状態です。ここまでにまとめたアプローチを一つひとつ進めていったことで、約半年で社内のメンバーだけで既存改善と新規開発が回せるようになりました。
このように自律的な開発組織ができると、自ずとユーザーに求められ成果に直結する機能が増えていきます。
以下は、私たちが初期にアプリのグロースハックを支援した組織の指標改善例です。支援開始から4ヶ月で、追いかけていたプロダクト指標が2.2倍に高まりました。
穴が塞がれていない状態で闇雲に機能をつくり続けることは、メンバーも疲弊し、プロダクトから事業成果を生むこともできないジリ貧の選択肢です。
プロダクトデザイナーの視点、プロダクトマネージャーの視点を合わせ持った役割の人材が一つひとつ穴を塞いでいくことで、必ず開発組織はリカバリーすることができます。
今回まとめたようにDesign & Researchは、事業が急速に成長する中で陥りやすい落とし穴を、プロジェクト推進をしながら塞いでいく役割を担います。
私たちはプロダクトデザインを軸としていつつ、目的は常に「プロダクトから事業成長を生むこと」に置いています。
ただつくり続ければ、事業が伸びる状態になっている開発組織は稀です。プロダクトデザイナーもUIだけに責任を持つのでなくて、開発組織が持続的にワークするような状態に向けて、責任範囲を広げて動く必要があります。
落とし穴にハマり、がんじがらめになってしまった開発組織も、4つの落とし穴を一つずつ埋めていけば必ず価値を取り戻せます。
社内だけでうまく根本課題の解決ができない時に、Design & Researchがその助けになれるよう今後も力を磨いていきます。
