突然ですが最近転職しました。転職先は三菱重工業 です。
業務内容については、概ねこちらの記事に書いてある感じです。
多くの人が意外に思うかも知れませんが、AWS をゴリゴリ使って毎日楽しくシステムを作ってます。
findy-code.io
製造業の世界に飛び込んだので、最近は製造業の世界に自分が経験してきたソフトウェア開発プロセス の良いところをどのように取り入れていくのか、といったことを考えることが趣味になっていたりします。
取り入れるべき開発プロセス を明確にイメージできるようにするために、一旦自分がこれまで学んだり、経験してきたソフトウェア開発のプロセスを一旦棚卸ししてみようと思い、記事にしてみました。
前提
Lean Startupについて
この開発プロセス は、Lean Startup の思想に基づいて構成されています。
Lean Startupについて間違いを恐れずに一言で言うならば、
「スタートアップにおいて、ムダ なくサービス開発を継続し続けるためのマネジメント論」です。
Lean Startupの源流はトヨタ生産方式 です。
そのため、このムダ という言葉は、トヨタ生産方式 におけるムダ から来ており、
「付加価値を高めない各種現象や結果」 と定義されています。
重厚長大 な市場調査と企画書を用意するよりも、
価値が伝わるミニマムな製品を作成しユーザーに直接ぶつけてみるほうが時間・金額的コストが安く、学びが多いこともあります。
逆によく考えずに手当り次第に機能を開発し、それが使われなかったとしたらムダが発生します。
それらの失敗から何かを学び、次に活かせるような学習のプロセスがなければ、ムダを生産し続ける組織になってします。
Lean Startupはそれらのムダを最小化するためのマネジメント方法です。
ただし、Lean Startup自体には、厳密なプロセスが規定されていません。
そのため私は、再現性高く改善できるプロセスが構築できるように、
Lean AnalyticsやDesign Sprint、ユーザーストーリーマッピング などのフレームワーク を組み合わせています。
この記事では、全体像をより具体的に把握することを優先し、Lean Startupの本質などに関する説明ではなく、それらを組み合わせたプロセスについて説明します。
この開発プロセス は1-10での利用を想定している
この開発プロセス は0-1ではなく、1-10での利用を想定しています。
すでに企画として立ち上がったサービスであり、PSFitは済ませており、
これからはユーザーの定着を目指していくところでの利用です。
それ以外のユースケース では有効かどうかを確認できていません。
ソフトウェア自体の開発にはアジャイル を採用している
この開発プロセス はすでに決まったものを時間掛けて作るのではなく、ユーザーの反応を見ながら作るものを決めます。
そのため、短い期間で適宜軌道修正をすることができるアジャイル を採用しています。
アジャイル 開発においては、職種をまたがってチームで開発するプロセスを提供してくれるスクラム と、
ソフトウェアエンジニアに向けてより良い規範を提供してくれるXPを組み合わせています。
ただし、スクラム やXPの部分については、それだけで膨大になってしまうため今回は説明しません。
もし、詳細を知りたいという方がいましたら、ブックマーク上でコメントいただけますと！
開発プロセス の全体像はこちらになります。
なお、この開発プロセス は市谷先生の「正しいものを正しくつくる」という書籍をベースにしています。
開発プロセス の全体像
この開発プロセス の左側をざっくり３行で説明すると、こんな感じになります。
リーンスタートアップ で事業計画を作成しリーンアナリティクスで事業計画に対して数字的な裏付けを行い
Design Sprint でアイデア を作るプロセスと、それを実際に決定する合意プロセスを提供します
この章では全体の開発プロセス について概要を軽く記載します。
それぞれのプロセスの詳細については、次の章にてまとめます。
最初のステップ：事業計画
事業計画フェーズでは、サービスの性質と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 Canvas ( leanstackの公式ページより引用 )
その９つの要素とは、
解決すべき課題、ソリューション、既存の代替品、主要指標、独自の価値提案、
競合優位性、ハイレベルコンセプト、顧客セグメント、アーリーアダプター 、コスト構造、収益の流れ、になります。
ビジネスはこの９つの要素の集合です。
どれだけ売上があったとしても、コスト構造が将来的にも掛かる見込みがある事業は継続することができません。
また、短期的に見てそれなりに利益が出たとしても、狙った顧客セグメントに利用して貰えなければ将来的に十分な成長を見込めない可能性もあります。
サービス開発当初は、この９つの要素はあくまでも仮説になります。
そのため、定期的にこのキャンパスを見直し、軌道修正をし続ける必要があります。
なお、リーンキャンバスについては上記９つの項目について検証すべき順番を定めており、その結果によって打ち手は変わります。
このあたりの詳細を知りたい場合は、こちらの書籍を参照してください。
リーンアナリティクスを利用してKPIを設計する
リーンキャンバスの主要指標は、Lean Analytics の手法を利用して決定します。
Lean Analyticsについて一言で説明すると「サービスにおいて最も注力すべき１つの指標をビジネスモデルと現在のステージから導き出すためのフレームワーク 」です。
Lean Analyticsは Lean Startupのマネジメント手法に対して、より厳密なデータ駆動の意思決定プロセスを追加します。
Lean Analyticsのフレームワーク において、スタートアップは「共感」、「定着」、「拡散」、「収益」、「拡大」の５つのステージで成長する としています。
共感ステージでは、顧客インタビューやソリューションインタビューを繰り返し、解決に値する課題と、ビジネスとして成立しうるソリューションの発見を行います。 定着ステージでは、顧客にとって必要不可欠である、定期的に正しく利用される機能を作ります。 拡散ステージでは、ユーザー獲得や成長にフォーカスします。 収益ステージでは、収益構造について見直して利益の最大化を行います。 拡大ステージでは、市場におけるシェアを拡大するために、競合他社を見て戦略を考えていきます。
それぞれのビジネスモデル・ステージ毎に最も重要視すべきとされている指標は下記のようになります。
Lean Startup/ Analytics では、この最重要視する指標をOMTM(One Metric That Matters) と呼びます。
厳密に言えば違うかも知れませんが、私はこれをKGIとして扱っています。
KGIが決まったならば、それを扱える粒度まで分解していきましょう。
操作や計測が不可能なKPIは使うことができません。
その後、分割したKPIに対して、中期的に追うものの優先度を決めていきます。
KPIの定め方については書籍に説明を譲りますが、
僕としては 顧客に提供する価値をKPIにして、必ず１つ以上組み込むこと を強くお勧めします。
顧客視点を忘れたサービスでも、順調に成長しているときは問題が顕在化しません。
しかし、サービスの成長が鈍化してきたり苦しい局面になると、
そのようなサービスでは多くのチームメンバーのモチベーションが低下し離職につながります。
情熱を持ってサービスのビジョンを語れるプロダクトマネージャーは数多くいます。
しかし、本当に大切なのはそれを実際の施策にまで落とし込んで形にしていくことです。
そういった意味でも、顧客に提供する価値をKPIに置いて、チーム全体で追っていきましょう。
仮説立案
もうひとつ大きな問題は、意思決定のプロセスです。通常、おもしろいアイデア が出てきたら、それをある段階で役員レベルで評価します。筆者も何度かそういう状況を見てきました。そこで何が起こるかというと、既存事業はともかく、新規事業を評価する目のない人たちにより、適切でない評価が下されることが多くなります。たとえ評価が適切であったとしても、既存の市場がなかったとしたらリスクの高いアイデア ということになりますから、そのリスクを取る主体が必要になります。すると、必ず反対者が出ます。そして、残念ながら、アイデア は実行に移されないことになります。なぜならば、役員の合議制では誰も、「リスクのあるアイデア を採用した結果に対する責任」を取りたくないからです。 エンジニアのためのデザイン思考入門 1.3.2 章より引用
この本にはこんなこと書いてますが、役員に限らず新規事業を評価する目を持っている人なんてほとんどいないというのが僕の持論です。
低リスクな施策を行い続けじりじりとサービスの状況が悪くなり、首が回らなくなったら一発逆転を狙ってハイリスクな施策に全力投球してしまう。
そんなリスクの取り方をしている企業、サービスは外から見たら分かりやすいかも知れませんが、内部からでは中々気づかないこともあるでしょう。
普通の人がリスクを取るには、根拠の裏付けができるものやプロセスというものが必要になります。Design Sprintは、そのための様々なプロセスを提供してくれます。
Design Sprint は Google Venturesにて考案された開発プロセス です。
Design Sprint が提供してくれるプロセスは大きく２点あります。デザイン思考に基づいたアイデア の作成プロセスと、そのアイデア を実行に移すための合意形成プロセスです。
Google Venturesが考案した開発プロセス だから、さぞかし理知的なんだろうなと思って読んでみると、意外と下記のような文章が多いことに驚きます。
スプリントをやるのはいいが、まる一週間は参加できないと決定者にいわれたら、要所要所で参加してもらおう。月曜日に問題についての考えを話してもらい... (中略)こうしたカメオ出演 しかできない場合は、常時参加できる代理人 を正式に立てて貰う(中略)あるスプリントでは、CEOがデザインディレクターにこんなメールを送った。「本プロジェクトのすべての意思決定権限を、貴殿に付与します」ばかばかしい？たしかに。効果はある？もちろんだ。 SPRINT 最速仕事術 P61より抜粋
このようにDesign Sprintでは、ある種ばかばかしいけれども実際に組織の中でよく起こる問題に対しても真剣に向き合っており、その上で合意形成が迅速に行われるような方法を提供してくれます。
Design Sprint では、開発に入る前に解決すべき課題をチームの中で明確にし、１週間という限られた期間の中で課題に対して有効と思われるプロトタイプの作成とテストまで行います。
今回の開発プロセス においては、解決すべき課題はリーンスタートアップ / Analyticsによって提示されます。
説明の詳細は書籍に譲るとして、ここでは Design Sprintを行う際の注意点を記載します。
Design Sprintを行う際の注意点は下記３点になります。
事前にサービスのライフサイクルの全体像及び数値を書き出しておく
事前に、一部のメンバーだけでも解決すべき課題について 5 whysをやっておくと、アイデア の有効性を検討する際に役に立つ
プロトタイプを提示するときは、使われる際の状態をできる限り定量 的に想定しておく
ユーザーヒアリ ングで顧客から聞いたことを鵜呑みにして施策立案をすることは良い方法ではありません。
顧客からの情報はボトムアップ 的な情報として価値はありますが、サービス開発者としてもトップダウン で課題を捉えておく必要があります。
そのために、事前にサービスのライフサイクルの全体像を書き出しておいて 、その上で課題を抽出し 5 whysで分析しておくことをお勧めします。
課題をマッピング しておくことによって、Design Sprintにて提案されたアイデア がどこの課題にアプローチするものなのか整理することができるようになります。
ものによっては、複数の課題を連鎖的に解決してくれるアイデア を適切に拾うこともできるでしょう。
このように適切な事前準備をしておくことによって、すぐれたアイデア を拾える下地を作っておくことが Design Sprintの効果を最大化する上で重要となります。
もう一つ行っておきたい準備としては、機能が使われる上での状況を可能な限り定量 的にイメージした上でアイデア を出すことです。
例えばチャットアプリにおいては、メッセージの流量、チャンネルの数によって適切なUIは異なります。
それを想定した上でプロトタイプを作って実験しなければ、間違った評価を得ることになってしまいます。
最後に
この章の冒頭で、初期に我々が救われ、思い違いをさせられた２つのフレーズについて取り上げた。「トイ・ストーリー 」後、
「物語が一番偉い」と「プロセスを信じよ」の指針に従えば、集中と前進が約束されたかのように思っていた。 ( 中略 )
同じように、「プロセスを信じた」が、「トイ・ストーリー ２」はプロセスによっても救われなかった。
「プロセスを信じよ」が「何もしなくてもプロセスがまちがいを直してくれる」に変わってしまっていた。そのときに欲しかった安堵は得られたが、同時に、ガードも低くなり、最終的には受け身になってしまった。
もっと悪いことに、いい加減になってしまった。 ( 中略 )
「プロセスによって自分が作られる部分もあれば、壊される部分もある」(中略) プロセスを「信じる」よりも「促す」ほうがイメージに近いと話してくれた。
プロセスのどがもたついているのかを確認して、尻を叩く。この場合も、プロセス自体ではなく個人が積極的な役割を果たす。 ピクサー 流 創造するちから 第一部４章 ピクサー らしさ より抜粋
ここまで開発プロセス について長々と書いてきました。
ですが、私個人としては、開発プロセス を守ることが最も大切なことだとは思っていません。
その開発プロセス を適用することで、どのような開発チームにしたいのかを考えることが最も重要だと思っています。
なので、目標とする開発チームのイメージが明確になければ、どのような開発プロセス も意味がありません。
Google は SRE、Design Sprint、OKRと、様々な開発プロセス を提案しています。
これらの開発プロセス を見ていて感じることは、人間の強さと弱さに向き合って、強さを最大化し弱さを最小化する仕組みを考えているように感じます。
開発プロセス は、エンジニアとして見れば、Rails のようなフレームワーク です。
Rails を使って、どのような価値を人々に届けたいかを決めるのは、開発者自身だと思う次第です。
