サービス開発の施策に納得できない時にエンジニアができるアクション - $shibayu36->blog;

サービスの開発をしていてPMから施策案が出てきた時、ソフトウェアエンジニアとして施策案が本当にユーザーのためになりサービスの成長につながるか納得できないことがある。 このような時にただ文句や愚痴を言っても何も始まらない。エンジニアからも何らかのアクションを起こし施策を前に進める必要がある。 そこでエンジニアができるアクションについて、自分が思っていることを書いてみる。 納得できないケースは大まかにどのようなものがあるか 納得できないケースでは大まかに2つのケースがあるのかなと思っている。 (1) 施策をしたい目的や仮説自体に納得できていない (2) 施策の目的や仮説は良いが、それを達成する手段に納得できていない 1つ目は、たとえば「ターゲットとしているようなユーザーって本当にいるか？」「ユーザーにこういう課題があると言っているが本当にそういう課題があるか？」「この指標に繋がると言っているが

[shiba_yu36]

目的自体に納得できていない・手段に納得できていないの2つに分けて、自分がよくやっているアクションを書いてみました

[dot]

「大前提: 施策の草案を作ってくれた人に敬意を持つ」コレめちゃんこ大事なのわかるけど、同じ人から何度もしょうもない施策が出されると先入観が形成されるし、トラブルになる時はだいたいそういう文脈が存在する。

[koogawa]

“大前提: 施策の草案を作ってくれた人に敬意を持つ” これが一番大事だったりするよね

[kamm]

納得できないことは伝えるし、別の提案もしたりしても、最終的にはしぶしぶ作業する。（もっと上が決めたことを、PMに言ったところで無駄なことは多々ある）　Xのエンジニアは大変だろうなと思う

[shibainu1969]

施策案決定のプロセスに入れるようにした方が良いと思う。ひたすら会議してようやく施策が決まったら、エンジニアから反対が出てやり直しは時間の無駄。

[poliphilus]

一応言うが引き下がらないことがほとんどなので、気にしないで引き受けて、作ったものが実際まったく役に立たなかったら「ほーら言ったじゃんね」と思うだけ。ギャラは支払われるので（笑）

[sigwyg]

施策に対する責任はPMが持つ、という前提を鑑みれば安全圏から石を投げているに等しい。一方で「エンジニアの観点から意見を出す」ことは大事。「注告はした」というスタンスで、あまり拘らないのが吉かなと。

[taku-o]

自分はそれをやった結果のお金への影響で、対応切り替えてる。お金は強い。お金が動くなら、その意見には反対しない。お金が動かないならそれを理由にして反対するけど、通るかどうかは別

[juneboku]

Amazon Leadership Principles にある「Disagree and Commit」の Disagree ってのは、まさにこういうふるまいのことを指していると思う。

[s-wool]

なぜ納得できないのか明らかにしておくの大事。

[luccafort]

“たとえば「ターゲットとしているようなユーザーって本当にいるか？」”これは思うことがある。が結局自分自身もそのユーザがいるのかいないのか検証してないし、ちゃんとデータで殴り合うのが大事だよね。

[yasuharu519]

とてもいい言語化だ...

[syu-m-5151]

とても良い言語化すぎる…。

[sonots]

流石です

[yamadadadada2]

大体の機能は「営業がそれを約束して受注しちゃった」で作られる

[naari_3]

ソフトウェアエンジニアとしてでも、本当に価値を出すのであればビジネス周辺のドメインについても詳しくある必要はあるし、「ギャラはもらえるから」で済ますのはその姿からかけ離れているように思う

[chuff_chuff]

“何らかのアクションを起こす前に大前提がある。それは施策の草案を作ってくれた人に敬意を持つことだ。”

[omega314]

まあ、「ほら言った通りだろ」とか「ざまあ」とか「もう遅い」とか期待しだすと心が腐るので（てか結果論・後知恵だし）、そうはならないようにする。本当に納得できないなら半端に関わらず身を引いた方が健康に善い

[ledsun]

そうなのよね。大抵の場合は、エンジニア側の背景知識が足りてない（ので、目的に納得できていない）。エンジニアリング的な提案をする（or される）のは、背景知識を共有できたあと。

[diveintounlimit]

数値を出したところで客観性が欠けた人には何も響かないし何も変わらないという悲しい事実がある。

[uva]

「施策をしたい目的や仮説自体に納得できていない」or「手段に納得できていない」

[nilab]

「サービスの開発をしていてPMから施策案が出てきた時、ソフトウェアエンジニアとして施策案が本当にユーザーのためになりサービスの成長につながるか納得できないことがある」

[xKxAxKx]

前職ゲーム開発だったんだけれどめちゃくちゃ分かる。提案出しつつ最終的に「まあ、やるけど...」って折れることが多かった。ディベロッパーだったんで、結局パブリッシャーの移行に沿わざるを得ない、という。

[ya--mada]

そもそもコミュニケーションが無くて終わっとる組織なのでは？

[kojimamasahiro]

普通に言われた通りにつくる（見積もりする）か、自分が施策を考える側に周るかじゃないのかな？

[bonoumamire]

落とし所がわかるエンジニア

[kazoo_oo]

常にこうありたいな。それがオーナーシップってもんだよね。

[a-know]

良い

[hatfatcat]

これをやってもダメな時のアクションも知りたい。

[everybodyelse]

納得できていなくてもやってみてやはりダメだった、と確認することも大事なお仕事なので、一通りこちらが話して変わらないなら、自分たちの納得関係なくそのまま実装しちゃうかしら。状況にもよるけど。

[okbm]

売上に責任持って施策して、その結果給料に反映されるなら文句言っていいと思う。そういう立場にないなら大体がわがまま

[twox]

「施策に対する責任はPMが持つ」って末端には空虚な言葉だなと思う。責任って言っても実際にはただとっとといなくなってお荷物の面倒を見るのは残った人達だし

[s_oshikawa]

出す側からすると別にその通りである必要はなくて、可能な限り個別具体的であるほうが意見をもらいやすいからそうしてる。もちろん意見を聞かないのは論外たが。

[hkanemat]

そう。最初から喧嘩腰はよろしくない（お互いに）

[nkazuki]

PMを批判せずに前向きに建設的にというのが一貫していて素晴らしい

[hdampty7]

「手段を実装する概算工数を知らせる」結構ね、現場離れてる人とか、こういうの言いがちなんですよ。概算が簡単にできるような規模の施策ならやっちゃえばいいのよ、最初から。負債が大きい時に悩ましいのよね。