原文:https://blog.leanstack.com/running-lean-10th-anniversary-edition/

時が経つのは早いものです。『Running Lean』の最終版から10年が経ちました。あれから私は、世界中の数百ものプロダクトチーム、コーチ、ステークホルダーを、何千時間もかけてトレーニングおよびコーチングしてきました。私のゴールは、本書で最初に示されたステップバイステップの体系的なプロセスを、私のプロダクトだけでなく、さまざまなプロダクトや業界において検証および洗練することでした。

本書はいくつかの疑問には答えてくれましたが、以下のような難しい質問に次々と直面することになりました。

  • どうすればリーンキャンバスだけで投資家(やステークホルダー)にアイデアを認めてもらえるのか?
  • どうすればゲームやファッションのような「欲望駆動」のプロダクトで課題インタビューを実施できるのか?
  • どうすれば非テック系のプロダクトやサービスにRunning Leanを適用できるのか?

新版では、これらの疑問をすべて解決しました。

その過程において、私は追加のビジネスモデリングツール、新しく生まれ変わった検証戦略、さまざまな方法論やフレームワーク(リーンスタートアップ、デザイン思考、ビジネスモデルデザイン、JTBD、システム思考、行動デザインなど)と統合した、さらに実践的なテクニックを開発しました。

非常に不確実性の高い状況下で画期的なイノベーションを実現するには、 1つのフレームワークに限定するのではなく、すべてのフレームワークからベストなものを選択すべきだと考えました。これらのフレームワークは重複するところもありますが、それぞれが他のフレームワークを凌駕するスーパーパワーを持っています。これらのスーパーパワーを新しく作ったフレームワークのフレームワーク(継続的イノベーションフレームワーク)に収めました。新版では、それを紹介しています。

新版では、リーンキャンバスに加えて、以下の内容も取り上げています。

  • アイデアを形成する「トラクション・ロードマップ」
  • リスクに優先順位をつける「顧客ファクトリー指標モデル」
  • 顧客を不覚理解する「顧客フォース行動モデル」

『Running Lean』の10周年記念版では、以下のことがわかります。

  • 初期のビジネスモデルを形成するための、より効果的なストレステストのテクニック
  • 解決に値する本当の課題を発見するための、完全に刷新した課題発見インタビュースクリプト
  • 顧客に「あったらいい」ではなく「欲しい」と思わせる、実践的なプロダクト構築プロセス

ここまで読んだ方は、単なるマイナーチェンジではないことに気づかれたかもしれません。そのとおりです。10周年記念版でもある第3版では、新たに120ページが追加されました。また、いくつかのパラグラフを除き、すべてを完全に書き直しています。

長年の経験を持つ実践者でありコーチでもある方が本書の早期アクセス版を読んだときのコメントを紹介しましょう。

これは新版というよりも、新しい本という感じだ。あまりにも違うので、少なくとも新版の枠には入れられないだろう。ざっと目を通そうかと思っていたが、じっくり腰を据えて読む必要がありそうだ。

Ross McKay、プロフェッショナルメンター

Rossは前の版をみんなに読ませたくらいなので、よくわかっているのだと思います :)

2022/02/05 (土)に東京工業大学エンジニアリングデザインプロジェクト(東工大EDP)の最終発表会を開催します。

東工大EDPとは、パートナー企業からいただいたテーマに対し、東工大生・武蔵野美術大生・多摩美術大生・昭和女子大生・社会人がチームを組み、ものづくりを通して解決に取り組むものです。

本年度は【オンライン参加】と【オンサイト参加】の両方をご用意しています。詳細は以下のURLよりご確認ください。

EDP Gala — 革命的未来体験(されよ) -
https://edpgala-2022.peatix.com/

▼当日スケジュール
12:00–13:00: 開場・受付
13:00–13:10: 開会のご挨拶とEDPの紹介(齊藤滋規/東京工業大学 環境・社会理工学院 教授)
13:10–13:40: 基調講演
13:40–15:35: 最終発表会
15:40–16:00: 2021年度パートナー企業募集に向けて(齊藤滋規/東京工業大学 環境・社会理工学院 教授)
16:00–17:30: デモ展示 ・パートナー企業募集相談会・CBECプログラム受講相談会

