LiBz Tech Blog

LiBの開発者ブログ

プロデューサ・プロダクトマネージャに頼られるエンジニアについて考える

はじめに

社内の会話で一緒にサービスしたいならどんなエンジニア?という話があり、プロデューサ・プロダクトマネージャ目線で欲しいと思うエンジニア像を社内で話していたものを書きます。

サービスを作るフローについて

まず「どんなエンジニアが頼られるか?」の前にサービスを作るフローについてまとめます。

①期初に目標設定

②目標を達成するために○○すればいいのでは?という仮説を立てる

③仮説を検証(企画→開発→テスト→リリース後の分析)

④成功!

⑤目標達成!
f:id:gac777:20190829173340p:plain

そんなうまくいきません・・・ 実際は f:id:gac777:20190829133032p:plain 仮説・検証を何度も行って、「仮説が正しい!」を繰り返しサービスを成長させていきます。 そのため、検証の数を増やせるエンジニアが頼られるエンジニアになります。

「検証」「仮説は正しい」を多くするためには?

  • 検証からの仮説は正しいの率を上げる(野球でいう打率)
    • 主に企画時点での規模感の分析など
  • 検証の数を上げる(野球でいう打席数)
    • 開発側の開発工数・企画工数 の2つがあります。 この中でエンジニアが特に影響を与えるのは「検証の数を上げる」になります。

プロデューサ・プロダクトマネージャーが頼るエンジニアは??

ある仮説に対して 1ヶ月開発かかるエンジニアA と 3日で終えるエンジニアB がいたら、プロダクトマネージャは迷いなくエンジニアBと一緒に仕事がしたいです。 (もっと欲求いうなら、今後の変更も加味した実装が出来ると凄い)

検証の数を上げるためには??

  • 企画が出来たら「要件」を理解し、工数を最小に出来る仕様変更を提示し設計する
    • 企画立案時はてんこ盛りな機能が入っていたりしまが、しっかりと企画の要件を確認すると実際はそこまで必要ではない機能がたくさんあることもあります。
  • 企画の時点でエンジニアが入り、企画が終わると同時に開発の設計まで終わっている
  • 設計では変更に強いシンプルな状態を担保する

学習と行動

  • 企画に対して理解をする
    • 本当にこの機能は必要
    • この機能はどう使われるの?(ユースケース)
    • この機能の目的は?
  • サービスのコードを把握する
    • サービスの全体のコードを把握することで、この機能は○○の仕組みを使えば簡単に実装出来る

番外編:企画をより理解するためのポイント

サービスの提供する価値はたくさんありますが、その中でも

  • うちはサービスは他社よりも○○なんです。
  • 1個しか選べないなら何を選択するか?

を意識すると良い企画、あれ?っていう企画もイメージ付きやすくなります。

番外編:どの技術を使うか?

この議論はすごく難しいと思いますが、「検証回数を上げる」という思想で決めるべきです。
技術選定をする時に「取得難易度」・「その技術を使える人数」なども検討にいれないといけないです。
「もうこの技術飽きた」「新しいのを使ってみたい」といったエンジニア欲求での検討はやめましょう
(やるならプライベートの時間でやったあと、必要かの判断が出来る状態で。)
誰に「その技術にした理由はなんで?」に適切に答えられるような判断をしましょう。
(↑はエンジニア面接含めて色々な企業で聞かれる面接質問です)