こんにちは。
今回は筆者のロールであるPMとして企画領域における要件定義と、開発領域における基本設計に対して
- 筆者が日々どのように進めているのか
- どのようなことがうまくいってるのか
- ダメな点はなにか
について書きたいと思います。
PMとして、と書きましたが広義の意味でのPMを指しており、それぞれの組織においてPdM、PjM、PgM等と適宜置き換えていただいて構いません。
どんな人に読んでほしいか
- PMとしてチームに参画しているけど、企画のプロでもなく製品開発のプロでもないので、狭間で思い悩んでいる方
- ↑のようなPMとのコミュニケーションが多いけど、期待に対してうまくPMが動いてくれない方
書かないこと
- 開発プロセス、プロジェクト管理などの時系列に関連する業務ナレッジ
- コミュニケーションが解決する領域
- ドキュメントの書き方
TL;DR
要件定義と基本設計とは
まずはそれぞれがどんなことを指しているのかを明確にしましょう。
先人に従ってググってみることにします。
が、それぞれの用語でググってもそれらしいものがパッと見つからなかったので、辞書的に見ていきましょう。
要件定義
要件:
１ 大切な用事。「要件のみ記す」
２ 必要な条件。「教育者としての要件を満たす」
定義:
１ 物事の意味・内容を他と区別できるように、言葉で明確に限定すること。「敬語の用法を定義する」
２ 論理学で、概念の内包を明瞭にし、その外延を確定すること。通常、その概念が属する最も近い類と種差を挙げることによってできる。
引用：要件（ようけん）の意味・使い方をわかりやすく解説 - goo国語辞書、定義（ていぎ）の意味・使い方をわかりやすく解説 - goo国語辞書
何が何やら、という感じですがザックリ自分の認識も混ぜて言葉にすると、
- 何をしたいのか、重要なのは何か、なぜそれが重要なのかを明確に言葉で表すこと
- つまりWhatとWhyを明確化すること
とここでは指そうと思います。
基本設計
基本:
１ 判断・行動・方法などのよりどころとなる大もと。基礎。「基本の型」「基本を身につける」「基本に忠実な演技」
２ （副詞的に用いて）基本的に。原則として。「基本、先発メンバーは固定している」
設計:
１ 建造物の工事、機械の製造などに際し、対象物の構造・材料・製作法などの計画を図面に表すこと。「ビルを設計する」
２ 一般に、計画を立てること。また、その計画。「老後の生活を設計する」
引用：基本（きほん）の意味・使い方をわかりやすく解説 - goo国語辞書、設計（せっけい）の意味・使い方をわかりやすく解説 - goo国語辞書
こちらも自分の認識も混ぜて言葉にすると、
- 要件を満たすための大元の仕組み、条件、影響範囲を明らかにして、どのように進めたらいいかを決めること
- つまりWhatの条件を明らかにして、Howの素案及び影響する領域を明らかにすること
とします。*2
どうやって要件定義をやるか
弊社ではスタディサプリという教育サービスの製品開発をしております。
基本的な製品・案件の企画はビジネスサイドのメンバーが行うことが主であり、大方の要件は固まった状態で案件として話が始まります。
その多くは、現状の製品に対しての「不」を解決することで、初回課金率を向上させたり、エンゲージメントを高めて継続課金率を上げたり、とビジネスKPI及びプロダクトの質に影響するものとなります。
しかし、ここでよく発生するのが、そういったWhatやWhyを明示せずに、Howに落とし込まれた状態でスタートしてしまう、というケースです。
例えば、
合格特訓ユーザーに夏休み期間中にコーチからだけでなく機械的にメッセージを送ってスタサプへのリテンションを高めたい （注：この例は仮のため実際のスタサプの機能・状況とは関係ありません）
というものがあったとします。*3
しかし、これではなぜリテンションを高めたいのか、なぜ夏休み期間中に特化しているのか、機械的にどんなメッセージを送りたいのか、などがわかりません。
この案件を掘り下げて本当にしたいことは何なのか、背景はなにか、を検証すると
合格特訓の生徒として、夏休み期間中にモチベーション高く勉強を続けられるようにしたい、なぜなら夏休みは時間がたくさんあるので、多くの生徒がサボりがちになってしまうからだ
というものが出てきます。
ここで重要なのは、常にWhatやWhyを明らかにする意識を持つこと、案件自体がHowになっていないかを意識することです。
今回の例のようにスクラム式のストーリー形式に言葉を置き換えてみると、何をしたいのか、なぜしたいのかを簡単に明らかにできると思います。
マーケットドメイン知識はどう使えばいいの？
WhatとWhyを明らかにするまでは実はそんなに難しくはありません。
本当に重要なのはこのWhyのターゲットユーザーは誰なのか、本当にこのような「不」を抱えているのか、を考えることです。
今回のケースであれば、
- ターゲット：合格特訓ユーザー
- 時期：夏休み
- 抱えている「不」：夏休みにサボってしまう
となります。
夏休みにサボる、は多くの読者が経験していると思うので疑いようのない事実にも感じます。
しかし、ターゲットが合格特訓ユーザーとなると話は変わってきます。
合格特訓は高3生の受講者が多い商品なので受験を目前に控えています。さらに、既にコーチが付いていて、学習へのモチベートもされ続けています。
果たしてそのような生徒が本当にサボってしまうのでしょうか？
ここに対しての疑問が生じれば、後は過去の合格特訓ユーザーの夏休みのスタサプ利用時間を夏休み前後と比較してみたりすれば結果はすぐに分かります。
その結果、そもそも要件定義自体が間違っている、ということが導かれる可能性があります。 （もう一度書きますが、この案件は本ブログのために筆者が適当に考えたものなので、スタサプの機能・状況とは一切関係がありません）
マーケット、つまりユーザーに対しての理解がなければ疑問は生じず、そのまま需要のない機能を作ることになりかねません。
PMは常にマーケットのことを意識して、それがユーザーにとって意味のあるものなのか、意味のある形での機能になっているのかを考えなければなりません。
どうやって基本設計をやるか
WhatとWhyは明確化されました。さて、設計をしましょう。
提供するユーザーの条件を整理して、どんなメッセージを表示するのかを考えて、、、とするにはまだ早いです。
まだ抽象度の高いWhatに対しての素案（How）がイケているかどうかの検証が出来てないですよね。
合格特訓の生徒が夏休み期間中にモチベーション高く勉強を続けられるようにしたいに対して、
コーチからだけでなく機械的にメッセージを送るは適切なのでしょうか？
「夏休みだ！よしやるぞ！」とユーザーに思ってもらうのです。「機械的にメッセージを送る」のが正しいでしょうか？
また、ユーザーは合格特訓ユーザーです。商品購入動機としてもコーチによるサポート、つまり人によるサポートがあることをメリットと考えているユーザーが多いはずですね。
そうなると、このHowはイケてないように見えますね。
では、どんなHowがイケてそうでしょうか？
いろいろありそうですが、ここでは
- 人によるサポートが重要
- 夏休み、という学生にとって特別な期間
というのをベースに考えると、
- 合格特訓ユーザーに夏休み限定、講師出演の「夏休みの時間の使い方」動画を受講出来るようにする
というような方がイケてそうですね。今回は例なので一旦この辺りにHowの素案をおきます。
この時点ではマーケットドメイン知識を使っています
気づいた方もいると思いますが、この時点では製品ドメイン知識はほぼ使っていません。
むしろ、ユーザーにウケるのか、ハマるのかを突き詰めて考えるフェーズになるため、マーケットドメインのほうが重要なのです。
Howを考え出した瞬間に製品のことを考え出すことが多いですが、
これが一番の間違いで、無数ある中からどんなHowを選ぶのか、においてはマーケットを考えなければいけないのです。
製品ドメイン知識はどう使えばいいの？
素案は出来ましたが、実際のそれをユーザーにどう提供するのかを決めなければ、製品は作れません。
考えなければならないことは例えば下記のようなことです。
* 提供する期間 * 対象のユーザー * リリース時期・コンテンツの入稿時期 * 訴求の仕方 * 利用デバイス間で差異がないか
それぞれに対して、下記のような考えが発生します。
* 提供する期間
* いつからいつまで提供するのか
* 既存の仕組みで、リリースとは別にコンテンツをピンポイントで提供・停止することはできるか
* 対象のユーザー
* スタサプの中での対象のアカウント属性は何か
* 小中高ベーシック・中学個別指導・団体会員のユーザーはどんな体験になるか
* リリース時期・コンテンツの入稿時期
* リリースはいつか、コンテンツが出来あがるのはいつか
* 入稿部分に修正は不要か、追加開発の必要はないか
* 訴求の仕方
* 講座を追加するだけで足りるのか、どのように訴求をするのか
* オススメ講座のような機能はあるか、拡張可能か
* 利用デバイス間で差異がないか
* ユーザーの体験は同じでよいか
* 既存製品が既に同じ体験になっているか、アプリのNotificationなどの考慮は不要か
ここで記載した最下段の「 * 」は全て製品ドメインがないと考慮・調査できないことです。*4
団体会員ユーザーというものが存在するということを知らないと、対象のユーザーの考慮不足が発生しますよね。
これによって見積もりの精度も変わりますし、素案に対しての費用対効果が高いのか、低いのかが大きく変わります。
結果的に、コスパが悪いから異なるHowにする、という結論が得られることもありえます。
製品ドメインをどれだけ知っているかが、最終的な品質だけでなく、やるかやらないのかにも影響するわけです。*5
じゃぁお前出来てんのか（筆者の反省）
いろいろと偉そうなことを書いていましたが、私が完ぺきにできているかと言われると、やはりそうでもありません。当然といえば当然かもですが、、、
教育業界と全く関係のない前職から転職して4ヶ月強、マーケットに対しての理解も浅く、企画をそのまま取り入れてしまうこともしばしば。
また、製品もまだまだ知らないことがたくさんある中で、条件が漏れているケースが多く、エンジニアにその都度救っていただいているような状態です。
以前やっていた案件でも、「これでいける！」と決めて進めたはずの案が考慮漏れ多数で1週間後にステークホルダーを全員集めて仕様の詰め直しをしたりしました。
幸い弊社は優秀なメンバーに恵まれており、大きな問題にならずにいますが、知識をためて適切にアウトプットする、ということを繰り返さなければ自分の価値がなくなるな、と毎日頭フル回転で働かせていただいております。
終わりに
今回は業務的には割とシンプルな部分を書かせていただきましたが、余談として私がPMとしてどうなりたいのかを記載しておこうと思います。
いい機会なのでね。興味ない人はここで画面閉じてOK。
私は元々9年エンジニアで戦ってきて、PMへジョブチェンジしたのですが、エンジニアへの未練というのは全くないのです。
というのも、エンジニアとしてモノを作ってアウトプットしていくことよりも、作るモノを定義していく、その定義するモノがマーケットフィットしていることを検証していく、という方に面白みを感じたんですよね。*6
そんな気持ちでPMをやってみると、ステークホルダーが多く、当然ムズカシイこともたくさんあるのですが、面白いと思うこともあります。
それは「PMはチームによって期待が違う」ということです。
チームの成熟度、メンバーの得意不得意、業績の状況、いろいろな要素によってPMに期待されることは変わります。
そんなことを知った私としては今後自分のキャリアとして、「究極のゼネラリスト（またの名を普通中の普通の人）」になりたいと思っています。
どのチームに入っても貢献できる、いることでチームが上手く回るようになればそんな嬉しいことはないなぁと。
まだまだ道半ばではありますが、少しずつゼネラリストとして成長しながら、同じようなゼネラリストを増やせるようにHowを言語化出来るといいなと思っています。*7
本記事はPMの @shunsuke-nishimura が執筆しました。
初ブログで思いの外、長文となってしまい申し訳ありません。本記事が悩めるPMの一助になれば幸いです。
*1:どちらも私の造語のようなので利用の際はご注意ください
*2:本来の意味での基本設計はもう少し製品に踏み込んでいることは理解しつつ、ここでは都合上この辺りに留めていることをご了承ください
*3:合格特訓ユーザーはスタディサプリ大学受験講座の合格特訓コースに入会しているユーザーのことを指しています。
*4:中学個別指導はこちら、団体会員はこちらをのユーザー指しています。
*5:もちろん全てをPMが一人でやらなければいけないわけではないですが、プロセスの手前で多くのことが考えられる方がコスパがいいですよね
*6:今日の話はここをどううまくやっていくか、のベース部分ですね
*7:再現性のある仕事 is 重要、というスタンス
