プロダクトの技術的負債とPMはどう向き合うべきか
プロダクトがうまくユーザーに受け入れられ、PMF（プロダクト・マーケット・フィット）をして、売上もたってきた。そんな時に1つ必ず論点になるのが「技術的負債とどう向き合うべきか」です。
これがなぜ論点になるかと言うと、組織やプロダクトによって共通の正解と言えるものがなく、人によって大きく判断が分かれるからです。特にエンジニアとプロダクトマネージャーではまた大きく考え方が変わるのも特徴。
大きな開発組織になるとテックリードやCTOが判断をするのですが、スタートアップや小さい開発組織だと実質プロダクトマネージャーが判断することも多いのが実情です。そこで今回は、プロダクトマネージャーにとって技術的負債とどう向き合うべきか、を書いていきます。
そもそも「技術的負債」とは何か？
まず最初に、そもそも技術的負債とはどんなものなのでしょうか。挙げ始めるときりがありませんので、この記事では以下3つを技術的負債として定義します。
設計の問題
最初の設計がスケール（大きくなる）ことを想定して作られていない場合などコードの質の問題
創業者が書いたクソコードがアプリケーションのパフォーマンスを下げている、不具合の原因になっている場合など技術選定の問題
バージョンが古い、エンジニアの絶対数が少ない言語で作ってしまい後から採用できず苦労する、など
こういった点で苦労することを技術的負債と呼ぶことが多いです。そして文字通り、この「負債」はどこかで返済をしなければ増え続けるのも特徴です。怖いですね！またコードのきれいさ以上に、実は初期の設計のほうが大事だったりもします。
そのため、できるだけ技術的負債が発生しないようにプロダクト開発初期は優れたエンジニアとプロダクトマネージャーがいることがとても大事なのですが、実際そんなに優秀な人が初期手伝ってくれるとは限りませんし、優秀な人であってもスピード優先で技術的負債を許容することもあります。事業がうまくいくことを期待しつつ、どこかで技術的負債を「返済」することを考えなくてはいけません。
エンジニアとプロダクトマネージャーの考え方の違い
まだジュニアのプロダクトマネージャーがエンジニアからこう言われたとします。
「このコード良くない書き方していつかリスクになるので、リファクタリングしていいですか？」
リファクタリングとは、内部のコードを改善することです。技術的負債を返済するとなった時、まず思いつくのがリファクタリングであるエンジニアは多いでしょう。
こうエンジニアから言われると、断る理由がないからOK出しちゃう。それで新機能開発が止まってしまう問題は超あるあるです。何がやっかりなのかと言うと、リファクタリングしたいというエンジニアの気持ちは間違えてないし、むしろ正しいです。ただ、問題なのは「今やるべきなのか？」というその1点です。
特にプロダクト開発の初期では、どんどんプロダクトを改善していかないとユーザーが離れていってしまいますし、競合が現れたらユーザーを奪われてしまうかもしれません。開発を止めるというのは、そういうリスクがあるのです。そのうえで、今リファクタリングをするべきなのか、はしっかり考えなければいけません。開発を進めるかリファクタリングか、どちらを選ぶかのバランスを取るのはプロダクトマネージャーの永遠の課題です。
もしリファクタリングをやらない判断をして断るにしても、しっかり説明できる理由がないと無下につっぱねることになるのでそれも良くありません。そこの判断基準は特に開発に関わるビジネス側の人間（プロダクトマネージャー、事業開発など）には常に悩みのポイントです。
技術的負債の返済は「部屋の片付け」と同じ、実害がない限り最小限がおすすめ
結論から言うと、特にスタートアップであればリファクタリングはサービスが死ななくなってからでOKであることがほとんどです。ユーザーが順調に増えている、売上が上がっている、こういうタイミングで将来への投資として行うのがベストタイミングです。
先ほども説明したように、開発スピードを取るか、開発の安全をとるか、はスタートアップにとっては常に悩ましい論点です。しかし、プロダクトが死んでしまっては、どれだけ綺麗にコードを書いていたとしても、しっかりした設計をしていたとしても、全て無駄になってしまいます。なので、プロダクトがまず死なないことに注力し、ある程度のコードの汚さや設計の甘さは目をつむるのが現実的だったりします。
ただ、これがエンジニアの人にとってはなかなか受け入れがたいことも事実です。せっかく自分が頑張って取り組むのであれば、綺麗なコードにしたいと思うのは当然の人情ですからね。しかし、ここは綺麗さよりも事業として成立することを優先することをチーム全体で合意できなければいけません。そしてそのコミュニケーションは、プロダクトマネージャーの大事な仕事の1つです（組織によってはCTOが担うこともあります）。
例えるなら、技術的負債の返済は部屋の片付けに似ています。ある程度部屋が汚れていても生活をするうえで全く問題ありません。しかし、あまりにもゴミが放置されたり、足の踏み場もないほど汚れていたりすると、さすがに実害がでてくるので掃除をしよう、となるはずです。このように、実害が出るまでは多少汚くても、まぁそんなものだと諦めてしまうバランス感覚が大事になります。
しっかり作りたいというエンジニアの気持ちを理解しつつ、とはいえ事業を成功させることにフォーカスして、多少汚くても前に進む、この共通認識があるスタートアップは成功しやすいのは事実です。
技術的負債が返せないならプロダクトを作り直すのも最悪あり
世の中には、技術的負債が返せなくなってサービスをまるごと作り直したプロダクトもあります。例えば、私が昔いたリクルートでは、スタディサプリというサービスにブランド統合する前後で、それまでの過去の技術的負債を返済することを諦め、Quipperというサービスを買収しシステムを乗り換えたことがありました。
このように、実は技術的負債は自己破産のように返済を諦め、まるっとシステムごと乗り換えるというのもありえるのです。もちろん、その場合は0から作り直したり、乗り換え先のシステムの互換性にも依存するので万能解ではありませんが、こういう選択肢も実はある、というのはあまり知られていません。
技術的負債は「発生するリスクの種類と確率」で返済を判断する
エンジニアの人と会話をするとき、プロダクトマネージャーが考えるべきなのは「どんなリスクが、どんな確率で起きるのか？」です。
例えば、こういったサービスとして致命的な問題が起きる場合は、新規開発を止めてでも取り組む必要があります。
個人情報が漏洩する
他のユーザーの情報が見えてしまう
運営するうえで取り返しのつかないミスが起きやすい
一方で、こういう場合は技術的負債に目をつむり新規開発を優先した方が良い場合が多いです。
読み込みスピードが落ちる
表示くずれが起きる場合がある
サービスがごくまれにダウンする
こういうリスクは潰しておくよりも、事業としてプロダクトを成長させることを優先することをおすすめします。プロダクトマネージャーは、エンジニアからリファクタリングについて聞かれたら、
「それを放置するとどういうリスクがあるのか？」
「どれくらいの確率で起きるのか？」
これらについて会話してみてください。会話してみると、意外と心情的に気持ち悪いだけで実はたいしたリスクじゃなかあった、というのもあるあるです。
とはいえ技術的負債を甘く見てはいけない！
プロダクトマネージャーにとってはプロダクトを成長させることを優先し、技術的負債の返済は最小限でOKと言ってきました。しかし、技術的負債によって死んでいったサービスも多数あることもまた事実です。技術的負債を甘く見てはいけません。
技術的負債をあまりに放置すると、こんな問題が起きるようになります。
障害が出る確率が増える
システムがダウンするだけでなく、エンジニアが開発中にいじってはいけない方法でコードをいじってしまい人為的なミスも起きやすくなります。工期が余計にかかる
1にも関係しますが、他のエンジニアが作業しやすいコードになっていないと余計な作業が必要になり時間がよりかかってしまいます開発者の離職、モチベーションが下がる
モダンな開発環境で仕事をしたいのがエンジニアという生き物なので、あまりに汚いコードだと関わるのをためらってしまいます
こういった問題が顕在化してしまうとすでに手遅れです。おまけに、放置し続けることで負債は雪だるま式に増えるため、返済で手一杯で新機能開発なんてできない、という状況になりかねません。
そうなる前に、CIの導入やコードフォーマッタの導入、テストコードを書くなど仕組みで解決することも大事です。プロダクトマネージャーはエンジニアの工数をできるだけかけることなく、技術的負債を「予防」する仕組みの導入ができるとベストです。自分だけで判断がつかない場合は、CTOレイヤーの人などにアドバイスをもらうと良いでしょう。
おわりに：自分で判断するだけがプロダクトマネージャーではない
今回は技術的なテーマの記事でしたが、必ずしもプロダクトマネージャーに開発経験があるとは限りません。そういう場合は、周りの先輩やエンジニアの人に頼りつつ、技術的負債とうまく向き合える組織を作っていってください。
こういった技術的負債の問題はプロダクトマネージャーと切っても切れない関係なので、今後も私自身、より考えていきたいです。ご興味がある方はプロダクトマネージャー用コミュニティPM Clubへどうぞ 💁♂️
この記事が気に入ったらサポートをしてみませんか？