agile
lean

Startupプログラマの為の新アジャイルマニュフェスト(Kent Beck: beyond agile programming)

More than 3 years have passed since last update.

はじめに

Kent Beck氏がスタートアップのイベントに登壇し、素晴らしい講演をしたビデオを友人のタイムラインから見つけました。Startup Lessons Learnd: Kent Beck talks beyond agile programming

アジャイルマニュフェストは10年が経過して、誰かの為にソフトウェアを作っていた時代から、スタートアップの時代に移行し、内容が一部古くなっていました。ところがこの講演でKentBeck氏は、それに対する素晴らしい回答をしてくれています。この内容が2010に行われているとは驚きです。

今回、このビデオを未熟なりにディクテーションして、適当ですが、日本語訳を作ってみました。本人に承認を取るつもりですが、ダメなら削除するつもりです。

スタートアップ時代のプログラマの考え方のヒントが沢山つまっているのではないでしょうか?つい、熱くなってしまいました。

また、ディクテーションも日本語訳もこれでいいかわからない部分もあるので、「違うだろ!」と思ったら是非Pull Requestを送っていただければと思います。皆さんのお役に立てれば幸いです!

Kent Beck : Beyond agile programming

1. ごあいさつ

皆さん、こんな朝早くからおいでいただきありがとうございます。何か凄い事を達成したことをお話できるわけではありませんが、皆さんが来てくれて本当に嬉しいです。

私は今日予定されている講演の中で、最もイマイチなアントレプレナーとして講演する名誉を授かりありがとうございます。私は、11のスタートアップに関わってきました。しかも、その中の1社すらも凄いお金を稼いだわけではありません。

大きな規模で成功したのは、一つだけ。JUnitです。

私はお話する内容(リーンスタートアップの分野)に豊富な知識があるわけではありませんので、オープニングスピーチをしてしまっていいのだろうかとは思っています。しかし、皆さんにはすぐにお話しする事を理解していただけると思いますのでお話を始めたいと思います。

しかし、私はあきらめません。リーンスタートアップのスタッフの皆さんが、新しいビジネスに挑戦するエネルギーを私にくれたのですから!
特に私が人生を費やして磨き上げてきた技術的な側面からお話したいと思います。

2. やぎのかゆいところ

私は南オレゴンの、片田舎のさらにはずれにすんでいます。そして、やぎを飼っています。2匹のあかちゃんで、すごく可愛くてふわっふわなんです。彼らと外に出ていたときに、背中の方かた、その下の方にかけて掻いてあげていました。多分虫かなにかで、気持ち悪かったのでしょう。そして、お尻のあたりを掻いてあげたら突然、やぎが気持ちよさそうに啼きました「あー、気持ちいい」って多分。

面白い。私がいろいろなところを掻いてあげても、何もおこらなかったのに、あるポイント、つまりやぎがかゆいポイントを掻いてあげると、今までとずっと同じ事をしていても、やぎが気持ちよくなるのです。この事は、私は想像できませんでした。多くの他の場所でやっていた、効果薄だった同じ事が、突然、すっごくやぎにとってもむちゃくちゃ効果的な事になったのです。スタートアップもこれに似ていると思います。

あなたが何かをやり続けていても、レスポンスが無い。やっても、やっても、レスポンスが無い。8個目ぐらいのアイデアで、突然何かが起こる。これは、あなたがエッジだからわけではありません。違う場所を掻いていたからであって、あるポイントに当たると、突然何かが起こって、(顧客の)リアクションがあなたに教えてくれます。ここが、特別なポイントだと。私はこういった幸運をキャリアの中で何回か経験しています。ソフトウェアパターンとか、テスト駆動開発とか、100ぐらいのスケールしたアイデアがありますが、これは、「かゆいところ」にあたったのです。

3. アントレプレナーがするべきこと

アントレプレナーとして、私が探しているのはこの「かゆいところ」です。どのように沢山の時間やりつづけるかではありません。チェーンソーの通路を通るようなものではないのです。かゆくないところを何回も掻くようなことではありません。

私がやるべき事は、かゆいところを探す事です。それは、いろいろな要素が絡み合っています。タイミングであったり、幸運であったり、掻く事で自体であったり。

あなたが掻く事をしなければ、かゆいところを見つけることはできません。

4. リーンスタートアップ

リーンスタートアップは、このことの素晴らしい例です。何かのタイミングだったり、人々や、マーケットがOKをくれるメッセージだったり。世界中で、エリックがやっているのと同じような事を多くの人が実践しています。

1年前、かゆいポイントにはヒットしませんでした。が、リーンスタートアップに関する事がありました。過去15年の私のビジネスモデルとの組み合わせです。

5. 資本効率のお話

自分がやろうと思っている事を、バリバリのモチベーションで始めます。素晴らしい資本効率はソフトウェアの中にだけある訳ではありません。ここにいる皆さんは、多分ソフトウェア畑の人がおおいですよね。多分ハードウェア系の人もいるでしょう。

資本効率が一番重要な事になったとしたら、あなたはきっと資本効率をよくするために、新しいビジネスモデルが必要になることでしょう。そして、資本効率がよくなるようなマーケットも必要になるでしょう。

そういうものが確立できて、次に来るのが、コミュニティのプラクティスでしょう、そして人々、リーンスタートアップの一部を担う、それぞれの個人だったり、名前だったり、メッセージだったり。デリバリの方法だったり、一緒にするタイミングだったり。

私にとって、リーンスタートアップは、これらの「レスポンス」を送ってくれます。世界中のかゆいところに当たった時のレスポンスを返してくれます。それが起こったら素晴らしいですね。

6. Basic Loop

だから、我々はわかったのです。基本的なループがあることに気づいたのです。

