プロダクトリリースの影響範囲

新規開発やエンハンスを行う際、それによって起こる影響の範囲をみなさんは正しく考えているでしょうか。今日はリスクヘッジ観点での影響範囲についてお話しさせていただきます。
なぜ、本日はこのテーマなのかと言いますと、今月に入りすでに3回他部門の新規開発による既存API変更やエンハンスによるプロダクト仕様変更によって、私の管轄するプロダクトに影響があり、やたらと工数を取られてしまったため、良い経験として書こうと思いました。

プロダクト開発で考えること

PdMであれば、誰でも「企画を考える」ということを少なくとも経験しているでしょう。例えウェイターと呼ばれる便利屋さん的なPdMであっても企画書の1度や2度は考えてきたと思います。

みなさんはどのように企画を考え、要件定義するまで進めているのでしょうか。課題やニーズ、ビジネスインパクトなどさまざまな内容を考えて企画書として落とし込んでいると思います。
企画の段階であまり細かいことを気にしていると、どんどんつまらないものになってしまうため、私は企画の段階ではある程度楽しみながらやるようにしています。ネガティブなことは要件定義の段階で洗い出すといった感じです。

企画を考えるモチベーション

まずは課題を先に考えることが多いのではないでしょうか。
この課題を解決したら、ビジネス価値はどのくらい？それを将来的にはこんなふうにしていけば、なんて面白いプロダクトが出来上がるんだ！といった具合に夢いっぱいで企画を考えます。

• ターゲットをイメージする
• 課題の本質を考える
• そもそも課題と捉えるユーザーがどのくらいいるのかを検証する
• 課題を解決した時にどのくらいのビジネス価値があるのか
• それはどのように発展していくことが想定できるのか

要件定義

企画がある程度まとまってきた段階で、徐々に頭の中でイメージを視覚化していき、要件定義の走り出しをまとめ出します。新規のリリースであれば、UI的な体験をイメージしながら、必要な機能を概要書に落とし込んでいきます。
この時、必要機能の干渉するシステム的影響と他部門を含めたセールスなどのリアルな人への影響を考えます。

• 他のプロダクトに影響はあるのか
• 影響があるのなら、それはどのようなものなのか
• 影響を回避する、もしくは別の方法はあるのか
• リアルな人間の業務に影響はあるのか
• 影響があるのなら、それはどのようなものなのか
• 影響を回避する、もしくはどのように共有すれば良いのか
• セキュリティ面でのリスクはどのようなものがあるのか
• 法的に考えても問題はないのか

　

リスクを考え出すとキリがありませんが、どこまで考えるのかは企画している機能によります。個人情報や利用ユーザーが多いものなら、考えても足りないくらいのリスクを考慮しなくてはいけません。
逆に、機能がつかえなくなったとしても、影響が少ないことや致命傷になるようなことがないのなら、ある程度考慮しておけば良いでしょう。基盤システムに関係するような開発は、会社全体を巻き込みかねないため、注意が必要です。

今回の経験

簡単にお伝えすると、他部門の人間が自分の管轄しているプロダクトだけしか考慮せず、同じAPIを使用しているプロダクトがあるということを全く気にせずに要件定義を完了させ、開発に着手。
エンジニアが、別の案件を開発中にたまたま気がついたという、偶然インシデントにならなかったということになります。
具体的な内容はお伝えできませんが、要件定義の段階でいろいろな部分に気をかけ入れば、当たり前のように回避できた内容です。

最後に

PdMという職種は、セールスからエンジニアまで、さまざまな人間と関わり、より素晴らしいビジネス（プロダクト）を作り上げていく立場になります。それだけストレスや悩みも多いですが、たくさんの人間を巻き込み自分達でハンドリングしてビジネスをコントロールしていると考えると、非常に楽しい職種なのではないでしょうか。

ただ、世の中で本当にそれを理解しているPdMがどのくらいいるのでしょう。言われたことを淡々とこなすだけのPdMが多い中、これからPdMを目指す方には、ぜひ、この職種の一番の楽しみを存分に味わってほしいと思います。