▼本年度パートナー企業一覧 (五十音順)

  • 株式会社小松製作所
  • さくらインターネット株式会社
  • パナソニック株式会社
  • ミズノ株式会社
  • YKK AP株式会社

なお、来年度のパートナー企業も募集しております。募集説明会を2022/1/21に開催予定です。以下のURLよりご確認ください。

2022年度「東京工業大学エンジニアリングデザインプロジェクト」パートナー企業募集説明会
https://edp2022-tokyotech-cfp.peatix.com/

この記事は、Camilla Buchananによる「Prototyping for policy」の日本語訳です。Open Government Licenseの下に提供されています。

Prototyping for Policy(政策のためのプロトタイピング)」とは、2018年11月にThe Legal Design Labがスタンフォード大学d.Schoolで開催したカンファレンスの名称です。弁護士、政策立案者、技術者、デザイナーが集まり、戦略とデザインの世界がどのように出会うべきかについて、さまざまな側面から検討するというものでした。

「政策のためのプロトタイピング」の参加者の様子

プロトタイピングは、プロダクトデザインやインダストリアルデザインのプロセスにおいては一般的なものですが、サービスデザインなどの目に見えないデザインの分野にも応用されています。プロトタイプとは、アイデアやソリューションの解像度の低いモックアップであり、実装前にテストを可能にするものです。プロダクトであれば、ダンボールで作ったものをテストできます。ウェブサイトであれば、手描きのワイヤーフレームでテストできます。サービスのインタラクションは、ロールプレイでテストできます。

以下のエスプレッソメーカーのコンセプトスケッチとモデルは、インダストリアルデザインのプロトタイプの典型的な例です。

いかにしてサービスを守るか

この記事は、Kate Ivey-Williamsによる「Death by double diamond」の翻訳です。本人の許可を得て掲載します。

幸運にも私は、過去にコンサルタント会社において、そして現在は英国の政府デジタルサービス(Government Digital Service)において、サービスデザイナーとして働くことができました。2つの異なる環境で働いたことにより、サービスデザインが直面する課題と、適切にデザインしたサービスを提供するために必要なことについて、多くのことを学びました。

そうした課題はサービスの導入部分にあります。サービスデザインの業界は方法論を身につけています。我たちは適切にデザインされたサービスがどのようなものかを理解しています。そのために何が必要なのかもわかっています。ユーザーエクスペリエンスのシミュレーションやテストに役立つプロトタイプを作成することもできます。それなのに、サービスの導入の前に何かが起きているようなのです。サービスデザイナーがサービスの導入に関わることはほとんどありません。つまり、机上で慎重に作り上げてクライアントに手渡したものが、サービスの導入後に変化しているのです。

その原因の多くは、一般的に使用される「ダブルダイヤモンド」のプロセスが、ウォーターフォールの特性を持っているためです。ダブルダイヤモンドの最後の「提供」ステージのあとに起こるのは、サービスデザイナーが指示書をクライアントに手渡し、クライアント自身にサービスの導入を任せるというものです。これには数年かかることもあります。その結果、ステークホルダーのエンゲージメントがどれだけ高くても、導入後のサービスは当初のデザインとはまったく違ったものになります。

このようなやり方をしていると、サービスデザイナーの意欲は大きく損なわれます。オリジナルのビジョンを踏襲した形で導入されるという確信もなく、デザイナーが壁越しに成果物を放り投げているというような状況です。これはサービスデザインの業界にとっても大きな問題です。現実世界で「我々があれをデザインした」と言えなくなるため、デザインの品質をベースにして自分たちの仕事の価値を売り込むことが難しくなるのです。その結果、現実世界の事例ではなく、方法論を売り込むことになります。こうした方法論には導入部分は含まれていません。サービスを導入するときの課題はそれぞれ異なるため、テンプレートを作るのが難しいからです。

