Shippioのプロダクトチーム

こちらのページの情報は、更新日：2024/2/19 時点の内容となります。

最新状態にご興味のある方は、ページ内の有料オンライン相談 or カジュアル面談から直接聞いてみてください。

Product

Shippioクラウドサービス

プロダクト概要

貿易業務や輸送ステータスの可視化を行うことで

貿易業務の効率化、脱属人化、機会損失削減を実現するクラウドサービスです。

プロダクトビジョン

Shippioでは、「理想の物流体験を社会に実装する」ことをMissionに掲げプロダクト開発を推進しています。

50年以上に渡ってイノベーションが起きていない国際物流領域のDXを推進し、デジタルの力で貿易業務、サプライチェーンの可視化・効率化を実現します。

解くべき課題

山積みのアナログ業務・属人性

非常に多くのアナログ業務が残っており、替えが効かないほどの属人化が進んでしまっていること

非効率なコミュニケーション

社内外にいる無数のステークホルダーとのコミュニケーションが、伝言ゲーム的に続いてしまうこと

不確実性への対応

予定通りに到着しない輸送、遅延のたびに調整業務等が発生してしまうこと

今Shippioがチャレンジする理由

ECの発展も含めて輸出入貨物の量は増えており、今後も増えていくと予想されています。しかしながら、日本の就労人数は減少しており、特にこの業界は若い人がなかなか入ってこない傾向にあります。

このままの状況が続くと、10年20年経った時に、島国の日本の要である物を輸出する、輸入するという業務が破綻しかねない危機感があります。

なぜこれまで変革が起こらなかったのかについては、デジタルを前提としたプレイヤーが入ってきづらい領域だったことが一因となります。

我々もスタートアップとして参入していますが、自社でフォワーディングをやったからこそ業界や事業の解像度が上がり、その知見がデジタルサービスに活きていると感じます。

ロードマップ

当社は荷主企業向けに輸出入に関する各種オペレーションとクラウドサービスをセットで提供する「デジタルフォワーディング」と荷主企業向けにSaaSモデルでクラウドサービスのみ提供する「Any Cargo」の2つの事業展開を行っています。これらの事業を推進するためにマルチプロダクト展開を行っています。

参考資料：https://speakerdeck.com/shippio/chuan-tong-chan-ye-mao-yi-nobian-ge-notamenimarutipurodakutozhan-kai-habi-ran-datuta

伝統産業「貿易」の変革のためにマルチプロダクト展開は必然だった

荷主向けのデジタルフォワーディングサービスを展開することから始めましたが、荷主の課題を解決するためには、デジタルフォワーディングだけだと解消できない部分がありました。

デジタルフォワーディングは、裏側で仲介を行うような形でコミュニケーションややり取りを効率的に行えるという点が特徴です。しかし、我々が取り扱っている案件だけをサポートしていても、貿易をスムーズに進めたり、良い物流体験を提供したりすることは実現できません。そのため、我々はソフトウェアを通じて価値を提供し、マルチ事業・プロダクト展開に焦点を移しました。

Shippioのマルチプロダクト戦略

今後は、荷主向け、社内Ops向けプロダクトのさらなる磨き込みに加えて、各物流事業者向けのプロダクト展開を考えています。

プロダクトに携わる魅力

日本が島国であるという特性から生まれる貿易のインフラをより良くしていけること、未来に繋がることを確信できることです。私たちがいなければ10年、20年後の日本の国際物流が止まってしまうことも考えられます。そのため、その強い使命感を持って仕事に取り組むことができます。

また、長年変化がなかった業務を、デジタルのみでなくオペレーションも含めてアップデートしていけることはやりがいを感じます。

以下のように貿易業務フローはとても複雑で、関係者も多く、必要な書類も多いです。島国である日本はどうしても輸出入に頼らざるを得ないことが多くありますが、その工程は熟練の手にゆだねられています。

例えば、今後新たなプレイヤーとして小規模事業者が日本から海外に進出しよととした時にはこれらのことが高いハードルになると考えられます。、そのようなハードルをなくすために、我々が無駄をなくし、誰でも扱えるように変えていき、業界スタンダードを確立することはとても意義のあることだと考えています。

多くのお客様から我々の活動に対して期待が寄せられており、膨大に蓄積された複雑な課題を、お客様や社員と一緒に紐解き、理想の物流体験を作っていけることが、プロダクトに携わる魅力だと思います。

サービスページ

https://service.shippio.io/

Team

チーム体制

プロダクトチームはCPOの下に配置され、プロダクトマネージャーとプロダクトデザイナーが所属します。現在は各5名ずつ + マネージャー1名です。

