これは Livesense Advent Calendar 2022 DAY 3 の記事です。

3行まとめ

オライリーの「プロダクトマネジメント」は、とても良い本だった。
しかし職務経歴書を書くときは、基本的に終わりのあるプロジェクトごとに書く
良いプロダクトを作りたいと思いつつ、職務経歴書を書きづらくなるのでは？と思ったので、解決策をひねり出してみた（が、自信はない。模索中）

プロダクトマネジメントは良い本

とても頷きながら読みました。

この本のサブタイトルにある「ビルドトラップ」とは、機能を作ること（アウトプット）だけが評価されるが故に、その結果（アウトカム）を見れなくなってしまうことです。

その頷いた部分をつらつらと書いてみますと

基本的にプロジェクト単位で進む仕事
作った機能の効果測定がおざなりになる
プロダクトマネジメントという仕事を学ぶ方法がとても少ない
問題ではなくソリューションに恋してしまう
UXはプロダクトのごく一部のはずがUXと連呼してしまう
判断基準として使うための戦略ではなくカッチリとした計画を作ってしまう
不幸な人たちは素晴らしいものを生み出さない
毎年恒例の11月になるとパニックになって翌年のことを予測する行事

心が痛くなります。

プロジェクト単位ではない、プロダクトがユーザーや顧客、そして売上や利益、そういったアウトカムにどれだけ貢献しているかを見ながら開発していく。素晴らしいことです。この本の内容を各現場に落とし込む必要はあると思いますが、誰でも上に書いたようなトラップに引っかかったことがあると思います。

機能を実装するのは楽しいし、自分が考えた機能が目の前で動いているのには満足感があります。プロジェクトだと区切りがあるので、終われば達成感があり、打ち上げをすれば盛り上がります。しかし、その後、そのプロジェクトで実装した機能はどうなったでしょう？ちゃんと使われているでしょうか？……自分で書いていて苦しくなってきました。

読みながらそういったことを考えていると、プロダクトマネジメントに注力していくことの重要性がわかってきました。

しかし職務経歴書はプロジェクトがないと書きにくい

プロダクトマネジメントを読んでいて、アウトカムを重視することが大事なんだなと考えているとき、別の問題が浮かんできました。
それは職務経歴書をプロジェクト単位で書いていることです。

プロジェクト単位で書いていくと、企画や開発などの、どの段階から入って、どういう役割をして、どういう結果になった、という一連の流れが書けます。言語やフレームワーク、ライブラリなどの技術選定をし、どういう問題が想定して、どのように実装したかが、すんなりと書けると思います。起承転結としてまとめられます。何より「結」、すなわち終わりがあります。

しかし、ある一つのプロダクトを開発していているときに、必ずプロジェクトに入っているわけではありません。法律が変わったり、バグが見つかったり、何かイベントがあってそれに必要な対応をしたり、ちょっとした既存の機能の改善したりと、様々な対応を日々こなしていると思います。そういう状況は、アーキテクチャの刷新とか、新しいフレームワークでの再構築とか、そういった大きな意思決定をするわけでもなく、いわゆるプロダクトの「保守・運用」と言えると思います。

企業にすでに十分な収益をもたらしているプロダクトであれば、この保守・運用はとても重要な仕事で、これをちゃんとやれる人材というのは、それなりに貴重である、というのが個人的な認識です。過去の実装を考慮して創意工夫する余地もあるし、テストをちゃんと書き続けることや言語やライブラリのバージョンアップを地道に続けていくことも大事です。プロダクトは時間が経過すれば必ず複雑になっていくものなので、技術的負債ができるだけできないように、むしろ品質を改善していけるような仕事をしている人は、貴重で得難く、採用も難しい人材です。

しかし、自分の仕事がプロダクトの保守・運用中心になったとき、もちろん開発はしているし、コードも書いているし、バグを取ることも大事な仕事であることもわかっている、が、ふと職務経歴書を書くときに、どうやって書けばいいのか？という疑問を持ってしまったのです。
あるプロダクトをずっと保守・運営していると、どこかで飽きがくるのも、こういう状況を避ける本能的なものなのではないか？などと、突拍子もない仮説まで考えてしまいました。