ですが、サービスデザインは方法論ではありません。サービスデザインはサービスのデザインです。グラフィックデザインがグラフィックのデザインであり、プロダクトデザインがプロダクトのデザインであるのと同じです。

サービスデザインの組織のなかには、トレーニングを販売してサービスの導入に影響を与えようとしているところもあります。トレーニングを実施しておけば、クライアントにデザインを手渡して離れたあとでも、サービスデザインを維持できると考えているのです。これには不幸な副作用があります。サービスデザインのコンサルタント会社が冗長で不要だと思われる可能性があるのです。多くの人たちがサービスデザインを理解するのは素晴らしいことです。ですが、1週間のトレーニングは、長年培った調査や業界の経験と等価ではありません。

ダブルダイヤモンドのプロセスに従い、サービスデザインの手法を使用するように教えるのではなく、組織がサービスを提供できるように、みなさんがサービスデザイナーとしての能力を高める必要があります。そして、それを実現するには、サービスの導入部分に関与する必要があります。

ウォーターフォールではうまくいきません。事業会社でもコンサルティング会社でも、サービスデザインの組織はますますアジャイルに移行しています。

アジャイルのおかげで、サービスデザイナーはサービスの導入部分に近づくことができます。そのための方法はいくつかあります。まずは、サービスデザイナーが現実世界に向けてデザインできるようになります。なぜなら、最初から現実世界で仕事ができるからです。サービスデザイナーは提案書を作成して、最後にそれを手渡すだけの存在ではありません。

アジャイルは反復的なプロセスです。つまり、プロセスの途中で(サービスが導入されるまで)サービスデザインを曲げたり変えたりできるということです。実際に動かして反応を見ながら、最高にデザインされたサービスを生み出すことができるのです。

アジャイルでは、特定の手法や「成果物」との結びつきが少なくなります。プロジェクトのステージごとに課題と対策を踏まえながら、アプローチを選択・変更していくことができます。

アジャイルを使うのはインハウスデザイナーのほうが簡単です。事実上、デザイナーであり、クライアントでもあるからです。ですが、コンサルティング会社もこの方向に進み始めています。私が以前勤務していたコンサルティング会社では、業務委託のような形でクライアントとの関係を構築し始めていました。つまり、ダブルダイヤモンドの「発見・定義・開発・提供」を売り込むのではなく、柔軟な契約と予算に移行していたのです。アジャイルにプロジェクトの計画を立案することで、戦略からサービスの試験運用に至るまで、組織に合ったペースでクライアントと協力しながら仕事ができるようになりました。また、サービスデザイナーはほぼフルタイムでクライアントと同席していました。そして、上層部のステークホルダーと協力しながら、デザインしたサービスの準備や提供ができているかどうかを確認していました。

サービスデザインは「提供」で終わりではありません。「導入」で終わりでもありません。サービスは進化を続ける反復的なものです。サービスデザイナーが影響を与えるには、すべてのステージに関与する必要があります。

Kate Ivey-Williamsは、英国のGovernment Digital Serviceのサービスデザイナーです。以前は、ロンドンでEngine Service Designのサービスデザイナーとして働いていました。

2020年10月のことになりますが、『Clean Agile』という本を訳しまして、その著者であるアンクルボブにインタビューした動画が公開されました。

人前でしゃべったりするのは苦手なんですが、最近はオンラインで何かやる機会も増えてたことだし、そんなことを言っていてもダメかなと思うようになりまして、とりあえずPodcastをはじめてみることにしました。

#1 Clean Agile and Tokyo Tech EDP

初回はその『Clean Agile』について軽く触れたあとに、講師として参加している東京工業大学エンジニアリングデザインプロジェクトについて話しました。

#2 Travels and Translations

2回目はGoTOトラベルキャンペーンを使った話、朝ドラ「ちりとてちん」が大好きで聖地巡礼した話、ドーミーイン大好きな話、「スクラムガイド2020」と『達人プログラマー第2版』の翻訳について話しました。

#3 Information and Task Management

3回目は情報管理やタスク管理について話しました。

とまあ、こんな感じで週1くらいで配信していきたいなと思っています。

