BtoBスタートアップでのプロダクトデザインの立ち位置を再定義している話

こんにちは、Shippio のプロダクトデザインマネージャーの @toofu__ です。

先日、株式会社ログラスさんとの共催で「Bayside Design Nite BtoB スタートアップのデザイン組織 ～ チャレンジできる環境で働く面白さ」という LT イベントを開催しました。この記事は、その LT で話した内容を補足しつつ公開するものです（アンケートで頂いた質問へのアンサーも記載しています）。

当日のスライドはこちらです。

ちなみに、対バン相手のログラスさんも、LT内容をベースに記事を公開されているので、ぜひご覧ください。

はじめに

このイベントのテーマは「チャレンジ」となっていますが、自分にとってのチャレンジは「いまのプロダクトやプロセスに対するデザイナー視点での課題を定義して、それに対する解決策を自分たちで（他のチームも巻き込んで）実施していく」というものでうす。その課題感であったり、それに対してどのように取り組んでいこうとしているのか、ということを話させていただきました。
ちなみに、ここで書いていることは、すでに取り組み始めているものだけでなく、まだ「やりたい」と考えている段階のものもあります。いずれは全部「やったぞ」と言える状態にしたい。

デザインチームをとりまく環境

チャレンジの前提となる、現在の Shippio の状況やプロセスを紹介します。事業等の紹介は会社紹介のスライドをご覧ください。

事業やプロダクトがどんどん変化する

Shippio クラウドサービスというソフトウェアは、当初はデジタルフォワーディングという、オペレーションを含む弊社サービスの顧客に対して付加価値的に提供されているものでした（フォワーディングとは、ざっくり言うと貿易における輸送手配などを行う代理店業務のようなものです）。そのため、Shippio はシンプルに貿易実務のためのプロダクトであり、想定される状況やユーザーストーリーが限られていました。

その後、フォワーダー（フォワーディング業務を請負人）として我々が関与しない貨物についても価値提供できるよう、ソフトウェア単体でのサービス「Any Cargo」の提供を開始しました。デジタルフォワーディングの付加価値に限らない価値提供ができるようになったため、顧客となる企業の幅が広がり、ログインするユーザーのミッションも多様になり、結果としてひとつのプロダクトで想定すべきユーザーストーリーも多くなっていきました。

さらに先日、Shippio以外のフォワーダーなどの物流事業者を Shippio クラウドサービス上に外部ユーザーとして招待することで、より実務を効率化させる「パートナーコネクト」の提供も開始され、複数の会社が Shippio 上で協業するというユーザーストーリーも出てきました。
こんな感じで、プロダクト・UIを使う人や業務が多様になってきました。

顧客課題の定義とソリューションの検討で役割が分担されている

Shippio のプロダクトチーム（Product Manger & Product Designer）では、5つの段階を踏んで企画を行っています。（スライド参照）

• Business Objective: 事業戦略に対して、プロダクトが担うべき目標です。Product KPI とも呼ばれたりする。

• Product Initiative: Business Objective の達成に向けて、プロダクトが実現しないといけない、比較的長期間かけて取り組むトピックです。

• Epic: Product Initiative を開発可能な粒度まで分解したものです。主に、満たすべき要件としてのユーザーストーリーと、それが実現されたときの Customer Outcome（顧客にとっての成果）として定義されます。

• Solution: Epic で定義された課題に対して、プロダクトがどのようになればそれを満たすことができるのかを定義します。オブジェクト設計であったり、正常系の業務フロー・操作フローなどが含まれます。

• Spec: Solution を実装可能なレベルまで精緻化した、いわゆる仕様書です。

これらのステップそれぞれに RACI というフレームワークで役割分担が定義されており、大まかに言うと「Epicより前のディスカバリーフェーズは Product Manager（PdM）」「Solution より先のデリバリーフェーズは Product Designer （PdD）」という分担になっています。

ソリューションの検討に使える時間が限られている

Shippio ではプロダクト開発のプロセスに Shape-up というコンセプトを採用しています（Shape-up についての詳しい紹介はこちらの note をどうぞ）。

Shape-up に合わせて Discovery ~ Design といった企画フェーズのリズムも定義されているのですが、定義上、 Solution の検討に使える時間が3週間しかありません。Solution に含まれる業務フローからオブジェクトモデリングなど、情報設計段階から正常系のユーザーフローまでを考えるにはちょっと時間が足りないと思っています。これを短縮するには、前段の Discovery フェーズ（Epic 定義＆優先順位付け）に入って、 Solution 検討に入る前から解像度を上げておくことが有効だと思います。が、 Spec 定義などの In Cycle のデリバリー業務と並行するため、Discovery に十分な工数が割けているとは正直言えません（ここはデザインチームの組織づくりで解決したいところではある）。

