プロダクトの言語化

新規事業においては、誰にどのようなユーザー体験を通してどのような価値を届けたいのかという観点に基づいて、要求・要件を自分たちで考えていくことになります。

新規事業に携わるチームメンバーそれぞれが、プロダクト価値を踏まえてプロダクトの設計・実装を進めていくためには、「目指すプロダクト像」の共有が欠かせません。

また、チームで開発を進める以上、相互の認識を合わせるべくプロダクトの設計をドキュメント化していかねばなりませんし、一方で継続的な変更に耐えられるようドキュメントは「最小限」にとどめるべきです。

本書では上記のような事柄を達成するために、どのドキュメントをどのタイミングで作れば良いのかという、プロダクトの言語化についてガイディングします。

言語化の進め方

目指すプロダクト像

チームでプロダクトを作る上で、まずは事業においてプロダクトがどのような価値・訴求力を提供すべきなのかを言語化しましょう。この言語化は、事業像を描く事業オーナーが行うのが望ましいでしょう。プロダクト価値、そしてそのプロダクトの機能要件・非機能要件は、事業像から導出されるためです。

この資料はチームメンバーと何度も見返すことでその価値を常に意識できるよう、記述ボリュームは抑え、スライド1-2枚程度の目処にしてください。チーム内だけでなく、顧客やステークホルダーへプロダクトの魅力を伝える際にも大きな助けになってくれるでしょう。

設計ドキュメント

以下の図に示すタイミングで、プロダクトに関わる設計ドキュメントを整備してください。

事業計画立案ステージでの成果物ドキュメント

事業計画立案ステージでの成果物ドキュメントは以下の通りです。プロダクトとして「何を作るのか」、そしてそれを「どう作るのか」に二分されます。

• 何を作るか
  • ユーザーストーリーマップ
  • 業務フロー
  • プロダクトバックログ
  • 概念データモデル
  • 非機能要件定義書
  • 画面遷移図
• どう作るか
  • システム設計図
  • 方式設計書

ユーザーストーリーマップ

見積もり・スコープ決定において最も大事なのはこれから作ろうとするサービスの全体像を掴むことであり、そのために必要なのはユーザーストーリーマッピングです。
ユーザーストーリーマッピングで作成するアウトプット(ユーザーストーリーマップ)はユーザーに何の価値を提供するのか・その目的が何かを表した図であり、「事業オーナー」と「エンジニア」「デザイナー」がそれぞれ議論しながら以下の順で作成します。

1. サービスのユーザーが誰なのかを洗い出す
2. それぞれのユーザーが商品・サービスを使いはじめてから使い終えるまでのユーザーのアクティビティを、時系列順で横に並べる
3. そのアクティビティをシステムで実現する際に考えられるバックオフィスの業務も記載する
4. 個々のアクティビティに必要となる機能を優先度順で縦に並べる

その上で、どこまでを最初のリリース対象とするのかの線(リリースライン)を引きましょう。このリリースラインに含まれる機能が最初の「開発スコープ」になります。このリリースラインは、サービスの価値を実現する「必要最小限」の機能をリリースできるように引きましょう。空想上のユーザーではなく実際のユーザーからのフィードバックを生かすほうが、サービスの成長につながるためです。

業務フロー

業務フローを作成することで、機能の洗い出し、システム化する範囲を明確化できます。
プロダクトを使って、誰がどのように業務を進めるのか・サービスを利用するのかを表現し、関係者間での「事業イメージ」の食い違いを防ぎます。また、要件定義や画面デザインなどのインプットになります。

業務フローの成果物イメージについては、業務フローサンプルをご参照ください。

プロダクトバックログ

プロダクトバックログは、順番に並べられた、プロダクトの改善に必要なものの一覧です。

バックログには、ユーザーストーリーを並べることが多いです。ユーザーストーリーは、ユーザーストーリーマップのリリースライン内に存在する機能から抽出し、継続的に記述を具体化させていきます。

具体的なユーザーストーリーの例¹が以下です。ユーザーの分類(役割)、ユーザーの目的、その理由を具体的に記述します。
このような形でユーザーストーリーの意図と本質を捉えた文章を記述することにより、チームは後段でより詳細な議論が可能になります。

ユーザーストーリーの雛形

概念データモデル

概念データモデルは、ビジネスとシステムの基本的な概念とそれらの関係を、抽象的なレベルで表現したデータモデルです。
「一人の顧客が複数の注文を持つことができる」といった制約等、ビジネスの要件を理解・共有するための基盤になります。

概念モデル設計の具体的な実施手順は以下のようになります。

1. 序盤にどういったモデルが登場するかを挙げていきます。それらのモデルを使って業務フローを回す想定をし、モデルの追加や削除をしていきます
2. 中盤ではそれらの間のカーディナリティ（多重度＝１対１、１対多、多対多か）を確定させていきます。自由度が高いとシステムは複雑化し、低いとシステムの制約になります
3. 終盤では概念データモデル図を作成します。概念データモデル図の変更は、業務のモデルや業務フローだけでなく実際のシステムの画面設計、API仕様やデータベースのテーブル構成と連鎖し、手戻りのコストとなるため、精度を高めなければなりません。

商品購入と利用ユーザーの例の紹介になりますが、概念データモデル図は、以下の画像のような図になります。
モデルをグルーピングしてドメインとして扱うと分かりやすくなります。

非機能要件定義書

非機能要件はシステムアーキテクチャに大きな影響を与え、時に不可逆な判断が必要になります。
このためこの段階で、非機能要求グレードを参考に、事業オーナーと非機能要件を定義しましょう。

非機能要求グレードで定められる全項目について要件を定義するのは、スモールスタートを目指す新規事業に対してはオーバースペックです。このため、以下のような進め方を行いましょう。