複数のプラットフォームで配信しているので、ぜひ登録してみてください。

この記事は、Sanjay Poyzerによる「Become a service designer in government: step by step」の日本語訳です。Open Government Licenseの下に提供されています。

公共サービスのデザインは、私がこれまでに経験したなかで最も意義があり、最も満足のできる、最もやりがいのある仕事です。政府のやっていることの背景にある真の意図を考え、大きく改善されたアウトカムを国民に届けられるように、公共サービスに携わる方々をガイドしています。

「どうやってこの仕事に就いたの?」とよく聞かれます。私の話をしてもよいのですが、みなさんが本当に知りたいのは「サービスデザイナーになることは可能なのか? 可能だとしたらどうやって?」なのでしょう。そこで、GOV.UKのようなステップ式のガイドを作成しようと思いました。

1. いろんなことに関心を持つ

私の知る優れたサービスデザイナーたちには、印象的な特徴があります。それは、世界について、そこで生活する人たちについて、それらすべてがどのように動いているかについて、執拗とも言うべき大きな関心を持っていることです。たとえば、Harry Vosは商品の物流について独自の考えを持っています。Kay DaleはDIYが本当に大好きです。Lou Downeはセーリングからゲリラガーデニングに至るまで、あらゆることに取り組んでいます。

物事に関心を持つことは、物事をよりよくするための最初のステップです。何かに興奮すれば、そこからアイデアが生まれてきます。サービスデザインとは、以前とはまったく違うアイデアを持つことだとされますが、それは新しいアイデアではありません。すべてはどこからか盗んできてたものなのです。私が興奮するのは、どこからか何かを取り入れて、それを新しい文脈に持ち込んでいるときです。そのためには、大きな関心の「パレット」を持つ必要があります。本を読んだり、映画を見たり、面白い人たちと話したりしてください。すでに関心のあるスレッドをフォローして、世界がどのように動いているかをもっと詳しく知りましょう。

2. 何らかのデザイン理論を学ぶ

みなさんは(おそらく)研究者になりたいわけではないでしょうから、ここでは意図的に「何らかの」という言葉を使いました。あらゆるデザインの専門分野において、優れたデザインの基本原則を理解することは必要不可欠です。私の専門は音楽でした。そこから多くの重要なスキルを学びました。それらは今でも使っています。たとえば、誰かと一緒に仕事したり、アイデアを生み出して反復させたりするスキルです。あるいは、観客とクリエイターの関係性を理解することも重要です。デザイン理論に関しては、私は以下のような本を読みました。

  • 誰のためのデザイン?(ドナルド・A・ノーマン)
  • Research & Design Method Index―リサーチデザイン、新・100の法則( Bella Martin and Bruce Hanington)
  • ハマるしかけ―使われつづけるサービスを生み出す[心理学]×[デザイン]の新ルール(Nir Eyal)

これは網羅的なリストではありません。あくまでも私の役に立ったものです。私は「GOV.UK Service Manual」や「Design in government blog」からも多くのことを学びました。すでに公共セクターで働いている方は、GDSで開催しているトレーニングコースに参加してみてはいかがでしょうか。

3. サービスとそのデザイン方法について学ぶ

最近はちゃんとしたサービスデザインのコースが(Royal College of Artなどに)ありますが、私はそのようなルートを通っていません。

無料または安価なミートアップやイベントがあったおかげで、私は多少なりとも音楽の分野からテクノロジーの分野に移行できました。サービスデザインを学ぶための優れた方法は、このようなイベントに参加することです。たとえば、Global Service JamsService Design Fringe FestivalGovJam(労働・年金省が支援)などのイベントがあります。

ただし、このことは理解しておいてもらいたいのですが、サービスデザイナーに適した規定のアウトプットなどありません。あるのはよりよいサービスだけです。 ジャーニーマップ、ブループリント、ワークショップなどは、 そこにたどり着くまでに使用するツールにすぎません。

