保守性から見た長期目線でのプロダクトマネジメント
はじめに
これまで、「プロダクトは長期で考えましょう」みたいなことを言われても正直ピンと来ていない部分がありました。
「プロダクトが長く続いて、ビジョンの達成に近付き、使ってくれるユーザー、運営しているメンバーがみんな幸せな状態が維持できればいいのでは？」くらいの解像度です。
いくつかの具体的な取り組みを通じて個人の考えをアップデートできたのでまとめようと思って今回のブログを書いています。
なお、10Xでは絶賛採用中ですのでご応募や雑談お待ちしております（詳細は最後に）
長期目線でのプロダクトマネジメントは「持続的にプロダクトが提供できる状態を作る」こと
プロダクトマネージャーとしては自分の関わるプロダクトが長く多くの人に使われて課題を解決し続けてほしいという思いはあるはずです。
ただ、その前提として持続的にプロダクトを提供できる状態を作ろうとすることが長期目線でのプロダクトマネジメントの1つの要素になるかな思っています。
持続的にという視点には、納得感のある価格を維持する、競合に負けないような状態を作る、セキュリティインシデントを起こさないなど多岐に渡ります。
この状態を作るための1つの取組みとして10Xでは「保守性」を大事にしています。
プロダクトマネージャーから見た保守性って何？
長期目線の前提として、10Xでは保守性という言葉をよく使い大事にしています。過去の会社ではあまり聞いたことがなかったワードです。
wikipediaには以下のように書いてありますがあまりわかりませんでした。
保守性（ほしゅせい、英：maintainability または serviceability）は、 指定された条件下で規定された手順および資源（材料・設備・治工具・ソフトウェア等）を使用してアイテムの保守が行われた場合、与えられた使用条件において、要求された機能が保持される、または修復される能力をいう。
様々な取り組みを経て、現時点の個人的な解釈としてはこのように認識しています。
ある目的に対してプロダクトが一定のコストで運用・進化できる状態を維持できる特性
保守性というテーマはソフトウェアエンジニアの方が正しく言語化していたり、世の中的には答えがたくさんあると思うので、あくまでプロダクトマネージャーとしての僕の1つの解釈になります。
一定のコストで運用・進化できる状態になると、プロダクトを運営するコストが減るということになります。ゼロにはできませんが必要なラインまで下げることで、PLが健全化します。
CFOとの会話の中で運用はコスト、機能開発は投資としてPLでは整理されており、運用の削減 = 明確にコスト削減に効果があると理解をしました。（*正確な整理は何かを参照してください。EBITDAの理解が進みました。）
中長期的にプロダクト・事業のPLが健全化して、より積極的な投資ができる構造を構築・維持することに繋がります。運用が多いとその分コストが大きくなるので、売上が大きくない状態ではPLは健全化せず、最終的にはプロダクトの提供が難しくなるリスクが発生します。
個人的な葛藤
ベロシティが出てない、運用多い、障害多い、問い合わせ多い、みたいな問題は顕在化しつつあり、このままではスケールしたときに首が回らない状態になることは自明であり、保守性の重要性は理解していました。
一方で、直接的な要望が出てたり、数値が改善できる見込みがあったり、他社差分を埋めるようなわかりやすい武器になる機能を作りたい気持ちが個人的にはありました。
保守性高めるぞ！は全社的な取り組みとして決定事項だったので、個人的な感情は一旦蓋をして、どうしたら自分としてこの課題をうまく解決できるのかという視点で向き合いました。
運用業務削減に向けた具体的な取り組み
運用業務の可視化
まず、手を付けたのは活動の可視化です。JIRAを導入していたのでこれを軸に進めました。JIRAと仲良くなれない人も多いと思うけど、トラッキングしやすくて便利な側面もあるので、少しずつ仲良くしてあげてください。
StoryPointsベースでの活動の分類
JIRAのチケットに以下のラベルを付けてもらって、StoryPointsを活動で分類しました。
新機能開発/改善：新機能開発や既存機能の改善活動。機能開発、個別機能のPF化、アルゴリズム改善etc・・・
保守運用の改善：保守運用のための改善活動。リファクタ、運用の機能化、SLO改善etc・・・
保守運用：保守運用の活動。既存バグの解消、障害対応、依頼対応、アラート対応etc・・・
実施時期から未来のラベル付けは開発チームの運用に落とし込んでもらいました。
（Epicと同じラベルを付くようにワークフロー組んでくれてたり、スクラムイベントでラベル付の時間取ってくれたりと各チーム工夫してくれてました）
依頼件数の可視化
次に、上記の保守運用に含まれるものではありますが、具体的に「依頼事項」の可視化をしました。
もともとCSやBizDevからの仕様確認、調査依頼など、はJIRAのフォーム経由で受ける運用を組んでいました。
これはタスクの見える化、開発チームで実施タイミングをコントロールしやすくする、個人ではなくチームで解消できるようにするなどの目的からの運用ルールです。
JIRA経由にしていたことで上記同等に可視化は容易でした。
運用業務の機能化
可視化と並行して、繰り返し発生している運用業務を機能化する意思決定をしました。
一例として具体的には、ネットスーパーは店舗に対して配達エリアを設定しており、住所と店舗が紐づく構造になっています。特定の住所をA店からB店に移すといった運用になります。他にもいくつかの運用業務を機能化しています。
この運用業務は実は事業KPIにも効く非常に重要な作業です。（詳細はまたどこかで）
社内的にはかなり業務効率化されており、1回の実施コストもある程度抑えられていました。
しかし、スイッチングコストや非開発チーム（パートナー企業とBizDev）間の調整コストなども課題としては存在していたのでそれらの削減も含めて取り組みました。
もともとの運用を踏襲する形で仕様に落とし込むと非常に複雑でこれはまずいと思いました。人間は3つの時間を意識することは不可能です。（詳細はまたどこかで）
非常に複雑な仕様を叩き台としてエンジニア、QAのみんなとホワイドボードでを使って議論し、いくつかの現行運用を維持することは諦め、極力シンプルな仕様に落とし込みました。
運用をプロダクトに落とし込むときに、そのままのものを維持することはできないケースがあるよねってのを改めて認識しました。迂闊に始めた運用の期待値調整は大変になりますね。（詳細はまたどこかで）
この機能は、運用をそのまま踏襲しない仕様にして、figmaを元にユーザービリティテストで得たフィードバックを仕様に盛り込んで、開発を丁寧に進めた結果、想定の120点のクオリティとの評価をもらいました。
社内の運用を減らすという目的はありつつ、結果的に満足度の高い機能として作り込めちゃうところが素晴らしいチームだなって思っています。
さいごに
10Xではこのような考えに共感し、長期で本質的な課題解決に向き合えるPM、SWE、デザイナー、BizDevを募集しています。(2025/01時点)
ネットスーパーも大きくフェーズが変わってきていたり、新規事業の仕込みも進んでいたりと、ワクワクする機会がたくさんあります。
カジュアルに話すところからどうでしょう。XでDMください。