7/25に開催したMeetupで、当日ご参加頂いた、達人出版会の高橋さんより「アジャイルサムライ-達人開発者への道-」というタイトルの書籍を頂戴しました。
本ブログで紹介する記事はどちらかというと「顧客開発モデル」に関連する記事が多く、アジャイル開発に関する情報を提供していなかったのですが、この本は一読して「これは絶対に必読だ!」と強く思いましたのでご紹介しようと思います。
「必読だ!」と思った理由は、本書に書かれていることはまさにリーンスタートアップの実践そのものであり、これから実践に移そうとするスタートアップにとっては、この書籍の内容を実践しさえすれば、リーンスタートアップの半分は実行可能なぐらいにピッタリなのです。
「アントレプレナーの教科書」または”Running Lean”と本書の2冊は、現時点で私の考えるリーンスタートアップ・バイブルです!(もちろん自分たちなりのカスタマイズは必要ですが)
では読んでいて「グッ」ときた箇所をハイライトでご紹介します。
P.13:ソフトウェア開発の3つの真実として「プロジェクト開始時点にすべての要求を集めることはできない」と紹介されています。
この姿勢はまさに”Pivot”を実践するリーンスタートアップの考え方そのもので、これからどのようなロードマップを引いていくべきなのかを表す、もっともシンプルな教えです。アイディアの段階ではまだまだ仕様は全然決まってないということですね。
P.17:アジャイルチームのご紹介ウォーターフォール型のプロジェクトではチームメンバーの役割は明確にされていますが、アジャイルチームでは、すべての役割は「チーム」の責任とされています。「アントレプレナーの教科書」でスティーブ・ブランクも、製品開発チームと顧客開発チームはイコールであり、開発担当、営業担当、マーケティング担当といったチーム編成はスタートアップにとっての大きな問題だと言っています。創業者チームのすべてのメンバーが同じ責任を共有することは、リーンスタートアップの実践においてとても大切なことです。P.26の職能横断型チームにも同様の記述あり。
P.21:積極的に深く関わる顧客の存在アジャイル開発では、顧客(プロダクトオーナー)の積極的な関与が必要となります。どのようなソフトウェアを作って欲しいか?を知っているのは顧客(ユーザ)だけだからです。リーンスタートアップを実践するアントレプレナーにとって、プロダクトオーナーたる存在は、将来そのサービスを使ってくれるユーザそのものですから、彼らの意見を聞かないで製品開発を行うということは、アジャイル開発において顧客の関与なしに開発をすることに等しく、最終的にユーザが満足するサービスが出来上がることは決してないでしょう。Meetupなどで「ユーザから有効なフィードバックを得るためにはどうしたらよいか?」という質問をよく受けるのですが、最も有効な手段はユーザとの信頼関係を構築することです。一度信頼関係を築いてしまえば、その先の手段についてはあまり問題ではなくなって来ますので、まずはUVPでユーザからの信頼を勝ち取る努力が必要です。
P.32:「誰かがコードを書き始めるまでは、何もかもが捕らぬ狸の皮算用だ」
まさに真実!
P.46で紹介されている「インセプションデッキ」は、リーンスタートアップを実践する際にも非常に有効なツール群です。
「我々はなぜここにいるのか?」に応えることは、Pivotを行う際の強力なビジョンになり、「エレベーター・ピッチ」で紹介されている質問文は、そのまま顧客の仮説記述になります。また、「やらないことリストを作る」という観点は、MVPを目指すスタートアップにとって、TODOリストを作成することよりも大きな意味を持ち、チームのスピードを格段に上げることになるはずです。
P.156:MMF(Minimal Marketable Feature Set)この2つの”M”を理解することは、リーンスタートアップの実践において非常に大切です。最初の”M”のMinimalは、「システムの価値の80%がシステムの機能の20%からもたらされている」という言葉に代表されるよう、MVPを体現する言葉です。長々とした機能リストを作成するなどもってのほか!2つめの”M”は、「市場価値があること」を意味しています。最小限の機能で市場価値を生み出せないプロダクトでは、成功する可能性は非常に低いでしょう。
P.191:ユーザのペルソナを作成する
私は普段から、リーンスタートアップの最初の一歩である「顧客の仮説」の記述は、ターゲットするユーザを絞り込めば絞り込むほど、リーンスタートアップのスピードは増すとお勧めしています。アジャイル・サムライでも、ユーザのペルソナを作成することを推奨しており、ユーザの理解を深める手段として紹介されています。絶対にやるべきですね。
P.192:ペーパープロトタイプの作成
これもリーンスタートアップでまさに推奨されている手法。出来上がるソフトウェアのイメージを手軽に素早く、しかもほぼ無料で作成できるため、とても効果は高いです。
P.198:カンバンプロジェクトの進捗管理方法として、トヨタのカンバンボードが推奨されています。リーンスタートアップでは”Running Lean”の著者Ash Mauryaも推奨しており、ぜひ活用したいところです。ただし、仮説と検証を繰り返すリーンスタートアップでは、カンバンボードのカスタマイズが必要です。
P.273:継続的インテグレーションリーンスタートアップを実践していく上で、継続的開発環境を構築することはとても大切なインフラ整備です。単に開発環境でバージョン管理システムの準備やテストの簡略化をするということではなく、リリースに備える文化をチーム内に構築することが大切です。
いかがでしょうか?まさにリーンスタートアップですね。
それと最後に最も大切な事を。この本に書かれているようなチームが出来たとしたら、たとえプロダクト自体が失敗したとしても、そのチームはとても高い価値を持つようになり、セカンドチャンスを得るのは非常に容易になるということです。リーンスタートアップを実践することの意味は、アントレプレナーの価値を、プロダクトやサービスから、創業者チームの価値にすることが出来るのです。日本でもシリアルアントレプレナーが増えていくには、こうしたことが当たり前にできるチームがどんどん出来てくる必要があるのかもしれません。言い換えると、シリコンバレーにはこうしたチームが沢山存在していることも、シリアルアントレプレナーが多い理由なのしょうか。
ちなみにこの書籍は2011年8月10日(つまり今週水曜日)の発売です
いち早く手にして、リーンスタートアップの実践につなげてみてください!