エンジニアから プロダクトマネージャーへの 一年目のガイドライン
「エンジニアからプロダクトマネージャーへの一年目のガイドライン」を書く目的
現在プロダクトマネージャのようなことをやっているためのまとめになっています。
現時点で完全なガイドラインではないもののやっていることをまとめることで自らの仕事をよりよくしていくことが目的です。
この記事の内容は僕だけでなく僕の会社のメンバーやアドバイザーの方などと一緒に考えたものやアドバイスを含め始めたものです！
また、プロダクトマネージャと書いていますが、正式な僕の役割はチームリーダーなのです
Twitterやってますので、よかったら絡んでください〜！(@entaku_0818)
自己紹介
遠藤拓弥と言います！
母がエンジニアなのでエンジニア になりましたって100回くらい言ってます。
ネットワークエンジニア ->サーバーサイドエンジニア ->モバイルアプリエンジニア-> PMと言うようなキャリアです
現在はCBCloud(https://cb-cloud.com/)で運送会社向け業務支援システムSmaRyuTruck(https://smaryu.town/truck/)を創るエンジニアチームのリーダーとして働いています
プロダクトマネージャとは？
プロダクトにおいてプロダクトマネージャの役割
よく一般的に言われるプロダクトマネージャの役割は下記の画像があらわしていますね。
つまりプロダクトに関する全てなんですが、一人で全ての役割をこなすことはとても難しいです。
私のプロダクトにおける役割
今のプロダクトで僕の一番の役割は主に要件定義からデザイン、エンジニアリングに関する部分のまとめを行っています。
なので、今回まとめるnoteの範囲もデザイン、エンジニアリングに関する内容が中心となります。
* PdMとマインドセット
* PdMと意思決定の見える化
* PdMとデザイン
* PdMとエンジニアリング
PDMとマインドセット
マインドセットとは？
マインドセットと言ってもたくさんの捉え方があると思います。
noteで拝見したことのあるクラシルPdMの奥原さんのこの箇所がとてもよくあらわしていると思うので、引用させていただきます。
まず、PdMとはどのような存在なのか。一言で表すならば、「プロダクトの成長に責任を持つ人」です。
上の記事では「愛」だとか「執念」だとか抽象的な概念が語られていたりしますが、それが一番重要だと思っています。PdMは結構泥臭い役割です。プロダクトを成長させるためには、何でもしますというスタンスが求められていると思っていて、自己犠牲的である時もあると思います。思うように上手くいかない時もあるでしょう。最初は自分の無能さに毎日絶望に浸る時期もあると思います。
その中で諦めず、プロダクトを成長させるために自分を今何をすべきかを考えて実行していくためには、愛するということ、執念深いことが必要不可欠だと考えています。
マインドセットと自身の壁
マインドセットについて書かせていただきましたが、いきなり視座が上がり必要なマインドセットを備えることは難しいことだと思います。
私の場合の話をさせていただきます。
私は自分の特徴としてエンジニアのキャリアを積んでいることだと考えています。
元々エンジニアだったため、「プロダクトの成長に責任を持つ」に注力することがなかなかできない状態だった。
これを自分なりに分析してみた結果はエンジニアは成果物が定義されている。つまり自分がやったことが見えやすい状態になっていると考えた
当初僕が自分の役割を考えたときに`コードを書かずにエンジニアとしての価値を発揮できるのか？`と思いました。(実際全く書いてないことはないけど)
今までエンジニアとして仕事をして、エンジニアとして評価されている人間がいきなりマインドを大きく変えることはとても難しいものでした。
このマインドを変えるために今僕が参考にしているのは下記のPotcastで話している内容です。
人間が人間に指示を出すのではなく、人間がコンピュータに指示出すようになっていき、より抽象的な仕事や問題をコンピュータができるようになっていく。
そうなると、かつての部長職や課長職のように抽象的な目標を達成することを一般社員がやるようになる。入社後、最初にやる仕事がかつての部長と同じ仕事になる。
そのうち人間はビジネス的な仮説を立てるのが仕事になり、ソフトウェアを書く人と仕様を書く人が一緒になっていく。
この話が正しいかどうかはわかりませんが、僕は今すごく腹落ちしている内容で、この考えを基に自分の考え方やマインドを整理しています。
PdMと意思決定の見える化
プロダクトにおいて多くの意思決定が必要となります。
意思決定の事項がなぜ、どのような背景で行われたかを明確にし、プロダクトに関わるメンバーの目線を合わせておくことで、
その意思決定事項が不明確であったり、確かな理由が無い物はプロジェクト全体を迷わせてしまうことになります。
===
7/XX
===
参加者 XXX、XXX
ゴール
- 〜〜〜〜〜〜〜〜〜
- 〜〜〜〜〜〜〜〜〜
- 〜〜〜〜〜〜〜〜〜
決定事項
- 〜〜〜〜〜〜〜〜〜
- 理由:〜〜〜〜〜〜〜〜〜
- 〜〜〜〜〜〜〜〜〜
- 理由:〜〜〜〜〜〜〜〜〜
宿題
- 〜〜〜〜〜〜〜〜〜
- 〜〜〜〜〜〜〜〜〜
まぁかと言って議事録として目新しいものはここには特にないと思います。
全ての会議の前に決定したい事項まで明確にあると良いです。また決まらないと進まないことも多いので、今日何を決めなきゃいけないのかを正確に言語化しておきます。漏れていると後で痛い目を見ます。
PDMとデザイン
僕はデザイン時に意識していることはデザインの議論事項と決定事項とその理由を明確にしておくことをしています。
- そのデザインで達成したいこと
- 達成するため案とメリデメ
- 後から異なる案も選択できるようにしておく
- 黒は決定事項、緑は検討事項的にわかるようにしておく
またFigmaのデザインは基本的にデザイナーの方にコンポーネント化して、もらっていて、私の方でも簡単な変更をできるようにしています！
弊社ではFigmaを導入し、これらのデザインを誰もが見えるようにしています！
PDMとエンジニアリング
エンジニアリングとは？
改めてエンジニアリングとは？と問われると難しいですね。。。
仕様を考えることなのか？システムの設計をすることなのか？はたまたコーディングをすることなのか？
私がエンジニアリングについてもっともよくあらわしていると思う言葉は「エンジニアリング組織論への招待」で書かれている下記の言葉です。
実現のために不確実性の高い状態から不確実性の低い状態に効率良く移していく過程の全てのことです。
この不確実性を無くしていくことがエンジニアリングであり、様々な方法で不確実なものを無くすことが重要だと考えています
実現方法
デザインと大まかな仕様が決まったタイミングで、仕様を書きます。
まず大枠の仕様について下記のようにまとめます。
ここでは、何故と何をの部分を明確に書いて、この機能によって何を達成しなくてはならないのかを明確に書くようにしています。
- 目的
- なぜこの機能をいれるのか？
- なぜこういう仕様にしたのか背景
- 仕様説明
- 機能詳細
- 入力文字系のルール、正規表現
- ステータス別の分岐
- 実装の考え方
- その他
またこれを補足するようにテスト仕様書を作成し、デザインと仕様だけでは補えない部分をテスト項目で確認するようにしています。
またエンジニアと1on1を下記の形で実施し、プロジェクトにおける問題を排除しようとしています。
特に拘っているところはアクションを明確にすることです。
====
xx/xx
====
- 困っていること・気になっていること
- 最近うまくいったなと思うタスク
- 目標振り返り
- なんでも話したいこと
- 最近やったこと、やりたいこと
- アクション
この1on1での質問事項は下記のスライドを参考に作らせていただきました！
最後に
ここまで読んでいただきありがとうございました！
繰り返しになりますが、上記のことは私だけでなくチーム内外のメンバーによって助けられながら実施できています！
また、これは完全なものではなく、考え方やり方は僕自身いつも見直していきたいと考えています。
ご意見や深く話したい内容ありましたら、お気軽にご連絡いただけるととても嬉しいです。
年末にまた内容をアップデートして投稿したいと考えています。
参考
こちらの方々のnoteを参考に書いています！
いつも大いに参考にさせていただいてます！ありがとうございます！
この記事が気に入ったらサポートをしてみませんか？