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

by Shippio

Slide 1

Slide 1 text

スタートアップでの   プロダクトデザインの立ち位置  を再定義している話  Shippio プロダクトデザインマネージャー   Toru Yoshioka  2023-11-20 Bayside Design Nite 

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Shippio の事業・プロダクトの変化 

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Copyright © 2023 Shippio, Inc. All Rights Reserved. プロダクトの変化  ● デジタルフォワーディングの顧客に対してクラウドサービスを提供   ● 2023/01 クラウドサービス単体での提供を開始（ Any Cargo）  ● 2023/11 物流事業者（例：Shippio以外のフォワーダー）や、納品先などを招待できる機能の提供を開始（パートナーコネクト）   → プロダクトを使う人・業務が多様になってきた   https://www.shippio.io/news/partner_connect/ 

Slide 9

Slide 9 text

Shippio のプロダクトづくり 

Slide 10

Slide 10 text

Copyright © 2023 Shippio, Inc. All Rights Reserved. Shippio のプロダクトづくりのプロセス  顧客にとって価値あるアップデートになっているかどうかを見失わないように、以下のフォーマットに沿って意思決定をしています   ● Business Objective  ● Product Initiative  ● Epic  ● Solution  ● Spec 

Slide 11

Slide 11 text

Copyright © 2023 Shippio, Inc. All Rights Reserved. Epic  Product Initiative (Business Objective 達成に向けてプロダクトが実現しなきゃいけないこと)を開発可能な粒度まで分解したもの  ● ざっくり言うと、こんな感じで定義されます   ○ 満たすべき要件としての User Story  ○ それができるようになったときの Customer Outcome （顧客にとっての成果）  ● あと、大元の Product Initiative 達成に向けた「この Epic を通じて検証したい仮説と検証方法」も定義されます  

Slide 12

Slide 12 text

Copyright © 2023 Shippio, Inc. All Rights Reserved. Solution  Epic で定義された課題に対して、プロダクトがどのようになれば Customer Outcome（顧客にとっての成果）が出せるのかを考える  ● 業務フローの変更点  ● オブジェクト定義・設計  ● プロダクトの操作フロー（正常系）   ● ざっくりスケッチ  ● User Story の実装にあたって実現したい使い勝手など    

Slide 13

Slide 13 text

Copyright © 2023 Shippio, Inc. All Rights Reserved. Spec  Solution を実装可能なレベルまで精緻化した仕様書   ● レイアウトやスタイリング、文言  ● 使用するコンポーネント  ● 異常系やUIスタックを含めた振る舞いのロジックやパターン    あとから参照されたりするので、サイト内の機能単位で分類されて、 notion database でストックされている 

Slide 14

Slide 14 text

Copyright © 2023 Shippio, Inc. All Rights Reserved. Business Objective  Product Initiative  Epic  Solution  Spec  Epic  Product Designer (PdD)  Product Manager (PdM)  CPO  Management  プロセスと責任範囲のイメージ  Solution  Spec  Product Initiative 

Slide 15

Slide 15 text

Copyright © 2023 Shippio, Inc. All Rights Reserved. Shape-up  「6週間の開発（Cycle）+ 2週間のクールダウン  （Cooldown）」のリズムで開発を行う  要件やその機能が必要とされる背景をドキュメントにまとめ、エンジニアを含むチームメンバーやマネージャーと合意をとる   くわしいことはデザインチームのメンバーが書いた note 記事があるので、そちらをご覧ください。       https://note.com/shippio/n/nd49f55d6ac7a 

Slide 16

Slide 16 text

Copyright © 2023 Shippio, Inc. All Rights Reserved. Pre Cycle  In Cycle  Cycle N-1  Cooldown  N-1  Cycle N  Cooldown  N  Epic 定義  6weeks  2weeks  6weeks  2weeks  Solution 検討  Scoping  Epic 定義  Solution 検討  Scoping  Spec 定義＆実装  Shape-up のながれ  PdM  PdD  PdM/PdD/EM  PdD/EM  Spec 定義＆実装 

Slide 17

Slide 17 text

Copyright © 2023 Shippio, Inc. All Rights Reserved. Spec 定義＆実装  Pre Cycle  In Cycle  Cycle N-1  Cooldown  N-1  Cycle N  Cooldown  N  Epic 定義  6weeks  2weeks  6weeks  2weeks  Solution 検討  Scoping  Epic 定義  Solution 検討  Scoping  Spec 定義＆実装  Shape-up のながれ  PdM  PdD  PdM/PdD/EM  PdD/EM  3weeks 

Slide 18

Slide 18 text

Copyright © 2023 Shippio, Inc. All Rights Reserved. なやみ：Solution を考える時間が3週間しかない  ● もちろん Discovery フェーズ（Epic 定義＆優先順位付け）にも関わっているが、 In-Cycle （Spec 定義・デリバリー）と並行するので、そこに割ける工数は正直薄い   ● 業務フローからオブジェクトモデリングなどの情報設計〜正常系のユーザーフローまでを考えるには時間がかかる  ○ 「3週間で足りない」とか遅くね？と思ったあなた。あなたはきっと優秀なので Shippio で働きませんか？  ● 結果として Epic に対して too speciﬁc な仕様になりがち 

Slide 19

Slide 19 text

