これってデザインマッチポンプ？要件の行き来を減らし、プロジェクトをスムーズに進めたい（切望）
はじめまして、株式会社ビザスクでプロダクトデザイナーをしている宮島です！
いきなりですが、プロダクト開発で当初に見積もった要件が本当に必要なのか精査することで開発工数が削減された経験はないでしょうか？
デザイナーやPdMが仕様を調整することで開発の負担を減らしポジティブな結果になったように見えます。
しかし、実際には初期の要件整理がうまくいっていれば、すでに進んでしまっていた開発見積もりやテーブル設計など細かなところで起きてしまう手戻りをもっと減らせるはずです。
私はこの現象を自戒をこめて「デザインマッチポンプ」と呼んでいます。
本記事では、私の所属するチームをケースとした、この「デザインマッチポンプ」が発生する背景と、向き合い方について考えてみます。
前提：チームの構成、開発スタイル
私たちは、プロダクトを開発するにあたり以下のようなメンバーを中心にチームが構成されています。
Biz、PdM、デザイナー、エンジニア
また、初期フェーズということもあり、開発スタイルはウォーターフォール寄りで必要な要件を網羅的に洗い出す必要がありました。
要件の全体像が見えてきたらデザインが走り出し、後追いで実装が始まるというのを機能単位で繰り返すので、そういった意味では部分的にアジャイルな感じもあります。
「デザインマッチポンプ」とは？
私が「デザインマッチポンプ」と呼んでいるのは、以下のようなプロセスを指します。
要件定義の段階で「必要そう」と思われる機能がどんどん追加される
その結果、開発の工数が増大する
開発フェーズに入ると「やっぱりこの機能は今は不要かも」となり、仕様が削減される
エンジニアの負担が減ったように見えるが、本来は最初から不要な工数をかけなくて済んだはず
この現象の本質的な問題は、「要件が行ったり来たりすること」ではなく、初めから不要な機能を省けていれば、チーム全体がもっと効率的に動けたのでは？という点にあります。
「完成は、付加すべき何ものもなくなったときではなく、除去すべき何ものもなくなったとき、達せられる」
という、サン=テグジュペリの言葉が、デザインの格言として引用されることもあります。
実際にウォーターフォール方式では、要件を煮詰め、プロダクトの欠点を明らかにしながら取り除くことに時間をかけるため、要件が初期に膨らんでしまう可能性を常に抱えています。
ただ、インターフェースを具体的に考える段階で、ワイヤーフレームに描写されなかった細かな不整合が発見されたり、その過程で要求が変更されることもあるため、本当に変更の余地はないのか傷口は小さな間に抑えておきたいです。
ちなみに、機能が複雑になり開発工数が増える変更はデザインマッチポンプとは呼んでいません。
それは機能を求めすぎているか、課題を正確に把握できていない可能性があるので、「なぜ当初の要件では不十分なのか」をチームで話し合い、さまざまな視点から必要十分なところまで削る議論があってもいいのかなと思います。
なぜデザインマッチポンプを歓迎できないか
1. 開発のリソースをじわじわと蝕む
要件がエンジニアに展開された瞬間から、着手はせずとも少なからず何かしらの見積もりや検討が頭の中で始まります。
後出しで要件を変えることは、小さいながらもエンジニアのリソースを消費してしまいます。
最近では、人の時間やお金、好意などを薄く削ってモヤモヤさせる人のことを「スライサー」と呼ぶそうですが、頻繁にデザインマッチポンプを起こすことは「スライサー」に該当するのではないでしょうか。
2. チーム全体に検証不足の不安を煽ってしまう
開発工数が減る変更だったとしても、要件が頻繁に変わることはチームの混乱を招きます。
デザインプロセスでよく聞く「ダブルダイヤモンド」では、課題を特定するための発散と収束、解決策を決定するための発散と収束が行われますが、デザインマッチポンプはその後の現象であり、頻繁に起こることはダブルダイヤモンドの内容が不十分だったことを意味します。
それは、将来的に他の要件も変更されるかもしれないという不安をチームに与えてしまいます。
デザインマッチポンプが発生する背景
この現象が発生する原因として、主に以下の3つが考えられます。
1. 初期の要件整理が不十分
プロダクトの目的や優先順位が明確になっていないと、「とりあえず入れておこう」「後から考えよう」といった形で機能が増えていきます。その後、開発が進むにつれて「やっぱり不要では？」と削減されるのですが、このプロセス自体が不要な工数を生んでいます。
2. 役割ごとの視点の違い
私たちのチームでのプロダクト開発には、Biz、PdM、デザイナー、エンジニアなどといった複数の立場の人が関わります。それぞれの視点が異なるため、どこで要件を確定させるかが曖昧だと、仕様が行ったり来たりしてしまいます。
Biz：日々の業務の中で顧客と最も近い立場におり、PdMと一緒に課題感や要求を整理する
PdM：プロダクトの方向性を決め、開発の優先順位を調整する
デザイナー：課題感や要求をもとに、適切なインターフェースを設計する
エンジニア：PRDやFigmaをもとに技術的な要件を検討し開発を進める
顧客の声に直接触れる機会が多いのはBizですが、それをもとに課題を整理し、適切なプロダクト要件へと落とし込むのはPdM、デザイナー、エンジニアも含めたチーム全体の役割です。誰か一人が課題を定義するのではなく、関係者全員が共通認識を持って進めることが重要です。
3. 仕様変更のプロセスが属人的
仕様変更の背景がチーム全体に共有されていないと、「なぜこの変更が必要なのか？」が不透明になり、結果的に開発チームの混乱を招きます。
また、変更になった背景を共有していれば、同じ理由で変更する可能性がある箇所をチーム全体でキャッチアップしやすくなりますが、その機会も失われてしまいます。
デザインマッチポンプを減らすためにしていること
これらを踏まえて、特にデザイナーの私が意識的に実施していることを紹介します。
1.「言うだけ言ってみる会」で着手中のものを常に共有する
週に1回、デザイナーの私が直近でよくコミュニケーションを取っているエンジニア（主にフロント）をmtgに招待して、今行っている作業やなんとなく気になっていることをラフに共有する時間を作っています。
どのようなことをしようとしているかを早めに共有することにより、エンジニア視点のより良い案が出てきたり、検討漏れの発見に繋がっています。
また、この会のタイトル通り、多少無茶かもしれないことも言ってもいい場としています。これにより日頃からのコミュニケーションのハードルが下がり風通しの良い関係を築けています。
ちなみに、年始にイタリアへ行ってきたのですが、今年はサン・ピエトロ大聖堂の「聖なる扉」が開く25年に1度のタイミングでした。この扉をくぐると罪が許されると言われていて、私もちゃんとくぐってきました。「言うだけ言ってみる会」は、どんな意見や提案でもまずは受け入れ、プロジェクトを成功へ進める聖なる扉でありたいです。
2. 「要求決定からエンジニアへ展開」をなるべく早い段階にする
デザインを作り込んでからではなく、とりあえずすぐにワイヤーフレームに、要求を達成するための一連の流れを落とし込み、エンジニア視点での技術的な変更の可能性を検証してもらいます。
また、仕様で悩んでいる箇所があった場合は、私からの理想案と、エンジニアからの（工数的な）理想案を出してもらい、ユーザー体験と実装コストを天秤にかけて判断しています。
3. 標準コンポーネントなど、既存のアセットを利用していい場合はそのスタンスをデザイナーが明確にする
ビザスクが実現したい世界観やブランドをプロダクトに反映するためにデザインシステムは作られています。
ただ、初期から全て盛り込むのではなく、段階的に自社オリジナルのアセットに置き換えるべきと判断したコンポーネントは、ブラウザやライブラリ標準のものを使用しています。
これも、エンジニアの親切心で既存のデザインシステムを基によしなに実装される前に、デザイナー側が「標準コンポーネントを使用してほしい」というスタンスを明確にすることでムダな作業をしてしまうリスクを減らします。
デザインマッチポンプが起きたらすべきこと
どんなに注意を払っても要件変更が起きてしまうことはあります。
そんな時にどういう立ち回りができるかも大切だと考えています。
1. 変更背景を共有する
前述しましたが、エンジニアにも変更背景を共有することで、同じ懸念点が他の箇所であった場合にエンジニア側でもキャッチしてくれる可能性が期待できます。
2. 見かけだけの変更で済むのか確認する
表面上の機能は小さくなったかもしれないけど、テーブル構造が変わったりと見えないところの影響が大きいかもしれないので、そのタイミングで仕様を変えることが現実的なのかエンジニアからの意見を聞いた上で最終的に変更を決定するようにします。
総じて大事なのは、一方的な変更の報告にしないことです。日頃からエンジニアと良好な関係を築くためにコミュニケーションを大切にし、変更が起きた場合でも、信頼値を消費しない柔軟性のあるチームが理想だなと思っています。
さいごに
デザイナーはBizとエンジニアの架け橋だと思っています！
テキストコミニュケーションが多い職種だからこそ、プロダクトビジョンをしっかりとインターフェースに翻訳し、チームの雰囲気を醸成する立ち回りも意識していきたいです。
そして、デザインマッチポンプで起こっていることは、「開発工数を減らしたデザイナーの成果」ではなく、「もしかしたら防げたかもしれないこと」として、エンジニアの信頼を得るためのチェックポイントだということを私は考えて真摯にこれからも向き合っていきたいです。
ここまで読んでいただきありがとうございました！
カルチャーフィットを大切にするビザスクの働きやすさは胸を張って自慢できます。もし開発チームに興味があれば、ぜひ一度カジュアルにお話ししましょう！