これは ビットバンク株式会社 Advent Calendar 2020 の 23 日目の記事です。
はじめに
どうも皆様こんにちはこんばんは。ビットバンク株式会社のmonmon09です。アドベントカレンダーのエントリーのほとんどがテック系ということもあり、味変もかねてエンジニアからPdMになった話をmonmon09さんの個人的な思い出の垂れ流しでオナシャッス！とのことでしたので、やっていこうと思います。
では参りましょう。
お品書き
- 先に結論
- ¥100と100の違いは
- 酒量を弁えることは重要だと思う
- サービスを愛するがゆえに
- プロジェクトマネジメントの衝撃
- 物事を成功と失敗に分けて考える必要があるのかな？
- おわりに
先に結論
読んでいただいている方は忙しい方も大勢いらっしゃると思いますので、先に結論を簡潔に書いておきます。
- サーバーサイドエンジニアとして開発をしていた
- 凄腕プロジェクトマネージャーがやってきて、その手練手管に衝撃を受けた
- 俺にもできる！と思ってプロジェクトマネージャー（PjM）やってみた
- 上手く行ったこと、上手く行かなかったこと含め場数を踏んだ
- 開発をより良くするためには要件の段階でエンジニアリングの知識を持つ人が関わる方が効率的だと考えた
- 要件段階からビジネス側と絡むためにはプロダクトオーナー（PO）がいいんじゃないかと思った
- 自分のピープルマネジメントに限界を感じ、意思決定機能とピープルマネジメント機能を明確に分けた
- プロダクトは良い感じになったが、企画段階の問題はシステム的な負債として残った
- 良いプロダクトを作るには要件段階ではなく、企画段階から関わることが最も効率的だと考えた
- 自分のキャリアで企画段階から関わるならばプロダクトマネージャー（PdM）がいいんじゃないかと思った
- 今も試行錯誤している←いまここ
なぜこの心持ちに至ったのかについては10年を語る必要があるので、読み物として面白そうなエピソードをピックアップして紹介していきたいと思います。
¥100と100の違いは
私の初めてのHello World!は2008年の4月で、折しもあのリーマン・ショックまであと5ヶ月というタイミングでした。右も左もわからんド素人の私に開発なんてできるわけもなく、日々技術書を写経したり、先輩方のMTG議事録を作ったり、雑用的な調査をしたりして1年を過ごしました。その後の2年は派遣SEとして日々VBAと戯れておりました。
当時、部長に私の長所と短所を教えてください！的な話をしたことがあります。その時部長は少し考えて「俺が始めに¥100って書いて、その後社員の人たちが¥100って書いているのに、君は100って書くでしょ？100円を表す意味としては正しいよ。だけど見てる人はそういうところも見てるんだよ。君の長所は100って書けるところだし、短所は¥100って書けるのに100って書いちゃうところだよ。」という話をしてくれました。今、振り返るとなるほどなと思います。
自らの正しさには価値があるかもしれませんが、その正しさは万人にとっても価値があるとは限りません。立場が変われば見方も価値観も変わります。そういった多種多様なステークホルダーの想いをプロダクトの成長に上手く生かしていくこともプロダクトマネージャーに求められる機能の一部なんじゃないかなと思ってます。
酒量を弁えることは重要だと思う
iPhone4発売から約1年経過した2011年の夏頃ソーシャルゲームの業界に転職を果たしました。当初はサーバーサイドエンジニアとしてJoinしましたが、10数名の小さな会社だったのでありとあらえる仕事が落ちて（？）ました。ここぞとばかりに「私やります！」的な感じでサーバーサイドの開発だけでなく、企画からイラスト・サウンド発注、進捗管理、と手を広げ多忙を極めました。そして1年で燃え尽きました。。。自分の酒量を弁えずに酒を飲むのは危険ですね。
無理をして限界突破すれば一時的に大きな成果をあげることはできるかもしれません。ですが、それは元気の前借りや需要の先食いといった言葉で表現される状態と似ていて、持続性を持たせることが非常に困難ですし、下手すると限界突破する前よりもスペックが下がってしまうリスクも孕んでいると思います。
資本主義の原理的に言えばプロダクトは常に成長し続ける必要があります。プロダクトを常に成長させていくにはコミットしてくれるチームと共に試行錯誤し、プロダクト・チーム・自分それぞれが一緒に成長していくこと。その成長によって飲める酒の量を少しずつ増やしていくこと。こういったスタンスが大切なんじゃないかと思います。
サービスを愛するがゆえに
燃え尽きてから1年後にECサービスのサーバーサイドエンジニアとして無事社会復帰を果たしました。Joinしたチームはサービスが提供しているコンテンツに対してかなり愛着を持っているメンバーが揃っていました。ニワカだった私に「そもそもxxxxという作品の根底にある文脈はxxxxで....」と語り出すと止まらない。そんなメンバーばかりのチームでした。なのでサービスに対しても愛着を持って日々の開発をしていたと思います。もちろん私も同じで、自分の書いたソースコードが動いているサービスが可愛くないわけないですよ。
ですが状況は常に変化するものです。当初は牧歌的だった開発も会社からの期待度が上がり予算が上がると、それに比例する以上の成果を求められるようになります。プレッシャーが限界を超えた時、私たちが取った手段は自分たちの都合を通し他チームの都合を否定することでした。もちろん非合理的に自分たちを優先したわけではありません。私たちから見れば合理的な理由に基づいてはいたんです。ですが都合を否定された他チームからしてみればあまり気持ちの良い状況ではないとおもます。
愛ゆえに排他的になる・・・自分たちを守るために攻撃的になる、追い詰められて視野が狭くなる的なよくある話だと思います。愛は盲目ってことですね。
数年後に「あぁ、こういうことだったんだ」って気づきを与えてくれたブログに出会ったので、それを貼っておきます。
プロジェクトマネジメントの衝撃
とある終わりの見えない炎上プロジェクトに関わっていた際にPMP（Project Management Professional）を持っている凄腕のプロジェクトマネージャーがプロジェクトにJoinしました。彼はこの終わりの見えない炎上プロジェクトを終結させるために大ナタを振るい、見事リリースに持ち込みました。
私は幾度となく彼と仕事終わりに飲みに行き、彼が用いたあれやこれやを聞かせてもらいました。その理路整然とした知識体系、彼が用いた手練手管、背後にある哲学。どれをとっても衝撃的でした。今まで自分がいかに無手で困難に立ち向かっていたかを理解し愕然としたと同時に、これを自分のものにしたいと考えました。
その後PjMとしていくつかのプロジェクトに関わりました。その時の彼ほどではないですが、それっぽくやれるようになったのではないかと思います。プロジェクトマネジメントの知識体系や経験はかなりポータブルなスキルだと思いますし、マネジメント層の方はインプットしておいて損がないスキルなので、是非インプットしてみてください。
物事を成功と失敗に分けて考える必要があるのかな？
私のキャリアは開発メンバーから始まって開発チームのリーダー、PjM、POと徐々にビジネス側に近づいてきたわけですが、プロダクトマネジメントを目指した直接的なきっかけを強いてあげるならば、以前一緒に働いてくれた方の何気ない一言だったと思います。
その方と一緒に働いてた時のことを肴にランチしてたんですが、私が「あの時のプロジェクトは成功だった」とか「あのアプローチは失敗だったなぁー」的な話をしていた時にこんな話をしてくれました。
「monmon09君ってさ物事を成功と失敗に分けて考えるよねー。俺はさ成功と失敗ってある時点の状態を評価したものでしかないと思うんだよね。物事にはいい状態と悪い状態があって、時間や環境の変化と共に良くなったり悪くなったりするんじゃないかな。悪い状態なら少しでも良い状態に、良い状態ならばより良い状態になるようにする。少なくとも俺はそう考えているよ」
言われてみれば当たり前のことだと思うのですが、正直かなりの衝撃を受けました。個人的には短いスパンで物事を捉えると二元論的な思考になりがちなので、短期/中期/長期それぞれのスパンで構造的に思考するように気をつけたりします。
世情や環境の移り変わり、プロダクトの状況、会社や社員の方々の状態、多くの変数があるとおもいますが、それをプロダクトという切り口で計測し、特定のタイミングの結果にもコミットしつつ、中長期的な目的達成のロードマップを示して、関係者全員に「今私たちはここにいる！次はここまで行こう！」と伝えていくことがPdMに求められる機能なのではないかと思います。
おわりに
いかがだったでしょうか。文字にしてみると案外不可解な意思決定の結果としてエンジニアからプロダクトマネージャーへロール遷移をしたんだなぁと思いますが、その時々の私は結構真剣に悩んで答えを出したはずです・・・（多分）
こんな経緯でPdMになったんだなぁとか、こんな心持ちで日々プロダクトに向き合ってるんだなぁということをフワッっと知っていただければ幸いです。