Design Councilがこうしたツールを紹介してくれています。ですが、全体的な「ダブルダイヤモンド」はかなり規定的なものになっています。この危険性については、Kate Ivey-Williamsの記事を読んでみてください。GDS Service Designトレーニングによるリーディングリストも素晴らしいです。

ある時点から「サービスとは何ですか? どうすれば優れたサービスになるのでしょうか?」と質問したくなるかと思います。この数年、GDSでは何度もこのような質問をしてきたために、サービスの実用的な定義優れたサービスの特徴のリストを作成することができました。

4. 何かを届ける

サービスデザインは不思議な仕事です。マネジメント職でもないのに、ロゴやコードなどを指して「あれは私がやった」と言うことができないのです。これがサービスデザインの最大の欠点だと思うこともあります。私は何も生み出してないじゃないかと感じるのです。ですが、サービスデザインはチームスポーツです。私のやっていること(たとえば、実践的でありながら広い視野を持ち、野心的であるようにみんなを説得すること)は、実際に生み出されるものに大きな影響を与えています。

その方法を教えてくれたのは、スタートアップの経営でした。時間とお金がすぐに尽きてしまう環境で誰かのために何かを成し遂げることの本当のプレッシャーを教えてくれました。また、Bethnal Green Venturesのサポートを受けたことも幸運でした。サービスデザイナーを含むメンターを派遣してもらい、現場でサポートを受けながら学ばせてくれたのです。また、その頃にEric Riesの『リーン・スタートアップ』を読み「実用最小限の製品(MVP)」が何であるかを学びました。しかし、本当に重要なのは、自分の周りにいる人たちを集め、誰かの問題を本当に解決できるものを作ってもらうことです。そして、それがどのように使われるかを観察して、何度も繰り返していくのです!

2019年度の東京工業大学エンジニアリングデザインプロジェクトの作品のひとつ「UROBON by チーム窓」を、二子玉川の「蔦屋家電+」に出展することになりました。2020/3/14から5月中旬までの2か月ほど展示予定ですので(追記:7/14まで延長となりました)、ぜひご覧になってください。作品の詳細は以下になります。 UROBON / 東京工業大学 エンジニアリングプロジェクト | 蔦屋家電+ 二子玉川家電 UROBON / 東京工業大学 エンジニアリングプロジェクト 当たり前を疑う…store.tsite.jp 今回の出展のきっかけは、前期の授業のテーマを「新しい家電のユーザー体験をデザインせよ」にしたことでした。そのときに、授業で終わらせるのはもったいないので、最終的な作品を家電量販店にディスプレイさせてもらったらおもしろいよねーという雑談を教員同士でしていたのでした。 ところが、雑談レベルで終わるのかと思いきや、東工大のある大岡山駅近隣でめぼしい候補を見つけ、蔦屋家電+にターゲットを絞り、先方にコンタクトして、出展用の予算を確保して……という感じで話がするすると進み、最終的には2月の発表会の様子を見て、全8チームのなかから本作品を選出することになったのです。動こうと思えば動けるものですね!

蔦屋家電+に出展しています!
蔦屋家電+に出展しています!
以下は、Kent Beckによる「Programmer Test Principles」の翻訳です。本人の許可を得て掲載します。
チョコレート対バニラ

TDD対BDD。このテストツール対あのテストツール。テストビフォー対テストアフター対これは動くから俺を信じろ。ある時期から、こうした詳細に関する議論には飽きてしまった。もっと原則について議論したい。

詳細に関する議論はなかなか結論に至らずに、話が行ったり来たりする。チョコレート対バニラ。チョコレート。バニラ。チョコレート。バニラ。

詳細の議論に負けを認めさせられるようなことがあっても、その譲歩は絶対的なものではない。私の状況がチョコレートを勧めているのに、私にバニラを食べさせてくれと言えるだろうか? これでは埒が明かない。

原則

一方、原則は議論を生み出す基盤になる。原則には賛成しても状況が違っているのなら、答えは違ってくるかもしれないが、そこで論争になることはない。原則が、異なる状況における異なる答えを生み出したのである。

