最新情報をお届けします！
マーケティング・不動産・介護などDX推進で存在感を高めるSpeee社。DX事業本部・新規事業専任PMが塚本尚さんだ。彼がPMとしてやってしまった、エンジニア、ビジネス、システム、それぞれへの「決めつけ失敗談」とは！？
※2021年12月14日に開催された【開発PM勉強会】 株式会社Speee、塚本尚さんによる「3つの決めつけから見る失敗の要件定義」セッションを書き起こし形式でお届けします。記事内では「PM＝プロダクトマネージャー」として表記しています。
はじめまして、Speeeで新規事業のPMをしている塚本と申します。現在、3つ目の新規事業に取り組んでおり、絶賛グロース中のサービスに関わっているPMです。
本日は「3つの決めつけから見る、失敗の要件定義」と題して発表させてください。
…さて、突然ですが、「要件定義」とは、一体何を定義することでしょうか？
この問いに対して、私なりに辿り着いた答えを、今回のテーマにしようと思いました。それが「WhyとWhatをしっかり定義すること」です。
この後にも出てくる「How」の意味と合わせて、定義をしておくと、
・Why：実現させたい理由や背景
・What：実現させたいこと。またはその条件。
・How：その条件を満たすための方法
を意味する、としました。
PMやプロダクト開発に関わってる方であれば当たり前の定義だと思うのですが、私はここに至るまでにかなり失敗をしていて。その体験から学んだこと、特に「決めつけによる失敗」の話ができればと思います。
さっそく「決めつけによる失敗」ですが、具体的には「Howへの決めつけ」をしてしまっていました。特に3つあると思っていて、
・エンジニア側への決めつけ
・ビジネス側への決めつけ
・既存のシステム・仕様への決めつけ
です。ちなみに先に補足をしておくと、「ビジネス側への決めつけ」は、「ビジネスオーナー、事業責任者とやり取りする時の決めつけ」です。
この3つの決めつけによって、見事に要件定義に失敗しました。ここから具体的に見ていければと思います。
まずは話のタネになるところなので、私が関わってるサービスの簡単なフローをご説明します。
▼ユーザーが記事・広告を見る
▼サービスサイト内に入ってくる
▼サービスLPを通して入力フォームを経由する
▼その後会員登録を完了させる
▼その後、参画企業様にご紹介する
いわば、BtoBtoCサービスをイメージいただくといいと思います。このようなサービスでの失敗談をお伝えします。
まず1つ目が「エンジニア側への決めつけ」ですが、やってしまった失敗は「Whatが抜けたHowの連携をした」です。
例えば、先ほどのBtoBtoCサービスでは、記事広告からLPに遷移する際、どの記事広告経由かを識別するためのパラメーターを振るのですが、私から「会員登録完了時点で、そのパラメーターをデータベースに格納したい」と連携をしました。それをエンジニアに実装してもらったのですが、私が提案した方法＝Howでは、パラメータの形式や遷移方法によってはデータベースに格納されないことが後からわかりました。
この時に「ハッ」としたんですよね。「What」を連携した上で、開発チームとしてHowを検討すべきだった。にもかかわらず、私自身が「How」を決めつけ、実装まで連携してしまった…。
あるあるの話だと思いますが、身を持って知れたのは大きかったと思います。改めて、
Howではなく、WhyとWhatに強く向き合うべき
これが教訓として残りました。
実現したいWhatに対し、私たちがエンジニアレベルで仕様を細かく把握しているわけではありません。そのWhatの実現に対し、Howの検討が充分ではありませんでした。
失敗その2は、「ビジネス側へのHowの決めつけ」がありました。やってしまった失敗は「Whatを充分理解しないまま、Howを決めつけてしまった」です。
1の失敗とも関連するのですが、先ほど「記事からの流入によって会員登録された時」を想定し、エンジニアに「パラメータをデータベースに格納できるようにしたい」と連携をしました。
ただ、その後、広告を増やしたことで、広告を含む別の流入経路から会員登録された時は、パラメータが引き継がれていないことがわかったのです。
ここでもまた「ハッ」としました。なぜ、失敗したか。すごくシンプルで、単に考慮が漏れていたのです。ここからの教訓としては、
ビジネス側とPM（私）で、今考えている「What」が必要充分か、すり合わせるべきだった
ということです。私たちPMは、自分の考えている「What」が実現したいことに対して、充分なものか、ここに注力すべきだと感じました。
実現方法を考える開発チームにおいて「What」に強く責任を持つ。ここができるのは、あくまで私たちPMだからです。
もちろん、開発チーム全体で「What」を考え直したり、そもそも「Why」についてもちろん議論もしますが、その中で、
Whatに1番強く責任を持てるのはPM
というのが教訓となりました。
最後に失敗その3として、既存のシステム・仕様への決めつけによって失敗してしまった例を話します。
ここでやってしまった失敗は、「既存の仕様を活用できるはずだ」と決めつけたことです。やってしまったことだけ見ると「あるある」です。
・企業の「契約ステータス」管理する仕組みが既存であった
・その仕組みを使い、既存企業の情報掲載ページの公開・非公開を制御してほしいとオーダーした
・結果、その情報掲載ページは意図通りに制御されなかった
この失敗の要因は「既存の仕様が、作った当時に定義した通りの使い方で利用されているはずだ」と思い込んでいたところにありました。もともと企業の契約ステータスを管理する仕組みを用いる条件だったのですが、過去定義した通りに利用されていなかった、というオチでした。
ここからは、
既存の仕様が、現在どのように利用されているか、ちゃんと把握すべきだ
が、教訓になりました。
ポイントは「現在どのように？」だと思います。過去に定義した通りに使われていれば、うまくいった可能性もあったかもしれません。現在利用しようとした時のオペレーション、使われ方が変わっていたことが盲点でした。
当然、プロダクト上、オペレーションに関わる部分で、想定外の用途で利用されることも充分に有り得るので、そこも学びになりました。
このような現状の仕様、システムへの決めつけがチームで「How」を検討する余地を無くしてしまった。ここも教訓として残ったという感じです。
これは私自身の捉え方ですが、
・要件は実現したいことを出すために必要な条件・仕様は条件を実現する方法
こう捉えており、「Howへの決めつけ」は「仕様の決めつけ」でもありますよね。
先ほど言及したところですが、私自身、エンジニアレベルで細かく仕様を把握しているわけではありません。ですので、現状の「How」を活用できるか、自身だけで判断すべきではないと思っています。
そういった時に特に重要になるのが、ディスカッションすることで、その「How」が活用できるか、どの「How」がいいか、を話していくこと。
最後にこの発表のまとめです。
PMによる「Howの決めつけ」でプロダクトが失敗する確率って相当高くなってしまうのでは？と、私自身、体験から感じました。
なので、改めてですが、PMは「Why」とか「What」の定義をしっかりすべきであり、「How」は対話とかディスカッションを通し、チームに委ねる。「How」はチームに属するものだと肝に銘じ、プロダクト開発を進めるのがいい。これらの失敗から学んだことになります。これで発表を終わりたいと思います。ありがとうございました！
（おわり）
編集 ＝ CAREER HACK
4月から新社会人となるみなさんに、仕事にとって大切なこと、役立つ体験談などをお届けします。どんなに活躍している人もはじめはみんな新人。新たなスタートラインに立つ時、壁にぶつかったとき、ぜひこれらの記事を参考にしてみてください！
経営者たちの「現在に至るまでの困難＝ハードシングス」をテーマにした連載特集。HARD THINGS STORY（リーダーたちの迷いと決断）と題し、経営者たちが経験したさまざまな壁、困難、そして試練に迫ります。
Notionナシでは生きられない！そんなNotionを愛する人々、チームのケースをお届け。
