Why に向くためのデザインプロセスとは？
今週もお疲れ様です！アルプのデザイナーの大澤 (@Tadaki) です。
先週デザインシステムについて記事を出しましたが、本日の記事ではデザインプロセスについて紹介したいと思います。
アルプではサブスクリプションビジネスを行う企業向けに、今まで手作業や自社開発がスタンダードだった契約や請求の管理を SaaS として提供する Scalebase というプロダクトを開発しています。
B2Bのプロダクトを扱う企業では、ビジネスチームがお客様から要望等をヒアリングし仕様を決め、プロダクトチームに実装を依頼するという流れが多いと思います。
この構造の問題の一つは、かなり強く意識づけする仕組みがない限り、プロダクトチームが Why でなく How や What に向きがちになってしまうということがあります。
この記事では、Scalebase の開発でプロダクトチームが Why に向くためのプロセスの一例として、ビジネスとプロダクトチームが連携し、デザインに落とし込むまでのプロセスを紹介します。
大澤 直毅 | Tadaki Osawa
Web制作会社で自社音楽系SNSの制作・運営と受託開発に従事。
2010年ピクシブ株式会社に入社。ECサイト BOOTH の立上げから運営をはじめ、新規事業立ち上げのデザイナーを担当。
2019年8月アルプ入社。プロダクトデザインを担当。
アイディア段階からプロダクトチームを巻き込む
Scalebaseの開発では、「トリアージ」と呼ばれる新機能や改善タスクが優先度つきで集約されたカンバンを運用しています。
将来的に導入していただきたいお客様に必要な要件、ご利用されているお客様からの要望などを元に新機能や改善の種となる issue を起票し「トリアージ待ち」のレーンに追加します。起票はビジネスチームに限らずデザイナー、エンジニアも含め誰でも起票できるようになっています。
「トリアージ待ち」のレーンに issue を起票
「トリアージ待ち」に入れられた issue は毎週末に開催されるタスク整理会で対応を決めます。タスク整理会にはビジネスチーム、デザイナー、エンジニア含むプロダクトチームが参加し、今週起票された issue について、お客様の要望や現時点でのオペレーション、それに対してどのような機能を提供すべきかをざっくりと認識合わせをしています。
issue について大筋の対応と優先度を決めると、タスクとして優先度順にカンバンに積んでいきます。このように機能の大枠を決める段階からデザイナー、エンジニアが入ることで、その機能はどのようなお客様にどのような価値を届けるのかを早期から認識合わせすることができます。
issue の対応タスクとその優先度を決めレーンを移動
誰の、何を解決するか、どのような価値を届けるかにフォーカスする
ビジネスチームが優先度の高いタスクからPRD（Product Requirement Document）と呼ばれる仕様書を作成します。PRDには以下の内容が書かれていて、プロダクトチームと読み合わせを行っています。
・その機能がなぜ必要なのか、お客様のペインは何か
・具体的にどのようなお客様から要望があるのか
・お客様の課題を解決するためには、どういう要件を満たす必要があるのか
特になぜ必要なのかの部分が重要です。Scalebaseは契約や請求の管理を扱うため、経理でないデザイナーやエンジニアがリアリティを持ってドッグフーディングをするのは難易度が高いです。なるべくビジネスチームからお客様のリアルな情報を聞けるかが重要になります。
ビジネスチームは、プロダクトチームに正しくお客様の情報をインプットすることを常に意識してくれています。例えばお客様ごとの オペレーションフローを FigJam などにまとめたり、必要に応じてお客様との打ち合わせに同席させてもらっています。
お客様ごとのオペレーションを FigJam でまとめる
また、社内には税理士法人や監査法人に勤めていた公認会計士のメンバーが2人いて、知識が足りず理解しづらい点など即座に回答をもらえます。プロダクト視点を持ったヘビーユーザーが隣りに居るようなもので、自分が経理業務をしたことがなくてもかなり解像度高くプロダクト開発ができています。
要望を汎用化しデザインをする
PRDを通して、お客様の課題やオペレーションを理解した上でデザインに入ります。お客様ごとでオペレーションに差異があるので、フローを整理し汎用化した機能として提供する必要があります。
いきなり Figma でデザインせず中間の成果物として、汎用化したお客様のオペレーションフローに対してどのような機能があるとオペレーションがスムーズにいくかを FigJam で整理しています。
具体的には、以下のようにお客様のオペレーションフローと、補足としてお客様の感情をマッピングし、既存機能・新機能を組み合わせたときに結果としてオペレーションがスムーズになっているかを確認しています。
この FigJam で作った中間成果物は、機能を提供する予定のお客様、ビジネスチームやエンジニアにも共有することで、関係者がより早い段階で完成形のイメージを共有しながら開発することができます。
まとめ
このようにビジネスチームとプロダクトチームが相互に歩みよることにより、機能ができたあとに「何か思っていたものが違う」となるのを防いでいます。
共通のドキュメントを用意することは、認識のズレはもちろん、無駄な確認時間を減らし、本来考えるべきところに時間をあてることにも繋がります。
このフローも一例ですので、組織やプロダクトに応じて効果的なデザインプロセスは違うと思います。記事を読んでくれた方にとって、良いプロセスや意思決定について考えるキッカケになっていれば幸いです。
終わりに
アルプではデザイナー含め、積極的にメンバーを募集しています。今回の記事を見てご興味を持ちましたら、是非Meetyで私とカジュアル面談しましょう！よろしくお願いします！