詳細で論争するよりも、原則で論争したほうが生産的だ。私が完全性よりも速度を優先していると主張しても、あなたは速度よりも完全性を優先していると主張することができる。両者がそれぞれの状況において「正しい」。つまり、それぞれのニーズを満たす最高の決断をしているのだ。それと同時に、こうしたレベルで原則について議論することで、お互いの違いをうまく理解できるようになる。

プログラマーテスト

テストは神託である。「嗚呼、大いなる神託よ、これをデプロイしたら何が起きるというのか?」「我が子よ、大惨事が発生するだろう」。このように、テストはデプロイの結果を予言してくれる。

プログラマーテストは神託であり、コーディングと意思決定を繰り返すことによるフィードバックを提供してくれる。また、プログラマーテストは、難しい制約の組み合わせの影響を受けることになる。

プログラマーのテストは高速でなければいけない。フィードバックはプログラミングの流れを妨害してはいけない。スローテストはコーディングの意思決定をバッチ化してしまう。後続のテストの失敗はデバッグが困難である。これは、意思決定の1? 意思決定の2? それとも2つの組み合わせ?

どれだけ速ければ速いのか? 1秒未満が境界のように思える。目を離す間もないくらい、待ち時間が短いからだ。これが10秒だと椅子に深く腰掛けて目を離すことになるだろうが、新しいことを始めるほどの時間ではない。1分はコンテキストスイッチだ。デバッグのコストが高まり、実行するテストの数を減らしたくなる。

プログラマーテストは確定的でなければいけない。よく見かける「当てにならない(flaky)」テストは除外にするにしても、この主張が物議を醸すことになろうとは思ってもいなかった。確定的ではないテストは即削除する、というFacebookの方針が私は好きだった。カバレッジを下げたくなければ、テストができるように設計を変更して、テストを改めて書けばいい。

プログラマーテストは予言するものでなければいけない。神託が「デプロイしろ」と言ったのに、デプロイが失敗したのなら、神託を信じることをやめるだろう。

プログラマーのテストは、振る舞いの変化に敏感であり、構造の変化に鈍感でなければいけない。つまり、プログラムの振る舞いが安定しているように見えるなら、テストを変えるべきではない。

構造を変えないテストには、特定のスタイルの設計だけでなく、特定のスタイルのプログラミングと設計の両方が求められる。「このオブジェクトがこのメッセージをこれらのパラメータを持つオブジェクトに送信してから、あのメッセージをあのオブジェクトに送信すること」のようにアサートしているテストをよく見かける。だが、このようなアサーションは、世界で最も醜いプログラミング言語の構文だ。オペレーションの順序を気にしなければいけないとしたら、それはシステムの設計が間違っている。

プログラマーテストは安価に記述できなければいけない。テストを書くことに給与が支払われるわけではない。「a) きちんと動作」する「b) 変更できる」コードに対して給与が支払われるのだ。テストがそれを支援することもあるだろうが、他の条件が同じであれば、テストにかける労力は少ないほうがよい。

プログラマーテストは安価に読めなければいけない。テストは(コードと同様に)書くよりも読むことのほうが多い。

プログラマーテストは安価に変更できなければいけない。ひとつの振る舞いを変更したことで、テストがいくつもレッドになることがある。テストは個別に検討および変更できるようにすべきだ。そうすれば、テストが変更の非常ブレーキになる。

まとめると、プログラマーテストは、

  • プログラマの待ち時間を最小限にする。
  • 信頼して実行できる。
  • デプロイ可能かどうかを予言できる。
  • 振る舞いの変化に反応する。
  • 構造の変化に反応しない。
  • 安価に書ける。
  • 安価に読める。
  • 安価に変更できる。

なんとも解決が難しい制約の組み合わせである。なかには矛盾しているものもある。どれが最も重要で、どうすればそれを最大限に満たすことができるかを見つけよう。そして、それがあなたの仕事である。

領域

私がプログラマをコーチするときに懸念しているのは、彼らがテストの領域を探索したことがないことだ。テストに1分以上かかっているが仕方ない。テストを非確定的にするしかない。コードの構造を変えたときにもテストを変更せざるを得ない。そんなことはない。

