こんにちは。SmartHRのタレントマネジメントプロダクト開発本部でプロダクトエンジニアをしているmasaruです。
最近私たちのチームでは新規プロダクトの立ち上げを経験する機会がありました。その時に行った3つの取り組みを本記事では紹介します。
はじめに
新規プロダクトの開発を始める際、技術選定からリリース計画まで、チームで決めるべきことは無数にあります。「技術選定では何を採用するべきか」「どの機能を優先して開発し、何をやらないのか？」「いつまでにリリースするのか」—こうした意思決定の一つひとつが、プロダクトの成否を左右します。
しかし、チーム内で共通認識が揃っていないと、意思決定のための議論は毎回空中戦になり、時間ばかりがかかってしまいます。たとえ決まったとしても、明確な判断基準がないため、全員が納得できる結果にはなりません。結果として、誰もが妥協したと感じる選択になってしまうのです。
筆者のチームも、新規プロダクトの立ち上げ時に同じ課題に直面しました。そこで、開発に着手する前に「チームの意思決定をスムーズにするための土台作り」に時間を投資することにしました。本記事では、その中で実践した3つの取り組みを紹介します。
本記事の対象読者
- チームでプロダクトの0→1開発をこれから始める方
- 新規プロジェクトの立ち上げに関わるエンジニア、プロダクトマネージャー
- チームの意思決定に時間がかかることに課題を感じている方
本記事で紹介する3つの取り組み
- インセプションデッキの作成 - プロダクトの方向性と優先順位の共通認識を作る
- アーキテクチャ特性の洗い出しと優先順位付け - 技術選定の判断基準を明確にする
- 完成の定義の作成 - MVPに至らない機能開発のゴールを設定する
それでは、順番に見ていきましょう。
取り組み1: インセプションデッキの作成
なぜインセプションデッキが必要だったのか
新規プロダクト開発では、日々さまざまな意思決定が求められます。例えば、以下のような場面です。
- プロダクト全体や各機能開発のリリース計画を期日ドリブンで進めるか、スコープドリブンで進めるべきか？
- 複数ある機能案の中で、どれを優先的に提供し、何をやらないと判断するのか？
- 技術的負債が見つかった場合、今対処するべきか、リリース後に対処するべきか？
こうした判断を迫られるたびに、メンバー間で異なる前提や価値観が表面化します。共通認識が揃っていないと、毎回ゼロから議論を始めることになり、意思決定に膨大な時間がかかってしまいます。
さらに問題なのは、たとえ決議できたとしても、その判断の根拠が明確でないため、全員が納得する結果にならないことです。「本当にこれでよかったのか？」という疑念が残り、チームのモチベーション低下にもつながります。
そこで、私たちはプロジェクト開始時にインセプションデッキを作成し、チームの共通認識を形成することにしました。
インセプションデッキは、Jonathan Rasmussonの著書『アジャイルサムライ』で広く認知されるようになったフレームワークで、プロジェクトの目的や制約、リスクなどを10個の質問に答える形で整理するものです。今回は、その中から特に重要と考えた6つのテーマに絞って実施しました。
インセプションデッキで合意した6つのテーマ
私たちのチームで合意形成した6つのテーマは以下の通りです。
1. 我々はなぜここにいるのか
私たちはプロジェクトの存在意義を明確にするために、「なぜこのプロダクトを作るのか」「誰のどんな課題を解決するのか」をチーム全員で言語化しました。
プロダクトの目的を共通認識することで、チームメンバーが各場面で的確な判断ができ、メンバー間での対立を避けることができます。
例えば、機能開発の優先順位を決める際に「このプロダクトの存在意義に照らして、この機能は本当に必要か？」と立ち返る際などにここで合意したことが活きてきます。
リリース前のプロダクトに関する機密事項を含むため、詳細は伏せさせていただきますが、私たちは以下のような形で作成しました。
私たちは、〇〇と感じている従業員の背中を押すためにここにいます。
SmartHRの強みである〇〇と、xxを活かし、上記を実現します。
結果として
- ◯◯
- △△
- xx
という状態を実現します。
2. エレベーターピッチを作る
私たちはプロダクトの価値を30秒で説明できる文章を作成しました。
この文章を作ることで、プロダクトの独自性と提供価値が明確になります。
こちらも機密事項を含むため全てを公開することはできませんが、私たちは以下のように作成しました。
〇〇の従業員向けに、xxができるプロダクトを提供します。 これは、〇〇を目的とした新しいxxです。
従来の〇〇とは異なり、xxをすることで、△△します。
その結果、従業員が〇〇でき、企業はxxを実現します。
3. やらないことリストを作る
新規開発では、あれもこれもと機能を盛り込みたくなりますが、スコープを絞ることが成功の鍵です。そこで私たちは「このプロダクトでやらないこと」を明確にしました。
例えば、私たちのプロジェクトでは以下のような項目を「やらないこと」として合意しました。
- 競合とは同じ土俵では戦わない
- 自社の他プロダクトと類似の機能を独自で作り込まない
- ターゲットから外れるペルソナを定義し、そういったユーザーに向けた機能は提供しない
4. 「ご近所さん」を探せ
プロジェクトを成功させるためには開発チーム以外にも様々な人々に協力してもらう必要があります。
私たちののプロジェクトでは、セールスチーム、カスタマーサポートチーム、プロダクト横断の開発チームなどをここで洗い出すことができました。
早い段階で関係者を特定し、巻き込むことで、後になって「聞いていない」という事態を避けられます。
5. 夜も眠れなくなるような問題は何だろう
私たちはプロジェクトの重大なリスクを洗い出しました。リスク全てに対処するのは現実的に不可能なので、対処するか否かの判断をし、対処するものにはあらかじめ対処法を明らかにすることで、後にリスクが顕在化した際に慌てずに済みます。
例えば、以下のようなリスクが挙がりました。
- 目標となる売上が達成できない
- インシデントや障害が発生する
- 開発チームのメンバーや、ステークホルダーが退場する
6. 何を諦めるのかをはっきりさせる（トレードオフスライダー）
プロジェクトには、時間、スコープ、品質、予算の4つの制約があり、これらはトレードオフの関係にあるため、すべてを最大化することはできません。トレードオフスライダーでは、これらの要素に優先順位をつけます。
例えば、私たちのプロジェクトでは以下のような優先順位になりました。
- 品質
- 予算
- 時間
- スコープ
この優先順位があることで、「期日を守るためにスコープを削る」という判断が、全員納得の上でできるようになります。
実施方法
インセプションデッキの作成は、以下の流れで実施しました。
事前準備（重要！）
プロダクトマネージャーに、各テーマについて叩き台となる文章を作成してもらいました。これがあることで、ワークショップ当日の議論が格段にスムーズに進みます。
ゼロから考えるよりも、叩き台を見て「ここは違うと思う」「この表現の方がいい」と議論する方が、短時間で質の高い合意形成ができます。
ワークショップ（90分）
Figjam（オンラインホワイトボードツール）を使ったオンラインワークショップを実施しました。
- 各テーマについて個人ワーク
- プロダクトマネージャーの叩き台を共有
- メンバーが付箋で自分の考えを追加
- 似た意見をグルーピング
- チームの共通認識を言語化
- 出た意見を元に、チームとしての最終的な文章を作成
- 全員が納得するまで議論
事前準備のおかげで、6つのテーマすべてを90分のMTG1回で完了できました。
実際に効果を発揮した場面
インセプションデッキを作成したことで、以下のような場面でスムーズな意思決定ができました。
初回リリースの計画
リリースまでのロードマップを作成する際には、トレードオフスライダーで定義した優先順位（時間 > スコープ）に基づいて、リリース時期を固定し、スコープを調整する方針で進めることができました。
必須機能とNTH機能の振り分け
各機能について、「これは必須（Must Have）」「これはあったらいいな（Nice To Have）」の振り分けを行う際、インセプションデッキの内容に照らし合わせることで、議論が発散せずに済みました。
取り組み2: アーキテクチャ特性の洗い出しと優先順位付け
インセプションデッキだけでは不十分だった理由
インセプションデッキによって、プロダクトの方向性や優先順位についての共通認識はできました。しかし、技術選定やアーキテクチャの判断をするための情報は不足しており、さらに具体的な基準が必要でした。
プロダクトの立ち上げ段階では、例えば以下のような意思決定が必要になります。
- どういった技術スタックを採用するか？
- どのようなアーキテクチャを採用するか？
- インフラ構成をどうするか？
こうした技術選定は、後から変更することが非常に困難です。そのため、「時間をかけて慎重に検討したい」というモチベーションが働きます。
一方で、リリース時期は決まっており、議論を長引かせて開発が遅々として進まない状況も避けたい。このジレンマを解決するために、アーキテクチャ特性を明確にし、優先順位をつけることにしました。
アーキテクチャ特性とは
アーキテクチャ特性とは、システムが備えるべき非機能要件のことです。例えば、以下のような特性が一般的に存在します。
- 信頼性 - システムが利用可能である時間の割合
- 弾力性 - 急激な負荷増加に対応できる能力
- パフォーマンス - レスポンスタイムやスループット
- 進化性 - 機能追加や、変更や修正のしやすさ
- デプロイ容易性 - リリースやロールバックのしやすさ
- テスト容易性 - テストの書きやすさ、実行しやすさ
- セキュリティ - 不正アクセスやデータ漏洩への対策
- 開発コストの低さ - 学習コストが低く、オンボーディングが容易
各特性はトレードオフの関係になるケースが多く、すべての特性を高いレベルで満たすことは現実的ではありません。そのため、自分たちのプロダクトにとって何が最重要かを決めることが、適切な技術選定の鍵になります。
アーキテクチャ特性の定義方法
アーキテクチャ特性の各概念は、エンジニアには馴染みがありますが、プロダクトマネージャーやビジネスサイドの人には理解しにくい場合があります。
そこで、各アーキテクチャ特性をプロダクトマネージャーが重要性を判断できる表現に書き換えました。
たとえば、弾力性の技術的な表現は以下でした。
システムが急激な負荷増加に対応できる能力
これをプロダクトマネージャー向けの表現に書き換えたものが以下です。
〇〇（イベント名）の公開直後には、多くのユーザーのアクセスが想定されます。この際に、ユーザーがアクセスできない状態に陥らないようにする必要があります。
レベル感: ライブチケットの販売サイトで想定されるレベル（瞬間的に数万人が同時アクセス）
また、もう一つ例として、デプロイ容易性の技術的な表現は以下です。
デプロイやロールバックのしやすさ
こちらもプロダクトマネージャー向けの表現に書き換えると以下になりました。
不具合が発生したときの復旧までの時間は短くなければなりません。
レベル感: 本番環境で不具合が見つかった場合、修正版を5分以内にデプロイできる、または1分以内に前バージョンにロールバックできる
ポイント：極限の例を示す
ここで重要なのは、極限までその要素が求められる他プロダクトを例に出すことです。
例えば、弾力性の例では「ライブチケットの販売サイト」を挙げています。このレベルの負荷対策には、相応のコストがかかります。
極限の例がないと、「弾力性も重要そうだ」となんとなく感じて判断を見誤ります。極限の例があることで、「自分たちのプロダクトはそのレベルまで提供する必要はないので、この要素はさほど重要ではないかも」と冷静に判断できるようになります。
優先順位付け
アーキテクチャ特性を洗い出したら、プロダクトマネージャーとミーティングを行い、各特性の優先順位の並べ替えを行いました。
「高いレベルで提供したい」から、「ある程度のレベルで提供されればよい」までを直線の軸におき、各特性をその軸に沿って並べました。
実際に効果を発揮した場面
アーキテクチャ特性の優先順位を決めたことで、技術選定の意思決定が格段にスムーズになりました。
たとえば、フロントエンドの設計方針について意思決定を行う際に、2つの案のどちらにするべきか議論する場面がありました。
そこで以下のように、アーキテクチャ特性ごとにそれぞれの案を採用した場合の星取表を作成しました。（活用例を示すためのイメージです。優先順位は実際決定したものとは異なります。）
| アーキテクチャ特性 | 優先順位 | A案 | B案 |
|---|---|---|---|
| セキュリティ | 1位 | ◯ | ◯ |
| 進化性 | 2位 | ◯ | ◯ |
| 信頼性 | 3位 | ◯ | ◯ |
| 弾力性 | 4位 | × | ◯ |
| パフォーマンス | 5位 | × | ◯ |
| 開発コストの低さ | 6位 | ◯ | × |
これを用いて私たちは、A案にもB案にはない優れた部分はあるものの、B案のほうが重要なアーキテクチャ特性の多くを満たしているため、B案を採用すべきであると意思決定をしました。
このように、優先順位に基づいた定量的な比較により、全員が納得する形で、スムーズな意思決定ができました。
取り組み3: 完成の定義の作成
MVPに至らない機能開発におけるゴール設定の難しさ
新規プロダクトの初回リリースには、複数の機能が含まれています。例えば、ユーザー登録機能、管理者向け機能、通知機能などです。
しかし、これらの機能は単独ではユーザーに価値を提供できません。すべてが揃って初めてMVP（Minimum Viable Product：実用最小限の製品）になります。
このような状況では、機能単位で何をゴールとすべきかが自明ではありません。
- 実装が完了したらゴールなのか？
- テストまで完了したらゴールなのか？
- ステージング環境にデプロイしたらゴールなのか？
チームメンバー間でゴールの認識がずれていると、以下のような問題が発生します。
- 完了したと思っていた機能に、実はバグが残っていた
- ステークホルダーの期待と実装内容がずれていた
- 次の機能開発に進んでいいのか判断できない
本プロジェクトにおける「完成の定義」
一般的なスクラム開発における「完成の定義（Definition of Done）」では、各ストーリーの完了に対して厳密なルールを設けます。ただ、私たちのような立ち上げ段階のプロジェクトでは開発スピードを優先するために、機能単位で一つの「完成の定義」を定めておくことにしました。
スプリントレビューを通じて、ステークホルダーからフィードバックを得られていること
具体的には、以下のプロセスを経ることを完成の条件としました。
- 実装完了 - コードレビュー、テスト、デプロイまで完了
- スプリントレビュー - ステージング環境で実際に動作するものをステークホルダーにデモ
- フィードバック収集 - 期待と合っているか、修正が必要かを確認
- 修正の反映 - 致命的な問題や誤解があれば修正
この定義により、「自信を持って各機能を完了とし、次の機能開発に進める」という状態を作り出すことができました。
まとめ
3つの取り組みが果たした役割
本記事では、新規プロダクト開発の立ち上げフェーズで実践した3つの取り組みを紹介しました。
- インセプションデッキの作成 - プロダクトの方向性と優先順位の共通認識
- アーキテクチャ特性の洗い出しと優先順位付け - 技術選定の判断基準
- 完成の定義の作成 - 機能開発のゴール設定
これらの取り組みにより、以下のような効果が得られました。
意思決定速度の向上
共通認識と判断基準が明確になったことで、議論が発散せず、短時間で意思決定できるようになりました。技術選定やスコープ調整など、重要な判断を迫られる場面で、その効果を実感しています。
全員が納得できる判断
意思決定の根拠が明確なため、「なぜその判断をしたのか」を誰もが説明できます。これにより、妥協ではなく、全員が納得した上で前に進めるようになりました。
「早く開発を始めたい」という気持ちは、誰もが持つものです。しかし、共通認識がないまま開発を始めると、後になって大きな手戻りが発生したり、チーム内での認識のずれが問題になったりします。
開発着手前に、本記事で紹介したような準備に時間を投資することは、長い目で見れば開発スピードを上げることにつながります。
これから新規プロジェクトを始める方へ
本記事で紹介した3つの取り組みは、私たちのプロジェクトで効果があったものです。すべてをそのまま適用する必要はありません。
重要なのは、チームで共通認識を作り、意思決定の判断基準を明確にすることです。その手段として、インセプションデッキやアーキテクチャ特性の整理が役立つのであれば、ぜひ試してみてください。
皆さんのプロジェクトが成功することを願っています。
We Are Hiring!
SmartHRは積極的に新規事業への投資を進めています。プロダクトの0->1フェーズに関わってみたい、という方は、ぜひカジュアル面談からお話してみませんか？
