新米PMが仕様策定において大切にしている観点

この記事は[trocco Advent Calendar 2022](https://qiita.com/advent-calendar/2022/trocco) 14日目の記事となります。

こんにちは。troccoのプロダクトマネージャーをしております佐々木と申します。
今回は、troccoでプロダクトマネジメントを行なっている立場から、仕様策定を行うにあたってどのような観点を大切にしているか共有できればと思います。

# 自己紹介

改めまして、troccoでプロダクトマネージャーをしております佐々木と申します。（そもそもtroccoとはなんぞや、という方は[こちら](https://trocco.io/lp/index.html) をご覧ください）
troccoを開発している[primeNumber](https://primenumber.co.jp/)には今年の10月に転職してきたばかりで、かつ前職はデータサイエンティストとして働いておりPMの経験は無かったため、新しい仕事に戸惑うことも多いですが日々楽しく働いています。

# この記事はなにか

PMの業務内容は各会社ごとの定義の違い、プロダクトの形態・フェーズ、PMのスキルセットなど様々な要因で変わり得ると思いますが、自分を含め多くのPMの方々はプロダクトの機能開発における仕様策定を任されることが多いのではないかと思います。

仕様を考える上では、何を作らないといけないか、逆に何を作らないかを様々な観点から評価し、時にはトレードオフの関係性になるような観点がありながらも、現時点で最良と思われる意思決定を行う必要があり、入社当時も今も（そしてきっとこれからも）悩みながらやっていくしかないものだと~~諦めています~~思っています。

正解のないこととはいえ、意思決定を繰り返していくうちに、ある程度自分の中で「こういった観点で評価していけば"正解の"仕様を決めていけるのではないか」 といったある種の「型」が見つかってきており、最近はその型を意識しながら仕様策定を進めることで比較的スムーズに進められているのではないかと思っています。

この記事では、自分が仕様策定を行う上で意識している観点と、その観点で考える際に注意していることについてお話しできればと思います。

# 想定読者

- 実務経験1年未満の新米PMの方
- B2B SaaSでPMをやられている方
- なんかよく分からないけど最近こいつ仕様決めているぞ、何を考えているんだ、と思われている弊社の方

# 大切にしている観点

前提として、今から紹介する観点は、「既に複数考えられた仕様案のうち、どれが現時点で最良だと考えられるか」を決める上で使うものになっています。どのような仕様案が考えられるか、仕様を考える前にそもそもこの機能を作るべきか、といった意思決定を行う場合にはまた違った観点や考え方が必要になるかと思います。（機会があればまた別記事に）

では、自分が大切にしている4つの観点をそれぞれ紹介していこうと思います。

## 顧客要望

B2B SaaSの開発においては、顧客からの要望があって機能開発が決まるケースが多く、（※ troccoの場合、新しい転送元・転送先のコネクタを開発する際に参考にさせていただくケースが多いです） まず顧客がどのような要望を伝えているのかしっかりと理解することが大切です。

ここで注意しているのは、「その要望を叶えることで具体的にどのようなユースケースが実現できるのか」「そのユースケースは顧客にとってどれだけ重要か」という点です。

一般的に要望をヒアリングした際に、その要望をそのままの意味で捉えるのではなく、なぜその要望を相手が出してきたのか考えよう、と言われますが、これをもう少し具体化すると「相手が最終的にやりたいことを想像しよう」という意味だと捉えています。

ある機能が欲しい、こういう仕様にして欲しい、といった要望には、その背景に「こういったユースケースを満たしたい」という考えがあるはずです。まずはこうしたユースケースを想像・理解し、**仕様を決める上での論点を「顧客の要望を満たしているか否か」ではなく、「顧客のユースケースを満たしているか否か」のより本質的な方向にシフトさせる**ことが大切だと感じています。

その上で、ユースケースをどこまで満たすべきかを考えるにあたり重要度を論点とします。スタートアップで開発にスピード感が求められる中、全ての要望を受け入れることは難しいため、要望を出している顧客にとってどれだけ重要か、今後利用を考える他の顧客にとっても同じように重要なのか考え、他の観点も考慮しながら対応範囲を決めていきます。

## 競合他社の実装

仕様を決める上で避けては通れないのが競合他社の実装との比較です。競合と比べ、どこまで自社の機能はユースケースを満たせるようになるべきか、満たすユースケースは殆ど変わらなくてもユーザーにとって利用しやすいのはどんな仕様か、を見ていきながら決めていくことになります。

troccoというプロダクトはデータエンジニアリング領域のSaaSになるため、この領域で事業を行なっているプロダクトやサービスは仕様を決める上での参考にさせていただいています。具体的には https://www.moderndatastack.xyz/ に載っているようなプロダクト・サービスは意識することが多いかなと思います。

ここで注意しているのは、「意識しすぎない」ということです。矛盾しているようですが、他社の真似をするだけでは意味がないですし、そもそもいただいている要望が違っていて前提が異なっている可能性があるため、意識しすぎでも無駄なケースも多いと思います。

自分は仕様決めの論点を洗い出すために参考にすることが多いです。**競合他社のどのプロダクトでも同じ仕様になっている部分は特に異論がないでしょうし、逆にある会社では実装しているが、別の会社では実装していない項目があったら、それは自分たちが仕様を決める上でも論点になる項目だろう**、とあたりをつけます。こうすることで効率的に仕様決めを進められると感じています。


## 既存実装との整合性

これは特にtroccoにおけるコネクタ開発の仕様を決める際に意識している観点になります。troccoでは[数多くのコネクタ](https://trocco.io/lp/service.html)を開発しており、新規でコネクタ開発を行う、または既存のコネクタを改修するといったタスクはよく発生します。その際、「これは既存実装で似たようなものがあるな」となるケースがあるので、まず既存実装を参考に見にいくことも大切だと感じています。

ここで注意しているのは、タイトルにもある通り「整合性」です。**既存実装と合わせるように実装する理由は、開発スピードの都合上もありますが、顧客がこの機能で何が出来るのか他の機能から類推できるようになる**、というメリットが大きいと考えています。

troccoというプロダクトの性質上複雑な設定が必要になることもありますが、それでもこれまでtroccoを使ってきたユーザーがスムーズに他の機能も使えるような仕様を意識することで、少しでもユーザーにとって使いやすく、データエンジニアの頼れる右腕になれるようなプロダクトにしたいという思いで開発を進めています。

## 実装・メンテナンスコスト

顧客側の視点に立って考えることは非常に大切ですが、それと同時に開発側の観点も重要だと考えています。開発リソースが限られている中でこの機能開発にどこまで実装コストをかけられるのか、これは後から実装するとしておいても支障はないのではないか、など実装・メンテナンスコストを盛り込みたい機能との天秤にかけて意思決定していくことになります。

ここで注意しているのは、「コストについて自分で考えすぎないこと」「将来的なコストを意識すること」という点です。

自身はデータサイエンティストとして1年半ほどの実務経験はありますが、エンジニアリングについて特段知見がある訳ではなく、工数について正確に見積もることは難しいです。そのため、**自分はこの仕様は勝手に工数が重いと考えていたが、エンジニアの方に相談したらそうでもなかった（逆も然り）といったことが起きる**ので、自分で抱え込みすぎず気軽にエンジニアに相談するように心がけています。

特に弊社のエンジニアは優秀な方が揃っており、仕様の相談すると、実装工数だけでなく、その仕様を採用した場合の懸念点・代替案についても共有してもらえることが多いです。仕様を決める上で自分だけでは考えられていなかった観点も提示してもらえるのでいつも助かっていますこの場を借りて御礼申し上げます🙇

また、コストを考える上では時間軸を意識する必要があります。どうしても現時点で顧客のユースケースをミニマムで満たす選択肢を取りたくなってしまいますが、将来的にこうしたユースケースが必ず発生する、その際仕様を変更する際にこれだけの変更コストが発生するだろう、という将来的なコストも見積もっておき、意思決定の際にはそのコストも考慮する必要があると考えています。

## 最終的にどう決定するか

最終的に仕様を決定する際は、上記の4つの観点と各機能に特有の観点を混じえながら、選択肢に挙がった仕様がどうなのかそれぞれの観点で評価し、最終的に1個に絞り込んでいきます。この絞り込み方には明確な正解はなく、その都度その都度柔軟に対応する他ないと考えています。

重要なのは、現時点で考えるべき観点についてしっかりと情報を集めていることだと思います。それがあれば仕様に迷って他の方に相談しにいく際にも前提がすり合わせしやすいですし、自分なりに意思決定の理由を言語化できるので、他の方に説明し合意形成を行いやすいと考えています。

# おわりに
...ということで偉そうに書き連ねてきましたが、実際にはまだまだ仕様策定フェーズで決めきることができない・時間がかかってしまうことも多く、まだまだ自分自身学ぶことが多いなと感じています。

そんな新米PMではありますが、周りのビジネスメンバー・開発メンバーが 優秀 & コミュニケーションが取りやすいことでなんとかやっていけています。
PM未経験だけれども挑戦したい方、既にPMとして働かれていて、より面白いプロダクト、メンバーと働きたい方には滅茶苦茶おすすめできる環境ですので、是非[こちら](https://herp.careers/v1/primenumber/requisition-groups/ebc961e9-a474-4cc4-a426-5d49944f6c02)からご応募ください！（PM以外も募集しております！ ぜひお気軽にご応募ください）