顧客課題に対して too specific な仕様になりがち

現在のプロセスとしてはこんな感じなのですが、プロセスに対するデザイナー視点での課題として、 Epic で定義された顧客課題に対して too specific な仕様になりがちになることが挙げられます。
顧客課題に対して too specific な仕様になることの何がダメなのか？というと、自分は大きく2つの理由があると思っています。

情報設計負債につながる

よくある話だと思いますが、初期段階では限られたユーザーストーリーに対して価値を提供できるような MVP として設計されたプロダクトに対して、改善を積み重ねていった結果、あらためて振り返ると「いまこの設計が本当に理想なんだっけ？」となることがあります。たとえば Shippio だと、デジタルフォワーディングを前提としたサービスのみ提供していたころは、まだ弊社にフォワーディング業務を依頼してくださる会社の貿易実務担当者のユーザーストーリーに特化した設計になっていました。しかし、Any Cargo, パートナーコネクトといったサービスが増えてきた現在、「このユーザーストーリーを考えると、プロダクトの設計はもっとこうなっているべきなのでは？」というような話がよく出てきます。

コアな体験を悪くしてしまう（可能性がある）

スタートアップのプロダクト開発は「足りてない機能を追加していく」ことで顧客課題を解決していく場面が多いと考えています。Epic としてユーザーストーリーを定義し、その実現にフォーカスしようとすると、既存の別のユーザーストーリーの使い勝手を下げてしまったりします。たとえば「ある機能を使うためのボタンを追加しなければならない。もとから別のボタンがあるのでまとめてひとつのメニューボタンに格納しよう」みたいな感じで、もともとのボタンにアクセスするためのクリック数がひとつ増えてしまったりします。そしてそれが実は既存ユーザーが頻繁に使用する重要な機能であった、という事象は珍しくありません。もちろん新しい機能を優先することが適切な場合もありますが、正しくトレードオフを判断しないと、どんどんコアな体験が使いづらくなっていってしまうおそれがあります。

どのように役割を再定義するか

デザインチームのミッションをつくる

まず、 Shippio のプロダクトデザイナーのミッションを以下の2つに設定しました。当たり前のことを書いてるような感じもしますが、改めて言語化するのが大事だと考えています。

Product Initiative の達成に貢献する PdM と一緒になって、ビジネスの成長につながる顧客課題解決（Customer Outcome）に向けて、プロダクトのありようを考える。
ソフトウェア品質の維持・向上 それと同時に、実際に Shippio を使う人にとっての体験が良いものになる（User Outcome）よう、モノとしての最も適した形や使い勝手を実現する。

ちなみに Shippio では「顧客価値（Customer Outcome）」と「ユーザー価値（User Outcome）」を区別しています。

• Customer Outcome: Shippio によって、顧客自身が抱えているビジネス課題をどれだけ解決できるのか。たとえば物流コストをどれだけ削減できるのか。基本的にはこれが「企業が Shippio に対してどれだけお金を払ってくれるのか」という Economic Value につながります。

• User Outcome: Shippio を使う業務をどれだけ良く（効率的に）行うことができるのか。たとえばパートナーとのやり取りをどれだけスピード感早く行うことができるのか。これが情報設計や、デザインの評価の軸になります。また、Economic Value が同等の競合サービスとの比較になったときに、優位に立つことができると考えています（しばらく使わないとわからないから簡単には言えないですが）。

課題とソリューションの関係性をとらえなおす

そのうえで、プロダクトづくりにおけるプロダクトデザイナーの立ち位置を「Epic（課題）ありきで、それに対しての解決策を打ち返す」だけでなく、「モノ（Product）のあるべき姿としての設計を前もって定義しておき、それを Epic とマッチさせて次の改善につなげる」という役割に見直そうとしています。

具体的に言うと、「ひとつの Epic に対して Solution を考える」のではなく、「複数の Epic を解決しうる汎用性のある Solution を考える」ことをデザイナーの基本行動としよう、というものです。

そうすることで、変化の激しいスタートアップのプロダクトが、その時々の課題に過剰適合してしまい、避けられる情報設計負債を積み上げることを防げるのではないかと考えています。
（もちろん、プロダクトのフェーズ次第ではどんとこい過剰適合のスタンスで、ピンポイントの課題を最速で解決すべきシーンもあるはずです。自分たちがどういうスタンスを取るかは PdM や Eng も含めて議論すべきだと思います。）

もっとも適したかたちをつくるための取り組み

