Voicyプロダクトマネージャーのエモジマ(@kitajima_snooze)です。

音声コンテンツの会社のPMをやっているので、音声コンテンツが大好きなわけですが、最近ボクが推したいのは「ゆるコンピュータ科学ラジオ」です。

先日公開された「感情がない人はAPIとして優れているし、情報隠ぺいは正義」という回が最高だったので、これをPM的に解釈してご紹介したいと思ったわけでございます。

※この記事は、Voicy PdM Teamのマガジンにまとめられています。気になったらマガジン自体もフォローしてね！

経理部の方々は優秀なREST API

上記の放送の話をボクなりギュッとまとめると「経理専門の部署があれば、他部署の人間は会計知識がなくても、安心して経費精算ができる」と言うことになります。

経理部が経理部内でやっている中の処理や計算は、他部署から見たら何をやっているか不透明で、ブラックボックス化しています。

しかし、それでいいのです。営業部や開発部の全員が簿記の資格を取らないと経費精算ができないと大変です。

他部署の人間は、経理部から提示されたルールを守って期限までに申請を上げるだけで良いのです。
これは非常に画期的なことであり、自分の集中すべき事に割く時間を確保できます。

これをプログラミング的な例えで言うと、優秀なREST APIと言えます。
(これでピンとくる人には結構刺さると思うし、ピンと来ない人がAPIについて深く調べる必要はない笑)

APIとは、情報をいい感じに処理して返してくれるやつ

例えば、Voicyでは外部の決済代行サービスを利用して、ユーザー課金機能を実装しています。

我々のような小さなベンチャー企業は、自社でクレジットカード決済サービスを開発して堅牢なセキュリティを担保して運用するなんて出来ません。（やりたくもない！笑）

その際に、決済代行サービスが提供しているAPIを利用します。
ざっくり「いい感じに顧客情報を送ると、決済したレシートを返してくれる」といった仕組みになっています。

これにより決済代行サービスは良しなにクレジットカード決済の処理をしてくれるし、その仕組みをボクらは理解しなくても、利用することができるのです。
Voicyはレシートの情報を確認した後、ユーザーに機能を解放するだけで良くなります。

これは経理部が、いい感じに経費精算をしてくれるのとほぼ同じです。
つまり経理部は優秀なREST APIと言うことなのです。(暴論)

ルール(仕様)を決めることのインパクト

常々思っているのですが、業務上のコミュニケーションはなるべく簡潔であるべきだと思って、これは以前書いた記事でも強調しています。

ルールを守った運用を徹底していれば、認知負荷が下がり余計なことを考えずに、各々が自分の1番すべき仕事に集中することができます。

有効なルールを作ることは非常の重要です。
「誰に聞けばいいのか？」がハッキリ決まっていっていれば、問題が発生した際、解決するまでの時間が圧倒的に短縮されます。

担当者が決まっていなければ「誰に相談すれば解決するのか？を相談して探す時間」が発生してしまいます。

また「どう言う情報を渡せば、解決してもらえるか？」がハッキリしていると、より問題の解決が早くなります。

例えば、カスタマーサポート担当が「ユーザーに発生しているエラー状況を調べたい」となった場合。
「エンジニア」に相談して「該当ユーザーの登録メアド」を伝えると言う運用をルール化しておくと、非常にシンプルに課題を解決できます。

「メアドを伝える」という運用が決まっていない場合、エンジニアは「メアドを教えて？」と聞き返す必要があります。サポート担当は、思いがけずメアドを調べるという工程に入り、結果としてユーザーを待たせる事になってしまいます。

誰かに何かを相談する時に、なんの情報を渡したら解決するのか？を想定することが非常に重要になってきます。

また、エンジニアが「どのようなクエリでデータベースを検索しているか？」などをサポート担当が知る必要はありません。
サポート担当は「メアド」をエンジニアにインプットするだけで、「エラーの状況報告」と言うアウトプットを受け取ることができます。

ちょうど決済サービスに顧客情報を送ると、決済レシートを返してくれるように。
雛形に領収書を添付して経費申請を経理にあげると、給料日に支払ってもらえるように。

あらゆる業務上のコミュニケーションは定型化していくことで高速化でき、各々の得意分野に集中することができ、生産性が上がります。
また他部署から依頼を受け付ける専門部署の存在価値も、相対的に上がっていくとも考えられます。

PMは誰と何を話すか？を瞬時に想定する

プロダクトマネージャーは、あらゆる事情を加味した上で判断、意思決定をする事が求められます。
その際に「何がクリアになれば、判断が可能か？」を考え、逆算して「誰に相談したら、クリアになるか？」を想定します。

例えば「顧客課題A」を解決したいと考えます。機能を企画して開発に進めるために、
・課題の解決策として企画趣旨が妥当か？
・仕様設計は最適か？また開発期間がどれくらいかかるか？
がわかれば、スケジュールを決めてGOの判断ができます。

企画趣旨の妥当性を明確にしたい場合、顧客サポート部署と相談し、課題の共有とディスカッションを深めることで判断がつきそうです。

また、仕様設計と開発期間の見積もりはエンジニアに相談し、企画趣旨の共有と仕様書のレビューをしてもらうなどで、具体的になっていくでしょう。

誰と何を議論すべきか？議論するために必要なものは何か？を想定をスムーズにできると、意思決定が早くなり、より素早くユーザーに新しい機能を提供できるようになるのです。