SaaS エンジニアのキャリアパスとしてのプロダクトマネージャー
はじめに
この記事は "プロダクトマネージャー Advent Calendar 2020" の 1 日目の記事です。
今回は、SaaS (Software as a Service) 企業にエンジニアとして入社した人間がプロダクトマネージャーに転身して感じた、 SaaS エンジニアのキャリアパスとしてのプロダクトマネージャーについて語ってみます。
自己紹介
Chatwork 株式会社のプロダクトマネージャーです。ただし、今回の記事は所属会社の意思を表すものではなく、個人の意思に基づくものですので、その点についてはどうかご了承いただければと思います。
アルバイトで Web サイト制作をおこないつつ、就職先では自然言語処理を扱う研究開発部門に所属した後、よりユーザーに近い領域で面白いサービスをおこなっているところを希望して Chatwork に転職してモバイルアプリエンジニアになりました。
そして 2019 年からプロダクトマネージャーに社内転職し、社内ではエンジニアからプロダクトマネージャーに転身した 1 号 (そしてまだ 1 号) として、今日まで活動しています。
結論から
結論からいうと、SaaS プロダクトのエンジニアはもっとプロダクトマネージャーを志向してもいいと思うし、してほしいです。どうしてそう思うに至ったのかを書き記してみましょう。
SaaS のプロダクトマネージャーとはなにか？
Chatwork 社内ではプロダクトマネージャーのことを PM と読んでいますので、この記事でも今後 PM とさせていただきます。さて、 Chatwork は SaaS プロダクトです。ビジネスチャットを Web を経由して、またはモバイルアプリをクライアントとして使っていただくプロダクトで、フリーミアムモデルとセールスモデルの 2 つを持っています。
SaaS プロダクトは永遠の β 版ともいわれています。ユーザーが目にしたプロダクトはその時点のスナップショットでしかなく、ユーザー課題/技術的課題など、様々な課題を解決するための変更が 1 日に何度もデプロイ (サービスを利用できるようにする作業のこと) され、同じユーザーが 1 日に目にする形が何度も変更されることもありえます。
この迅速さこそが SaaS プロダクトの特徴であり、パッケージ型ソフトウェアとの最大の違いであるともいえます。プロダクトのロードマップを描いたとしても、そこには描ききれない大量の変更が日々加えられていきます。
そんな SaaS プロダクトの PM とは、ともすれば PM ですら追いきれない変更点を追い把握し、変更とユーザーの反応の関係も把握し、次の課題解決を見つける役割を担っています。
なにが SaaS のスピードを生み出しているのか？
なぜ SaaS プロダクトがパッケージ型ソフトウェアと異なる、爆発的な変更速度を生み出しているのかといえば、技術です。速度の裏にはそれを実現するための技術があります。
今やデータセンターに自前のハードウェアを設置しなくても、 Amazon Web Services, Microsoft Azure, Google Cloud Platform などの XaaS を活用すれば良く、プロダクトの本質的なコードに集中しやすい環境が整っている……というのは、聞いたことがある人も多いのではないでしょうか？
これは正しいです。SaaS を取り巻くあらゆる構成そのものが、コードによって管理できるようになり、インフラレイヤーからユーザーが触るフロントエンドレイヤーまで迅速な変更ができるようになりました。つまり、 SaaS を取り巻く構成自体もソフトウェアになっているのです。
では、プロダクトの本質的なコードにのみ集中できるのか？という問いかけに関しては正しくないと答えます。あらゆるレイヤーをコードで管理できるようになったということは、そのコードの保守・運用・管理が必要になったのです。この観点が抜けがちです。
SaaS の開発スピードを落とす方法
ソフトウェアというのは、プログラムのコードによって構成されています。そして、コードは動くようになって完成ではなく、動くようになってから保守・運用・管理が必要になります。私がソフトウェアエンジニアとして活動し始めるとき、師匠に教わった言葉があります。
「プログラムはまず動くものを作る。そして次に、正しく動くものを作る。最後に、美しく正しく動くものを作る。」
どういうことかというと、
1. まずは提供したいことものの最小構成を作る
2. 次にエラーが出ないように動作するものを作る
3. 最後に保守・運用・管理が考慮できる形にしていく
と、いうことです。
本来、ソフトウェアを作るということは 3 番までをセットで計画するわけですが、ユーザーは最速で 1 番の時点で利益を享受できます。そのため、スピード重視として 2 番、 3 番を計画せずリリースということが起きてしまいます。その結果が積み重なるとどうなるか？ソフトウェア開発のスピードが激減していきます。
そして先ほど、SaaS を取り巻くあらゆる構成がコードで管理されるといいました。つまり、このコードも 3 番までをセットで計画しないとどんどんスピードが落ちていくことになります。
SaaS の開発スピードが落ちるとなにが起きてしまうのか？その答えは非常に簡単です。ユーザー課題の解決スピードが落ちます。価値提供までの時間が長くなるということは、ユーザーから見たプロダクトの価値が時間とともに落ちていくということです。
SaaS の開発スピードを落とさないために
では、PM は SaaS の開発スピードを落とさないために何をしたら良いのでしょうか？
まずはソフトウェアというのは作って完成ではなく、保守・運用・管理が待っているということを知ること。次に SaaS をとりまくあらゆるものがコードで管理されているということは、プロダクトを構成するあらゆるものの保守・運用・管理が必要であることを認識することです。
PM としてはこの認識を持ったうえで、エンジニアとコミュニケーションしていくと良いでしょう。それでも PM としてはまず 1 番を達成した時点でリリースしたいと思うこともあるでしょう。で、あれば、2 番、3 番もその後実施できるようにプロダクトの展開を計画すればよいのです。
ソフトウェア開発は難しい
しかし、2 番、3 番をソフトウェア開発経験がない PM が計画できるか？というと、私はできなくはないが、非常に難しいと考えています。身もふたもない話ですが、経験がものをいう世界でもあるからです。
そもそもソフトウェア開発というのは難しいのです。ユーザーが見える部分がイメージしている課題解決だとしたら、ソフトウェア開発においては「機能要件」と呼ばれるものになります。
一方で目に見えない部分。パフォーマンスやレスポンスタイムなど体感に関わりながらも具体的に表しづらい部分もあります。これを「非機能要件」といいますが、これを具体的に考えるには実務的なソフトウェア開発経験が必要になります。未経験だとイメージしづらい部分もあるでしょう。
例えば SaaS プロダクトの背後に MySQL のような RDB があるとします。このテーブル構成とリレーションの関係、そして今回実現したい機能のために必要なクエリをイメージし、必要な計算量から発生する時間が、ユーザー体験上に出てくるか……？なんて相当に考えるのが難しいでしょう。
もちろん PM 全員がすべて把握する必要はないと思います。しかし、組織にいる PM 全員が誰も知らない、分からないというのは危険です。ではどうするか？そのためには SaaS プロダクトのエンジニアが PM になれば良いのです。短絡的に見えるかもしれませんが、社内で、プロダクトを取り巻く状況、技術を知る人間が PM になったら、非常に心強いですよね？
キャリアパスとしてのプロダクトマネージャー
私自身、まさか PM になるとは思っていませんでした。もともと技術を使って作ったもので誰かが喜んでくれたら嬉しい、だからエンジニアになる……と思っていた人間なので、 PM というタイトルが付くこと自体に違和感はありません。驚いているのはキャリアパスの部分です。
考えてみると、業としてソフトウェアエンジニアをおこなっている人間が、将来に渡ってソフトウェアエンジニアであるかというと、必ずしもそうではありません。
しかし、そこにある選択肢はスペシャリストとしてソフトウェアエンジニアを極めるか、マネージャーとしてソフトウェアエンジニアを率いる人間になるか？という二元的なものしかないのが現状、多くの可能性ではないでしょうか？
そこに第三極として加えたいのが PM です。プロダクトマネジメントトライアングルとして有名な三角形の各頂点はそれぞれ、
・Users
・The Business
・Developers
です。この中でも最近は Users と The Business に注力する PMM (Product Marketing Manager) というものも注目されています。PM は全体を見ることになりますが、PM と PMM がいる場合、相対的に Developers への関わりが薄くなってしまいます。それであれば、 Users と Developers に寄る Product Experience Manager や Technical Product Manager が一緒にいてほしいと考えています。
そのような領域をカバーできるのは SaaS プロダクトであれば、ソフトウェアエンジニアです。ソフトウェアエンジニアは極めて専門性が強いスキルを持っています。そのスキルをプロダクトマネジメントに向けることができれば、プロダクトの進化を適切にコントロールできるようになるはずです。
だからこそ、私は SaaS プロダクトのエンジニアはもっとプロダクトマネージャーを志向してもいいと思うし、してほしいと考えているのです。
おわりに
この記事では SaaS プロダクトのエンジニアのキャリアパスとしてのプロダクトマネージャーについて述べました。 PM の仕事は組織によって最適化される部分も多くあると思います。それでも、ソフトウェアを構成するにあたって必要な要素というのは不変的です。
組織内にいるからこそ見えること、分かることと、ソフトウェアエンジニアとしての感覚を持ち合わせた PM というのは極めて貴重です。もしも組織内にそのような PM がいないならば、ぜひとも社内から PM になりたい人を募る、またはそのような PM になりたいエンジニアの声を聞き逃さないようにしてください。
以上でプロダクトマネージャー Advent Calendar 1 日目の記事は終了です。 2 日目は "まんまるねこ" さんが担当されます。一読者として、この Advent Calendar で掲載されていく記事が楽しみです:)
この記事が気に入ったらサポートをしてみませんか？