【Quipperブログ】ドメイン知識を使いこなせ！

こんにちは。Quipper採用担当の鈴木です。今回の記事は、@shunsuke-nishimura による「ドメイン知識を使いこなせ！」です！是非、ご覧ください！

こんにちは。

今回は筆者のロールであるPMとして企画領域における要件定義と、開発領域における基本設計に対して

筆者が日々どのように進めているのか
どのようなことがうまくいってるのか
ダメな点はなにか

について書きたいと思います。

PMとして、と書きましたが広義の意味でのPMを指しており、それぞれの組織においてPdM、PjM、PgM等と適宜置き換えていただいて構いません。

どんな人に読んでほしいか

PMとしてチームに参画しているけど、企画のプロでもなく製品開発のプロでもないので、狭間で思い悩んでいる方
↑のようなPMとのコミュニケーションが多いけど、期待に対してうまくPMが動いてくれない方

書かないこと

開発プロセス、プロジェクト管理などの時系列に関連する業務ナレッジ
コミュニケーションが解決する領域
ドキュメントの書き方

TL;DR

ドメイン知識にはマーケットドメインと製品ドメインの両面があるよ((どちらも私の造語のようなので利用の際はご注意ください))
要件定義ではマーケットドメインが、基本設計では何を明確化するかによってマーケットドメインと製品ドメインの両方が重要だよ

要件定義と基本設計とは

まずはそれぞれがどんなことを指しているのかを明確にしましょう。

先人に従ってググってみることにします。

が、それぞれの用語でググってもそれらしいものがパッと見つからなかったので、辞書的に見ていきましょう。

要件定義

要件:
    １ 大切な用事。「要件のみ記す」
    ２ 必要な条件。「教育者としての要件を満たす」
定義:
    １ 物事の意味・内容を他と区別できるように、言葉で明確に限定すること。「敬語の用法を定義する」
    ２ 論理学で、概念の内包を明瞭にし、その外延を確定すること。
　　　　通常、その概念が属する最も近い類と種差を挙げることによってできる。

引用：要件（ようけん）の意味 - goo国語辞書、定義（ていぎ）の意味 - goo国語辞書

何が何やら、という感じですがザックリ自分の認識も混ぜて言葉にすると、

何をしたいのか、重要なのは何か、なぜそれが重要なのかを明確に言葉で表すこと
つまりWhatとWhyを明確化すること

とここでは指そうと思います。

基本設計

基本:
    １ 判断・行動・方法などのよりどころとなる大もと。基礎。「基本の型」「基本を身につける」
　　　「基本に忠実な演技」
    ２ （副詞的に用いて）基本的に。原則として。「基本、先発メンバーは固定している」
設計:
    １ 建造物の工事、機械の製造などに際し、対象物の構造・材料・製作法などの計画を図面に表すこと。
　　　「ビルを設計する」
    ２ 一般に、計画を立てること。また、その計画。「老後の生活を設計する」

引用：基本（きほん）の意味 - goo国語辞書、設計（せっけい）の意味 - goo国語辞書

こちらも自分の認識も混ぜて言葉にすると、

要件を満たすための大元の仕組み、条件、影響範囲を明らかにして、どのように進めたらいいかを決めること
つまりWhatの条件を明らかにして、Howの素案及び影響する領域を明らかにすること

とします。((本来の意味での基本設計はもう少し製品に踏み込んでいることは理解しつつ、ここでは都合上この辺りに留めていることをご了承ください))

どうやって要件定義をやるか

弊社ではスタディサプリという教育サービスの製品開発をしております。

基本的な製品・案件の企画はビジネスサイドのメンバーが行うことが主であり、大方の要件は固まった状態で案件として話が始まります。

その多くは、現状の製品に対しての「不」を解決することで、初回課金率を向上させたり、エンゲージメントを高めて継続課金率を上げたり、とビジネスKPI及びプロダクトの質に影響するものとなります。

しかし、ここでよく発生するのが、そういったWhatやWhyを明示せずに、Howに落とし込まれた状態でスタートしてしまう、というケースです。

例えば、

合格特訓ユーザーに夏休み期間中にコーチからだけでなく機械的にメッセージを送ってスタサプへの
リテンションを高めたい（注：この例は仮のため実際のスタサプの機能・状況とは関係ありません）

というものがあったとします。((合格特訓ユーザーはスタディサプリ大学受験講座の合格特訓コースに入会しているユーザーのことを指しています。))

しかし、これではなぜリテンションを高めたいのか、なぜ夏休み期間中に特化しているのか、機械的にどんなメッセージを送りたいのか、などがわかりません。

この案件を掘り下げて本当にしたいことは何なのか、背景はなにか、を検証すると

合格特訓の生徒として、夏休み期間中にモチベーション高く勉強を続けられるようにしたい、
なぜなら夏休みは時間がたくさんあるので、多くの生徒がサボりがちになってしまうからだ

というものが出てきます。

ここで重要なのは、常にWhatやWhyを明らかにする意識を持つこと、案件自体がHowになっていないかを意識することです。

今回の例のようにスクラム式のストーリー形式に言葉を置き換えてみると、何をしたいのか、なぜしたいのかを簡単に明らかにできると思います。

