2024年も、もうすぐ終わりますね。
今年は全然アウトプットができてなかったのですが、今回の年末年始休暇は運良く長く比較的時間を作れたので、滑り込みで振り返りをアウトプットしておこうと思います。
はじめに
新卒から20年弱、エンジニア領域を中心に仕事をしてきました。
プログラマーからキャリアをスタートし、DBA、プロマネ、EMと、 いわゆる作る側 のロールを中心に歩んできています。
そんな私が、2023年の後半から、PdMという いわゆる考える側 （探求する側）のロールを担当することになりました。
プロダクトづくりに対して、ロールが変わったことによる視点の違いから改めて気づいた点について、備忘録的にまとめてみます。
作る側 や 考える側 という表現は、視点の違いをイメージしやすくするために便宜的に使った表現となります。
いたずらに対立構造を助長したいわけではありません。
あくまで、 私の 視点の違いを表現として分けたかったため、ご理解いただけますと幸いです。
この記事で書かないこと
「〇〇はこうすべき」「△△はしてはいけない」といった強い主張は書きません。
もし、そう読み取れてしまっても、あくまでも 私 が感じたことを書いているだけだとご理解ください。
再認識した大切なコト５つ
視点が変わっても、改めて大切だな〜と感じたことを５つに絞って書いてみます。
その１：「なぜ？」を言語化する重要性
さっそく 「そんなもん、ロール関係なく社会人なら当然じゃないか！」 と言われそうですが、再認識したことのお話なのでお許しください。
開発チームと会話する中で、「ここ、こうしたいんだよね」「AじゃなくてBにしたい」って思うことがあります。
そんな時、「なぜ、そうしたいのか？」「なぜ、AではなくBなのか？」を、しっかり言語化して伝えることが大切だと再認識しました。
しっかり論理立てて背景を説明することで、開発メンバーに納得して取り組んでもらえますし、副次的な効果として「〇〇って背景を考えると、BよりB'の方が良いと思うけどどうする？」といったように、考えつかなかった案を提案してもらえることもあります。
顧客への提供価値を考え、言語化し、未来に渡ってそれを提供していく こと。
それこそが「なぜ？」を言語化する目的の一つであると感じます。（余談ですが、「未来をポジティブに」っていい言葉ですよね。）
その２：顧客の声は大事。でも、盲信しない。
役割的にも、個人的な興味関心としても、商談同席やフォローアップMtgに同席することも圧倒的に増えました。
やっぱり現地現物・生の声は非常に大切ですし、ありがたい機会です。
幸いにも素敵なお客様に恵まれていて 「この機能が良い」「ここは〇〇にしてほしい」と良いフィードバックも課題のフィードバックもいただくことができています。
しかし、新しい価値提供のタネになることもあれば、ご意見ご要望への対応を見送らせていただくこともあります。
それは、担当プロダクトが 特定領域向けのホリゾンタルSaaS であるというサービス特性があり、フィードバックをすべて対応していると個別最適（誰かは使いやすいが、他の誰かは使いにくいサービス）につながるリスクがあるためです。
プロダクトビジョンや提供価値の評価指標と照らし合わせて判断をすること、やるべきではないことを「やらない！」と断言することが求められているため、 顧客の声は大事。でも、盲信しない。 を大切にし続けたいと思っています。
強い言葉で表現するならば、 ムダなものを作らない という言葉に表すことができそうです。（余談ですが、「ムダ排除に全力を」っていい言葉ですよね。）
その３：役割分担は大切
チーム内のロールと組織図上の責務がマッチしていないこともあると思います。
現状、私たちのチームもご多分に漏れずそのような状況ではあります。
とは言え、環境を嘆いていても何も始まりません。その環境でどうすることが大切か？です。
スヌーピーさんも
You play with the cards you’re dealt …whatever that means.
と仰っていますしね。
と、言うことで、私たちのチームでは、大きくは私と開発チーム、細かくは人単位で役割分担をしています。
役割分担というとセクショナリズムのような線引に聞こえてしまうかもしれませんので正確に表現すると、 誰が何についてオーナーシップを持つか？ を明確にしています。
少人数のチームであるため、「PdMはこれだけ、開発チームはこれだけ」といったように簡単な線引をしてしまうと、スピードが出ないため、私たちはあくまで オーナーシップ を明確にしています。（余談ですが、「チームであれ」っていい言葉ですよね。）
細かい分担は割愛しますが、ザックリ表現すると なぜ作るか？何を作るか？ を私（PdM）がオーナーシップ、 どのように作るか？ を開発チームにオーナーシップを持ってもらっている状況です。
この領域は自分がオーナーシップを持つ という1つの指針が、日々の迷いを減らして行けると感じます。
その４：越境の大切さと越境のマナー
前述の通り少人数のチームであることと、オーナーシップを持つ領域を定義している私たちのチームであっても、役割を越境していくことって大切だな〜と思っています。
「これ、なんでこうなってるんだろう？」
「これ、AじゃなくてBじゃダメなのかな？」
といった疑問があれば、そのまま放置しないことが大切です。
オーナーシップだけではなく、フォローワーシップを持って、役割を超えてコミュニケーションができるか？って、良いプロダクト開発チームか？の一つの指標な気がします。（余談ですが、「自らがチームの主体であれ」っていい言葉ですよね。）
私たちのチームは、 少人数チームが故に生まれたあうんの呼吸で、この越境がうまく機能してきた と感じています。
ただ、越境と越権って紙一重だな〜とも思っています。
相手に対して配慮ないアプローチ・表現をしてしまうと、 良かれと思っての提案が、ただの批判に聞こえてしまう こともあります。
そうすると、本来不必要な争いが生まれたり、排他的なセクショナリズムにつながったりと、チームがワークしなくなってしまうので注意が必要ですよね。
その５：「作って終わり」ではない。作って始まる。
情報を集め、そこから思考して、仮説を立てて、ものづくりをする。
そして、顧客に提供する。
一連のフローを一周すると一定の達成感もあるので、一区切りとして次のことに目が向き始めます。
理想を追い求め続ける限り、課題がないは無い と言われたりもしますし、ドンドン新しい機能を提供していきたいという思いも大切です。
ただ、提供した機能が課題解決につながっているのか？は検証しなければいけません。
定量・定性の両面で分析して、検証することが大切です。
分析したり、検証する中で、思ったほど価値提供できていないと分かることもあります。
辛いですよね。
頑張ってきたことに対する徒労感とか、価値提供ができていない現実の全てを忘れたくなって、赤羽で昼から飲んで、飲んで、酔いつぶれたくなっちゃいますよね。
分かります。その気持ち。赤羽行ったことないけど。
赤羽で飲んで酔いつぶれても、新橋で愚痴をこぼしても、過去と事実は変わりません。
ただ、未来と解釈は変えることができます。
事実（情報）をもとに、思考して、仮説を立てて、改善していく。
それが大事だと思います。
身近にいる優秀なエンジニアが 勝つまで続ければ勝率100%っす！ って言っていました。
作って終わりにせず、改善を続けて勝率100%を目指すことって大事だなって思います。（余談ですが、「失敗を称え、失敗に学べ」っていい言葉ですよね。）
もう一点補足をするとすれば、狙い通りに価値提供ができた場合でも、「なぜ、この機能は思い通りに価値提供ができたのか？」を考えることも重要だな〜と思っています。
まとめ
この1年 いわゆる作る側 から、 いわゆる考える側 に変わったことで、プロダクト開発というものに対して見る視点や見方が変わった部分も多くあり、心地よい刺激とともに過ごした1年でした。
一方で、 視点が変わっても変わらない価値観 （大切にしたいコト）にも気づけた1年でした。
将来、もしかしたらまた違う考え方を持つことになるかもしれませんが、少なくとも2024年の年末時点で感じた振り返りとしてはこんな感じかな〜と思っています。
来年はどんな年になるかに期待しながら年越しを迎えたいと思います。
残り少ない2024年ですが、みなさま良いお年を。