Shippioのプロダクトデザイナーが向き合っている課題
こんにちはShippioのプロダクトデザイナーのしんぎょうちです。
先日よしおかが、Shippioのプロダクトデザインが今おもしろい理由をこちらの記事で書いてくれました。
この記事では、プロダクトデザインの設計として、プロダクトデザインチームが今向き合っている課題についてより具体的に書いていこうと思います。
Shippioのプロダクトデザイナーが実際にどんなことをしているのか、貿易のSaaSを作るにあたって何をするのか、知っていたければ幸いです。
また、ここに書いていることは、他の会社でも結構あるあるなんじゃないかと思うので、似たようなことで悩む皆さんにはご笑覧いただければと思います。
レガシー産業でプラットフォームを作る
プラットフォームというと、いろんなプレイヤーがみんなアクセスできて、情報を共有・編集できて、誰とでもコミュニケーションできて…みたいなのを想像しませんか？
貿易のプラットフォームでは、集まるプレイヤーの関係性が様々なので、みんながアクセスして仕事をできるようにするためには、乗り越えないといけないハードルがいくつもあります。
いろんな役割のプレイヤーが関わるので、公開していい情報ばかりじゃない
たとえば、Shippioでは商品情報や取引先のマスタを管理できますが、個々の案件に関わる情報として個別のアイテムを共有するのは良くても、マスタ全体を共有することは避けたいといったケースがあります。
また、金額情報もコンフィデンシャルで、以下のような事情があったりします。
フォワーダー（輸送の代理店）の受注金額を運送会社に公開しない
商品の仕入額は、同じ社内でも別の部署には共有しない
公開していい情報だけクラウドサービスに登録したらいいんじゃないか？とも考えられますが、それだとExcel等での既存ツールによるクラウドサービス外での二重管理が発生してしまい、業務効率化の効果が半減してしまいます。
しかし逆に、プレイヤーによって細かく情報を出し分けると、誰に何が見えているか把握できなくなって、それはそれでよくわからなくなりそうなんですよね…
どうやってそのあたりを整理するか、みんなが情報セキュリティに安心して使えるようにするか、を考えています。
フォワーダー(代理店)を介さずに特定のプレイヤー同士が直接コミュニケーションをとることは避ける
国際物流の手配は、たいていフォワーダーと呼ばれる代理店が間に入って手配を行います。フォワーダーは荷主のために、船や飛行機、トラックの運送会社とやりとりをして手配を行います。
業界慣習として、フォワーダーが手配している案件でも状況によっては荷主が運送会社に直接コミュニケーションをとるといったことが起きうるのですが、トラブルを防ぐためになるべく避けるべきです。
また、荷主からしても、本来はフォワーダーにまるごとお任せしているので、トラック運送会社とフォワーダーのやりとりは不要な情報であり、ノイズとなるので見えないほうが良い、という考え方もあります。
会社によってNG/OKのラインが違うので、基本的には
まずフラットでオープンに作り、使ってもらえるユーザーからフィードバックをもらいながら少しずつ調整
という方向でやっているのですが、すごい事故が起きるとこわいので、事前にどんなリスクがあるかはちゃんと把握しておく必要があります。
プレイヤーによって見たい情報の粒度や視点が違う
Shippioのプロダクトは、「シップメント（船積み）」というオブジェクトを中心に作られています。シップメントとは、1回の船に乗せる貨物を表す単位です。
海上輸送や通関は船積み単位で手配されるので、フォワーダーとのコミュニケーションにはシップメントを中心に行われます。したがって、このオブジェクトが基本になるのは妥当なのですが、実際にはもっといろいろな単位があります。
コンテナ
納品はコンテナに対して行うので、納品管理をしたりトラックの手配をする場合はコンテナ単位で管理するのが理想です。
発注・受注
物流は倉庫から出荷するところから始まりますが、「貿易の取引」という観点では、海外の会社と品物を受発注するところから始まります。
そのため、荷主の多くは受発注から可視化・管理したいと考えています。
商品
荷主の会社の、物流担当者以外のプレイヤーは、自分が配送を待っている商品がいつ届くのかに関心があるケースが多いです。
「ある品物を海外から輸入する／輸出する」ことについて、それぞれのプレイヤーが見たい単位で情報を登録したり、取得できるようにするにはどうするか、というのは情報設計の大きな課題です。
それぞれのプレイヤーにとっての「あるべき物流体験」を作る
前述したように、Shippioのユーザーにはいろいろなプレイヤーがいて、それぞれにやりたいことが違います。
荷主に対してのコンセプトの違うサービスの体験統一
Shippioは荷主（輸出入したい会社）に対して2種類のサービスを提供しています。
国際物流の代理店事業（デジタルフォワーディング）
手配はShippioオペレーターが行うので、荷主は入力作業などをほとんどやる必要がない。もろもろShippioにお任せ。
輸送を自由に管理できるプロジェクト管理ツール的なクラウドサービス（Any Cargo）
他のフォワーダーに依頼している案件を自由に可視化できる。必要な情報は全部自分たちで入力する。
どちらも輸送案件として同じようにクラウドサービスで管理ができるのですが、荷主からすると「同じオブジェクトなのにできることが違う」といった状態になってしまっています。
サービスのコンセプトが違うのでそれでも問題ないとも言えますが、「荷主としてのあるべき物流体験」という視点では、何か目指すべきものがあるはずです。
そのため、次のように、物流事業者にとってのあるべき体験を作りながら、同時に荷主にとってのあるべき体験を作り、体験統一をしようとしています。
「物流事業者にとってのあるべき物流体験」を作りながら、物流事業者と一緒に「荷主にとってのあるべき物流体験」を作る
最近Shippioでは、物流事業者向けのサービス提供を開始しました。
物流事業者が必要な機能を設計し、クラウドサービスに載せていく必要があるのですが、それは同時に、
物流事業者が荷主に理想的なサービスを提供することをサポートする
ことでもあります。
上で書いた「荷主にとってのあるべき物流体験」とは、他の物流事業者の皆さんを巻き込んで実現していくものだと考えています。「荷主にとってのあるべき物流体験を提供するための物流事業者向けの機能」です。
また、物流事業者の業務効率化を目的とした機能であっても、荷主にとってどう見えるのか、両面から考えていくことになります。
たとえば、先日クラウドサービスのチャットに「メンション機能」をつけようと検討したのですが、物流事業者目線では「メンション忘れ／漏れ」が、物流事業者起因での情報の伝達漏れに繋がる恐れがあるとして、見送りになったりしました。
このように「一見良さそう、すごい普通」に見える機能でも、別の視点から見ると重大な懸念があったりもするので、機能を実装するか、どのような設計にするか、検討に時間がかかることが多いです。
これらの問題を解決したら、何が良くなるの？
物流部門の人や物流事業者は今、あらゆることのしわ寄せを受ける立場にあります。
たとえば海運状況はずっと不安定です。半年ほど前ですが、スエズ運河が通れないためにパスタが届かないニュースがありました。
他にもパナマ運河が水位不足で通れなくなったり、悪天候やストライキなどで港の営業が止まってしまったり、そういう大きな問題がなくても船はよく遅れます。
それにも関わらず、商品の欠品や、材料の不足による工場の稼働停止というのは、事業成果に直結するので、ギリギリまでがんばって防がないといけません。物流は「届いて当たり前」と見なされがちで、物流事業者にもその期待がそのまま来るので、物流関係者全員が大きな負荷を受ける、という構造になりやすいです。
また同時に、物流部門や物流事業者の仕事はまだ非効率になってしまっていることも多く、日々業務に忙殺されています。大企業の物流部門の方は、商品がちゃんと届くか心配で、休日も心が休まらないといった話も聞きます。
欠品まで起きてニュースになることは稀ですが、それは企業の物流部門の人や、フォワーダー・物流事業者の人たちが日々起こる問題に対処してなんとかしているからなんですね。
だから、Shippioのプロダクトによって、もっと仕事が効率化され、何が問題が起きてもすぐわかるし、対処もすぐできるというようにしたいと思っています。
他にも解決したい、実現したいことはたくさんあるのですが、そのうちの一つがこの現場の負担、非効率さです。
いろいろ書いてきましたが、大変であると同時にとても楽しくはあります。作業時間が減ったり、対応漏れが減ったというお声をいただく時もあり、少しずつではありますが物流の現場を良くするのに役立っていると思えます。
もしShippioでデザイナーをやることに興味が出てきた人、こういうプロダクトデザインの悩みをもっと話したい人がいたらカジュアル面談でご連絡いただけると嬉しいです。
また、今度こういったことをお話しするイベントをやるので、よかったら来てください。
この記事が気に入ったらサポートをしてみませんか？