上記の原則を考えてみよう。原則に違反しているテストを見つけよう。同様のテストで原則を守っているものを想像してみよう。そのようなテストが書けなければ、テスト対象のソフトウェアの設計を、プログラマーテストの原則を満たすテストが書けるようなものにしてみよう。

以下は、Kent Beckによる「Fast/Slow in 3X: Explore/Expand/Extract」の翻訳です。本人の許可を得て掲載します。

ソフトウェア企業の偉い人が「私たちは遅いでしょうか?」と聞いてきた。

3X思考の使い手である私は「まあ、そうですねえ……それは曲線のどこにいるかで決まりますね」と答えた。

要約

Explore/Expand/Extract

3Xの記事を書いてからしばらく経つので、簡単に説明しておこう。アイデアやプロダクトや企業が成長していくと、価値を最大化する振る舞いが劇的に変化する。

  • 探索(Explore)―無関心を克服するために、小さな実験を数多く試してみる段階。
  • 拡大(Expand)―拡大のボトルネックを解消するために、次に制約となるリソースの制限を緩和する段階。
  • 抽出(Extract)―成長を維持するために、成長が終わっても継続的に収益性を高める段階。

「速い」か「遅い」か

「速い」か「遅い」かは、曲線のどこにいるかで意味が違ってくる。

探索―アイデアが生まれてからフィードバックを得るまでにかかる時間は? 大企業だと社会構造が複雑であり、リスクの許容度が低く、抽出の考え方が文化の大部分を占めているため、この遅延時間が増える傾向にある。また、遅延が「実験数が減る → 成功数が減る → 1つの実験に対するのプレッシャーが高まる → 実験数が減る」というフィードバックループを生み出すことになる。

時間/日/週/月あたりに、どれだけ実験を行なっているだろうか? 増えた遅延時間は、実験を行う人員を増やすことで一時的に低減できるかもしれない。だが、遅延は指数関数的に増加し、投資は一時的なものである。探索における成功とは常に予期できないものなので、速度の指標は「件数」にしておくとよいだろう。

拡大―新たなボトルネックにすばやく人やお金を投入しているか? 成長を滞らせるボトルネックは、時間が経てばだいたい判明する。だが、ボトルネックを軽減できる人やお金が動かないこともある。元の場所にいたほうが有益だからだ。

Facebookのエンジニアリングでは、新たなボトルネックに非常にうまく対応していた。最も優秀なエンジニアたちが、厄介な技術的問題に群がるのである。Facebookはこのようなレベルのレジリエンスを達成するために、大きな成功を犠牲にしてでも、喜んで対価を支払っている。複雑なマネジメント環境で、このような対価を支払う組織はそう多くはない。だが、これは実現可能である。

抽出―収益性の高いプロジェクトにかける時間は? こうしたプロジェクトは、収益を高めるかコストを減らす。成長している組織は、もはや価値を提供しないプロセス、引き継ぎ、遅延を放置している。使い物にならなくなったものが膨れ上がる危険性があるため、もはや価値を提供しないプロセス、引き継ぎ、遅延を排除する必要性(あるいは、レジリエンスを高めることで、価値を提供できるプロセス、引き継ぎ、遅延を増やしていく必要性)を省みることがない。

Conclusion

「私たちは遅いでしょうか?」

「探索しようとしていて、本質的な理由がないのに実験に時間がかかっているのであれば、遅いでしょうね。あるいは、月あたりの実験数が少ないのであれば、やはり遅いでしょうね。

拡大しようとしていて、重要なリソースが欠けているために成長できず、右往左往しているとしたら、遅いでしょうね。

抽出しようとしていて、収益性の高いプロジェクトに必要以上に時間がかかっているとしたら、遅いでしょうね」

角 征典 (@kdmsnr)

角 征典 (@kdmsnr)

ワイクル株式会社 代表取締役 / 東京工業大学 特任講師 / 翻訳『リーダブルコード』『Running Lean』『Team Geek』『エクストリームプログラミング』他多数