1. 非機能要求グレードに含まれるモデルシステム3種を参考に、システムが機能低下/利用不可能な状態になった場合の影響の程度、システムの役割として開発対象プロダクトにもっとも近いモデルシステムを選択する
2. 選択したモデルシステムと開発対象プロダクトとの非機能要件の差を、事業オーナーと確認する
3. 非機能要求グレード中の「重要項目」²を対象に、それぞれの項目に対する非機能要件を事業オーナーと合意する

モデルシステムのイメージ(非機能要件グレード³より引用)

画面遷移図

サービスを具体的に言語化するアウトプットの1つが画面遷移図です。

注意しなければならないのは、ここでは「ユーザーインタフェースの設計」を目的とするわけではなく、サービスのイメージを共有することが目的です。そのため、デザインを重視するようなユーザーインタフェースではなく、サービスのコアとなる部分が表現されるようにします。

システムに詳しくない事業オーナーもいます。そのような場合、たとえば後述の概念データモデルに関して事業オーナーと認識を揃えるのは難しいでしょう。この場合であっても、今回の画面遷移図や画面のワイヤーフレームをベースに説明することにより、効率的に概念モデルの認識合わせも行えます。

システム構成図

プロダクトをどのような構成で実現するかを考え、図として表現したものがシステム構成図です。この図は、今後見積もりを作成する際の重要なインプットになります。プロダクトバックログ、非機能要件定義書をベースに、必要な機能を洗い出し図に表します。

プロダクトを、何を用いて実現するかも大事な要素になります。クラウド環境で自分たちで構築するのか、SaaSを利用するのか、あるいはそれらを組み合わせて利用するかもシステム構成図に落とし込みます。

以下は、ユーザーからの問い合わせを受けるコールセンターを作ることになった場合の、システム構成図の例です。

方式設計

方式設計を実施します。ここで方式設計をしておく理由は、以下になります。

• 機能の実現イメージがわかず、各機能に対する見積もり精度が下がってしまう
• システム構成図が描いた内容と整合性が取れず、後のステージで構成から再検討することになってしまう

特に事業のコアとなりえる機能に対して実現方式が不透明であったり、方式設計での選択が見積もり結果に大きく影響するようなケースでは、方式設計を実施する必要性はより高まると考えます。

この時点で方式設計を詳細に行う必要はありません。機能の実現イメージを持ち、見積もりができる程度の方式設計ができれば十分です。
アーキテクチャ設計・インフラ工数見積もりに記載しているアーキテクチャ設計も活用するとよいでしょう。

実施した方式設計の結果は簡単でもよいので方式設計書として残しておき、開発時に詳細を詰めていきます。

事業化準備ステージでの成果物ドキュメント

ドキュメントは事業化準備ステージ以降でも継続的に更新するとともに、システムの状態と同期をとることが必要です。
また、円滑に開発を進めるために必要なドキュメントを整備していきます。

• ドメイン知識
• ER図
• 画面デザイン

継続的なメンテナンスを行うためには、後述する「Doneの定義」に、ドキュメントの更新を含めておくと良いでしょう。

ドメイン知識

プロダクトが提供したい価値をプロダクトに反映するためには、ドメイン知識が必要になります。
このドメイン知識は言語化しておきましょう。
ドメイン知識をどのようなドキュメントとして表現するかは形式は問いませんが、どこにどういう知識が掲載されているのかは、事業開発に関係する人が見ることができる場所に一覧しておく必要があります。

• 市場環境や競合製品については、事業計画書においてまとめられているでしょう。
• 事業の全体像は、既に顧客向け営業資料としてわかりやすくまとめられているかもしれません。
• 対象業界特有の用語や自分たちが新たに定義した用語は、用語集としてまとめるのが良いでしょう。

ドメイン知識は最初から全てを網羅してドキュメント化する必要はありません。
事業において重要な概念や、チームメンバーや顧客から質問を受けた内容を中心に順次言語化していくのが良いでしょう。

ER図

事業計画立案ステージで作成した概念データモデルをベースに、サービス開発に必要となるデータモデルをER図で表現してください。

プロダクトのリリース後も継続的に開発が続き、求められる要件の変化に伴うデータモデルの変更がしばしば発生します。一方で、データモデルの変更はプロダクトに大きな実装影響をもたらします。
プロダクトに関わる世界をモデリングし、データベースの正規化を適用し、なるべく変更に強いデータモデルを設計するように心がけましょう。

画面デザイン

画面デザインは、プロダクトの顔となり、ユーザーからの第一印象に大きな影響を与える重要な要素です。エンジニアに「効く」デザイントレーニングをご参照ください。

UIデザイン・画面遷移図ともに一度作成して終わりではなく常に更新し続けていく必要があるため、プロダクト開発に携わる多くの人が「使えるか」でツールを選定してください。Figma等のUIデザインツールで描画することを推奨しますが、場合によってはExcelでも構いません。

まとめ

チームで臨む以上、良いプロダクトを皆で作り上げるには、言語化・ドキュメント化することが極めて重要です。
一方でその更新の負荷が大きくなると、本来行うべきプロダクト価値の作り込みが行えなくなってしまいます。

本書では、このトレードオフを解消するプロダクトの言語化、作成すべきドキュメントについて、我々が考えているベストプラクティスを示しました。

---

1. Kenneth S. Rubin、『エッセンシャルスクラム』、翔泳社、2014。↩︎
2. どれが重要項目なのかについては、非機能要求グレードに含まれる「05_樹形図.pdf」をご参照ください。↩︎
3. 「非機能要求グレード2018利用ガイド」より引用。↩︎