人でやるか、システムにするか（1-6／第6回）

単純な入力作業や、社内での問い合わせ返信など、プロダクト関連のよくある処理でも人が手で回しているものはないでしょうか。
それらのどこまでを人がやり、どこからをシステムとしてプロダクトに組み込むかは、PdMが決める範囲です。

ここでは実装の詳細ではなく、その判断について解説します。

システムとは

サービス提供を効率化する手段や仕組みのうち、電子化・自動化されたものを、この連載では「システム」と呼びます。

サービスの体制をシステムに置き換えていく、というイメージです。
システム側で決めることは3つあります。

この3つをもとに、何を・どのように・どれくらいシステムにするかが決まると、開発や運用にかかるコストも決まってきます。

システム化のメリット・デメリット

システム化する理由は、同じ体験を多くの人に、同じ品質で届けるためです。

システムは複製と再現性が高く、サービスもビジネスもスケールしやすくなります。同じことを大きな単位でやることに適しています。
逆に人による運用は、コストがかかる、急には増やせない、同じ結果になるとは限らない、という意味では不安定です。
なので、ITシステムがコアなサービスでは、コアのサイクルからなるべく人を取り除いていく設計になります。

ただし、カスタマーサポートや例外対応のように、複雑なことや不測の事態は定型化することが難しく、人が担う部分とセットで設計することになります。

なお、この「複雑なことはできない」は、生成AIによって少し変わってきています。
これまで手順書やオペレーションとしてフローを固めていたような業務（少し曖昧な問い合わせや文章の読み書きのように人が担う前提）だった部分も、結果の保証が要らない範囲であれば、ある程度システム側に寄せられるようになりました。
人の担当範囲が狭くなったというより、人とシステムの境目に「だいたい合っていればよい処理」という層が増えた、と捉えるのが近いと思います。

これらをふまえて、開発コストなどのデメリットよりもメリットが上回っていそうであればシステム化していくべきでしょう。

どこまでをシステムにするか

サービスの内容によって、システム化する範囲は変わります。

テクノロジーを武器にする多くのサービスは後者で、ここが事業の鍵になります。

例: ECサービスの問い合わせ

例えば、ECサービスに月1,000件の問い合わせが来ていて、そのうち7割が注文の配送状況とパスワードの再設定だったとします。
この2つは手順が決まっているので、画面から自分で確認・再設定できる導線を作れば、システムに任せられます。

残りの3割は、返品の可否やトラブルの相談のように判断が要るので、人が対応する部分として残します。
ここまでシステムで答えようとすると、システム化で得られるメリット以上に、定型化しにくい部分の開発にコストがかかってしまうためです。
また、重要度が高い問題は判断を誤ったときに信頼を損ねることもあるでしょう。

システム化の判断ライン

どこまでシステムにするか決めるのもPdMの仕事ですが、全てシステム化 or 全て人でなんとかするのではなく、第4回でお話ししたようにビジネスモデルとサービスの性質から逆算してその範囲を決めます。

システム化の優先度に迷っているものがあれば、まず人が対応している作業を「定型」か「判断が要る」かで分けてみてください。
そのうえで、通常の施策開発と同じようにROI（効果の大きさ/かかるコスト）が高いものから手を付けましょう。

ただし、人が行っている作業は単純なコストだけでは測れず、担当者どうしの力関係や、顧客からの印象なども影響します。
例えば、コスパが低いからと社内作業のタスクを自動化しないままにすれば、担当者からの印象は良くなくなり協力体制を損ないますし、ユーザーにとって面倒な処理はすぐに影響がでなくても不満を蓄積していくでしょう。
そのため、定量面でのプロダクトマネジメントの考え方をもちつつ、実際の業務では定性的な観点も意識して線を引いてみてください。

まとめ

• システム = サービス提供を効率化する仕組みのうち、電子化・自動化されたもの

• システムは、複製・再現・増減に強く、複雑なことと不測の事態に弱い

• 定型の作業からシステムに。線はビジネスモデルとサービスの性質から引く

次回は、これらを開発する際に起こりがちな見積もりの課題について解説します。

「プロダクトマネジメントわかりたい」

プロダクトマネジメントに関するnoteを週2ペースで連載してます。
よければ記事に対するリアクションや疑問、感想いただけると嬉しいです！