Build(ビルド), measure(測定), learn(学び)です。私はビルドをします。私はビルドを作るときに、本当に価値のある事をする事を選択できたら、とてもいい気分になります。測定したり、学んだり、数学的な事をやってみたり、ビルドをつくったり。

なぜなら、私はビルダーだからです。それが心地よいのです。

このループを、リーンシンキングの観点から見た場合、このループは本当は逆向きの方向進むのです(バックワード)。

ビルドから始める事。これは、私がやったことで、失敗続きだった方向なのです。ですので、皆さんは真似しなくてもいいと思います。もし、試してみたかったらやってみたらいいですが。しかし、このループは逆向きの方向が望ましいのです。

7. マルチテーブル

みなさんに2つのお話をしましょう。今スタートアップをやっているのです。

マルチテーブルが出来ることって良くないですか?

あなたがオンラインのポーカーをやっているとします。最初は1対1でプレイができるようにします。しかし、それは相当退屈でしょう。だってリアルで出来る事ですから。

20ゲームのポーカーを一度にやること。コレはマルチテーブルといいます。

8. マルチテーブル作戦

 スタートアップとしては、資本効率を上げるためには、20人の人は1つのアイデアのスタートアップに要らないです。10人, 5人, 2人, 1人とどまる事をしりません。

 それだけの人がいたら、あなたは、同時に2つのスタートアップができます。同時に2つのスタートアップが一度にできます。マルチテーブルみたいなものです。私は2つのことを試せるし、全くもって間違った事をやってることに気づいても致命的ではありません。
 

9. TDDの例

 
なぜ、テスト駆動開発というクレイジーなアイデアを思いついたのでしょう。実際のコードを書く前に、テストコードを書きます。もちろん実体がないのですから、テストは最初はいつも失敗します。ところがいったんテストが動くようにコードを書けば、それはクールな事に変わるのです。だから、私はスクリーンキャストをしようと思っています。

TDDに関しては、本を書いて売っても儲かりません。他のメディア展開が必要です。自分でテスト駆動開発をやっているところを録画して、いい情報と、楽しめるナレーションをかぶせてみる。私にとっては一度にやるのは大変ですが、私が録音して公開すれば、人々が考えている事がわかるでしょう。

これが、ループを逆向きにまわす事でしょうか。ビルドから始まっています。

私は、いくつかのエピソードをVimeoに上げます。最初の10分を。それから、編集します。それから、人々が100回ぐらい見てくれたらOKでしょう、そうなったらマーケットに出します。

10. 学習につまづく

しかし、私は「学習」フェーズでつまづいてしまいました。だから、先に「ビルド」して、「計測」しました。しかし、何が「学習」を押し進められたのでしょうか?

たぶん、何人かは興味をもってくれたとは思います。

私は逆向きのループに関して学びます。私はものづくりからはじめました。飛び越えて、モノ作りをすることから。

そして、今私は完成させるために、出版社さんとかスタッフの方を探しています。

しかし、私はこの流れでは、何か重要なバリューを失った気がするのです。
 

11. 次のプロジェクト

対照的な次にプロジェクトを紹介させてください。次は、ニーズから始めました。私が出来るならば見つけ出したいだろうニーズです。(注:多分仮説の事かと思います)

49歳の脳みそは、昔のようにはいきません。私の脳力は、昔のようにはいきません。

ゆっくりしたらダメですかね?私が失った脳力を復活させられないだろうか?

そこで、私は小さなゲームを作り始めました。私はこれをわざと秘密にしておきました。ものすごくいいアイデアを持っていたからではありません。
 フィードバックを受ける準備ができていなかったからです。そこで、私はアナウンスできる状態になるまで、アナウンスをしないようにしようと思いました。その代わり私は「質問」から始めたのです。
 
 私が速く、クリアに考えられるようになる手助けができないだろうか?
 
 「学習」の次は、「測定」です。私は「ミス」と「成功」を測定します。そして次にコードを書く事です。
 
  仮説があっているかを確認するために、測定して、そのために、コードを書くのです。
  

12. バックワードループ

私は考え方を改善することができました。私は今回は完全に前回と違う気分でした。なぜなら私は逆向きのループをまわせたからです。
 
このループは、「学習ー測定ービルド」と呼ぶべきだと思います。「ビルドー測定ー学習」ではありません。私は「ニーズ」から始めたいのです。

次の質問は、このツールを自分以外の他の人が考えるときに使えるかです。この質問も正しいのであれば、次の質問は、このツールを誰か買ってくれるか?です。これが今私がやっていることです。質問から始めること。学習から始める事。次に測定がそれを助けて、最後にビルドです。

13. pushモデル

「学習ー測定ービルド」のサイクルはプルの原則です。リーンの原則です。他に、プッシュ型というのもあります。

プッシュ型は大抵の人々が仕事のスケジュールを立てるやりかたです。各プログラマをできるだけ効率的に働かせて、ものをつくります。その後、誰かが買ってくれるかを確認します。これがプッシュモデルです。プロダクトをつくって、それを誰かが買ってくれるかを確認する。

プルモデルの考え方によれば、プッシュ型は、ミクロの効率を上げますが、マクロの効率を犠牲にします。プログラマは効率的にものを作りますが、できたものは誰も欲しくないといように。

これらの、失敗は、我々は、完璧で、洗練されていて、ぴっかぴかに磨きをかけたプロダクトを作っている事に関係するのです。ただし、誰も実際には買ってくれない、、、

14. pullモデル

 プッシュ型の考えの、ソフトウェアエンジニアリングとしてよい仕事をしようとする事は、沢山のバリューを生む事にはなりません。

 今日お話ししたい、最初の原則は、プルの原則です。「学習ー測定ービルド」はスタートアップでしっかりしたものを作る原則だし、2つめの原則は、フローの原則です。
 

15. アジャイルマニフェスト

