この記事は、Bill One開発Unit ブログリレー2025の第15弾になります。
はじめに
こんにちは、Bill Oneのプロダクトデザイナーをしています、古川です。
PdM・エンジニア・デザイナーのチームで議論を重ねながら、日々プロダクト開発を進めています。私が所属するチームでは、最近、新規機能の開発に関わる機会が増えてきました。
そんな中で強く感じているのが、新規機能開発は、既存機能の改善と比べて進め方が一気に難しくなるということです。
まだこの世にない体験をつくるため、ユーザーの使い方は仮説に近く、また仕様も柔らかい状態から始まるため、「何をどこまでやるのか」が揺れ動きやすい。だからこそ職種間で密に会話しながら進める必要があり、実際にコミュニケーション量は多くなりがちです。
一見すると議論も活発で、うまく回っているように見えます。ただ、実際に関わる中で、少しずつ違和感を覚える場面が増えていきました。
例えば
- 体験の必要性について、後から改めて議論が発生する
- 体験の方向性を定めるのに必要以上に時間がかかっているように感じる
- 以前に共有した内容と重複した議論や、デザイン確定後の手戻りが発生する
どれも誰かがサボっているわけでも、スキルが足りないわけでもありません。
ただ、「なかなかスムーズに開発が進んでいないのでは？」という違和感が続いていました。
そのときに感じ始めたのは、チームとしての進め方に原因があるのではないかという疑問でした。
この記事では、新規機能開発においてチームで動くことを意識したときに、どこでつまずきやすいのか、そして今、どんな向き合い方が必要だと感じているのかをデザイナー視点で整理してみようと思います。
振り返って見えた、チームとしてのつまずき
開発を振り返ってみて「うまくいっていなかった」と感じたポイントは、大きく二つありました。
1. 構想をPdM・デザイナー間で作りすぎていた
一つ目は、初期の構想をPdMとデザイナーだけで作り込みすぎていたことです。新規機能には正解がありません。だからこそ、「まずは形にしないと始まらない」という焦りが生まれます。
その結果、体験の流れやUIの方向性をある程度固めた状態で、エンジニアに共有していました。もちろん、その内容自体は考え抜いたものでした。
ただ振り返ると、「どう実現するか」という手段を、かなり早い段階で決めすぎていたのだと思います。
その結果、
- デザインを確定・連携、あるいは実装する段階で「技術的に難しい」「別のやり方が必要」と分かる
- PdM・デザイナー間で話し合った内容を共有するだけでも、余計なコストがかかる
といったことが起きていました。
「必要なメンバーを巻き込んでいたつもり」でも、必要な視点が、必要なタイミングで入っていなかった。それが一つ目のつまずきでした。
2. ユーザーに対する視点が揃っていなかった
もう一つの要因は、ユーザー理解に関する前提のズレでした。
デザイナー、PdM、エンジニアの間で
- 想定しているユーザー
- 利用シーン
- 課題の切り取り方
が、微妙にズレていたのです。
新規機能において「どのユーザーに、どんな価値を提供するのか」が、チームの共通前提として十分に揃っていない状態でした。
例えば、ユーザー像は共有されているつもりでも明文化されていなかったり、職種ごとに異なる前提で解釈されていたりする。そうした状態で議論を進めると、全員が「ユーザーのために」と考えていても
- どのユーザーを
- どの状況で
- 何を解決したいのか
が噛み合わず、後になって「そもそもこの体験は本当に必要なのか」という議論に立ち戻ることになります。
その結果、体験の方向性をなかなか決めきれず、意思決定にも時間がかかるようになっていました。
「ちゃんと考えているはずなのに、なぜか進みが遅い」。
そんな感覚があったのは、ユーザー理解の前提が揃わないまま議論を重ねていたからだったのだと思います。
これは、ユーザー理解が足りなかったというよりも、「どの前提で話しているのか」をチームとして明示できていなかったことが原因だったように思います。
やったこと・やろうとしていること
この振り返りを通して強く感じたのは、新規機能開発では、初期段階での目線合わせが想像以上に重要だということです。
ここからは、実際にやったこと、そしてデザイナーとして今取り組もうとしていることを整理してみます。
1. いつ誰を巻き込むかを、意識的に設計する
まず取り組んだのは、初期構想の段階からエンジニアの視点を入れることでした。全員を集めるのは難しいため、担当プロジェクトのエンジニアリーダーにできるだけ早い段階から関わってもらうようにしました。
目的はシンプルで
- 技術的に難しそうな点はどこか
- 現実的な手段として成立しそうか
を早めに知ることです。
体験を作り込む前に、「この体験案は現実的に成立するか」を技術観点で見立てる、という位置づけです。
新規機能は既存機能に比べて影響範囲が広く、前提が固まったあとに修正が入ると、その影響が体験全体に一気に波及します。だからこそ、早い段階でこの視点を入れるだけでも、手戻りは確実に減ると感じています。
2. ユーザー視点を揃えるために、考える順序を意識する
次に意識し始めたのが、ユーザー理解をどう揃えるかです。
新規機能開発ではスピードも求められるので、最初から完璧にユーザー理解を揃えるのは現実的ではありません。一方で、デザイナーとして「ユーザーにとって優しい体験」を考えるあまり、体験を最初から細かく詰めすぎてしまうことがありました。
その結果、
- 今、どのユーザーの、どの課題を話しているのかが曖昧になる
- 本当に揃えるべき前提が後回しになり、議論が散乱する
という状態になっていたと思います。
そこで意識するようになったのが、ユーザー体験を一気に作ろうとせず、考える順序を分けることでした。まずは、課題を解決するための最小限の体験に集中することです。
「どのユーザーが、どんな状況で、何に困っているのか」
という前提をチームに共有したうえで、メインとなるストーリーを初めに議論する。そのために必要となる案出しやプロトタイプの作成を素早く行う。例外的なケースや分岐については、その後に考える。
まだ十分に試せているわけではありませんが、この順序で考えることで、「今、何について話しているのか」をチーム全体で揃えやすくなると感じています。
3. 揃えた前提を、チームに共有するためのアウトプットを用意する
2で意識した考え方は、頭の中だけで整理していても、チームには伝わりません。
そこで工夫したのが、揃えた前提をどうアウトプットとして共有するかです。
試みとして現在は、ユーザーの課題ごと（ユーザーストーリーごと）にアウトプットを分け、共有するプロトタイプに全体のシナリオとして参照できるページを含めるようにしています。
ユーザーストーリーごとに整理することで、
- ユーザーはどんな状態から使い始めるのか
- どんな変化が起きたら「課題が解決された」と言えるのか
を、一つずつ明確に示せるようになります。
これはデザインを細かく見せたいからではなく、チーム内で共有すべき前提を、迷いなく揃えるための工夫です。結果として、課題の妥当性を議論しやすくなり、後から関係者が増えても、意図や判断の前提を共有しやすくなったと感じています。
おわりに
正直なところ、まだ模索中の部分は多いです。新規機能開発に「これが正解」という進め方はないと思っています。だからこそ、定期的に振り返りながら、「今の進め方はどうか？」とチームで話し続けたいと考えています。
今回の振り返りは、チームで動くデザイナーとしての反省でもありました。
デザインは画面を作ることだけではなく、
- メンバーをどう巻き込むか
- ユーザーの前提をどう揃えるか
- 周りにどう共有するか
それらすべてが、プロダクトデザインの一部なのだと、改めて感じています。
この試行錯誤が、これから新規機能に向き合うエンジニアやデザイナーにとって、少しでもヒントになれば嬉しいです。
Sansan技術本部ではカジュアル面談を実施しています
Sansan技術本部では中途の方向けにカジュアル面談を実施しています。Sansan技術本部での働き方、仕事の魅力について、現役エンジニアの視点からお話しします。「実際に働く人の話を直接聞きたい」「どんな人が働いているのかを事前に知っておきたい」とお考えの方は、ぜひエントリーをご検討ください。
