Zenn
⛳

新規事業を立ち上げるための設計指針を作ってみる

2023/03/01に公開
デザイン
設計
新規事業
idea

用語定義

  • エンドユーザー
    • サービスを利用するユーザーこと
  • サービス
    • ウェブサービス、モバイルサービスのこと
  • business/develop
    • ビジネスサイド/技術(エンジニア)サイドのこと

なぜこの記事を書いたか

businessサイドには、起業の科学をはじめとして、新規事業の立ち上げ方を詳しく解説した書籍が多数あります。
しかし、それらの書籍はbusinessサイドの話がほとんどで、developサイドの設計に関する話はほとんどありません。

一方でdevelopサイドにはアジャイルやウォーターフォールをはじめとして、いくつもの設計手法がありますが、新規事業を立ち上げるための設計手法ではありません。

そこで、新規事業を立ち上げるにあたってbusiness要素とdevelop要素を統合した設計指針を作ってみます。

4つの領域

この設計の指針では4つの領域が登場します。
これら4つの領域は価値を中心にしてお互いがお互いと結びついています。
(ですので、businessサイドとdevelopサイドは分業すべきではないと思っています。)

価値領域

サービスの根幹をなす最も重要な領域です。
まずは、ここから設計を始めます。
特に重要なのが、コアバリューです。(後述します)
コアバリューを肉付けしていくことで、設計を深く大きくしていきます。

システム領域

エンドユーザーには見えない裏側の仕組みを設計します。
どちらかといえば、バックエンド、インフラ寄りの概念です。

デザイン領域

スケッチ→ワイヤーフレーム→モックアップ(→プロトタイプ)と徐々にブラッシュアップしていきます。

プロジェクト領域

サービスを立ち上げるにあたって様々な制約があります。
例えば、個人での開発、社内起業、会社を立ち上げて複数人での開発、また外部から資金調達をするしないなど、プロジェクトによって、ヒト・モノ・カネ・情報が異なります。
それらを設計・整理する領域です。

  • 例えば、人（ステークホルダーやメンバー）
  • 例えば、お金(資金繰りや補助金)
  • 例えば、リスクマネジメント
  • 例えば、優先順位(トレードオフスライダー)

全体イメージ

ウォーターフォールのように前のフェーズに戻れないということはしません。
むしろ、最初はざっくりと作って、次にブラッシュアップして、その成果を前工程にフィードバックさせて設計を深化させていく、というような作り方を推奨します。

価値領域

サービスの価値を設計します。
ここでいう価値とはエンドユーザーが感じる価値を指します。
最低でも以下のことを設計すると良いでしょう

コアバリュー

新規事業における最も重要な概念です。
ここが成功するかどうかの95%ぐらいを占めます。
「誰の」「どんな課題を」「どのように解決するか」「その解決からどのように収益を得るか」
を設計します。
ここを解説しだすと長いので、詳細は起業の科学など、ビジネス系の起業関連書籍をご覧ください。
(おすすめあったら教えてください。)

アクター

コアバリューの 「誰の」 の部分を深掘っていきます。
アクターには多くの場合ロールが存在するので、合わせてロールも定義します。
例：
サービスにはエンドユーザーがいます。
このエンドユーザーがアクターに相当します。
このサービスではエンドユーザーはサブスクリプションを契約することで有料会員になることができます。
その場合、エンドユーザーというアクターは有料会員と無料会員の2つのロールを持つことになります。

要望

コアバリューを実現するための要望を定義します。
まずは大雑把に「できたらいいな」という思いつきレベルのものをリストアップしていき、
「アクターが××を○○したい」、「アクターを〇〇したい」 という形でブラッシュアップしていきます。
例：
利用者が商品を購入できるようにしたい。
利用者を認証したい。

要件定義

要望を抜けなく漏れなく定義します。
要望は他の要望と整合している必要があります。
要件はわかりやすく表現されている必要があります。
要望に対して要件は1:Nの関係になります。

「アクターが○○をできること」 という形で表現します。

例：
「エンドユーザーを認証したい」という要望があった場合、要件は以下の通りになります。

  • エンドユーザーが会員登録できること
  • エンドユーザーがログインできること
  • エンドユーザーがログアウトできること
  • エンドユーザーが退会できること
  • エンドユーザーがパスワードを再設定できること

ユースケース設計

要件に1:1で紐づきます。
シンプルで箇条書きに

  • 前提条件
  • 正常ケース
  • 異常系ケース
    を記述します。

さらに、ユースケースを書いたら以下のことをチェックします。

  • ユビキタス言語、ドメイン名、ページ名にない単語を使っていたら、修正する。
  • 関連する要件がCRUDを満たしているかチェックして、足りない要件があれば要件に追加する。

ユビキタス言語

曖昧さのある用語をプロジェクト専門用語として定義します。
プロジェクト内では普段からその用語を使うことで認識や実装の齟齬を防ぎます。

その他

価値を深堀りするために、もしくはプロジェクトの事情で以下のものを作成すると良いかもしれません。

  • 事業計画書
  • ピッチデッキ
  • リーンキャンバス
  • ペルソナ
  • カスタマージャーニーマップ
  • ジャベリンボード
  • ユーザーインタビュー
    などなど

システム領域

サービスのエンドユーザーには見えない裏側の仕組みを設計します。

ドメインモデリング

要件・ユースケースに対して、それらを満たせるドメインモデルを作成します。
詳細は省きます。

DB設計

上記の要件を満たせるテーブルを設計します。
詳細は省きます。

非機能要件設計

必要に応じて非機能要件を設計します。
最低でもセキュリティとバックアップはやっておきましょう。
システム構築の上流工程強化（非機能要求グレード）：IPA 独立行政法人 情報処理推進機構

デザイン領域

スケッチ→ワイヤーフレーム→モックアップ(→プロトタイプ)と徐々にブラッシュアップしていきます。
Webデザインにおけるプロトタイプとは？ワイヤーフレームとの違いや作成方法を紹介 ‣ UI/UX Front ミエルカヒートマップ

スケッチ

手書き程度の簡単なデザインを作り、画面のアイデアを形にします。
要求を定義するために、また、具体的なイメージを考えるために作成します。
画面・付箋・矢印程度のもので表現します。
類似単語として、UXブループリント、ペーパープロトなどがあります。

ワイヤーフレーム

ワイヤーフレームとは、ウェブサイトやアプリケーションの画面構成やレイアウトを設計する際に使用される、枠組みのみを示した図面のことです。
スケッチをより具体的にしたもので、ページのレイアウトをグレーのコンポーネントで表現します。

モックアップ

ワイヤーフレームをより詳細化して、完成形のデザインを作成します。

プロトタイプ

モックアップに動きをつけます。

プロジェクト領域

新規事業を立ち上げるにあたって、ヒト・モノ・コト・情報を設計・整理する領域です。
プロジェクトの状況に応じて以下を作成すると良いかもしれません

  • ステークホルダー
  • 資金繰り表
  • トレードオフスライダー
  • マーケティング
  • 開発標準・手順

ケーススタディ

今後、別の記事で書く予定です。

参考書籍

Discussion