フローの原則はアジャイルマニフェストの後で説明します。アジャイルマニフェストが作られたとき、私は病気で死にかけていていましたので、ミーティングのことははっきり覚えていません。

ジムハイスミスと、マーチンファウラーは、考えをまとめるにあたって、本当に貢献してくれましたし、賞賛されるべきです。

10年前、アジャイルマニュフェストは、ソフトゥエアの世界を一歩先に進めました。

その部屋にいた人が同意できることは、あまり多くはありませんでした。我々が同意出来た事は、人々に魅力的であること。そこで、我々はAgileという言葉を取り上げました。

なぜなら、みんながアジャイルになりたがっていたからです。もし、あなたのアイデアがみんなに受け入れられてもらえるように名前をつけるとき、みんなが、すでに知っていて、その言葉が、忠告してくれたり、どういう事が起こるのかを語ってくれるようにするのがいいでしょう。

16. プロセスやツールより、個人と相互作用

昔、いいソフトウェアを作る為には、我々はよいプロセスやツールを持つべきだという考えがありました。

もし、あなたが正しいプロセスを持ったならば、誰が実行するかは重要ではありません。だから、あなたはモンキーを雇って、ソフトウェアを書かせたら、まったく同じものが出来るあがることになります。

だから、プロセスやツールでは、十分ではありません。そこで、こういう事でソフトウェア開発の世界を一歩先に進めました。

人そのものや、人々が相互にコミュニケーションを取るのが重要だよ。プロセスとかよりもね。

これが、10年前の一歩でした。

17. チームのビジョンのチームの決め毎

これは、私がスタートアップのプログラマを始めたので、これでは十分ではなくなってしまいました。それを越える必要がでてきたのです。

今の私は、私がどうやっていい仕事をするか?ということを考えるのではなく、チームが如何にいい仕事をするか?という事を考える必要があるのです。

この事は、時には実践的ですが、時にはあまり面白くない事も起こることを意味します。

もし、チームが沢山の事を達成できるためには、私がベストと自分で思える事をする事を少なくしないと行けないケースがあります。

自分が、問題を解決するクールなテクニックをしっているとします。そして、チームの他のだれも、そのドメインのPhDを持っていません。もちろん、その問題を解く為の技術的なベストな方法もしりません。

 もし、自分がその事をしる唯一の人だとすると、自分ならそれをやれるけど、自分はチームの一員だといって、一歩引く必要があります。
 
 私は一歩ひいて、チーム全体としてもっと達成できるように手伝います。
 
 そして、そのような状況だと、私はテストを動かすことも、タスクを引き受けることもNOといわないといけないかもしれません。そのかわり、チームにルールをフィットさせることをしないと行けないでしょう。
 
 しかし、こういったことは、チーム全体のパフォーマンスを上げる傾向にあります。チームのビジョンと、チームのルールを守ってもらうことは、個人のパフォーマンスを最適化することの先をいっています。
 

18. 包括的なドキュメントより、動くソフトウェア

アジャイルマニフェストには4つの価値があります。

次は、全てがドキュメント化されていれば、上手く行くという迷信です。

そういったドキュメントは、いつもソフトウェアにくらべて古くなっていました。だから、それはもっともよくある勘違いです。

だから、ドキュメントではなく、動くソフトウェアに重点を置いたのは、大きな一歩だったのです。

もし、あなたが凍結されたシステムの完璧なるドキュメントをもっていたとすると、そのシステムは、すでに誰のものでもない問題を解決することになります。

だから、今日の問題を解決するソフトウエアをもつことが重要です。だからこの事はとても大きな一歩でした。

19. 学習を検証すること

スタートアップの環境では、10回に9回は、どうやってソフトウェアを書いていいのかわかりません。

 フライトキャスターがいて、彼らの仕事は凄いテクノロジーの責任をもっているとします。私はそういう環境で働くのは好きです。なぜなら、私は、他の2つのサイクルの事を無視することができますから。これは素晴らしい。しかし、、、
 
 スタートアップでは、動くソフトウェアで進捗を測定することはできません。
 
 スタートアップは、ほとんど不可能なことのリストで始まるのです。
 
 これは、「検証しないと致命的になる仮定」と呼ばれます。つまり、その仮定が覆ると、そのビジネス自体が成り立たなくなるのです。例えば誰かがお金をはらってくれるかとか、顧客を獲得できるのかとか。
 
 ほとんど不可能な事に首を突っ込むゲームみたいなものです。
 
 だれか、このWebゲームにお金を払ってくれますか?もし、それがほとんど不可能だったとして。そら、誰も払ってくれないでしょう。
 これは、いつだってクレイジーなアイデアです。
 
 しかし、ほとんど不可能リストをもって、スタートアップを始める事はとても価値のあることなのです。
 
 あなたが、その不可能を可能に変えることに成功したらどうなるでしょう?
 
 動作するソフトウェアは、その解の一部にはなりえますが、最高の回答ではありません。

 だから、アジャイル開発をこえて、組織として、学習する機会をつくり出すことが重要なのです。単純にコードを書く事ではなくてです。
 

20. 契約交渉よりも、顧客との対話

10年前の、その他の伝説としては、正しい契約をすれば、全てが上手く行くというお話です。反対の事は正しいと思います。あなたがチームを訪問することができたなら。

 あなたが、ソフトウェアをみて、サプライやとカスタマーの間の契約がゲームオーバーと言えば、あなたはなにもできません。
 
 この点では、契約はあまりよくありません。
 
 顧客との対話が、最初に細かい事を決めて契約をすることよりも重要という話しをした事は大きな一歩です。
 

