私は現在SaaSのPdM(プロダクトマネージャー)として製品をどう進化させるべきか考える仕事をしているのですが、私がPdMになってみて困ったのがフィジビリ（※）でした。
SaaS業界の経験がそもそも浅く、さらにPdMになったばかりの私にとっては新機能の検討にあたりフィジビリをやった方が良いというのは知識として知ってはいたもののじゃあ具体的にどうすれば良いのか？については全然分かりませんでした。
ネットや書籍で調べてみても概念的で抽象度の高い情報しか得られず、「そうじゃないんだよ！もっと具体的な情報をくれよ！」と強く感じたので、今後他の人が同じ悩みを持たなくて済むように自分がフィジビリを経験したら具体的にまとめようと決めてました。
私自身がPdMとしてヒヨッコなのでベテランから見れば「もっと良い方法あるよ」という感じだとは思いますが、あくまで一つの意見としてこんな感じでフィジビリやってるよ！というのをご紹介するのが本記事の趣旨ということでどうか怒らず優しい目でお願いします。
そもそもベテラン勢の皆さんがきちんとやり方を発信してくれていたら私も最初から困ってない（八つ当たり）ので、この記事を読んで「いやいやこいつ分かってないな」と思うレベルの人はぜひご自身のやり方をどこかで発信してください。
私ももっと勉強したいです。
なぜやる必要があるのか（目的）
フィジビリをやる理由はなんなのか？
本質的に言えばその機能が市場で受け入れられるのかあるいは受け入れられるのに必要な条件を検証するため的なことだと思いますが、会社員的に言えば開発する許可をもらうために必要な情報を取る手段という感じでしょうか。
新機能の開発にはとてもお金がかかるので、その機能を開発することで本当に市場から受け入れられるのか？や、今想定している運用で問題ないのか？などは事前にクリアしておかないと経営としてもその案件の開発にGOは出せません。
結局のところはリリースしてみないと本当のデータは取れないのですが、投資コスト（＝開発コスト）を上回るだけのメリットが出せそうだということを開発前になんとか少しでも確認しておきたい、あるいはメリットを出すための必要条件を洗い出したい、という状況で行うわけですね。
なので全部の開発案件についてフィジビリを実施するわけではなく、想定される使い方や提供する価値の新規性が高く、本当にその機能で狙った価値が提供できるのか不確かな新機能案についてフィジビリをやる感じです。
例えばですが、ダッシュボード上で現状は日付順でソートできるようになっているけど名前順ではソートできない、という状況で「お客さんからの要望が多いから名前順でもソートできるようにしよう」というような案件の場合にはフィジビリはやらないです。
すでにやっている機能の延長なので新規性が少なくどんな要件で作ればどんな価値を提供できるのかもイメージしやすいからですね。
逆にフィジビリが必要な案件がどんな場合かでいうと、ダッシュボード上で対象者を探す際に「ダッシュボードを閲覧している人が見たそうな人を自動でレコメンドする」機能の開発を考える場合ならフィジビリが必要になります。
この場合、レコメンドの精度というかレコメンドされた人がどれくらい探したい人のイメージに近いのかあたりはリリース前に確認しておきたいので実際にフィジビリで検証しておくというイメージでしょうか。
どのタイミングでやるのか
フィジビリを行うタイミングとしては机上での機能構想が固まった後です。
こんなアイデアがあったらいいなと思いついてすぐだとフィジビリやれるほどの具体的な情報が固まってないのである程度アイデアが固まってからフィジビリすることになります。
ではどれくらいアイデアを固めておく必要があるのかについて具体的に説明していきます。
前提として、レコメンド機能の開発で上の人からGOを出してもらうためにはざっくり分けると「レコメンド機能の開発にかかるコストがどれくらいか」と「レコメンド機能を開発して期待できる事業影響（売上など）はどれくらいか」の情報が必要となります。
それら二つの情報について机上の仮説だけでなくより信頼度や精度を上げるために行うのがフィジビリです。
まず開発コストを明確にするにはその機能の仕様を具体的に決めなくてはなりません。
例えばレコメンド機能はダッシュボードにログインしたら自動で表示されるのか、あるいはどこかの画面からボタンを押すと表示されるのかなどUIUX観点でいくつも選択肢が考えられると思います。
では実際にどの仕様が良いのかについては机上では考えられるものの顧客に受け入れられるのかについてはフィジビリを通じて検証した方が良いので機能の仕様に関して想定される選択肢と現状考えられる最適な選択肢まで仮説として具体化しておいてからフィジビリに入るイメージです。
また、期待できる事業影響という観点で言えばどんな属性の企業にどんな課題があり、どんな価値を提供することで、どんな事業KPIにどれくらいの効果が期待できるのか、という仮説作りは終えてからフィジビリを通じて検証するという流れになります。
レコメンド機能の場合、例えば「人事が新設部署の人員確保のために社内異動で誰を異動させるべきか考えるのが大変」という課題があったとして、「レコメンドすることで適切な従業員を探す手間を半分に削減できる」という価値を提供し、それにより「解約率を5％減らせる」という仮説を立てます。
それらは現状仮説でしかないので、その仮説のまま開発〜リリースまで行ってしまうと実際には見立てた通りの効果が出ない可能性があります。
なので仮説を固めた上で開発する前に「本当に仮説通りにいきそうなのか？」を確かめるためにフィジビリを行う感じです。
まとめると、フィジビリをやるタイミングは「机上で考えられることは全て考えた。あとは実際に検証してみることでしか情報が得られない。」というフェーズになってからということになります。
どうやるのか
ではここから具体的にどうやるのか説明していきます。
目的を明確にする
まずはフィジビリの目的を明確にする必要があります。
レコメンド機能であれば「実際にレコメンドした内容が顧客にとって使えるものになっているか？」や「レコメンドによって従業員を探す時間がどれくらい減ったか？」などがフィジビリ目的として考えられます。
評価基準を決める
検証目的を決めたら次は検証結果を評価するための評価基準を決めます。
検証目的が「実際にレコメンドした内容が顧客にとって使えるものになっているか？」なら、「レコメンドした100人の中で90人以上で納得感を感じてもらう」などと評価基準を決めます。
その場合、仮に評価基準に満たなかった場合でも「企業から良いと評価された人数が90名未満だった場合には評価が悪かった人物についてそれぞれ理由を洗い出し、ロジックの改善を試みた上で再度確認してもらってOKをもらいにいく」などとネクストアクションまで決めておくようにするとスムーズです。
検証環境を準備する
検証環境も整えておく必要があります。
レコメンド機能であればレコメンドを体験できるように「これが入力されたらこれをレコメンドとして出力する」というロジックをまず決めます。
検証目的が仮に「こちらが決めたレコメンドのロジックはお客さんにとって有益な精度になっているか？」を検証する場合なら、ミニマムでの開発が許されるなら入力に対して出力結果を返すだけの簡単なフォームを作っても良いと思いますし、それができなくてもエクセルのマクロでも似たようなことができると思います。
あるいは何もそうした技術的なことをしなくても条件分岐のロジックを図に書いてみて、人が手作業で判断できるようにするでも全然オッケーです。
例えば「人事が新設部署の人員確保のために社内異動で誰を異動させるべきか考えるのが大変」という課題へのレコメンド機能なのであれば「募集部署が営業系の場合、保有スキルに営業が含まれている＆直近の人事考課で最高評価をとっている人をレコメンドする」みたいなロジックが考えられると思います。
協力してくれる企業を探す
フィジビリに協力してくれる企業も見つけないといけません。
協力企業の数は多い方が検証の確実性の観点から言えば望ましいもの、現実的には検証に協力してくれる企業がそんなに見つからなかったりそもそも自社の検証に割ける人手が足りなかったりするので数社くらいの企業で行うケースが私の場合には多いです。
ただ、レコメンド機能の場合にはレコメンドの精度の確らしさを確認する必要があるのでもしかすると数社では足りないかもしれません。
その検証目的の達成に必要なサンプル数は意思決定権を持っている上の人と調整をしながら決めていくのが良いと思います。
協力企業の探し方としてはカスタマーサクセスにまず「レコメンド機能を検討してるんだけど検証に協力してくれる企業に心当たりない？」と相談します。
すると「A社なら興味を持ってくれるかも！」みたいに何社か候補がリストアップできるので、それらの企業に対して検証の目的や協力して欲しい内容をまとめた資料を作り、カスタマーサクセスを通じて検証に協力いただけないか打診してOKをもらうという感じです。
覚書を締結する
検証に協力してくれるところが見つかったらその企業と覚書を結び、得たデータの利用目的などについて合意しておきます。
今回で言えばレコメンド機能の検証以外に使いません、みたいな内容です。
検証を開始する
覚書まで締結できたら実際に検証を開始！
異動候補者のレコメンドをするために社員の経験や評価データを使うという場合なら、企業から実際に個人を特定できない形で社員ごとの経験や評価データをもらい、そのデータをもとに既に決めたロジックに従ってレコメンドする社員を特定します。
もらったデータをもとにレコメンド対象者を特定したら企業に「この人がレコメンド対象として上がってきたのですが実際見てみてどう思いますか？妥当だと思いますか？微妙な点はどこら辺ですか？」などとヒアリングしてみたり、定量的に見る上では「レコメンドされた100人の中でOKをもらった人数」を計測してみても良いでしょう。
検証結果を評価する
検証を一通り終えたら検証結果を評価します。
予めて決めておいた評価基準に則ってその検証が合格なのかどうか判定します。
一度不合格となった場合でもそれで終わる必要はなく、あらためてレコメンドロジックを修正することで企業からの評価を上げられるかどうかも検証していけばOKです。
ただ企業からのフィードバックを受けても改善できる見込みが全く持てない場合にはそこで検証を終了し、機能の開発自体も断念するか大きく方針転換を検討する必要が出てきます。
まとめ
フィジビリの具体的なやり方についてご紹介しましたが、実際にはいろんな方法があるのだと思いますのであまり今回ご紹介した方法にとらわれることなくより効率の良い方法を見つけていってください。
そして良い方法を見つけたらぜひ教えてください。
