143
40

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

こんにちは。プロダクトマネージャー(PM)をしている澁田敦紀です。
この記事はリンクアンドモチベーション Advent Calendar 2021の14日目の記事です。

プロダクトマネージャー(PM)とはプロダクトを育てる役目です。そのためには、経営層などのステークホルダーをまとめ、セールスやエンジニアからなるプロダクトチームを率いる必要があります。 その幅広い役割から、「ミニCEO」と呼ばれたりします。 プロジェクトマネージャーとは異なる役割です。※兼任することはよくあります

#これはなにか
PM2年目の私ですが、有難いことに複数のプロダクトに関わらせていただき、今年一年間でも多くのエンジニアの方と協働してきました。
この記事では、私が今年一年で**”エンジニアに言われて嬉しかった言葉”を超個人的なランキング形式で紹介しつつ、
PM目線にはなりますが、私の思う
良いエンジニアとはどのような存在なのか**について書きます。

会社やチームによってエンジニアのあり方や、PMとの協働の仕方も違うと思いますが、
このような協働の形があるということを知っていただき、少しでも良いエンジニア・PM・プロダクト開発チームへの道標になれば良いなと思います。

ちなみに、私のチームではアジャイル開発、とりわけデュアルトラックアジャイルを行っています。
このデュアルトラックアジャイルについては、同アドベントカレンダーの12/25に投稿します。
興味ある方は読んでください...!

#5位 「ユーザーの声聞いてみたいです」
###開発したプロダクトを使うユーザーにまで興味を向けられる
エンジニアをしていると、目先の開発・コーディングに熱中してしまうことが多いのかなと思います。
それ自体はとても素晴らしいことです。
一方で、プロダクト開発は使うユーザーが居てはじめて意味を持ちます。
ユーザー価値まで目を向けられるエンジニアは、プロダクト開発においてとても心強いです。

また、PMは顧客の声をいかにエンジニアまで結節するか?に注力すべきと考えています。
プロダクト開発チーム全体でユーザー価値に向き合い続けられる状態を作ることが、ユーザーに選ばれるプロダクトへの近道です。

#4位 「こんなデザインはどうでしょう?」
###デザインを形にするだけでなく、一緒にデザインを考える
PMが要件を考え、デザイナーがデザインを作り、エンジニアがコードを書く
といった流れになっている開発現場は多いと思います。
それ自体は全く問題ではないです。むしろ私のプロダクトでも基本的にはその流れをとっています。

一方で、デザイナーがすべての可能性を考慮しきれるとは限りません。
PMとデザイナーがよく議論することはもちろん、
エンジニアもデザイナーと議論を出来るのが良い開発チームかなと思います。

#番外編1 「そういえばRubyGoldとりました」by フロント
###学び続け、自ら役割を広げる
フロントエンドエンジニアの方ですが、趣味でバックエンドも勉強してみたとのことで、ある日突然
「そういえばRubyGoldとりました」
と言われましたw
フルスタックエンジニアが最強であるかは私にはわかりません。
一方で、PMとしては、ある分野のプロフェッショナルと同じくらいに、様々な分野を広く見える方は有り難いです。

プロダクト開発チーム内でユーザーの課題を見つけ、要件を決め、ユーザー価値を生み出す
となると、その時々で必要な役割が変わります。
バックエンドが重たいタイミングがあれば、フロントが重たくなるタイミングもあります。
このようなときに、色々出来るエンジニアの方がいるとチーム体制に自由度が生まれ、開発速度が上がります

何より、日々新たな挑戦をしているエンジニアの方は、きっとどうにかしてくれるという信頼を置けます。

#番外編2 「どうでもよい話なんですが」
###雑談などでコミュニケーションをとってくれる
私は、PMは孤独だなと感じることがあります。
PMの役割は多くの人と協働することではありますが、同じ目線で同じ悩みを共有できることは中々ありません。
そうなると誰かとチームとして肩を組んでいるような感覚を失ってしまうこともあります。

弊社では、"Gather"というコミュニケーションツールを使っており、チーム内での議論や雑談を垂れ流しています。
エンジニアの方々が今困ってる実装についてわいわい議論してるのを聞いてると羨ましいなと思ったりします。

同じ悩みは共有できずとも、趣味の話や最近あったことなどの雑談をしていただけると、親近感が生まれます。
PMに話しかけてくれるだけでも本当に嬉しいです。

また、タスクの話ばかりでは仕事をこなすだけのチームになってしまいます。
私は、そのようなチームに良いプロダクトは作れないと思っています。
チームを明るく盛り上げ、チーム力を上げてくれるエンジニアは、チームとプロダクトを変えます。