21. 顧客発見

 今、あなたはスタートアップです。あなたには顧客がいません。
 
 私はコラボレートしたいですが、いないのです。コラボレートする顧客がいないのであれば、スティーブブランクが行っているとおり、ビルの外にでて、顧客を探してくるしかありません。顧客がいるなら、顧客との対話は重要です。でも、いなかったら見つけましょう。 
 
 ですので、スタートアップの場合は、それを越えるひつようがあります。
 

22. 計画に従うよりも、変化を抱擁する

 10-15年前の伝説として、ソフトウェア開発を上手く行かせる方法は計画をたてることだという話しがありました。
 
 働くために、計画を立てて、正しく計画を実行する。これは何回もプロジェクトマネージャから聞いた事です。
 
 多分計画を一生懸命立てても、いろいろ変わってしまうことに気づくでしょう。だから、変化を抱擁することが重要といったことは、とても大きな一歩です。
 
  実際の世界は、計画よりずっと柔軟なものです。
  
 変化に対応する事のメタファーは、変化に対応してプロジェクトを実行することなのです。いい感じですね。
 
 

23. 変化を起こす

あなたは今やスタートアップの一員です。変更するものがまだありません。

なぜなら、何も動いていないからです。最初に慣性の法則で習った事を確立させることが必要です。

これは、変化を起こすことが必要です。ただ、対応するのではありません。

あなたが(世界に)変化を起こさなければ、スタートアップとしては、何もしていないのと同じ事です。

軍隊は変化を起こす事について、偉大なコンセプトを持っています。
 
あるチームは、自ら事を起こします。一方他のチームは、それに反応します。

ある、歴史的に有名な軍隊ののリーダーがいます。彼は、何かを始めることについてのいい教訓です。

 あなたが300人の部下しかないとして、あなたは、他のチームがせめて来るのを待ちません。なぜなら、あなたが事を起こすと、圧倒的に優位に立てるからです。もちろん、あなたは危険にさらされます。
 
  一方、他のリーダーは、あなたが何をしでかすかばかりを心配しています。そして、彼自身が何をするかには頭がまわりません。
  

24. the Civil War

このことは、Civil Warでも起こりました。グラント将軍は、西の軍隊にいきました。レポーターは彼にたずねました。彼がRoberty Leeが次に何をすると思っているかと。彼は答えました。「私はLeeが何を次にするかには興味がない。私が次に何をして彼を心配させるかのことを考えているんだ」

このことが、Civil Warの展開を変える事になった。

25. アジャイルマニフェストを越えて

だから、私にとっては、アジャイル開発を越えて、スタートアップは、チームビジョンをもって、規律をもって、全体を最適化しないといけない。

 プロセスやツールは、人のアウトプットを最大化しない。ソフトウェアを作る事よりも、学習することにフォーカスをあてよう。
 
 そして、ニーズからはじめて逆のループをまわそう。顧客を見つけるのだ。
 
 そして、変化を単に待つんじゃなくて、自ら変化を起こすのだ。
 

26. プルの原則

最初の原則はプルの原則でした。私は2番目の原則について話すといっていましたね。

 あなたが欲しいことに対する学習からはじめて、逆のループをまわして、あなたの欲しいものを作るのだ。
 

27. フローの原則

2番目の原則は、フローの原則です。もし、あなたが2つのデリバリを半々の機能でリリースできるなら、1つのデリバリをするよりも、ずっと価値がある事です。

私は別の日にノルウェーの男について話していました。年上で大きなコンサルティングファームにいました。彼は私にスタータアップの戦略を教えてくれたのです。

開発者が、本当に磨き上げたプロダクトをつくりました。素晴らしすぎて誰も文句をいうことが出来ないぐらいです。あなたはそれに1年を費やしました。本当にいいものをつくりあげてリリースしました。そして、フィードバックを得ました。誰もこれを買いたくなかったのです。こういうことは起こるのです。

 だから、半分のプロダクトをつくって、仮説と検証をしっかりやりましょう。しっかり学んだ後に、磨き上げましょう。
 
 3ヶ月。これがフローの原則が有効に働く期間です。
 
 全体のサイクルを如何に短く出来るか?これが我々が考えるべき事です。
 

28. ペイメントゲートウェイ

 ゲームの話しを考えましょう。私の妻は私がプログラムコードを書いてお金にならない状況にうんざりしています。だから、このゲームが売れるのかというのを早く検証したいのです。

 儲かるかな?このゲームは2つのパートからできています。あなたは最初のパートをプレイします。
 
 そして、あなたが、最初のパートに熱中したなら、「購入」ボタンがでてきて、購入すると、次のパートに進めるという感じです。だから、私はエンジニアと話しをして、これをやるためには、ペイメントゲートウェイをつくらなあかんなと。
 
 私は考えました。これは、スタートアップエンジニアリングのエンジニアリングゲームであると。だから、これを分割できないだろうかと。分けられないように見えるタスクを小さなピースにできないだろうか?
 
 これは、クールなパズルです。あなたは「学習ー測定ービルド」を通じて解決するのです。全てのエンジニアの脳みそをフル回転させて、自分がオッケーと思えるアイデアを思いつきました。だからお話します。
 
 私が考えた事は、ペイメントゲートウェイなしで、どうやって実装できるだろいうか?ということでした。最初のパートが終わったあとに、購入ボタンがあらわれて、ボタンを押すと、次のパートが始まります。ただし、我々にメッセージが飛ぶようにするのです。
 
 だから、我々は、みんなが「購入ボタン」を押してくれるかどうかを知る事ができるのです。しかし、みんなが「購入ボタン」を押すと、後半のパートを無料で遊べてしまうのです。
 
 最高でしょう。顧客ができないのです。私は顧客がいないので、ペイメントゲートウェイがあるかどうかは、たいした問題ではないのですから。
 
 もし、私は100万の顧客を獲得したら、そして、私がペイメントゲートウェイを実装していなかったら、お腹いっぱいになってしまうでしょう。
 
 しかし、私は「購入ボタン」を押してくれるかどうかだけが知りたいのです。
 

