この資料の目的

自分のキャリアを振り返ってみると、PdMとソフトウェアエンジニア業を兼務することが多くありました。PdMとして業務していくなかで、エンジニアへのお願いの仕方を間違えて、想定よりも多く時間が掛かってしまうこともありました。その問題は、特に新しい技術を使って課題を解決しようとするときによくありました。

この記事では、新しい技術を試す際、現場で良くみるムダな仕事が発生しちゃってるケースを例に、そうならないよう自分が意識しているお願いの仕方を言語化してみようと思います。

よく見る良くない依頼の仕方

ケース１

PdM: 最近、XX という技術をよく聞くんだけどさ、あれでうちのサービスも良く出来ない？
エンジニア: うーん、とりあえず検証してみるんで、何ができたら嬉しいか教えてください
PdM: 何ができるか分からないからなー。とりあえず試してみてよ。良さそうだったらどう使うか考えるからさ。
エンジニア: やってみました！こういう結果になりました！
PdM: なるほどー、ありがとう！仕事で使いそうなことがあれば何か提案するわー。

ケース２

PdM: 最近、機械学習で不良品を見つける、ってことを他社でやってるらしいじゃん。うちの部署でもやってみたいからちょっと調べてみてよ
エンジニア: やってみました！僕たちの生産ラインで試したら、検知精度は75%みたいです
PdM: ちょっとうちの仕事では使えなそうだね〜。ありがとう

なんでこうなっちゃうの？

双方、エンジニアがあれこれ調査してくれましたが、成果につながらない、とても残念な結果になってしまいました。ちょっと極端に描いてしまいましたが、程度の差こそあれよく見る光景ではないでしょうか。( 僕は経験があります )

これらの問題は、扱おうとしている技術がどういうものか、そもそも何を解決したいのか、双方の解像度が低いときによく見られます。技術に関する理解が深ければ解くべき課題は定めやすいので混乱は生まれにくいですが、技術の理解が浅く、課題定義の能力も欠けていると現場はものすごいカオスになります。

そんなカオスな状態は下記の図の緑の状態にあります。こんな状況では「課題」というのもおこがましいので「何か」って言います。

これを望ましい状態に持っていくためには、「技術」と「課題」の双方から確実性を高めていくアプローチが考えられますが、初手は「課題」の解像度を上げるべきです。たいていのケースで「課題」の解像度を上げるほうがコストが低いからです。

対処方法

ケース２で、PdMがもう少し状況を深く掘り下げ、下記の情報が分かっていたとします。

出荷時の不良品は0.08%であり、これを目標値とする
生産時の不良品は0.5%
現在採用している不良品の検知システムは偽陰性が1%ある
そのため、最終的には人の目ですべて確認している
確認の際は、月ウン百万の人件費が掛かっている
不良品の見極めはルールベースで定められず
見極めには深い知識と経験を持つ工員が必要になる
現場は高齢化が進んでおり、恒常的に人を確保することが難しい
熟練工の確保や、また業務時間の増加による従業員の不満増加という面で、事業継続リスクを抱えている
なので「検査工数の削減」「検査の簡易化」などの対処が求められる

※ 設定は新聞で読んだ事例を参考にしています。ので、現場の人から見ると間違いだらけかもですがご容赦ください

ここまで把握してれば、エンジニアに仕事を依頼する前に、下記のような意思決定をできるはずです。

意思決定を事前に下した場合、PdMからエンジニアへの依頼は下記のようになるでしょう。

機械学習による不良品の検知を試して欲しい
目的は不良品検査の工数削減
精度が十分に高ければ、不良品検知の完全な自動化を検討するし
精度が十分でなくとも偽陰性が基準値未満なら検査の工数を十分に下げられるはず。
なので、「精度」「偽陰性」「カットオフ値の調整有無」の３つの観点で調査してみて

そうすればエンジニアから、下記のような回答が得られるかも知れません。

不良品の検知精度は75%程度なので、基準値に対して未達です
でも、偽陰性はx%でした
カットオフ値を調整すると精度は70%に下がりましたが、偽陰性は基準値を下回りました
不良品と判断した製品をのみを抽出した場合、検査する部品数を大幅に下げられそうです
このシステムを導入したら、不良品検査に掛かる工数が30%程度下がる見込みです
ということでやっていきましょう！

こんな感じで、仕事を依頼する前に色々ちゃんと考えておくと、良い成果につながりやすいです。

さいごに

多くの人がアイデアを考える際、課題と解決策のセットを１つのアイデアとして捉えている。しかしアイデアは本来、課題と解決策に分離可能である。思いついたアイデアは一見きれいにまとまっているように見え、発想した本人も思い入れが強くなっていることも多いが、アイデア自体を課題と解決策に分離してそれぞれを検討することでさらに発想が広がることがある。「プロダクトマネジメントのすべて」より引用。

ソフトウェア開発の経験が長いと、「課題と解決策を分けるなんて、当たり前じゃないか」と感じます。でも、意外と、驚くほどに、それらを混同して話し合ってしまっていることがあります。「うちのチームはそんなことないよ！」ってチームの場合は、きっと優秀な誰かが事前に整理してくれてるから。もしくは、チームメンバー全員が高いレベルにあって、議論が混ざらないからだと思います。誰かがそこらへん混同し始めると、意図せずみんなで混同し始めることが多くあります。そんなときに「あれ、なんかおかしいぞ」って気づいて、話を戻そうよって言える人は珍しいでしょう。ということで、PdMは「課題」と「解決策」を分け、「解決策」も複数パターン考慮した上でエンジニアに依頼すると、そこらへん混同せずに議論でき、業務がスムーズに進みます。

そもそもエンジニアにお願いする前にやれることもたくさんあります。

note.com

ということで、人に仕事をお願いする前に、自分で色々考えときましょう！という記事でしたー。