サービスの開発をしていてPMから施策案が出てきた時、ソフトウェアエンジニアとして施策案が本当にユーザーのためになりサービスの成長につながるか納得できないことがある。
このような時にただ文句や愚痴を言っても何も始まらない。エンジニアからも何らかのアクションを起こし施策を前に進める必要がある。
そこでエンジニアができるアクションについて、自分が思っていることを書いてみる。
納得できないケースは大まかにどのようなものがあるか
納得できないケースでは大まかに2つのケースがあるのかなと思っている。
- (1) 施策をしたい目的や仮説自体に納得できていない
- (2) 施策の目的や仮説は良いが、それを達成する手段に納得できていない
1つ目は、たとえば「ターゲットとしているようなユーザーって本当にいるか？」「ユーザーにこういう課題があると言っているが本当にそういう課題があるか？」「この指標に繋がると言っているが、繋がる理由がわからない」といったものだ。
2つ目は、たとえば「目的は良さそうだけど、課題解決の手段になっていなそう」「この手段を実装しようとすると半年かかってしまうため、施策のインパクトに見合わないのでは」といったものだ。
それぞれアクションが全然異なるので、アクションを起こす前に何に納得できないかについては自分の中でちゃんと言語化しておくと良い。
ではこのような時にどうアクションすると良いだろうか。
大前提: 施策の草案を作ってくれた人に敬意を持つ
ここで話が少し逸れるが、何らかのアクションを起こす前に大前提がある。それは施策の草案を作ってくれた人に敬意を持つことだ。アクションを起こすにあたって、喧嘩腰で行動する・嘲笑気味に行動するなど、敬意のない形で提案しても何も進まないことが多い。
まず第一に敬意を持ち、相手は自分の知らなかった情報を持っているからこの施策案が出ているのではないかなどと考え、謙虚な姿勢で臨むと良い。
目的や仮説自体に納得できていない時のアクション
自分がよくやっていることを2つ挙げてみる。
目的や仮説について質問する
ここが間違っているのではないですか？みたいに正論をぶつけるのではなく、施策の目的や仮説がより明瞭になるように質問を繰り返す。以下のような部分が明らかになるように質問をしている。
- どういう層のユーザーが
- どの程度の人数がいて
- そのユーザーたちはどういう課題を感じていて
- 課題を解決することでどういうユーザー体験となり
- その結果サービスのどの指標にどの程度繋がるか
仮説の妥当性が精緻に検証されている必要はなく、まず言語化してもらうことが大事。言語化できれば、エンジニア側でその仮説の妥当性を事前に検証することもできる。
仮説の妥当性を示す数字を出す
仮説が言語化されているなら、エンジニア側でその妥当性を数字で出してみると良い。自分が納得できていない部分が「対象ユーザーの数」なのであれば、その数を調べることで仮説の妥当性が検証できる。
この時、フラットに検証するように心がける。納得できない時は反証を探してしまう傾向にあるが、自分の直感に反して仮説が妥当ならそれで良いのだ。
達成する手段に納得できていない時のアクション
こちらも2つほど挙げてみる。
手段を実装する概算工数を知らせる
施策案が膨大な規模になっていて実装工数が大きすぎると感じた場合は、PM視点では工数が大きいとは思っていなかったというすれ違いが発生していることが多い。そういう場合はエンジニア側で概算工数を出すことで、PMが再検討しやすい状態にできる。
目的を達成する最小のスコープを提案する
概算を出した上で、目的を達成する最小のスコープをエンジニアから提案しても良いだろう。最小スコープの提案はエンジニアの得意領域だと思う。たとえば「ブログのアクセス数をグラフィカルに時系列で可視化したい」みたいな施策案があった時、「まずは直近7日のアクセス総数を出すだけで仮説を検証できませんか？」と提案するようなものがあり得る。
この時、PMにとって手段の中のどの部分が重要と考えているかを先にヒアリングしておくと、より良い提案になるだろう。
提案するときは以下のポイントを押さえておくと良い。
- なぜそのスコープで目的を達成できると考えているか
- そのスコープだと、ユーザー体験としてどういうデメリットがあり得るか
- 施策案として提案された手法と比較して、どの程度実装工数が異なるか
まとめ
サービス開発時に施策案に納得できない時にエンジニアからどうアクションを起こすかの例を記事として書いてみた。端的にいうと、何が納得できないかを自分で言語化し、施策案を考えた人に敬意を払って、前向きに提案すると良い。
