エンジニアがPdmっぽいことをしてた振り返り
2022年も終わり、新しい年が始まりました。
去年は仕事面では激動の年でした。
買い物代行型・ダークストア型の食品デリバリーサービス(クラシルマート)の立ち上げと撤退。その後、主力メディア(クラシル)の推薦アルゴリズムの開発チームへの異動。
デリバリーサービス時代はサーバーサイドエンジニア&Pdmとして動いていましたが、
推薦アルゴリズムチームに異動してからは、100%Pdmとして動いています。
N=2ではありますが、Pdmとして動く上での勘所が少しづつ見えてきたので、それの整理・棚卸しをします。
Pdmとしてやることって何？
端的に言うと、
与えられたミッションに対して、プロダクト開発の意思決定をすること
だと思っています。
与えられるミッションの大小や性質は、存在するPdmの数だけあると思います。事業の立ち上げがミッションだったり、休眠ユーザーの掘り起こしがミッションだったりなど。
事業としては撤退してしましましたが、
プロダクト開発の意思決定をする時に、考えていたポイントを下記にまとめます。
「やること」を発見する
ビジネス上の数値と「やること」をリンクさせる
ミッションを達成するために何か行わなければいけません。
現状のままでは、ミッションを達成することができないからです。
やることを発見するために、
自分はまずKPIツリーを作成していました。
「？」がついているノードは、親のノードに影響しているかもしれない仮説ベースの数値です。
例えば注文数は、
「セッション数」* 「注文率」(ただし最大値は注文キャパシティ)
と言うのは自明ですが、注文率は「品揃え数」や、「受け取りの容易さ」に依存するとは限りません。
このように「ビジネスに紐づく数値」と、その数値に影響する「事業としてやること」を整理すると、「開発としてやること」、「運用としてやること」が整理できるようになります。
後は、好影響を与える仮説を高い精度を維持しながら執行していきます。
問題や課題を構造化することで、表面的な解決ではなく本質的な改善を行うと、意味ある前進を生むことになると思います。
「やること」が「現在と理想の線上」にいること
やることが決まったら、それらが理想の状態との線上にあることを確認すべきです。
例えば、お客さまの注文内容を倉庫でピッキングする時、商品が欠品してしまうことがリピート率の低下につながるとします。
その際、考えられる対応が以下の二つだった場合、どちらを選択するでしょ
うか。
事業の性質や、顧客やパートナーとの関係性によって異なると思いますが、僕らは「在庫同期の正確性の向上」を選択しました。
そもそも欠品を起こさないという考えです。
僕らは仕入れから販売までを自社で行っていたので、そのフロー内の各種データを持っています。したがって、欠品を起こさないようにする事は現実的に可能で目指すべき状態です。加えて、複雑性を運用に寄せず開発のみに寄せることができます。
開発の制約になってしまいますが、
当時はシステムの設計上、リアルタイムで在庫同期を行うことができませんでした。複数の条件が重なると、とあるタイミングの注文で欠品が発生してしまっていました。
このケースは防ぎようがなかったので、方針を変えて「偽陽性在庫」、つまり在庫がないのに在庫があるように表示されてしまうことを防げるような在庫同期の方針を取りました。
これにはデメリットもあって、「偽陰性在庫(在庫があるのに在庫がないように見える商品)」が発生してしまうことです。機会損失につながってしまいます。
とはいえ「偽陰性在庫」の発生は多くなく、それによる機会損失は少なかったので、欠品が発生してしまう方が大きな損失と判断し、今回のような方針を取りました。
仮に、「欠品時の代替品選択機能の実装」を行っていたら、
在庫管理のあるべき姿から離れてしまいますし、やらない方が良い複雑な運用が発生し、全体の足枷になっていたかも知れません。
「やること」を業務設計へ組み込む
「やること」が決まったら、それを継続して運用できるようにしなければいけません。※一回やるだけで完結するものは除きます
デリバリー事業では、事業立ち上げに必要なプロダクトの設計・実装がミッションだったので、「やること」が多岐にわたって存在しました。
購買管理、債務管理、発注管理、仕入管理、商品管理、在庫管理、注文管理、配送管理、etc…
発注内容と実際に仕入れた数があっているか。
あっていない時は、仕入れは継続中のステータスなのか、買掛金はどうするのか。仕入れ先の請求書と、どのように突合するのか、、
経理に渡すデータはどんな種類のデータなのか。それを渡すには普段からどんな管理をしていれば良いのかなど、、
(仕入れや会計管理の部分は、特にドメイン知識が必要な部分でした)
***
これらの管理を、誰がどのようにどのような流れで行うかを業務設計としています。
その際に考えていたポイントがいくつかありました。
複雑なコトをどう扱うか
業務の流れにおいて、必ずどこかで複雑なコトが発生します。
複雑なコトは一定必要ですが、なるべく無くしていきたいです。
業務の複雑さと作業量は、トレードオフの関係になることがあります。
作業量としては少ないけど、やることが複雑。
作業量は多いけど、やることはシンプル。
同じ結果を産もうとしても、
複雑なコトの寄せ方によって、プロセスが変化し同時に業務の性質が変化します。
ERPとWMSを選定する際、
各システムのデータ連携をどうしたら良いものになるか考えていました。
さまざまなツールを調査した結果、最終的に以下の二つの運用になりそうでした。(ツールAを使う場合運用A、ツールBを使う場合運用B)
ツール間で公式に連携が取れていると、データ連携が自動で行えます。
しかし、こちらの要件に100%合わせた連携できるわけではありません。
例えば運用Aの場合、下記のような手運用が必要になりました。
発注と仕入れ実績の突合の際、生鮮食品のみ手動でデータを調整しなければいけない
箱買いで仕入れをする際は、手動でデータを調整してから連携しなければいけない
大体のケースでは自動でデータ連携できますが、
そこまでレアでないケースでも手運用が発生してしましそうでした。
その運用も簡単なものでなく、仕入れが終わっているものが何かを知っている必要があるなど、他の業務のステータスに依存しています。
ある業務が他の業務のことを知っている必要があると、業務が複雑になりやすく、スケールにも対応しづらくなってしまいます。
一方で運用Bは手運用が毎日発生しますが、
その作業は複雑ではなく、どのようなケースでも同じ作業をすれば良いだけです。また、仕入れのステータスを知る必要がないので、自分の業務以外の知識をつける必要がなく、本業務に集中することができます。
シンプルな作業はスケールさせやすいです。
価値がストックする等な作業だったり、人件費が賄えるのであれば外注する選択肢も容易に取ることができます。
シンプルな作業は自動化しやすいです。
自動化することで、膨大な作業量が要求されも問題なく業務を遂行できるようになります。
シンプルな作業は組み合わせやすいです。
新たな要件が発生しても、変化に柔軟に対応することができます。
結果的に、ツールBを選定しました。
巷にはたくさんのERPやWMSがありましたが、それぞれ特徴が違います。
事業それぞれに最適な運用があるように、それぞれに合うツールがあります。自分達にとっての最適は何かを考え実行していき、プロダクトが事業の成長の足を引っ張らないように努めていきたいですね。
「組織とプロダクトのスケール」に対応できること
プロダクトが事業の足を引っ張らない必要条件に、スケールに対応できることがあると思います。
エンジニアリングの面のスケールもありますが(今回は話しません)、
プロダクトの成長に伴い組織もスケールさせる必要が出てきます。
ピープルマネジメントなどもありますが、
Pdmとしてやる事の一つとして業務設計に視点を当てると、
スケールした時に、他の業務に依存せず業務を遂行できるかはとても大切な視点だ思っています。
大切だと思う理由は主に2点あります。
【1点目】
他の業務を知る必要がないので業務の難易度が下がり、人員拡充をしやすいです。これはメリットが分かりやすいですね。
【2点目】
業務の担当者がその業務の最適化をしやすい環境を作ることができ、担当者の当事者意識を最大限活用することができます。
業務が適切でない依存をしていると、「他の業務でこうなっているから、何もできない」など「私たちがこうすると楽だけど、そうすると他の業務に皺寄せがいく」といった状況が発生してしまいます。
コンビニの店長が「良かれとやったこと」が、いちいち本部に影響してたら管理が難しいですよね。
しかし、最適化をガチガチに制限してしまうと、店長ができることが無くなってしまい、コンビニの売上が上がりづらくなってしまうと思います。
現場で事業成長のエンジンをかけれるのは大きな強みです。
そこがお客さまへの価値の提供に近い部分なので、高解像度でさまざまな発見をしやすいです。
***
責務の分け方を適切に行うことは難しいですが、初期に考えきることをお勧めします。
余談 エンジニアPdmとしての強み
業務の性質を言語化できれば、技術選定も捗ります。
エンジニアに大体何を伝えれば、技術選定の手助けになるかなんとなく分かるのは良かったです。各方面のプロフェッショナルと、建設的な議論ができたかと思います。
また、アーキテクチャ考えたりクラスの設計したりする時の考え方が応用できました。
今まではインフラのレベル、アプリケーションのレベルでそれらを考えていましたが、それを事業レベルで考えられると整理が捗りました。
最後に
単純ですが「やること高精度で発見し、やり続けること」がすごく強力だと思っています。
Pdmは与えられたミッションに対して誰よりも解像度高くあり、チームのプロフェッショナルを活用できること、各分野の合理的なことを合理的だと理解できることが大切だと考えています。
今まではECや小売ドメインでしたが、今後は機械学習と推薦のドメインです。会社としても個人としても新しいチャレンジです。不確実性を楽しみながら立ち向かっていこうと思います。
個人的なネクストステップは、もう一段上げた視野で原論を持つ事と思っています。
現在は事業計画を立てるなどの負荷はかけられていません。
事業計画に則り、それが評価される時期に事業の最大値を持ってくることが重要だと感じており、市場、キャッシュフロー、投資家からの見られ方、さまざまなリスクなど様々な側面から、どのタイミングでどんな要因による最大値を持ってくるか。それをコントロールするために、事業的な意思決定の優先度を決める必要があります。
幸いなことに、坪田さんや(大)竹さんなど、経営陣と近いところで仕事ができてるので、考えを盗んだりぶつけたりする事で、その辺のオペレーションもできるようになろうと思います。
弊社には、開発出身Pdmがたくさんいます。彼らから学べることがたくさんあるので、追いつけ追い越せの精神で2023年も頑張っていきたいです。
この記事が気に入ったらサポートをしてみませんか？