29. 全体のループを考える

 スタートアップの開発者として、全体のループを考える必要があります。
 
 最も大きな違いは、どのように私が最高のソフトウェア開発をするかを考えるのではなく、「学習ー測定ービルド」のループを如何に早くまわすかということを考えるのです。
 
 できるだけ、早くループをまわして、出来る限り最高のバリューを各サイクルで得ようとします。
 
 私はそれらを達成するために、エンジニアリングを実施します。例えばモックアップとか。ソフトウェアすら必要ありません。インデックスカードとか、シャーピーとか。まぁ、私は嫌いですけど。
 
 今18時間を節約したって?
 私はいいエンジニアか?って。そのとおり。
 
 私は他のエンジニアの友達を感心させたい。しかし、彼らはスタートアップの問題をかかている。
 

30. 良いスタートアップのエンジニアリングとは

時々は、ハッカーになったっていい。

しかし、基本的にはあまりよくない。

我々はコピペして、2行変えるだけだぜ!

みんな、こんなゲームをプレイしたい?例えば我々が、注意深くリファクタリング、リファクタリング、リファクタリング、、、、三昧な

それは、エンジニアとしては気分がいいかもしれない。しかし、それはスタートアップのエンジニアリングとしては、あまりよくない。それらは、もっとも安い方法じゃないからだ。

ループをまわすことは、スタートアップでいつもハックを繰り返すことじゃないんだ。

31. モードを変える

もし、ゲームがヒットしたらどうなるだろう、スケールしてしまったら。あなたは、そのサイクルから、モードを変える必要がある。あなたがやるべき事は、顧客を魅了できるかどうか確かめることでは無くなっているからだ。

今や、あなたが学習するべき事は、どうやったら顧客を倍にできるかだ。

テスト駆動開発や、自動化、リファクタリング、レスポンシブデザイン、そして、スタッフの仕事を妨げる事無く、平行で変更できるようにするようになることだ。

そして、今のお金の流れから、どうやったらより多くのお金を獲得できるかを学習するのだ。

そのとき、エンジニアリングはシフトする。完璧にスループット指向になる。どうやったらエンジニアリングチームのコストを減らす事ができるだろうか?

どうしたら、運用コストを下げる事ができるだろうか?
他に何かできることは?

スタートアップの良いエンジニアリングができるエンジニアになることです。

これらのフェーズで、これらモードチェンジ、つまり考え方の移行は本当に難しい事です。私もこの移行でトラブルになりました。

多くの他の人が、多くのエンジニアリングチームが機能を出来るだけ早く作るようにしていることを見てきました。

32. 先週より2倍早く機能を実装できたぜ

そして、彼らは気分よくなります。先週より、2倍早く機能を実装できた。俺たちクールだぜ!

もし、あなたが顧客を獲得してスケールしたとき、最高のエンジニアリング戦略は、機能を削減することです。

これらの、考え方の移行は本当に難しい。なぜならこれらは、技術の問題ではなくて、文化の問題だからです。

33. 結論

リーンスタートアップでの、モノ作りのゴールは、ループをまわす時間を最小化し、そこから得られるバリューを最大化させることです。

原文

ディクテーションしたものなので、不正確な内容が含まれていることをご了承ください。

1. Introduction

Thank you very much thank you all for your coming early in the morning and for those of you perform early in the morning.It’s not such an accomplishment for you to be here but I’m glad you’re here too.

I have the the privilege and honour of being the worst entrepreneur on the schedule today. I (las can?) have been involved in 11 startups but none of which have made significant money.

Only one of which has been successful on large-scale that’s JUnit.

I wasn’t quite sure about opening my speech by disclaiming any ability in the area that we are talking about. But I figured you’d figure it out soon enough anyway so I should just open up.

But the thing is I haven’t given up because I can see especially
the lean startup stuff is brought me new energy for continuing trying’ out the businesses.

Around the technical capabilities that I spent most of my life
trying to refine.

2. Goats story

I live in the southern Oregon, we are out on the boonies.
And we have goats , no, really goats.We just had two babies. They are so cute it’s like a little furry 80-80.

They are wonderful. But the other day I was out with the goats and I was starting to scratch the goats cause the bug you otherwise and the goat was okay whatever I went down the back in little further down the back. And then right near their hip, this goes to hip all of sudden, goats just went. Oh. That’s feels great.Ooh.

it’s interesting so I can scratch all over these skills, nothing, And I hit this one spot and all of this itchy spot you know, hit an itchy spot and all of a sudden the same activity that I’ve been doing all along turns into something wonderful for this goat.

I mean I can’t really imagine what it’s like I don’t want to really imagine what it’s like but I can see you that the same activity and lots of different places small effect and all of a sudden that same little activity has a completely outsized effects on the goat’s experience of the an... those scratchin’ and that’s so little like startups for me.

You keep doing stuff no response and you do stuff no response you do stuff no response and then you do the eighth idea you try out takes off is not like you’re edging. It’s not your scratching any different you just hit an itchy spot and when you hit an itchy spot, all of sudden the reaction tells you this is something special and I’ve had the good fortune to have that happen several times in my career, Where software patterns or test driven development. Those I mean I had hundred ideas that scale but those at that time really hit an itchy spot.

3. Entrepreneur

And as an entrepreneur that’s what I’m looking for that itchy spot not how can I somehow sustain hundred hour weeks I mean It’s not like a getting the chainsaw aisle to scratch the goaded doesn’t work not not twice.

But how can I take the things that I do and find a spot that that really some there’s it it’s a combination of factors right there su..There’s timing there’s luck and there’s scratching.

If you’re not scratching, you’re not getting to hit the itchy spot guarantee you that.

