長寿なソフトウェアで長寿なプロダクトを作るために
この記事はプロダクトマネージャー Advent Calendar 2 日目の記事です。 1 日目は ChibaReimi@rechiba3 さんの「テックコミュニティを盛り上げる、ということ」でした！
はじめに
こんにちは。
実は 2 年前の PM Advent Calendar でも同じようなテーマで記事を書きました。この記事はソフトウェアエンジニアが PM を目指すと良いことがあるのではないか？もっと目指しても良いのではないか？という視点で書いたものでした。
2022 年になり、自分の中で “SaaS プロダクトの PM (PdM) は、もう少し Tech 、とりわけ、ソフトウェアエンジニアリングの知識が (少しだけ) あったほうが良いのではないか？” という思いが強くなりました。今回はその思いと共に、どうして PM にソフトウェアエンジニアリングの知識が必要なのかを書いてみたいと思います。
ソフトウェアを書くということ
SaaS プロダクトは名前の通り、ソフトウェアをサービスとして提供するプロダクトです。ソフトウェアをユーザーに届けることで課題を解決し、その対価として私たちはビジネスを成功させていきます。そして PM が思い描くプロダクトをソフトウェアとして構成する人がいます。ソフトウェアエンジニアです。
ソフトウェアプロダクトをアジャイルに開発している場合、多くの組織では “スクラム” や “カンバン” などのフレームワークを使っていると思います。 PM はこのフレームワークの中でプロダクトオーナー（PO）などの役割を担い、バックログの整理や優先順位付けを行いつつ、開発者の役割であるソフトウェアエンジニアとコミュニケーションを密に取りながら、プロダクト開発を進めていきます。
役割が分かれていることで、 PM は自分自身がソフトウェアを書かなくても思い描くプロダクトを形にできるわけですが、 “ソフトウェアを書く = How” だから、ソフトウェアエンジニアに全て任せれば良いという思考になっていないでしょうか？
PM の役割として大事なことは Why と What を突き詰めることというのは様々な場所で語られていると思います。私はこれを否定しませんし、 PM として最も大事なことであることは私も同意します。どんな課題がなぜ存在するのか、そしてそれを解決するために何を作るのか？を考えることは PM が PM である理由です。
ただ、プロダクトを形作っているソフトウェアがどのように作られているのかを、本当に PM は知らなくても良いのでしょうか？ソフトウェアを書くということはプログラミング言語を駆使することだけではありません。ソフトウェアを書くということは、設計し、構築し、管理し、運用する一連の流れがあります。特にソフトウェアを適切に管理し、運用できるかどうかはプロダクトを健全に進化させられるかどうかに直結しています。
SaaS プロダクトの PM はプロダクトを健全に進化させられるようにするための How の知識が必要です。その必要な知識こそが、ソフトウェアエンジニアリングの知識です。
ソフトウェアは死に向かう
PM である私達はプロダクトを世の中に公開し、使ってもらい、フィードバックを得てまたプロダクトの改善に活かしていくことを目的としています。 SaaS プロダクトはソフトウェアがプロダクトの核です。そのため作られたソフトウェアが公開され、使われて初めて生を得ると思っているかもしれませんが、実はソフトウェアは書かれた瞬間から死に向かっています。
人が産まれてから大人になるまで、何もしないでも良いわけではありません。食事をし、運動し、排泄をして、睡眠をしたり……と、様々なメンテナンスが必要です。このバランスを崩してしまえば、病気や怪我をしてしまいますし、何もせずにいたらすぐに命は尽きてしまいます。ソフトウェアも同じです。書かれてから何もせずにいたら、すぐにダメになってしまうのです。
PM の目線で見ると、 SaaS プロダクトの成長 = ソフトウェアの成長と見るかもしれませんが、これは = ではありません。SaaS プロダクトとして健全に成長できているように見えても、ソフトウェアとして健全に成長できているとは限らないのです。ソフトウェアを健全に成長させるためには、ソフトウェアの “手入れ” が欠かせません。
長寿なソフトウェアで長寿なプロダクトを作るために
ソフトウェアの手入れとは、コードをより良い形に書き換えたり、セキュリティ問題に対応したり、ソフトウェアが動く基盤を整えたりとか、そういうものです。ソフトウェアはコードを書いて終わりではありません。管理・運用するものなのです。
こうした手入れをプロダクト開発の合間にできればよいですが、そう簡単ではありません。 PM はユーザーストーリーを考え、スクラム開発を行っているならばプロダクトバックログを管理しているはずです。皆さんのプロダクトバックログにソフトウェアを管理・運用するためのバックログアイテムはありますか？ 1 つもないとしたら、危険信号だと思います。
プロダクトバックログのすべてがユーザーの課題を解決するためのものとなってしまっている場合、ソフトウェアエンジニアは手入れをいつ行えばいいのでしょうか？プロダクトとして価値を発揮しているコードでも、手入れされないままならば、それからまた追加されるコードと比較して設計も古くなり、ソフトウェアを動かすための基盤も古くなり、プロダクトという蓋を開けてみると、構成しているソフトウェアとしてはチグハグな形になっている……ということになります。
このようなソフトウェアはその瞬間にプロダクトとして価値を発揮できたとしても、変更に弱く、開発スピードが落ちていき、新しい価値を提供したいと思ってもなかなか発揮できない状態になります。つまり、プロダクトとしても寿命を早く迎える危険性があるのです。
つまり、手入れされないソフトウェアは短命であり、短命なソフトウェアはプロダクトそのものを短命にしてしまいます。これを防ぐために、プロダクト開発の 2 割の時間は常にソフトウェアの手入れの時間に使えるようにすることをオススメします。
スクラム開発で 1 週間 (5 日) を 1 スプリントとしているならば、 1 日分です。1 日分も？と思うかもしれませんが、常に手入れされ続けているソフトウェアにできていれば、長い目で見たときにプロダクトの成長に対する技術的な障壁はかなり下がります。プロダクトとして新しい価値を発揮したいとき、安定したスピードで開発ができ、ユーザーに提供できるようになるのです。
もちろん 1 日分の時間がない分、プロダクトとして実現したいことの一部は諦める（スコープを小さくする）か、実現するまでの時間を長く見る必要があります。このあたりの話はソフトウェア開発界隈で有名な @t_wada さんが書かれている「質とスピード」という資料が有名です。ぜひとも一読することをオススメします。
PM とソフトウェアエンジニアリング
さて、ここまで書いてきたことに対して PM の皆さんはどのような印象を抱いたでしょうか？
何をいいたいのかよくわからない
言いたいことはわかるが、プロダクト開発においてのビジネスの側面を無視している
これらの 2 つのどちらかの印象を持たれた方も多いのではないでしょうか？一方でプロダクト開発としてソフトウェアを作ったことがある方は「わかる」という印象を持たれたのではないでしょうか。ソフトウェアを作ったことがなくても「わかる」という印象を持たれた方、ぜひとも一緒に働きましょう。
厳しいことを言うようですが、ソフトウェアを作ってみないと理解しづらい感覚というのは間違いなくあります。それでも、こうした記事を書いた理由は SaaS プロダクトの PM がソフトウェアエンジニアリングの知識がないままでは、長く健全に成長し続けるプロダクトを作れないと考えたからです。だけど、必ずソフトウェアを作る経験をしてほしいとは言いません。私が書いたようにプロダクト開発における 2 割の時間をソフトウェアの手入れに当てるだけで良いのです。
そして、どのような手入れが必要なのかはソフトウェアエンジニアと話をしてみてください。そのときに PM の目線でその手入れが生み出す価値を考えてみてください。これを続けるだけでも、PM の中にソフトウェアエンジニアリングの知識（のごく一部）がそうと知らずに染み付いていくはずです。
感覚的な話で、PM らしい分かりやすい Why / What / How を示した記事ではありませんが、 SaaS プロダクトを作る PM の皆様の新しい目線または共感を得られれば嬉しく思います。
明日、 3 日目の記事は松永拓也さんが担当されます。よろしくお願いいたします！
この記事が気に入ったらサポートをしてみませんか？