要件定義とは何を定義することか？
塚本尚氏（以下、塚本）：初めまして、Speeeの塚本と言います。今は新規事業のプロダクトマネージャーをしています。プロダクトマネージャーを始めて3つ目の新規事業で、絶賛グロース中という感じのサービスに関わっています。今回は、タイトル「3つの決めつけから見る失敗の要件定義」と題して発表します。
さっそくですが、要件定義って何を定義することなんでしょうか。、2枚目にこの問いを入れたことをちょっと後悔していますが、この問いに僕なりにたどり着いた答えを、今回発表のテーマにしようかなと思いました。
僕は、「WhyとWhatをしっかり定義することだ」という答えに至りました。ここで言ってるWhyとWhatみたいなところは、Whyは実現させたい理由や背景で、Whatは実現させたいこと、またはその条件です。このあとHowの話も出てくるので意味をお伝えしておくと、その条件を満たすための方法みたいなところを意味しています。
この答えというか、僕がここで大事にしたいことと言ってるのは、たぶんPMのみなさんや、プロダクト開発に関わってるみなさんは十分承知の上かと思いますが、僕がこの答えに至るまでにけっこう失敗をしてきてしまったので、その失敗をとおした学びとして、この答えにたどり着いた過程が少しでも伝わればいいかなと思います。
3つのHowへの決めつけ
今日は、決めつけによる失敗の話をします。その決めつけは、Howへの決めつけでした。そのHowへの決めつけは3つあると思っていて、1つ目はエンジニア側への決めつけです。2つ目がビジネス側への決めつけ。ビジネスオーナーや事業責任者みたいなところの方とやり取りすることはもちろんあるので、そこの方々と話してるときの決めつけという感じです。3つ目は既存のシステム・仕様への決めつけ。この3つによって要件定義が失敗した、ということがあったので、この話をします。
僕が関わってるサービスの全部ではありませんが、今回の話の種になるようなところの、簡単なフロー図を説明します。ユーザーさんが記事や広告を見て、サービスサイト内に入ってきて、サービスLPをとおして入力フォームを踏んで、そのあと会員登録を完了すると。
そのあと参画いただいてる企業さまにご紹介するような、いわゆるBtoBtoCサービスみたいなものをイメージしてもらえるといいかなと思います。このようなサービスに関わったときの、実際の具体的な失敗談みたいなものをお伝えできればと思います。
エンジニア側へのHowの決めつけ
まず1つ目、エンジニア側への決めつけというところで、やってしまったこととしては、Whatが抜けたHowの連携をして失敗しました。
具体的には、先ほどのBtoBtoCサービスで記事広告からLPに遷移するときに、どの記事広告経由かを識別するためのパラメーターみたいなものをつけるため、会員登録完了時に、そのパラメーターをデータベースに格納するようにしたいという連携を僕からしました。実際にそれをエンジニアに実装してもらいましたが、僕が提案した方法だと、パラメータの形式や遷移方法によってはデータベースに格納されないことが分かったんです。
このときにハッとして。これがなぜ失敗だったかと言うと、Whatを連携して自分の開発チームでHowの検討をすべきだったのにも関わらず、僕自身がHowの決めつけをして、実装を連携してしまったんです。
先ほどの例だと、遷移するときにパラメーターをつけるので、会員登録時に格納してほしいみたいなところまでのwhyとwhatに対して限定的なhowが実現されてしまった。つまり、Howを決めつけで連携してしまったのが失敗でした。あるあるの話だとは思いますが、Howではなく、WhyとWhatに強く向かうべきだというのが、教訓として自分の中に残りました。
実現したいWhatに対して、僕たちがエンジニアレベルで仕様を細かく把握してるわけではないというのがあるので、Whatの実現に対して、Howの決めつけが十分ではなかったということが教訓としてあります。ここまでがエンジニア側への決めつけでした。
ビジネス側へのHowの決めつけ
失敗の2つ目として、ビジネス側へのHowの決めつけがありました。ビジネス側への決めつけでやってしまったのは、Whatを十分理解しないまま、Howを決めつけて失敗してしまいました。
先ほどの例ともちょっと近いですが、僕は記事から流入して、会員登録されたときを想定して、パラメーターをデータベースに格納できるようにという連携を実際にエンジニアにしました。ただ、そのあと増えた広告という別の流入経路から会員登録されたときは、パラメーターが実際に引き継ぎできていないことがわかりました。正直ハッとしました。
これがなぜ失敗だったのかは簡単で、考慮が漏れていた、考慮できてなかったというのが失敗の原因でした。ここからの教訓としては、ビジネス側とプロダクトマネージャーの僕で、今考えてるWhatが必要十分かどうかを十分に擦り合わせるべきだったと感じました。
僕たちのようなプロダクトマネージャーというのは、自分の考えてるWhat、実現したいことに対して、十分なものなのかということに注力すべきだなと感じました。
実現方法を考える開発チームにおいて、Whatに強く責任を持っているのは、あくまで僕ら、つまりプロダクトマネージャーだと思いました。もちろん開発チームみんなでWhatを考え直したり、そもそもWhyについて議論をすることはありますが、その中でWhatに一番強く責任を持てるのは、僕らしかいないということがここでの教訓となりました。
システム・仕様への決めつけ
ここまでがビジネス側への決めつけというところで、最後に3つ目の失敗として、既存のシステム・仕様への決めつけがあって、失敗してしまった例をお話しします。
ここでやってしまったことは、既存の仕様を活用できるはずだと決めつけて失敗しちゃったことです。このやってしまったことだけ見ると、あるあるなんじゃないかと、個人的には思うところがあります。
僕の例だと、先ほどのBtoBtoCサービスの企業さん側のところですが、企業の契約ステータスを管理するような仕組みが既存であり、その仕組みを用いて、既存の掲載企業の情報掲載ページの公開・非公開を制御してほしいというオーダーを僕からしました。結果的に、その情報掲載ページが意図どおりに制御されないことが起きました。
なぜこれが失敗だったのかというと、既存の仕様が作った当時定義したとおりに利用されているはずだと思い込んでいたからです。もともと企業の契約ステータスを管理する仕組みのようなものを用いるというような条件でやっていました。既存の契約ステータスみたいなものを用いることをやりましたが、その仕様が過去定義したとおりに利用されているはずだと思い込んでいて、その結果、失敗してしまったというのがここでのオチみたいなところです。
ここから、既存の仕様が現在どのように利用されているかをちゃんと把握すべきだなというのが教訓になりました。ポイントは、「現在どのように」というところかと思っていて、過去に定義したとおりに使われてたらうまくいってた可能性もあるという。
確実にそのとおりにされてたらうまくいっていましたが、今現在、利用しようとしたときのオペレーションや、使われ方みたいなのが変わっていた。そのため、現在どのように利用されてるかみたいなところも、しっかり把握すべきだと思いました。オペレーションが変わることとか、想定外の用途で利用されてることはプロダクト上あるかなと思っていて。それも教訓になりました。
このような現状の仕様やシステムへの決めつけが、チームでHowを検討する余地をなくしてしまっていたというのも教訓として残ったという感じです。
（スライドを指して）僕自身は要件とか仕様をこのように捉えていて、要件は実現したいことを成すために必要な条件で、仕様は条件を実現する方法だと割り切っているというか、捉えると。
Howへの決めつけは、仕様の決めつけである。先ほども言及したところですが、仕様をエンジニアレベルで細かく把握してない部分がどうしてもあるので、その現状のHowを活用できるかどうかみたいなものは、自分自身だけで判断すべきではないと思っています。
（他セッションで）発表されたみなさんも、よくキーワードとして挙げていたのが、対話みたいなところだったと思います。対話によってとか、ディスカッションすることによってHowが活用できるかとか、Howがそもそもいいかみたいなものを話していくべきだなと感じています。
PMがHowを決めつけてしまったら失敗する
最後に発表のまとめです。Howの決めつけによるプロダクトの失敗確率は、相当高いんじゃないかと、この失敗を経て特に感じました。PMがHowを決めつけてしまっては、失敗すると言えるんじゃないかなと思います。
なので、WhyやWhatの定義を僕ら自身はしっかりすべきであって、Howは対話やディスカッションをとおしてチームに委ねて、How自身をチームに属するものだと肝に銘じて、プロダクト開発を進めていくのがいいんじゃないかというのが、これらの失敗から学んだことになります。
最後に、Speeeでも一緒にサービス開発を推進してくれる仲間を募集しているので、興味を持ってもらえればと思います。
（スライドを指して）このようなDXデモクラシーを掲げて、今まで恩恵を受けづらかったような領域に対して、価値提供するようなプロダクト開発もやってるので、興味あればよろしくお願いします。これで発表を終わりたいと思います。ありがとうございました。