4. Lean Startup

And lean startups is a great example of this for me too. Because something about the timing the message that people the market were all just right.

So in the world. There are probably thousands of people, Doing the same kinds of things that Eric was doing.

A year ago and it just didn’t hit an itchy spot but something about lean startups and the combination of pay my and my business model for the last 15 years.

5. Capital efficiency

Start working what am I going to do there’s a bunch of motivation The incredible capital efficiencies not just in software I mean I think most people here probably in software but but hardware businesses, too.

Their capital efficiencies go up to a factor of 10. So you got the need for a new business model you have capital efficiency You have markets that are much more efficient.

And all of that came to and then a community of practice people there are isolated people who are doing parts of lean startups And the name the message The way of the deliver, the timing all of the came together so for me.

Lean startups sends this response and the the response around the globe is really that’s one of those itchy spot.And it’s great that it’s happening.

6. Basic loop

So we see. Here’s the here’s the basic loop

Build, measure and learn, I’m a build guy. That’s that’s what I do that’s what I’m comfortable doing. If I have a choice between doing something really valuable In measure or learn or doing something really trivial and build I’ll build every every time Because I’m a builder it’s what I’m comfortable to do it.

When I looked at this from Lean thinking kind of perspective one thing I realises it this loop is actually backward.

It is the way that I’ve done it and I told you I have a long record of failure doing it that direction. so if you don’t want to, you don’t need to try it.

You can if you want but this loop is backwards.

7. multitable

I’ll tell you two stories I had two.
Startups going right now.

Is not cool that we can multitable now? You are in the poker when people play online poker.

They started playing two games at once and this was considered rule you can play two games well, turns out pokers mostly boring so you can actually play.

20 games of poker once that’s called multitable.

8. multitable strategy

Startups, As the capital efficiency increases right you don’t need 20 people to do is start up and you don’t need 10 people to start up then you can do start of 5 And with 2 ,with 1 is not stopping there.

You can do two startups, you can do five startups the once. I mean at some point it’s got it end but It’s cool that that’s that that kind of multi tabling as possible so so I have two things going one of them I’m doing completely wrong And now I’m hoping to get some ideas here today so I thought...

9. TDD example

Why have this test driven development idea you know which is this crazy idea that you write the test before you write the code, but test always fails, so why do you write it down well, turns out to be really cool work really well so that I’ll do some screen casts.

About TDD you know you can’t make money selling books anymore (Sycanth) so I got to find some other media strategy So maybe I’ll do some screen cast. so I’ll record myself doing test driven development And then you know do a little narration trying to be both informative and entertaining which is actually too much for me to do once but they have it so I’ll record these and then I’ll put them out there and see what people think.

That’s running the loop backwards. That starts with the build.

So I recorded a couple episodes of putting up on Vimeo the first 10 minutes and edited And then I saw what like people yeah people view Vimeo hundred times okay so there’s some market out there

10. Stuck on learning

But I’m kind of stuck on the learning phase. so I built, I measured but what is the how strengthen the learn.

I guess some people are interested.

Where do I go from here. I learn the loop backwards on that project.

I started it with making something because I just jumped to make in things.

And and now I’m kind of stuck I’ll push it through to completion of you don’t get them out there and find a publisher and out all that stuff.

But I get the feeling I lost a lot of value in that sequence.

11. The next project

Let me contrast that with my my next project which started with the need I wanted to find out if I could.

To not my 49-year-old brain so I know my memories not as good as it used to be, My cognitive skills aren’t as good as they used but.

Can I slow down? Can I recover some of what I lost?

So I built a little game and I’ll be cagey about this not because I’m trying of Build some you know build up interest I can see all of you are really excited about this idea.

But but because I’m not ready for more feedback so I’ll announce it when the time comes to announce it but I started with a question.

Can I help myself think faster and more clearly?

Well okay so now what’s the measurement of that I think a task. I thymic. And I measure the mistakes okay so now what software what I need to write.

In order to measure that in order to know whether or not.

12. the loop backwards

I can improve my thinking. That one feels completely different because I ran the loop backwards

So the loop I think really should be called learn measure build. I don’t I don’t say build measure learn I say learn measure build because I want to start with a need. now the next question is can somebody else use the same tools also help their thinking.

Turned out the answer to that is yes then the next question is Can we get somebody pay for this. and that’s what I’m working on now but It starts with a question learn then when the measurements are needed to support that And then build.

13. push

this learn measure build. Is the principle of pull. in the lean manufacturing you got push.

This is the way most people schedule work. You know, let me ... How can I get my programmers working as Good as possible, or as most efficiently as possible? Then then we’ll see if anybody will buy it. that’s the push model.

Build this product and see if anybody will buy it. the pull model says... That gains micro efficiencies like the programmers to work really fast in that environment, but it sacrifices a macro efficiencies by building things and people don’t actually want.

The number of those fails starts that I was talking about we are building products complicated sophisticated carefully polished products.

But nobody ever actually bought so

14. pull

In that environment looking at it from push perspective, Trying to do a better job of software engineering is not actually going to creating more value.

So the first principle little talk about Today is is a principle of pull.

Learn measure build is a way of making a concrete for for start ups the second one is the principal of flow.

15. Agile manifesto

That after I finished taking a shot at the Agile manifesto that I was at the meeting where the agile manifesto was written, I was deathly ill and on some ungodly antibiotics so I don’t actually remember much of the meeting.

Jim Highsmith and Martin Fowler really deserve the credit for pulling all his pieces together.

10 years ago the agile manifesto was a step forward.

It was a least common denominator of the people in the room that is that with those were the things we all could agree on And we wanted to make it attractive to people so we picked the word agile.

