この記事は【ReviCo】 Advent Calendar 2025 の23日目の記事です。
昨日は、おとさんの「New Relic の Workflows で Enrich Data を使う」でした！
はじめに
最初の記事で、ReviCoではルビーチームとサファイアチームに分かれて開発を進めているという話をしました。ここではサファイアチームのPO（プロダクトオーナー）として、どのような意識を持って取り組んだのかについて書きます。
PO歴
スクラム開発でのPO業務は、前にtoCサービスの「ReviCoポータル」の開発時にもPOとして取り組んではいたのですが、短期間（約半年）であったことと、ローンチ以降は手を動かす開発者としてPOを一時休止していたことがあり、ブランクがある状況でした。
サファイアチームでは細かい要望の改善、その他パフォーマンス改善を主に取り組むチームであったため、POとして期待されていたこととしては、仕様を詰めることで継続的に価値を提供すること、チームの状態を健全になるようにマネジメントすることでした。
意識的に取り組んだこと① トレードオフを意識した意思決定
意識的に取り組んだことの一つは、プロダクトの提供速度と意思決定回数のトレードオフを考えることです。
POとしての役割の一つに、プロダクトに価値を提供するためにプロダクトバックログを整理する作業があると思います。その中で悩んだ点は、要望をReady可能なシステム要件に落とし込むこと、そして仕様をどこまで決めるべきかという点でした。
PO始めたばかりの頃は「答えは営業の中にある」という強い信奉を持っていました。そのため、1つの要望に対して細かい設計書を作り（ある画面はこの色で、このボタンを押下するとこう表示される等）、すべての合意を得てからプログラムを作成しようとしていました。
この取り組みは結論としては上手くいきませんでした。主な理由は二つあります。
一つ目は、合意を得たい営業サイドのメンバーが多忙で、細部まで確認することが難しかった点です。
二つ目は、決め事が増えることで意思決定に時間がかかり、結果としてプロダクトのデリバリーの速度が遅くなった点です。
意思決定に時間をかければかけるほど、プロダクトの提供が遅くなる--このトレードオフを強く意識するようになりました。
そのような悩みを抱えていた時に、社長から教えていただいたのが「タイプ1」と「タイプ2」の意思決定という考え方です。
Amazon創業者のジェフベゾス氏が株主に贈るレターの中で書かれていたもので、意思決定には種類があるという内容を説いたものです。
「タイプ1」の決定は、いわゆる不可逆的な決断で、一度決めると元に戻すことが難しい決定を指し、「タイプ2」の決定は逆に戻すことが可能な決定のことを指します。
ジェフベゾス曰く、ほとんどの意思決定は「タイプ2」であるものが多く、この手の決め事は判断力の優れた個人やグループによって素早く行われるべきだと主張しています。
この考えを元を要件決めに照らし合わると、あらゆる決め事に時間をかけて合意を得る必要はないと考えるようになりました。要望を要件に落とし込む際は、その仕様が持つであろうインパクトを見極め、後から戻せるかどうかを意識するようにしています。
元に戻しにくいと判断できる決定については、営業サイドとしっかりと方針をすり合わせる。一方で、管理画面のボタンの色など、可逆的な決定についてはスピードを重視して、PO自身が責任を持って判断する。このようなスタンスで要件決めに取り組んでいます。
意識的に取り組んだこと② 開発チームの健全性を維持する
もう一つのPOとして役割といえば、スクラムの開発チームが健全な状態で開発を進められているかを確認することだと考えています。
前述のとおり、営業サイドの意見に寄り添うことはプロダクトの価値提供という観点からは重要ですが、あらゆるビジネス要望に対して「はいよろこんで」で対応していると、複雑な設計になったり、工数増加によって開発チームの負荷が高まってしまうという問題が生じます。
こうした問題を未然に防ぐため、リファインメントの場では以下のような観点を意識して議論するようにしました。
・この要望は、実装・運用の観点からどの程度の負荷がかかるのか
・現状の仕様のままだと、コードベースが過度に複雑にならないか
・そもそもの仕様を見直すことで、よりシンプルで保守しやすい形にできないか
これらを開発チームとともに検討することで、安定した品質を維持しながら継続的に開発できる要件になっているかを確認するようにしました。
また、ビジネス要望だけでなく、「このレイヤーにはテストコードが欲しい」「このような技術を試したい」といった提案についても、可能な限り積極的に取り入れるよう姿勢を持つようにしました。
コードベースに一番触れることが多いのは開発者であり、その現場感覚はプロダクトの健全性を保つうえで非常に重要だと考えています。
実際に対応するかどうかの優先度判断はPBIの整理で行うものの、技術負債の解消や保守性を見据えた改善にも、しっかりと向き合う必要があると感じています。
おわりに
今現在も悩みながら仕事に向き合ってはいますが、段々とプロダクトオーナーとして振る舞う自信が持ててきた気がしています。
より大きなメンバー、大きな機能についても振る舞えるように今後も取り組んでいきたいです。