初めに

ここ一年くらいですが、コロナ禍の影響もあり、新しくインターネットを利用したサービスのサービスを開始したいという相談を多く受けます。コロナ禍による事業再構築補助金等を利用して、収益構造の転換を図りたいというお客様が多いように思われます。
そういったお客様は、これまで、ITサービスには無縁であったことが多く、依頼内容も、RFPというよりは、アイデアのメモレベルであったり、口頭ベースであることが多いです。そういった場合、私はよく、リーンキャンバスと、ユーザーストーリーマッピングを使用して、お客さまが実現したいことを整理し、作成してほしいものに差異がないか確認するようにしています。ちょうどもうすぐ新しい案件で、要件定義を行うことになっているので、改めてこの方法を文章化して整理してみます。

リーンキャンバス

リーンキャンバスは、「Running Lean ―実践リーンスタートアップ」の著者であるアッシュ・マウリャ氏が考案したビジネスモデルを１ページで、下図のように、９つの要素で整理するフレームワークです。お客様の考えているサービスの顧客やその顧客が抱える課題、そしてサービスのソリューション、顧客へのパスや、収益モデル、コストなどを共通認識として共有するために非常に役に立ちます。

顧客セグメントと課題

リーンキャンバスを作成する場合、まず最初に、顧客セグメントを考えます。リーンキャンバスの考案者の、アッシュ・マウリャ氏の「Running Lean ―実践リーンスタートアップ」では、最初に課題から記述することになっていますが、インターネット記事によっては、顧客セグメントを記述するように紹介されていることも多いです。実際なんどかやってみたところ、顧客セグメントを先に決めないと、課題が、どのような人の課題なのか、わかりにくいことが多いので、顧客セグメントを最初に考えるようにしています。顧客セグメントには、早期にサービスを利用してくれそうな具体的なユーザー像をアーリーアダプターとして記述します。
次に、その顧客セグメントが抱える課題を考えます。実際のケースでは、お客様は実現したいサービス（ソリューション）ありきなので、そのソリューションが響く、顧客セグメント層と、解決できるとお客様が考えている課題はこれですよね？という確認を行うことになります。

独自の価値提案

次にサービスが提供する独自の価値を考えますが、ここを記述するのはなかなか難しいです。とはいえ、新しいサービスを作成したいというお客様は、何等かの仮説（こういうものをつくればこういう理由であたる）を持っているので、それを説明していただき文章化していきます。漠然としたイメージしかもっていないお客様の場合も、ここを一緒に考えることで、ビジネスモデルの価値を考えることができます。

ソリューション

次にサービスが提供するソリューションを考えます。ここは、お客様がやりたいことなので、すんなり記述できます。ただ、あまり多くをかかないように、優先度の高い３つのソリューションを記述します。

チャネル

次にサービスの顧客へのチャネルを考えます。事業を展開したいと考えるお客様は、比較的既存のユーザーへのチャネルを持っていることが多いので、それらを利用したり、SEOや、ブログなどのインバウンドチャネルや、Web広告などのアウトバウンドチャネルなどが考えられます。

収益の流れやコスト構造

次に、収益の流れとコスト構造を考えます。収益の流れは、どうやって収益を得るのかということを明確にします。よくあるのは、サービス使用料を得る、アドセンス広告収入、アフィリエイト広告収入などでしょうか。サービス使用料をとるようなサービスの場合、決済機能の実装が必要になります。
コスト構造は、開発費用や、運用費用や広告費用を精査します。収益とコストが整理できると、代替ローンチ後何か月目で、サービスが黒字になるかなどの目途が立ちます。

主要指標

サービスがどれくらいうまくいっているのかを判断するための指標を考えます。よく使われるのは下記の海賊指標(AARRR)という指標です。

• Acquisition（獲得）：何も知らなかった人が見込み客になったとき
• Activation（アクティベーション）：見込み客が満足のいくユーザー体験したとき
• Retention（定着）：反復利用するようになったとき
• Revenue（収益）：お金を支払うとき
• Referral（紹介）：顧客が他の顧客へサービスを紹介したとき

実際に上記のメトリクスを取得する方法や、その機能を実装するかはさておき、サービスの状況を判断する指標は明確にしましょう

圧倒的な優位性

最後に、圧倒的な優位性を記述します。正直、ここは書かないことも多いです。納得できる圧倒的な優位性があるビジネスモデルの企画はそうはありません。

ユーザーストーリーマッピング

リーンキャンバスを作成し、ビジネスモデルの共通認識が得られると、次はユーザーストーリーマッピングを実施します。ユーザーストーリーマッピングは、お客様が提供しようと考えているサービスを、ユーザーがどのように利用するのか、どのような機能を作成する必要があるのかということを明確にするのに役に立ちます。

ストーリーの流れ（ナラティブフロー）を考える

やり方は色々ありますが、私は、最初に、サービスをユーザーが使用する一連の流れを考えます。〇〇をして、それから〇〇のように大まかなユーザーのストーリーと、その流れを考えます。多少ストーリーが時系列的におかしくても気にしません。とくに最近は、マッチングサービスなどマルチサイド（提供する側と、それを利用する側の両方のユーザーが存在する）のビジネスモデルなど、時系列の前後が一意でない場合も多いです。そういう場合は、別のユーザーストーリーマッピングにしてもよいと思います。肝心なのは、一連の流れを最後まで作ることです。

ストーリの厚みを作る

次に、ストーリーの流れに厚みを作ります。〇〇、もしくはＸＸをするのような感じで、縦にユーザーストーリーを追加していきます。この時点ではできる、できないは気にせずに思いついたものはすべて追加していきます。ストーリーを追加した結果、しっくりこないのでナラティブフローを修正することも多々あります。

バックボーンを作る

次に、ナラティブフローを、グループ化し、ストーリーの骨格を作成します。個人的には、ここはあまり重要視してません。

リリースのスライスを考える

最後に、縦にならんだストーリーを優先度で入れ替えて、各リリースのスライスに分けていきます。案件自体のスコープから除外し、追加開発でお願いすることもあります。最終的に、この成果が、お客様に実装を約束する要件ということになります。

終わりに

以上が、私がよくやっているリーンキャンバスと、ユーザーストーリーマッピングを使用した要件定義です。当然、お客様より、重厚な要件定義書の提出を求められたり、厳密にウォーターフォールで開発する場合には、なかなか適用するのは難しいですが、新しいサービスをスタートアップする際は、このような方法をとると、お客様のやりたいことが明確になってよいと考えています。
また、業務システム開発など、社内システムの開発時には、ちゃんとしたRFPはあることが多いですが、そういう場合でもリーンキャンバスは不要ですが、ユーザーストーリーマッピングは結構有効なのではないかと考えています。ただ、そういったケースは、お客様の社内のシステム部門が、すでに、ユーザー部門のヒアリングを済ませており、そのヒアリング結果の要求に対して要件定義書を作成することが多いので、改めて、ユーザー部門にヒアリングしてユーザーストーリーマッピングさせてくれというのは、なかなか難しいでそうな気がします。

参考資料

• Running Lean ―実践リーンスタートアップ (THE LEAN SERIES) アッシュ・マウリャ (著)
• ユーザーストーリーマッピング　Jeff Patton (著)