Because everybody wants to be agile well it turns out if you name your idea something that everybody, wants Everybody will say they already are that so Just word of warning or where you are is gonna happen. oh yeah. we’ll in.

Here’s our here’s our 60 page lean products Beck.
Bro here’s a lean stealth stealth wants instant yet ha ha

Lean private beta. Is it’s a get one. And I make a great button.
I mean such an in joke though but then you know you had some ache.

Anyway oh and end that the reason it’s back at A is because my parents had a good sense to have a name beginning the alphabet.

16. Individuals and interactions over processes and tools

Agile manifesto anyway so processes and tools there was a day when When people thought in the non-focusing I’m just on the build process when people thought That what you needed to do to build software better was to have better processes and tools if you have the right tools.

And if you have the right processes it wouldn’t matter who was executed. You could have any monkey write the software and it would come out exactly the same.

Turns out that’s true.

So process and tools are not enough what You need at that point it was a big step forward to say

hey, The people matter and how they interact with each other matters More than following some set process.

So that was a step forward 10 years ago

17. Team vision and disipline

If I look at software development as I practice it in startups though That’s not enough I need to go beyond that

So it would be as an individual in a team building a startup

I need to think not about how good a job I can do but how good a job we’re doing.

That means sometimes very I mean there’s some practical and sometimes unattractive implications of that sometimes.

If I should do less than What I believe to be the very best in order for the team to achieve more.

So I might know about some really cool technique for solving a problem.

But nobody else in the team has a PhD in that particular little area, So even though that might be the technically best way of solving the problem.

I need to back away from that and say hey I’m on it yes but I’m on a team, If I’m the only person who understands this part of the system.

Then I need to back away from everything I know so the team can achieve more.

I might be in a situation where I can check this scene and I don’t have to run the test. And I need to say no the way we do things here is And have the discipline to fit in to.

what the whole team is doing the individuals interacting have a tendency to optimise their own performance.

But team vision and discipline goes beyond that to talk about How are we going to make the most progress we can together.

18. Working software over comprehensive documentation

So there’s four bolts and then manifesto and go through

(Brigitte) so the second one is about comprehensive documentation there was a day when The story was if you had everything documented if you had everything written down Then you’ll be just fine right.

You would’nt have to go like Talk to people you could just open up the book and read what the software did except Always the documentation was out of date.

it was the best misleading.

And and that was about it and ten years ago he looked at that said You know, documentation is not the point working software is a big step forward.

So if you have a perfect documentation for frozen system solves the problem nobody has anymore

That’s just not as good as having some software That solves today’s problems and that was a big step forward.

But the problem is it only goes so far

19. Validated learning

In a startup environment, it’s not that you don’t know how to write the software nine times out of 10.

I mean my hats off to somebody like a flight Caster who Clearly has some heavy duty technology behind what they do And I would frankly love to work in that environment because then I could pretend like I could ignore the Other two parts the cycle when that’ll be cool. but

You can’t measure progress by working software in a start up

you start out a startup with a list of almost impossibles

Used to call them the potentially fatal assumptions but that’s two negative you know you Potentially fatal assumption somebody will pay money for this you know that we can acquire customers.

That this will be an engaging game whatever those are all protected(pretend) almost it’s almost impossible.

Did somebody will pay money for a game on the web right really

Well if it’s only almost impossible when you have something.

If it’s clearly true then you don’t have anything.

Hey it’s always it’s always the crazy ideas that worked out

That is the most valuable to you start out every start up with his list of almost impossible.

And to succeed you need to find out Which of those really is impossible and which of them turns out With some work to be possible.

Working software can be part of answering those questions but it isn’t necessarily the best way to answer those questions.

So beyond agile software development is about creating the opportunity for learning as an organisation.

Not just about writing code.

20. Customer collaboration over contract negotiation

Another myth from 10 years ago that if you just have the right contract everything would be clearing goes smoothly

And the counterfactual is true you could go visiting team.

You look at their soft that that the contracted between the supplier and customer he says Game over you’re finished there’s no way that you’re going to be successful with this.

Just because the contract was wrong so with that point

It’s it’s a big step forward to say collaborating with customers is much better than trying to nail down all the details right at the beginning.

Yes yes that is definitely much better so

21. Customer discovery

Now you’re startup. you don’t have customer

I’d like to collaborate I want to collaborate you can hear an echo. but that’s it. what you do If you don’t have a customer with whom to collaborate well and Steve Blank will give you chapter and verse of this and I hope I can pick up some pointers You have to go find out who your customer is. customer collaborations great if you got a customer and if you don’t you got to go find them.

So agile development in a startup or development in a startup, it needs to go beyond

22. Responding to change over following a plan

Just what it says in the agile manifest so there was a day 10 to 15 years ago when the myth was the way it is software project is made a plan.

Plan to work, work the plan right if I heard that one more time from project manager.

I was going to do something was a glass two or three felony.Depending on how annoy you got, so if if your Plan the work with the plan and you realise now this Things change too much. then responding to change is a big step forward.

To say no it’s it’s not enough to follow the plan because Things just change too much. reality diverges from the plan Reality is the much less flexible than planned?

There was the one fundamental point that follows the plan thing Is that reality bends a lot less than the plan bends.

So saying let’s response to change our metaphor for executing the project to be responding to change

Well cool mean thats, it’s a big step forward

23. Initiating change

Now you’re in a startup nothings changing yet

Because nothings moving. you have to establish Momentum first. development in a startup

Requires initiating change not just responding to it

Now this is where my anti-responsibility hackles start going up you know where I basically I don’t want to be responsible

I know it’s have to but I don’t like it and I’m like oh it’s up to me.

To initiate change that because if you don’t initiate change the startup, you don’t have anything.

Not even moving. the military has this is great concept of being the initiative

One side has the initiative in any given engagement that’s the people who are acting in the other person’s reacting.