上記のようにデザイナーの立ち位置というかプロセスと言うかを変えていこうと考えていますが、障壁があります。ひとつは、幅広い課題に目を向けることそのものがシンプルに難易度が高いこと。もうひとつは、先に書いた通り Solution を検討するのがプロセス上3週間しかないので、汎用性のある Solution を考えるのに時間が足りないことです。
それを解決するために、いくつかの取り組みをチーム内で進めています。

ドキュメントのテンプレートで強制的に目を向ける

PdD が責任を持つ中間成果物に Solution と Spec があります。これらのテンプレートに項目を加えて、幅広い課題に目を向ける機会を生み出そうと考えています。
たとえば Solution には次のような記載欄があります。

• いま解決しようとしている Epic 以外にも、解決できそうな顧客課題、使い勝手の課題があれば、それを記載する

• 既存のユーザーストーリーに対する User Outcome との trade-off がないか

まだ Epic になっていない使い勝手の課題を集めておく

Shippio では顧客や社内からのフィードバックおよびバックログを管理するツールとして Productboard を使用しています。
Productboard にはフィードバックそのものである「insight」と Epic になりうるバックログである「feature」というふたつのオブジェクトがあり、insight は PdM によって feature に変換・蓄積されています。PdM はこの「こうすべき」というレベルまで昇華された feature に対して、優先度評価を行っています。
PdD はあえて feature を見ないようにして、 insight をチームメンバーで全部見るという活動をしています。一度抽象化されてしまった feature を見るのではなく、フィードバックそのものに対して「どういう使い方をしていて、何をしたくてこのフィードバックをくれたのか」という推論活動です。いずれその近くの Solution を考えるときに頭の引き出しから取り出すようになるのではないかと期待しています。

モノとしてのあるべき姿を事前に定義しておく

これはまだ「やれたらいいな」というレベルのものですが、集めた課題から「あるべき姿」を Epic よりも先に定義しておき、 Epic が定義されたら、あるべき姿から切り出す形で Solution を作ることはできないか？と目論んでいます。事前に「あるべき姿」というネタがあるので、3週間という短い期間でも、幅広いユーザーにとって使いやすい、品質が高いものをつくることができるのではと考えています。

頂いた質問へのアンサー

以上が LT でお話した内容です（補足含む）。
イベント後のアンケートで「もっとこんな話を聞きたかった」という質問をいただきました、ありがとうございます。現時点でのアンサーをここに残しておきます。2つとも良いパンチやで…

Q. Epic に対しての Solution が機能しているかどうか、どう効果測定しているのか

その Solution が Epic に対して好影響を及ぼしたのか（要は顧客課題にちゃんとアンサーできているのか）については、 Epic 自体の成功条件が達成できたのか、で評価するのがいいかなと考えています。そのために Epic に対して Post Launch Recap という振り返りのプロセスが社内で定義されています。

ただ、これまで述べてきた考え方では、 Solution の良し悪しは Epic の達成に 100% 比重が置かれるわけではないため、それだけではデザイナーの評価としては適切ではないと考えています。が、じゃあ Solution の良し悪しをどう評価するの？というのは正直まだ答えを見つけられていません。「ひとつの Solution で幅広い課題に対応できるようにする」が主たる目的のひとつなので、「その Solution によって、使い勝手に関する顕在化した課題をどれだけ解決できるのか」というのがひとつの評価指標にはなるかもしれません。設計品質として捉えるか、顧客品質として捉えるかはまた要検討です。

Q. このプロダクトはこうあるべきなんじゃね？みたいなインテグリティを見出す方法、およびそれの再生産方法は？

散々「モノとしての最も適した形や使い勝手を実現する」とか言っていますが、どうやったら「あるべき姿を発見できた」とみなせるのか、マジでわからないです。誰か教えてほしい。「こんな業務パターンが存在しうる」の引き出しをどれだけ多く持てるかという話なんでしょうか。

実際のところ、どこかのタイミングで「えいや」っと「こうあるべき」を決めつけるシーンが発生すると思っています。というよりも、基本的には「こうあるべき」のインプットとなる種々の制約や文脈は時間とともに変化していくので、あまり精度を追い求めない（得られる自信との時間投資対効果が低い）、と表現するのが正しいかもしれないです。「あるべき姿」のメンテナンスを日頃から行う必要がありそうです（「あるべき姿」と「いまのプロダクト」の二重管理？）。

最後に

Shippio のミッションである「理想の物流体験を社会に実装する」に対して、プロダクトデザインでできるチャレンジは数多くあり、自分たちで道を模索しながら取り組めるのがスタートアップのデザイン組織の面白さかなと思っています。

現在 Shippio のプロダクトデザインチームでは、こんな感じのチャレンジを一緒にやっていく仲間を募集中です。興味があるかたはぜひお声がけください！

youtrust.jp