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


Copyright © 2023 Shippio, Inc. All Rights Reserved. きょう話したいこと
 ● Shippio でのプロダクトづくりのプロセスと、デザイナー視点での課題感 
 ● それに対してどのように取り組んでいこうとしているか 


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


Copyright © 2023 Shippio, Inc. All Rights Reserved. 概要
 別のスライドがあるので、興味がある人はぜひ読んでみてください 
 https://speakerdeck.com/shippio/shippio-product-designercai-yong-zi-liao


Copyright © 2023 Shippio, Inc. All Rights Reserved. Shippioが挑戦するレガシー産業
 貿易業界
 Trading Inductory


Copyright © 2023 Shippio, Inc. All Rights Reserved. フォワーディング
 輸出入にまつわる各種業務の遂行
 集荷・出入庫、船積、運送、通関、保管、配達 
 クラウドサービス
 貿易業務の共有・可視化・効率化
 フォワーディングはShippioでも／他社でもOK


Copyright © 2023 Shippio, Inc. All Rights Reserved. 旅行代理店
 交通機関や宿泊先、各種チケットの手配
 クラウドサービス
 旅程やチケットの共有、チャットによる打ち合わせ
 どの旅行代理店の旅行でも利用できる 


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


Shippio のプロダクトづくり


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


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


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


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


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


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


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 定義＆実装


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


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


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


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


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


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


Copyright © 2023 Shippio, Inc. All Rights Reserved. 具体的には：ひとつの Solution で複数の課題を解決する
 Business Objective
 Product Initiative
 Epic
 Solution
 Spec
 Epic
 一石N鳥狙いたい


Copyright © 2023 Shippio, Inc. All Rights Reserved. さいきんデザイナー間でつくっている設 計原則にも、「適した形を考える」「課題 に対しての打ち返しではなく、広い視野 でデザインする。他の課題も同時に解 決できそうな汎用性を意識する」などの 意識していこうと書いています。


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


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


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


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


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


Copyright © 2023 Shippio, Inc. All Rights Reserved. まだ Epic になっていない使い勝手の課題を集めておく
 
 ディスカッションした内容は Miro でメモしておく
 なぜかデザイナー全員 iPad Pro + Apple Pencil 持ってるのでお絵 かきしながらディスカッションでき て良い


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


Copyright © 2023 Shippio, Inc. All Rights Reserved. モノとしてのあるべき姿を事前に定義
 
 議論のしやすさを優先して、この段階では Figma ではなく Miro（ホワイトボード） でやるようにしています


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