And there are military leaders through history who’s been very good at seizing the initiative

So you know you you only got, you know, you 300 people but you don’t wait for the other guy to come in Smack you take the initiative because when you have the initiative you got a whole bunch of advantages yes you’re exposed

But the other guy if you can make sure the other guy is busy

Worrying about what you’re going to do he doesn’t have time to think about what he’s can do to you

24. the Civil War

This happen late in the Civil War when Grant went to the
To the armies the east and a reporter asked him well you know
What what do you think Roberty Lee is going to do next and Grant said I don’t I don’t care what Lee is going to do next I’m going to make him worry about what I’m going to do next.

And that was the point that the that the Civil War turn around.

25. beyond the agile manifesto

So that for me is beyond agile development in the startups Team vision in discipline looking at the whole.

Process and not just what one not maximising one person’s output.

Focusing on learning instead of producing software.

So it starts with the need in move backwards discovering customers.

And this change initiation process instead of Waiting for the change that happen them and then responding.

I don’t know how many minutes that means have left. It’s ok.

26. the principle of pull

So the I told you I was going to talk about this the second principle so the first principle was the principle of pull.

That is start with Build you start with learning that you want to have an work backwards to the building you need.

27. the principle of flow

And the second principle is a principle of flow principle of flow says If you have all other things be equal Two deliveries half-and-half is more valuable than one delivery of the whole thing.

And I was talking to a guy in the Norway the other day, Senior guy in a big consulting company and he was telling me his start up strategy.

What is the builder really finally polished product so nobody could possibly complain about it. You know you spend a year and you make something that’s really good and send it out.

And I said well so sometimes when you do that you get the message back.

Nobody wants to buy this. oh yeah happens.

So could you build half the product and got an question answered Yeah sure when you been so polished okay how about you know.

Three months. that’s the principle of flow at work I’m trying to think.

How can we shorten the time through entire cycle.

28. Payment gateway

As came up the other day with respect to the game. so my wife is tired of me writing programs don’t make any money so one of my Really you can ask her. so so one of the things I want to validate early in this (price) of this game is

Can I make money. so the game has likes a couple of natural parts of divides into two parts And I thought okay so you do the first part.

And you get addicted to the game right that’s how it’s supposed to work And then there’s a button that pit uses I’ll pay to use the second part And I was talking to reengineer is working with on this and he said okay so we have to set up the payment gateway and …

And I thought how could we slice this finer to me this is the engineering game of start up engineering is Taking tasks that seem monolithic cutting them into little pieces of rearranging pieces.

It’s a cool puzzle to solve by the time you’ve gone through learn and measure and you get the build that’s the point
All of my engineering synapses are firing I’m thinking how can we slice up so I thought Okay here’s my cool idea now in this room this is unlikely to be remarkable but I’m proud of myself so I’m just telling you.

That is I thought how can we do this without having to set up the payment gateway …He said So how about if we write the first boad has the game we put the buy button And when you present buy, it just opens up the second half of the game but sends us a message.

So we know whether anybody’s going to press the buy button is right now we don’t know if anybody’s going to press the buy button.

but everybody press the buy button and we just get the second half of the game for free.

This is whereas wonderful not having customers, so what I love not having customers because when I make mistakes like oh not implementing the payment gateway is not a big deal.

If I had 1 million customers and I didn’t implement the payment gateway, I’ll be stuffed.

But I just want to find out if anybody’s going to press the buy button.

29. thnk about whole loop

As a developer in a startup, I have to be thinking about that whole loop.

And that’s really what’s different it is not how can I do Of the best software development it’s how can I Tightened the learn measure building loop as fast as possible.

Make it shortest as possible and extract the maximum possible value added each cycle through that loop.

I should do the engineering that achieves that Well sometimes that’s going to look like Mockups wanting not me software at all. you know I got an index card some sharpies I don’t like this.

Now, I just saved 18 hours.
Am I good engineer? Yeah.

I want to impress my other engineer friends but they got their own startup problem.

30. Good startup engineering

That’s okay so sometimes it’s going to look like hackery.

Base awful hackery. yeah we just copy this files of changing two lines.

Is anybody going to our people gonna to play the game is more like this and like that Well we could carefully retractor ….

Well I might feel good but it feels good to do good engineering But that’s not good start up engineering. not if there’s a cheaper way.

To get through that loop that doesn’t mean that always in startup you just hack hack hack and so you ever do.

31. Switch modes

What happens when you hit it ,when you hits scaling.
You got to switch modes from the cycle you’re going through isn’t can I attract customers.

But that’s not the learning you’re trying to to create it’s like that that learning you’re trying to create is
Is there any way we can handle twice as many customers that’s the learning you need at that point whole boy you need.

Test driven development oh boy do you need automation and re-factoring and responsive design and being able to make your changes in parallel without disrupting stuff.

And at some point when you’re saying when the learning is can we make more money from our current revenue stream.

Then engineering shifts yet again to to being absolutely throughput oriented how can you reduce the cost of engineering team.

How can you reduce the operational costs.
And it’s something else yet again.

To be an engineer good engineering in a start up.

Go through all those phases and notices the need to switch Making those transition seems to be really really hard I say that because I have trouble making this transition.

To see a number of other people to do also so can you realise it for a while the engineering team builds features faster and faster.

32. We can build the future twice as fast this week as we did last

And he feel Good. we can build the future twice as fast this week as we did last cool. that’s pretty cool.

When you hit scaling when you’re optimal engineering strategies probably removing features.

And carefully tuning the feature instead remain all of a sudden the value system has to change

Right how you kept score has to change and making those transitions seems to be Very difficult because there’s much cultural as they are is there technical.

33. Conclusion

But the goal of building in the lean start up Is minimising the time through the loop and maximising the value that is extracted from us.