Copyright © 2023 Shippio, Inc. All Rights Reserved. too speciﬁc な仕様のなにがだめなのか  ● 情報設計負債（造語）につながる  ○ そのときどきの MVP 的な設計をし、その改善を積み重ねた結果、「いま本当に   この設計が一番使いやすいんだっけ？」的な感じになる   ○ たとえば Shippio だと、デジタルフォワーディングだけを提供していたときの設計が、 Any Cargo がつくられたあとに「こういう業務をするには、もっとプロダクトがこうなってたらいいのに」みたいになる  ● ほかにも、ある User Story を実現するのが目的で設計した機能が、既存の別の User Story の使い勝手を下げてしまっていたりする  ○ Epic での顧客課題解決にフォーカスしてると、そのことに気付けない or 「まあいいか、時間もないし」って思っちゃいがち  

Slide 20

Slide 20 text

Product Design Team で  チャレンジしていきたいこと 

Slide 21

Slide 21 text

Copyright © 2023 Shippio, Inc. All Rights Reserved. Shippio のプロダクトデザイナーのミッション（仮）  ● Product Initiative 達成に貢献する  ○ Epic で定義された Customer Outcome を実現できるプロダクトのありようを考える  ● ソフトウェア品質の維持・向上  ○ モノとしての最も適した形・使い勝手を実現する 

Slide 22

Slide 22 text

Copyright © 2023 Shippio, Inc. All Rights Reserved. 考え方を変えてみたい  ● デザイナーは Epic（課題）に対して解決策を打ち返すだけではなく、   ● モノ（Product）のあるべき姿としての設計をさきに定義しておき、  それを Epic とマッチさせる役割である  ○ そうすることで、変化の激しいスタートアップのプロダクトが、   その時その時の課題に過剰適合するのを防げるのではないか   ※ もちろん、プロダクトのフェーズ次第では情報設計負債どんとこいでピンポイントの課題を最速で解決するほうが重要な場合もあるはず。 PdD がどういったスタンスで臨むかは、 Product Initiatives とかの段階で PdM を含めて認識を合わせなきゃならない（たぶん）  

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Copyright © 2023 Shippio, Inc. All Rights Reserved. Pre Cycle  In Cycle  Cycle N-1  Cooldown  N-1  Cycle N  Cooldown  N  Epic 定義  6weeks  2weeks  6weeks  2weeks  Solution 検討  Scoping  Epic 定義  Solution 検討  Scoping  Spec 定義＆実装  とはいえ、3週間でいちからそんなのを考えるのはむずかしい   PdM  PdD  PdM/PdD/EM  PdD/EM 

Slide 26

Slide 26 text

Copyright © 2023 Shippio, Inc. All Rights Reserved. 3週間でいちからやるのはむずかしいので、仕組みをつくろうとしています   具体的にやっている（やろうとしている）こと   ● Customer Outcome と User Outcome の区別  ● まだ Epic になっていない使い勝手の課題を集めておく   ● モノとしてのあるべき姿を事前に定義   ● そういうことをデザイナーみんなでやる   ○ 強制的に時間をとる 

Slide 27

Slide 27 text

Copyright © 2023 Shippio, Inc. All Rights Reserved. User Outcome と Customer Outcome の区別  User Outcome と Customer Outcome を区別して、両方にアプローチする  ● Customer Outcome  ○ Shippio によって、顧客のビジネス課題がどれだけ解決できるか  ○ → Economic Value につながる  ● User Outcome  ○ Shippio を使う業務をどれだけより良く（効率的に）行うことができるか  ○ → 情報設計や Solution 評価の軸になる 

Slide 28

Slide 28 text

Copyright © 2023 Shippio, Inc. All Rights Reserved. Solution Doc のテンプレートを整備することで、強制的に User Outcome や幅広い課題に目を向けるようにする  ● 今回の設計で意識したい User Outcome を記載する  ● いま中心となって取り組んでいる Epic 以外に解決できそうな課題がないかを考えさせる  ● 既存の User Outcome とのトレードオフを記載する  User Outcome と Customer Outcome の区別 

Slide 29

Slide 29 text

Copyright © 2023 Shippio, Inc. All Rights Reserved. まだ Epic になっていない使い勝手の課題を集めておく  ● Productboard を使っている  ○ 顧客や社内からのフィードバックが Productboard の  insight として仕組みになっている（感謝）  ○ ふだんは PdM がそれを feature (backlog) に分類して、 Epic の優先順位付けに使っている  ● PdD 全員で insight をひとつひとつ読み合わせて、「どういう使い方をしていて、何をしたくてこのフィードバックをくれたんだろう」をディスカッションしている  ○ 「この課題を抽象化すると、どう表現できるだろう」という議論をよくやっている 

Slide 30

Slide 30 text

Slide 31

Slide 31 text

Copyright © 2023 Shippio, Inc. All Rights Reserved. モノとしてのあるべき姿を事前に定義  ● プロダクトの機能ごとに「あるべき姿」を先に定義しておいて、そこから切り出す形で Solution Doc をつくることはできないか？を考えている  ○ 事前にネタがあるので、3週間でも広い視点で品質高いものをつくれるのでは  ○ 「あるべき姿」は実装負荷高いものになりがちなので、どうすればうまいプロセスになるかは考え中  ● Miro に張り出されたふせんから、あるべきだと考えるオブジェクト設計を「えいや！」で描き出す  ○ デザインはいつだってシーケンシャルなものではないのだ 

Slide 32

Slide 32 text

Slide 33

Slide 33 text

Copyright © 2023 Shippio, Inc. All Rights Reserved. まとめ  ● 顧客課題の解決だけでなく、ソフトウェアの品質の維持・向上も Product Designer の責任としてもっていきたい  ● → 特定の課題に過剰適合せずに広い視点で最も適した形を考えられる体制を整えたい   ● → フィードバックに広く全部目を通すとか、それを抽象的にとらえる議論とかをデザイナー全員で頻繁に行う 