↓現在メインで所属してる2チームのGather部屋です。チームの雰囲気に合わせて私が作りましたw
image.png
この部屋の中で議論や雑談を行っており、リモートでもオフィスで仕事をしているような感覚で業務できます!

↓Gatherが気になる方はこちらへ

#3位 「作ってみました」
###より良いプロダクトのためにやってみる
要件にもデザインにもない開発を勝手にしてしまう
そう聞くと問題児に聞こえるかもしれませんが、とてもありがたいです。

もちろん勝手に顧客へリリースするわけではありませんw
開発用の環境にデプロイして「これあったほうが便利かと思って作ってみたので触ってみてください」が出来るエンジニアは中々出会えないと思っています。
百聞は一見に如かず、「作ってみました」から実際にリリースしたものもいくつもあります。

これを行うためには、以下のようなハードルがあると思います。

  • プロダクト理解(ビジョンやユーザーなど)
  • 作りたいものを作れるスキル
  • 勝手に作っちゃう茶目っ気
  • 勝手に作ることが許されるチーム など

私は、エンジニアの素晴らしい提案やスキルはもちろん、ユーザーのことを考えての実装であれば勝手に作って触ってもらおうというチームの文化を作れていることが嬉しかったです!!!

#2位 「このサービス本当に良いですね」
###ビジョンに共感してくれる
プロダクトはユーザーの課題解決のために存在しています。
そして、その背景にはプロダクトのビジョンが存在します。
それは、作りたい世界です。
このビジョンへの共感度合いこそ、プロダクトづくりのエネルギーになります。

ビジョンへの共感がないエンジニアにとって、大切なのは以下のようなものです。

  • 工数・コスト
  • 納期
  • 技術レベル
  • ユーザーがタスクを行えるか など

もちろん、極力少ない工数やコストで短納期にユーザーがタスクを行える最小限のものを作ることは重要な観点です。
しかし、それだけでは作りたい世界は作れません。

ビジョンに共感することでこのようなことを考えられるようになるはずです。

  • ユーザーの課題が解決されるか
  • ユーザーに良い体験を届けられるか
  • この実装がこのプロダクトぽいか など

このような思考を通して初めて良いプロダクトが作れると考えます。

エンジニアが、自分の価値観にあった、ビジョンに頷けるプロダクトを見つけることは中々難しいと思います。
自分では案件を選べない場合は、尚更その難易度は上がります。
それでも私は、自分がビジョンに共感できるプロダクトの開発に携わるべきだと思います。
それが自分自身のためにもなると思うからです。

また、PMはビジョンに共感してくれる仲間を集めることが最も重要な役割の一つです。
PM・デザイナー・エンジニアなどの役割を寄せ集めたチームと、ビジョンで束なったチームとでは、
プロダクトづくりにおけるチーム力が全く違います。

#1位 「なんで作るんでしたっけ?」
###目的立脚で開発を進める
Why-What-Howはよく言われますが、

  • Why:要件定義書に書いてあったから
  • What:要件定義書にあるもの
  • How:頑張ってコーディング

で開発をしていては、良いプロダクトは作れません。
では、Why-What-Howはどのようなものなのか、

  • Whay:誰をどんな状態にするか
  • What:どんな体験を届けるか
  • How:どのような方法で提供するか

抽象的になりがちですが、ここらへんが程よい落とし所かなと思っています。

多くの開発現場では、PMが書いた要件定義書からデザインや設計書が作られ、実装に入っていくと思います。
そのような明確に上流下流が分離された開発では、
エンジニアは"How:どのような方法で提供するか"に目が行きがちです。
もちろんそれ自体が悪いわけではありません。適切な"How"を思考し、作り上げるのがエンジニアの役割です。

しかし、適切な"How"のためには、"What"や"Why"をしっかりと知っておく必要があります。

だからこそ、盲目的に与えられたタスクをこなすのではなく、
「なんで作るんでしたっけ?」と**"Why-What-Howの接続"**を意識できるエンジニアこそ、
良いプロダクトを作る開発者だと思います。

また、PMは、エンジニアやデザイナーを含む開発チームが
**"Why-What-Howの接続"**を意識しながらプロダクトづくりが出来るような仕組みを作らねばなりません。

#まとめ
最後まで読んでいただいた方、ありがとうございます。

私は、良いプロダクトは良いチームからしか生まれないと思っています。
そのチームを作るのは、PMであり、エンジニアであり、チームの全員です。
エンジニアとしての技術を伸ばすことは大切だと思いますが、
プロダクトづくりにはそれと同じくらい、もしかしたらそれ以上に大切なものがたくさんあります。

この世界に良いエンジニア・PM・チームが増え、そして良いプロダクトが生まれることを願います。

143
40
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
143
40

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?