エンジニアとプロダクトマネージャーを兼任 した1年間を振り返る 2023-07-28「エンジニアリングはどうグロースに貢献できるか」 @corocn

自己紹介 - ころちゃん / @corocn - Leaner Technologies のエンジニア - 岐阜からリモートワークしている Twitter X廃人です - 経歴 - エンジニア10年+、エンジニア採用6年、いろいろやってきた - 自動車 > 受託 > BtoB > CtoC > Leaner（BtoB） - Leaner入社後 - エンジニアとして5ヶ月ぐらい働く - 1年ほどプロダクトマネージャーを兼任（今日ここの話） - 3ヶ月おやすみしてエンジニアとして復帰

今日の話 - Leanerのプロダクトについて - プロダクトマネージャーの責任 - どういうアプローチで要望に向き合ってきたか

誰の向けの話？ - 事業成長に貢献したいエンジニア - プロダクトマネージャーのキャリアに興味があるエンジニア

Leanerについて

Leanerについて - “調達のスタンダードを刷新する” というミッションを掲げている会社 - 調達 = 企業の “買い物” の領域の SaaS を開発している - ユーザーは toB、エンタープライズ寄り - 現在プロダクトを2つ運営している

私はこっちのチーム

No content

プロダクトのフェーズ - 会社はシリーズAで累計10億調達 - Leaner見積 - 定量的な指標は置いてないが、最初の PMFは乗り越えた - 「いますぐ導入したい」「 Leanerがない環境にもう戻れない」 - との声がセールスやカスタマーサクセスから聞こえてくるようになって一定実感 - 自分がPMになったときはPMFは達成していなかったが、この 2年で伸びた

PMに求められること - プロダクトを成長させられるかどうか => ステークホルダーに対して約束を守れるかどうか

必要なマインド - 抽象的だが “使命感” みたいなものが大事 - プロダクトへの愛がある - 事業成長への執念がある - 他社の PM と話しても ソフトスキル > ハードスキル という回答が多い - なんだかんだ色んな職種の人とコミュニケーションするため - よく本で語られる内容とずれてるよねとは思う

その使命感はどこから - 調達購買領域は先発プレイヤーが少ない - 競合になるのは基幹システム系やオーダーメイド開発系が多い - 優れたユーザー体験を提供しているものが少ない - 自分たちがやらなくて誰がこの領域を刷新するのか？ - 良いチームでプロダクトを作っても売上や利益を伸ばせなかった経験 - 売らないと売上は立たず、いずれチームも解散することになる - ちゃんと売上を上げるところ、もっというと利益を出すところに拘りたい - その結果もって良いチームだと言いたい

約束を守る - 株式会社かつ資金調達（エクイティ・ファイナンス）をしている - ステークホルダーとの約束を守らないといけない - アーリーフェーズのサービスを使ってくれるユーザーは投資家 - ユーザーの期待にも応える必要がある - この視点があると事業責任者の意思決定にも納得できる

プロダクトへの向き合い方 ここで7分ぐらい

当時のプロダクトの状況 - 新規契約が徐々に増えてきた - ユーザーの「これじゃ運用できん」になんとか応える - 契約時に開発を約束してしまった機能がある - 3ヶ月で大きな機能を2つ3つリリースしなきゃいけない - 開発パンク気味 - 仕様もどんどん複雑に - どうしたらええんやこれ・・・（頭を抱える）

どういうアプローチで向き合ったか - わりと正攻法？ 1. 不確実性を下げる 2. やめることを意識する

1. 不確実性を下げる - 期限は3ヶ月後、時間がない - 何から着手するかで悩む - 何もわからない状態で見積もっても不正確 & 時間の無駄になる - 見積れる状態まで持っていくことが必要 - 実際に3ヶ月の最初の1ヶ月で不確実性を解消する時間にした - 勇気が必要だったが、結果的にお客さんとの約束は守られた

2. やめることを意識する A. タスクを捨てた B. バックログを捨てた C. 機能を消した

なぜやめることが大事なのか - “やらないこと” を決めるだけでは不十分 - 新機能のスコープでやらないことを決めても、既存の業務を見直すことにはならない - プロダクト機能も開発プロセスもやることが積み上がりがちになる - 意識して断捨離しないといけない - “今やってることをやめる” までちゃんと踏み込めるか？

A.タスクを捨てた - 正確に言うと メンバーを頼りまくった - 「エンジニアリングマネージャーのしごと」本でも同じような話がある - 他人のマネジメントする前に、自分をマネジメントしよう - 機能開発の優先順位をつけるまえに、自分の仕事の整理をしよう - ということで、どんどん皆に任せることにした - やりたいと思ってる人に任せるのが一番良い - なんだかんだ熱量がクオリティを左右する - 期初に「自分は何で貢献するか」「何を任せるか（やらないか）」をすり合わせるのが大事 - 評価もしやすい

B. バックログを捨てた - バックログに顧客要望が全部入っていた - めちゃくちゃな量チケットがあって混乱 - 別チケットで副次的に解決した課題も残ったまま - 最初はチケットを整理しようとしたが .... - チケットを整理しても仕事は進まないと気づいた - 頭の回転がはやくないので管理を仕事にしはじめたら終わるなと思った - 思い切って既存のチケットを全部捨てた - ファーストビューで全チケット見れるぐらいに制限したら動きやすくなった - 本当に必要な機能であればまた要望があがってくるという割り切りをして、脳のメモ リを開放した

C. 機能を消した - 技術負債の解消の前に ”仕様の負債” を解消すること - 仮説検証を繰り返していると不要な機能が残る - リファクタリングで使わない機能を考慮するのは虚無 - 仕様がシンプルになればカスタマーサクセスやセールスも嬉しい - 今のフェーズで消せなければ一生消せない - 設計をしっかりやる、使われるものをリリースするのは大前提 - 消すことに慣れておいたほうが心理的にも楽 - 某社は機能消す専門の部隊がいて、事業責任者がリーダーやってるらしい - 2ヶ月で小さいものも含めて30〜40消した - PMF前後で一番効くのはここかも

エンジニア出身のPMの強み - プロダクトの特性にもよる - toBはデータの扱いに慣れていることは明確な強みだった - System of Recordな側面を持つサービスだとデータの扱いが肝になるため - アプリケーションの寿命よりデータの寿命のほうが圧倒的に長いため - 優秀な非エンジニアの PM はデータの流れを理解するのが上手い - Why と How を繋げるのが圧倒的にはやくなる - デリバリーの速さが重要なフェーズでは武器になる - コードに触れ続けてもいいと思う - 自分の手に余るフェーズがきたらエンジニアに戻ることもできる

まとめ - 執念をもってやり抜くこと - ステークホルダーとの約束を守ること - 意識して捨てること