マーケットドメイン知識はどう使えばいいの？

WhatとWhyを明らかにするまでは実はそんなに難しくはありません。

本当に重要なのはこのWhyのターゲットユーザーは誰なのか、本当にこのような「不」を抱えているのか、を考えることです。

今回のケースであれば、

ターゲット：合格特訓ユーザー
時期：夏休み
抱えている「不」：夏休みにサボってしまう

となります。

夏休みにサボる、は多くの読者が経験していると思うので疑いようのない事実にも感じます。

しかし、ターゲットが合格特訓ユーザーとなると話は変わってきます。

合格特訓は高3生の受講者が多い商品なので受験を目前に控えています。さらに、既にコーチが付いていて、学習へのモチベートもされ続けています。

果たしてそのような生徒が本当にサボってしまうのでしょうか？

ここに対しての疑問が生じれば、後は過去の合格特訓ユーザーの夏休みのスタサプ利用時間を夏休み前後と比較してみたりすれば結果はすぐに分かります。

その結果、そもそも要件定義自体が間違っている、ということが導かれる可能性があります。（もう一度書きますが、この案件は本ブログのために筆者が適当に考えたものなので、スタサプの機能・状況とは一切関係がありません）

マーケット、つまりユーザーに対しての理解がなければ疑問は生じず、そのまま需要のない機能を作ることになりかねません。

PMは常にマーケットのことを意識して、それがユーザーにとって意味のあるものなのか、意味のある形での機能になっているのかを考えなければなりません。

どうやって基本設計をやるか

WhatとWhyは明確化されました。さて、設計をしましょう。

提供するユーザーの条件を整理して、どんなメッセージを表示するのかを考えて、、、とするにはまだ早いです。

まだ抽象度の高いWhatに対しての素案（How）がイケているかどうかの検証が出来てないですよね。

合格特訓の生徒が夏休み期間中にモチベーション高く勉強を続けられるようにしたい
に対して、

コーチからだけでなく機械的にメッセージを送る
は適切なのでしょうか？

「夏休みだ！よしやるぞ！」とユーザーに思ってもらうのです。「機械的にメッセージを送る」のが正しいでしょうか？

また、ユーザーは合格特訓ユーザーです。商品購入動機としてもコーチによるサポート、つまり人によるサポートがあることをメリットと考えているユーザーが多いはずですね。

そうなると、このHowはイケてないように見えますね。

では、どんなHowがイケてそうでしょうか？

いろいろありそうですが、ここでは

人によるサポートが重要
夏休み、という学生にとって特別な期間

というのをベースに考えると、

合格特訓ユーザーに夏休み限定、講師出演の「夏休みの時間の使い方」動画を受講出来るようにする

というような方がイケてそうですね。今回は例なので一旦この辺りにHowの素案をおきます。

この時点ではマーケットドメイン知識を使っています

気づいた方もいると思いますが、この時点では製品ドメイン知識はほぼ使っていません。

むしろ、ユーザーにウケるのか、ハマるのかを突き詰めて考えるフェーズになるため、マーケットドメインのほうが重要なのです。

Howを考え出した瞬間に製品のことを考え出すことが多いですが、

これが一番の間違いで、無数ある中からどんなHowを選ぶのか、においてはマーケットを考えなければいけないのです。

製品ドメイン知識はどう使えばいいの？

素案は出来ましたが、実際のそれをユーザーにどう提供するのかを決めなければ、製品は作れません。

考えなければならないことは例えば下記のようなことです。

* 提供する期間
* 対象のユーザー
* リリース時期・コンテンツの入稿時期
* 訴求の仕方
* 利用デバイス間で差異がないか

それぞれに対して、下記のような考えが発生します。

* 提供する期間
    * いつからいつまで提供するのか
        * 既存の仕組みで、リリースとは別にコンテンツをピンポイントで提供・停止することはできるか
* 対象のユーザー
    * スタサプの中での対象のアカウント属性は何か
        * 小中高ベーシック・中学個別指導・団体会員のユーザーはどんな体験になるか
* リリース時期・コンテンツの入稿時期
    * リリースはいつか、コンテンツが出来あがるのはいつか
        * 入稿部分に修正は不要か、追加開発の必要はないか
* 訴求の仕方
    * 講座を追加するだけで足りるのか、どのように訴求をするのか
        * オススメ講座のような機能はあるか、拡張可能か
* 利用デバイス間で差異がないか
    * ユーザーの体験は同じでよいか
        * 既存製品が既に同じ体験になっているか、アプリのNotificationなどの考慮は不要か

ここで記載した最下段の「 * 」は全て製品ドメインがないと考慮・調査できないことです。((中学個別指導はこちら、団体会員はこちらをのユーザー指しています。))

団体会員ユーザーというものが存在するということを知らないと、対象のユーザーの考慮不足が発生しますよね。

これによって見積もりの精度も変わりますし、素案に対しての費用対効果が高いのか、低いのかが大きく変わります。

結果的に、コスパが悪いから異なるHowにする、という結論が得られることもありえます。

製品ドメインをどれだけ知っているかが、最終的な品質だけでなく、やるかやらないのかにも影響するわけです。*5