こんにちは。SmartHRでPMをしているhiroki_mです。
この記事は「SmartHRのプロダクトマネージャー全員でブログ書く2024」への参加記事です。25人が持ち回りで毎週記事を投稿します。ぜひご覧ください！
この企画に参加するにあたり何を書くかを考えてみたのですが、テクニカル的な記事はみんな書くんだろうなぁと思い、私は24年1月をどう過ごしたかを表に出して良い内容にまるめて書いてみることにしました。
つまりオープン月報です（ちなみに、私が月報を書き始めたのは24年1月からですガハハ）。SmartHRのPMってこんな事やってるんだなというのがすこしでも伝わると幸いです。
はじめに：私のスペック
筆者のスペックを晒しておきます。
- PM歴
- 約10年ほどやっています。SmartHRにおけるPM歴は5年経過し6年目に突入しました。SmartHR以前はtoBとtoC両方のPMを経験しています。
- SmartHRでやっていること
- 数ヶ月前から新規プロダクトの立ち上げに関わっています。昨年はディスカバリーや下準備をしており、今年から本格的にチーム組成を行い動き出しました。
- プロダクトの立ち上げと並行して、年末調整のPMチームのチーフをしています。
- 昨年までは、年末調整のPMをメイン業務としつつ、プロダクトOpsの業務や新規プロダクトのディスカバリーなども行っていたりしていました。
1月10日 見積もりはだいじ
1月9日に全社キックオフがありました。
その翌日、年始早々パワーを使う催しを行いました。立ち上げ予定のプロダクトの概算見積もりを行うというものです。
プロダクトエンジニアには、事前にユーザーストーリーに対してストーリーポイントをつけておいてもらい、当日はポイントが大きい＆エンジニア間のギャップが大きいものについて認識合わせをする＆仮置きのベロシティで割った場合どれくらいの期間がかかりそうかをざっくり見積もるという催しです。
チームとしての開発をまだ行っていないのでベロシティもまだ出ていない、作るものに対する解像度もまだふんわりしている状態で、この催しに果たして意味があるのかという懸念はあったのですが、要求される品質、機能の水準とスケジュールのバランスをどこに取るかを考える上で早めにやっておく必要があると判断しました。
結果としてポイントを付けたエンジニアの見解はそんなに大きくズレてはおらず、やることの巨大さが見えた、当人たちが何に不確実性を感じているのかが可視化できたという意味では良い催しだったと思います。
どのような結果が出たかは割愛しますが、スコープの見直しが必要なことだけはわかりました。
PMの仕事はいつでもやらないことを決めることです。
1月12日 最短距離で進めるのは難しい
立ち上げ予定のプロダクトのスクラムが本格的に始まりました。
初期の開発目標として、価値検証を行う上での最低限の機能が揃っている状態を目指すこととしていました。これは社内外からの早期のフィードバックを得るためと、不確実性の検証をしやすくするためです。
この状態にいかに最短距離で到達するかが大事なのですが、リファインメントでは「それは今かんがえなくてもよいのではないか」というような枝葉の議論に多くの時間が割かれてしまいました。
やってみて気づいたのは、初期の目標の解像度がメンバーによってまちまちだということです。このリファインメントを経て、「最低限の機能が揃っている状態に向かっていかに最短距離を進むか」をより明確にする必要があるとの意識統一がチームでなされ、わたしはあわてて意識統一をはかるためのドキュメントを書きました。最初から書いておけよ！というお叱りを受けそうです。はい、すいません。
なお、リファインメントの進行は徐々によくなってきているものの、まだまだ改善する余地が多数あります。現在進行形でうまくいく形を模索しながらすすめています。
1月16日 透明性をあげる
私は板挟みという言葉なくしては語れない時期を長いこと経験してきました。プロダクトマネージャーになりたての頃（その頃はプロダクトマネージャーという言葉自体ありませんでしたが）、私はプロダクトとビジネスの調整に四苦八苦していました。
色々経験して思ったのが、期待値調整の大事さです。
制約事項が大きいかつステークホルダーが多いプロダクトほど、期待値調整は大事です。
が、期待値調整はただこちらの状況を一方的に伝えるだけでは出来ません。現在の状態から導き出される見通し、またどういう理由で現在の状態になっているのかがきちんと説明できないと、期待値調整は出来ません。
というわけで、プロダクトの開発状況や見通しを可視化できるようにしたり（といってもまだ見れるものはありませんが）、リファインメントに持ち込む予定の機能に関するズレ埋めをビジネスのメンバと行う。といったことをはじめました。
チーム一丸でやっていきですね。
1月26日 ヒアリングは楽しい
1月後半はお客様へのソリューションヒアリングを行っていました。
幹といえる業務の課題認識とソリューション案を提示し、方向性が正しいか確認するのが目的です。
結論としては、概ね方向性に関しては考えているもので良さそう。一方で、考慮しなければならないポイントがいくつかあり、そのポイントを外すと火傷しそう。ということがわかり、有意義なヒアリングだったと思います。
それにしても、お客様へのヒアリングは楽しいです。業務と課題がクリアになってくるのと、回数を重ねるにつれお客様が言っていることの背景やコンテクストが先回りで想像できてくる感がたまらなく良いです。自分がレベルアップしてる感覚を味わえます。
とはいえ、いまだにドメイン知識が深い内容になると、まったく理解できずに思考停止になるときもあります。まだまだ知らないことだらけです。
ちなみに、わたしがヒアリングを行う際は、以下に記載したようなことを意識しています。
・課題がない人から得られる示唆が実は大きいことがある
・準備するのは質問のスクリプトではなく聞くべきこと
・相手の表情をちゃんと見る
・深掘りたい＆広げたい課題はヒアリングを数件こなしたら見直す
・相手に興味を持ち、教えていただくという姿勢を持つ
・バイアスを持たない
1月29日 プロダクトOps業務の引き継ぎ
昨年、プロダクトが増えてきた現状において、事業戦略のロードマップに対する反映とアラインメントがゆるくなってきてしまっているという課題感と、プロダクトの要望管理に関する課題感が大きくなってきたことから、プロダクトOpsが爆誕しました。
プロダクトOpsの活動範囲は、以下の図における赤い領域と緑の領域に関するもので、私はこのうち赤い領域に関する活動を行っていました。
具体的には、各プロダクトのロードマップとリソース配分をアラインするため、以下のような取り組みを半期ごとに行いました。
- 各プロダクトが解決しようとしている課題のリストに対するビジネスサイドの温度感を組織ごとに集める
- 1をもとに全社の注力リストを策定する
- 全社の注力リストをもとに各プロダクトのロードマップを見直す。ロードマップ同士の調整が必要な場合は調整する
- 各プロダクトのロードマップを賑々しく発表する
あくまでプロダクトのロードマップは各プロダクトのPMが自律的に作るものであるという前提のもと、事業戦略の反映とプロダクト間のアラインメントがしっかり行われている状態というのを目指して、上記取り組みの仕組み化を行ってきました。
この仕組みが一定形になったので後任のPMにバトンタッチを行いました。課題はまだまだあると思っていますが、ロードマップのアラインの流れができたのは良かったと思います。各プロダクトのロードマップの賑々しい発表、見てて結構ワクワクします。
そんなわけで
1月も終わってしまいました。2月も頑張るぞー。
私たちはプロダクトマネージャーを募集しています！
SmartHRでは引き続きPMの採用に注力しています。PM職に関する情報をまとめた記事がありますので、ぜひご一読ください。カジュアル面談のリンクなどもこちらに掲載しております。