解決策を検討してみる

正直なところ、過去自分がプロダクトを保守・運用してきた身として、どう書くかを考えていたのですが、あまり思いついていません。

例えば、あるプロダクトの開発チームのリーダーとして運用を任されたとして、職務経歴書を書く内容を考えてみると、

事業成長系
- 売上・利益を伸ばした、もしくは新規事業であれば作った
- 不景気や競合プロダクトの大幅な成長があったなどの状況が悪かったが、売上・利益を落とさなかった
- そのプロダクトの業界でシェアを伸ばした
技術系

といった感じになるでしょう。

事業成長系だと、何かプロダクトの問題を発見しそれを解決した結果になると思うので、それはそれで分析から実装、その後の成果までを書けばよいのだと思います。
ですが、そういった分析や成果の効果測定といったことは、開発者ではなく、プロダクトマネージャーに任せてしまいがちなところはあると思います。なので、自分の成果として書いて良いものなのか、少し悩むかもしれません。
そこはプロダクトマネージャーが企画したのであればそれはそのように書き、開発者としての助言したことや、それが成果にどのような影響を及ぼしたのかを書けば、すべて自分の手柄にするよりは誠実と言えるだろう、と思いました。

技術系は、プロジェクトとしてくくり出しやすいので職務経歴書には書き出しやすいかもしれません。ただ、本を読んでいて気になった点としては、これらは非機能要件になりがちなので、アウトカムを重視していると軽んじられてしまうのではないか、という危惧はありました。事業が成長してきた後で、技術的負債に苦しめられて、新しい機能を実装できずに競合に負けていく、という事態は、開発者として責任を感じてしまいます。そのあたりのバランスを上手く取れた、というのも書けると良いことかもしれませんが、なかなか表現が難しそうです。

職務経歴書を読む側としても、あるプロダクトを何年も継続して運用していて、かつ、その事業がちゃんと伸び続けていた、もしくは、その中でよりよい環境にできた、というような内容が経歴に書いてあれば、それはそれで良い評価ができると思うのです。なので、パッとしたプロジェクトが職務経歴書に少ないとしても、何か長く安定的かつ発展的にプロダクトの保守・運用を行えていた開発者を読み取る目、というものが必要なのかもしれません。

最後に

プロジェクト、すなわち開発と運用がしっかりと分離しているもの、が仕事の中心である世界であれば、こういった心配はいらないと思います。建築物のように、一度建てたら基本的にはメンテナンスするフェーズに移るような感じです。

しかし、Webやソフトウェアの業界は、業界自体や技術の進歩、移り変わりも早く、開発と運用ははっきりと別れていません。「ソフト」であるが故に、作ったあとでも変更ができてしまいます。そうなると、プロジェクトよりもプロダクトを重視する、プロダクトマネジメントが良くフィットした考え方なのだと思います。

多くがフリーミアムモデルで成長してきたWebの業界にとって、まずはユーザーを集めることが目的で、収益はその後からなんとでもなる、ということもあったかもしれません。プロジェクトとして立ち上げて、ダメだったら次、というような開発方法です。しかし、昨今のSaaSとして提供されるプロダクトでは顕著に重要になりそうです。ある意味で、過去に多くフリーミアムで成長してきたWeb業界が、サブスクリプションで直接ユーザーから料金を得るようになったり、だんだん歴史のあるサービスになってきたことで生まれた、成長痛のようなものの一つなのかもしれません。

頷きながら読んだものの、定年も延びそうな、老齢になっても働けるうちは働かないといけない世の中になりそうな中、キャリアを積み上げた結果として出てくる職務経歴書の書き方に悩んだ、そんな読書でもありました。
プロダクトマネジメントはとてもオススメできる本なので、是非読んでいただきたいです。