PMに必要なスキルとは？新卒が1年を通して感じた4つの要素

こんにちは！ラクスルでプロダクトマネージャー（以下、PM）をしています平光です。
17卒の新卒として入社し、1年とちょっとが経過しました。
今日はこれまでの振り返りと学びを紹介しようと思います。

ラクスルにおけるPMの役割とは

ラクスルでは、要件定義からストーリー分解、スプリント / 長期の開発計画、受け入れテスト、サービスのリリースまでをPMが担います。
チームによっては、システムの設計にPMが入って議論したり、ワイヤーやデザインをPMが行うこともあります。開発チームによって求められる役割が異なりますが、チームに足りない部分を自分がカバーするかもしくはリソースを調達することで、サービスのリリースまで進めます。

役割が異なることによって幅広い業務に関われることはPMをやっていて楽しいですね。

課題設定が甘く優先順位が付けられない

入社してまず関わったのがラクスルのカスタマーサポート（以下、CS）チームが使う管理画面の機能拡張、再構築です。とはいえ、入社前にPMとして働いた経験があるわけもなく様々なことに戸惑いました。

例えば、

「機能一覧を書き出したり、実際に使う人にヒアリングして課題を書き出したりするもののどこから手をつけてよいかわからず優先順位が決められない」
「今のシステムがどのように作られているかわからず工数の見積もりができない」

大きなシステムだったので課題を把握した後、エンジニアと会話しながらスコープを小さく区切って開発していくのがよかったなと今になって思います。

シニアPMのもとで3ヶ月修行

約半年CSチームのPMをした後、ジョブローテーションの一環で発注基盤や物流などに関わるチームに異動しました。

シニアPMのもとペアワークをしながら、設計、ストーリーの作り方、プロジェクト管理、優先順位決め、エンジニアとのコミュニケーションなどについて学びました。
※ラクスルでは、ペアプログラミングだけでなく、場合によってはデザイナーやPMがペアワークをすることもあります。

この3ヶ月間で特に、ストーリーの作り方、分解の仕方について勉強になりました。

ストーリーは基本的なユースケースを満たせる幹となる部分から順に作り、その後エッジケースにあたる枝葉の部分のストーリーを書いていきます。

そうするとおのずとMVPから順にプロダクトを作っていくことが可能になります。

簡単な例ですがブログ投稿機能を題材に書いてみました。
ブログ投稿なので、ブログを投稿できるまでの必要な機能は幹となる部分ですね。
公開設定機能などは、ブログを投稿できるという要件に対してマストではなく、枝葉となる機能なので運用していく中で必要となったら開発。みたいな判断ができるかもしれません。
要件を考えれば考えるほど肥大化していきますが、開発リソースは限られているので本当に重要な機能かを見極めるのは大切だなというのを感じました。

また、ラクスルでは多くのチームで As / Given / When / Then… のGherkin記法を用いてストーリーを書きます。
ストーリーの書き方については過去の記事でも紹介しているので気になる方はそちらを見ていただければと思いますが、僕が実践している中で最も重要に感じたのはテスト可能な単位に小さくストーリーを分解することです。
そうすることで、工数の見積もりもしやすくなりますし、PMの受け入れテストもやりやすいです。
結果的に、見積もりが正確になっていると想定スケジュール通りに開発を進められるはずです。

プロダクト開発部のPMへ

その後、メインPMとしてスピードチェック入稿の商品拡張やマイページのリニューアルなどのプロジェクトに関わります。

デザイナーやフロントエンドエンジニアとプロダクトのデザインについて密にコミュニケーションを取り始めたのはこのタイミングが初めてでした。
また、属人的なテストを脱してテストを自動化するなどの守りの施策も重要だと認識したのもこのタイミングが初めてでした。
一歩引いた立場で全体を俯瞰し守りの開発も適度にプランニングできることも重要だと感じました。

1年を通して感じたPMに必要な要素

入社時は「PMの役割ってなんだろう」「PMのスキルセットってなんだろう」と思っていましたが、この1年を通して少しずつそれが明らかになってきた気がします。

現状と課題を把握するためのドメイン知識
プロジェクトを進めるコミュニケーション
意思 / こだわりを持って意思決定する
プログラミング、デザインへの理解

上記4つ、僕がPMに必要だと思った要素です。
一つずつ簡単に解説すると。

現状と課題を把握するためのドメイン知識

ドメイン知識が薄いと結果的に課題設定が甘くなり、プロダクトをリリースしてもエンドユーザーに使ってもらえなかったり、評価がいまいちだったりすると思います。

印刷 / データチェックの知識ももちろんですが、エンドユーザーがどうラクスルを使っていて何を課題に感じているのか、オペレーターが管理画面を使っていて何が使いづらいのかということを把握するのが大事だと思います。

プロジェクトを進めるコミュニケーション

プロジェクトを進める上で、エンジニア、デザイナー、顧客対応をするCSチーム、印刷委託先などなど多くの人が関わります。密にコミュニケーションをとらないとヌケモレが発生したりリリース直前でどんでん返しが発生してしまいます。特にエンジニアやデザイナーなどのプロダクト開発に直接関わる人たちに対しては、なぜそれが必要か？その課題に対して考えている解決方法が最適か？といったプロジェクトの意義について共通認識を持っておくことが特に重要だなと感じます。

悪い例だなと思うのは、JIRAなどのチケットに書いてある要件とかだけのテキスト中心のコミュニケーションしてしまうこと。
逆にいい例だなと思うのは、実際のUIや処理の流れの図を示したものをボードに貼るなどして、「ここに〇〇な機能が必要」「ここは〇〇の条件分岐で出し分ける」などを話すこと。そうすることで全体のゴールイメージの共通認識が持てるので、考慮漏れも発生しづらくなると思います。

意思 / こだわりを持って意思決定する

「この機能は初回のリリース時点では外そう」といったことが往々にしてあります。
開発工数の兼ね合いやリリース日との兼ね合い、または関係各所との調整で当初のスコープから変更をしたり、リリース日を調整したりすることがPMにはあると思います。そうした意思決定や判断ができてプロジェクトをとにかく前に進めていく力が必要です。

また、プロダクトや機能に対するこだわりを持てるともっと自分自身楽しくなるよ。とシニアPMからフィードバックをもらいました。

プログラミング、デザインへの理解

PMはエンジニアやデザイナー、ビジネスの人とのハブになっていることが多いです。
エンジニアとコミュニケーションをする上でもプログラミングへの理解があると「こういうやり方はどうか？」「こっちのほうが工数は少なくできそう？」といった話ができると思います。また、開発工数の見積もりもより正確にできるかと思います。デザイナーとのやり取りも同様です。

とはいえ、チームや会社によるのかなとは思います。
「PMにプログラミングスキルは必要か」というテーマの記事や勉強会を耳にしますが、やはり知見はあったほうがいいなと僕は感じます。