所属しているプロダクトマネージャーは、全員が世間の一般的な基準ではシニアクラスに該当すると思います。

動き方は、基本的に1名のプロダクトマネージャーと1名のデザイナーがタッグを組んで、各スクラムチームに入っていきます。エンジニアまで含めると約30名の体制となります。

プロダクトマネージャーのミッションで見ると、4人はスクラムチームのミッションに、1人はPdM Ops（オペレーションやPdMの生産性向上、仕様の品質向上など）に向き合っています。

スクラムチームのミッションや形は変わる可能性はありますが、現在のチーム構成は以下のとおりとなっています。

・Foundation：基盤やデータ連携、コア機能の安定稼働稼働、スケーラビリティを作っていくチーム

・SCO：物流事業者向けプロダクトを作っているチーム

・SG：我々のサービスを使ってより多くの貨物を取り扱うための価値の作り込みや課題解決を行うチーム

企画開発プロセス

開発組織全体での役割分担

プロダクトマネージャーとプロダクトデザイナーで、それぞれプロダクトデザインにおけるWHY(解決する問題や優先順位を決めること)と、WHAT(何をつくるのか決めて問題を解決すること)に責任を持つことにしました。

Shippioの対象とする貿易業界はとても複雑な領域です。そのため、課題の優先順位付けやソリューションの検討には、常にドメインの知識やユーザーの理解が求められます。一方、プロダクトにおけるUIデザインの作業量が特段多いわけではありませんでした。

そのためプロダクトマネージャーが「WHY: そもそも解決する問題や優先順位を決めること」に、プロダクトデザイナーが「WHAT: 問題をどう解決するかを決めること」にフォーカスできるように役割を明確にしました。

デザインプロセスの分解

Shippioではデザインプロセスを、Discovery（問題発見・優先度付け）、Design（解決策の決定）、Delivery（UI・実装）、GTM（リリースから分析）の4つのフェーズに分割しています。

一般的なフローではありますが、線状ではなくサイクル型で表現するのは、”リリースして終わりでなく、成果が出たら完了”という思想を込めて大事にしているポイントです。

参考記事：https://cocoda.design/kenjinishito/p/p36282217b0ef

開発サイクル

最近、Shippioでは1週間スプリントのスクラムをやめ、新たにBasecampのShape Up手法を導入しました。6週間の開発＋2週間のクールダウン期間（エンジニアがリファクタリングや技術研究を行う期間）というサイクルです。

Shape Up

Shape upでは6週間の開発サイクルがアップヒル(前半)とダウンヒル(後半)と呼ばれる2つのフェーズにわけられます。アップヒルではエンジニアはあまりコードを書かず、既存のコードを調べて実装方法を検討したり、システム構成を決めます。同時に、デザイナーは仕様書を書き、Figmaで画面仕様を作成します。その後のダウンヒルでは実装とQAを行い、リリースします。

6週間の開発期間に入る前に、要件やその機能が必要とされる背景をドキュメントにまとめ（ピッチと呼ばれます）、エンジニアを含むチームメンバーやマネージャーと合意をとります。

Shape Upの手法では、この段階では「太いペンで描いたスケッチ」が推奨されているので、私たちは手書きのスケッチや表示したい情報の一覧、テキストでの説明で実現したい内容を記述しています。また、ピッチを作成する時点で6週間でリリースできそうかを検討するため、エンジニアと要件を議論したり、スコープを定めます。

参考記事：https://note.com/shippio/n/nd49f55d6ac7a

カルチャー

Outcome-driven← ☓ DO

「Do」ではなく「Outcome」を意識: 常に意識は「顧客のOutcome」「ビジネスOutcome」。機能はその後。

Hypothesis & So What ← ☓ Waterfall

スタートアップは常時仮説検証。常に「今検証している仮説」を意識。

・「仮説検証」も「Outcome（So What）」を意識。「So What」がシャープでない仮説は無駄な検証になる（＝スピードが出ない）。必ず前進する。

・「仮説検証」目的のアクションをしている時は、「仮説検証」していることを忘れない（Doが目的にならないようにする）。

“Do Science” to focus on non-science issues ← ☓常に属人的な感覚で判断

・Factベース、なるべく定量で優先順位・要件を判断。

・Scienceできる80%の事柄を正しくScienceする事によって、20%のScienceできない事柄に集中する時間を確保。

なお、これらの内容は、今後プロダクトチームの人数が増えることを想定し、カルチャーを維持していくことを目的に作成されたShippioの「プロダクトデザインデッキ」にまとめています。その中では、他にも、ありたい姿や行動指針、ライフサイクルとして意識すべきこと、コミュニケーションのあり方などを定義しています。