最初に
さて、いきなり私事ですが、転職しました。 転職した会社の名前については、まだ社のSNSポリシーなどを正確に把握していないため、 こういった場では書かないでおきます。
転職した会社は日本に古くからある製造業です。 ここ１〜２年でクラウドの利用を開始したとのことですが、すでにGKE＆GO、AWS＆サーバレスでシステムを開発しています。 日本企業の技術者の技術力の高さを改めて実感しながら、 僕がこの企業で成果を出すために色々と模索していかなければなぁと気を引き締め直しています。
新しい会社は、僕がこれまで経験してきた企業とは全く違う性格の会社です。 今の会社で歓迎されるスキル、使えるスキル、捨てないといけないスキルがあります。 ソフトウェアエンジニアのスキルについては、大枠としては企業毎に大きな差はないでしょう。 しかし、プロジェクトマネジメントに関しては、ビジネスの性質によって求められる能力や常識が異なると思います。 この点について適切に整理するために、一度僕が経験した開発プロセスの概要を書き下してみます。
前提
Lean Startupについて
この開発プロセスは、Lean Startup の思想に基づいて構成されています。 Lean Startupについて間違いを恐れずに一言で言うならば、 「スタートアップにおいて、ムダなくサービス開発を継続し続けるためのマネジメント論」です。 Lean Startupの源流はトヨタ生産方式です。 そのため、このムダという言葉は、トヨタ生産方式におけるムダから来ており、 「付加価値を高めない各種現象や結果」 と定義されています。
重厚長大な市場調査と企画書を用意するよりも、 価値が伝わるミニマムな製品を作成しユーザーに直接ぶつけてみるほうが時間・金額的コストが安く、学びが多いこともあります。 逆によく考えずに手当り次第に機能を開発し、それが使われなかったとしたらムダが発生します。 それらの失敗から何かを学び、次に活かせるような学習のプロセスがなければ、ムダを生産し続ける組織になってします。 Lean Startupはそれらのムダを最小化するためのマネジメント方法です。 ただし、Lean Startup自体には、厳密なプロセスが規定されていません。 そのため私は、再現性高く改善できるプロセスが構築できるように、 Lean Analyticsやユーザーストーリーマッピングなどのフレームワークを組み合わせています。 この記事では、全体像をより具体的に把握することを優先し、 Lean Startupの本質などに関する説明ではなく、それらを組み合わせたプロセスについて説明します。
この開発プロセスは1-10での利用を想定している
この開発プロセスは0-1ではなく、1-10での利用を想定しています。 すでに企画として立ち上がったサービスであり、PSFitは済ませており、 これからはユーザーの定着を目指していくところでの利用です。 それ以外のユースケースでは有効かどうかを確認できていません。
ソフトウェア自体の開発にはスクラムを採用している
この開発プロセスはすでに決まったものを時間掛けて作るのではなく、ユーザーの反応を見ながら作るものを決めます。 そのため、短い期間で適宜軌道修正をすることができるアジャイルを採用しています。 ただし、スクラム開発部分については、それだけで膨大になってしまうため今回は一旦簡単な説明だけに留めます。
それぞれのフレームワークについて詳細を記載すると全体感の把握が難しくなるため、今回は概要をざっくりと説明します。 もし、詳細を知りたいという方がいましたら、ブックマーク上でコメントいただけますと！
開発プロセスの全体像
開発プロセスの全体像はこちらになります。 なお、この開発プロセスは市谷先生の「正しいものを正しくつくる」という書籍をベースにしています。
この章では全体の開発プロセスについて概要を軽く記載します。 それぞれのプロセスの詳細については、次の章にてまとめます。
最初に事業計画があります。 事業計画フェーズでは、サービスの性質とKGI/KPIの設計、ステークホルダーとのコミュニケーション設計を行います。 リーンキャンバスと、インセプションデッキを作成し、誰のためのどのようなサービスを作るのか。我々のサービスの競合優位性は何なのか。 サービス開発を進めていく上でのステークホルダーと、ステークホルダーの人たちのコミュニケーション方法を簡潔にまとめます。 そして、Lean Analyticsをベースに現在のサービスのステージを特定し、そのステージに適したKGI/KPIを設定します。 基本的にすべてのKPIを追うことは出来ません。そのため追うべきKPIの優先度も決めておく必要があります。 これらの資料は何度も作り直すことになるでしょう。 それはサービスを開発していくなかで、ユーザーや市場の解像度が上がるからです。 資料を修正する必要性が生まれるということは、チームが学習をしているということです。 それをポジティブに受け止めて、チームで話し合いながら更新していきましょう。
２番めの手順は仮説立案です。 仮説立案フェーズでは、事業計画フェーズで定めたKGI/KPIに対して、有効と思われる機能の仮説を出します。 仮説の立案は Design Sprintを利用して行います。 Design Sprintでは、KPIから逆算して達成すべき課題を定義します。 例えば、定着フェーズのECサービスを例に考えます。 KGIが 「90日以内に戻ってくる購入者の割合」として、 KGIに紐づくKPIの１つを「ユーザーが目的の商品を見つけることができた割合」としたとします。 このようにKPIを決めたとき、解くべき課題は２点に集約されると思われます。 １点目は「ユーザーが求める商品を用意することができる」であり、２点目は「ユーザーが目的とする商品に到達できる」になります。 Design Sprintでは、KPIにヒットしうるビジネス上の課題を予め建ててから、その課題に関連するユーザーの動きをインタービューを通して整理します。 整理する上でカスタマージャーニーマップのようなものを作ることもあります。 その後、チーム全体で課題を解決しうる機能の案を出し合い、簡単なモックを作って有効性を検証します。 詳細は追って説明しますが、Design Sprintはまず最初に、解くべきビジネス上の課題を明確にします。 また、開発物を決めるまでのプロセスも厳密に定められているため、迅速な意思決定が可能になります。
３番目の手順は、検証計画の作成です。 検証計画の作成は著書 Running Lean の8.5章にて説明されている「１ページの実験計画書」を用いて行います。 Design Sprintにより提案された案を、実験計画書に落とし込んでいきます。 実験計画書においては、開発する内容、求める成果、成果が得られると思われる根拠、成果の計測方法、実験の期間を記載します。 このとき、もし会社にデータ分析チームがいるのであれば、根拠の部分に関して定量的な裏付けを行うと良いでしょう。 また、世の中にはすでに同じ様な実験が行われている可能性もあります。 そういった実験結果が論文などで公開されていることもあるため、一度探してみても良いでしょう。
４番目の手順は、MVPの特定になります。 「１ページの実験計画書」で計画した実験を達成するために必要な最小限の機能を洗い出します。 この作業は「ユーザーストーリーマッピング」という手法を用いて行います。 ユーザーストーリーマッピングの「ユーザーストーリー」はスクラムで用いられる「ユーザーストーリー」と同じもので、 ユーザーがサービス上で目的を達成する上で発生するシーンと、それに対応した「ユーザーストーリー」をマッピングしたものになります。 全体を俯瞰することで、ユーザーに価値を提供するために必要な機能の一覧を把握できるようになり、目的を達成するための最小限の機能を認識できるようになります。 なお、MVPを特定する上では、セキュリティや法律の知識も必要になります。 例えば契約書を交わす上で必要な手順などを適切に把握していなければ、法律に違反するサービスを作ってしまうこともあります。 法律は機能単体で評価されるわけではなく、サービスの機能全体、そして実態で評価されます。 そのため、他のサービスの機能をそのまま自分たちのサービスに持ってきたからといって、法律上問題ないとは限りません。 また、法律を把握していれば、競合他者のサービスよりも、より良い機能を提案できることもあります。 そしてセキュリティについても意識する必要があります。MVPであるからといってセキュリティを疎かにすることはできないからです。
MVPの特定まで終わってしまえば、あとはスクラムのプロセスに乗せて開発を行えます。 そして出来たものを評価し、学習によって得られた結果をもとに、次の開発物を考案していくという流れになります。
以降、それぞれの開発プロセスについてより詳しく記載していきます。
事業計画
サービスを開発する上で、最も重要なのは事業計画です。 事業計画がなければ、その事業に投資すべきか否かを判断することができません。 事業計画は企業毎にフォーマットがあると思いますので、承認者に見せる資料はそのフォーマットに従ったものを作ることになります。 しかし、一般的な企業における事業計画書では、開発に携わるすべてのメンバーが理解することには難しい場合がほとんどです。 そのため、チームの内外で共通認識を作るための別のフォーマットも必要になります。 そのフォーマットというのが、リーンキャンバスとインセプションデッキです。
リーンキャンバスは、「Running Lean」の著者で知られるアッシュ・マウリャ氏が提唱するフレームワークで、 ビジネスモデルの９つの要素を１枚の紙にまとめたものです。
その９つの要素とは、 解決すべき課題、ソリューション、既存の代替品、主要指標、独自の価値提案、競合優位性、ハイレベルコンセプト、顧客セグメント、アーリーアダプター、コスト構造、収益の流れ、になります。 ビジネスはこの９つの要素の集合です。 どれだけ売上があったとしても、コスト構造が将来的にも掛かる見込みがある事業は継続することができません。 また、短期的に見てそれなりに利益が出たとしても、狙った顧客セグメントに利用して貰えなければ将来的に十分な成長を見込めない可能性もあります。 サービス開発当初は、この９つの要素はあくまでも仮説になります。 そのため、定期的にこのキャンパスを見直し、軌道修正をし続ける必要があります。 このあたりの詳細を知りたい場合は、こちらの書籍を参照してください。
リーンキャンバスの主要指標は、Lean Analytics の手法を利用して決定します。 Lean Analyticsについて一言で説明すると「サービスにおいて最も注力すべき１つの指標をビジネスモデルと現在のステージから導き出すためのフレームワーク」です。 Lean Analyticsは Lean Startupのマネジメント手法に対して、より厳密なデータ駆動の意思決定プロセスを追加します。 Lean Analyticsのフレームワークにおいて、スタートアップは「共感」、「定着」、「拡散」、「収益」、「拡大」の５つのステージで成長する としています。 共感ステージでは、顧客インタビューやソリューションインタビューを繰り返し、解決に値する課題と、ビジネスとして成立しうるソリューションの発見を行います。 定着ステージでは、顧客にとって必要不可欠である、定期的に正しく利用される機能を作ります。 拡散ステージでは、ユーザー獲得や成長にフォーカスします。 収益ステージでは、収益構造について見直して利益の最大化を行います。 拡大ステージでは、市場におけるシェアを拡大するために、競合他社を見て戦略を考えていきます。 それぞれのビジネスモデル・ステージ毎に最も重要視すべきとされている指標は下記のようになります。
Lean Startupでは、この最重要視する指標をOMTM(One Metric That Matters) と呼びます。 厳密に言えば違うかも知れませんが、私はこれをKGIとして扱っています。
KGIが決まったならば、それを扱える粒度まで分解していきましょう。 操作や計測が不可能なKPIは使うことができません。 その後、分割したKPIに対して、中期的に追うものの優先度を決めていきます。 優先度を決める上で大切なことは、書き出したKPIについてその性質を掴むことです。
開発チームとしてすべてのKPIを追うことは短期的にはとても難しく、１つないしは２つ程度のKPIに注力することになります。 しかし、KGIを分解したKPIといっても、そのKPIを上げることがKGIの上昇につながるというのは仮説でしかありません。 故にどの仮説から検証していくのかというのは、とても重要な問題になります。 大きな意思決定の軸としては、今すでに持っている情報からKGIを達成する確度が高いものを選ぶか、 持っていない情報を得るために探索することを選ぶのかの２つになります。 後者をないがしろにすると途中まで順調に成長するけれども、最後に伸び悩む問題に遭遇する可能性があります。 その場合、結果的にサンクコストが大きくなってしまうでしょう。
仮説立案
7/6 (月)に書く 5 whysを利用したトップダウンのアプローチと、Design Sprintを利用したボトムアップのアプローチを繰り返し、問題に対する解像度を上げて、複数の課題にアプローチできるアイデアを探し出す話しをする。
検証計画の作成
7/7 (火)に書く
MVPの特定
7/8 (水)に書く
