book

リーンエンタープライズ ―イノベーションを実現する創発的な組織づくり

by Jez Humble, Joanne Molesky, Barry O'Reilly, 角征典, 笹井崇司, Eric Ries

October 2016

Beginner to intermediate

384 pages

4h 24m

Japanese

O'Reilly Japan, Inc.

Read now

Unlock full access

　　なぜ本書を書いたのか　　誰が本書を読むべきか　　本書の概要　　謝辞　　　ジェズ・ハンブルより　　　ジョアンヌ・モレスキーより　　　バリー・オライリーより
　　1.1　リーンエンタープライズは人間のシステムである　　1.2　コマンド＆コントロールに代わるミッションコマンド　　　摩擦と複雑適応系　　1.3　ミッションの原則に従って大規模に連携する　　1.4　人材は競争優位である
　　2.1　新しいアイデアの探索　　　新しいビジネスモデルの探索時はソフトウェアの開発投資を最小限に　　2.2　検証されたビジネスモデルを活用する　　2.3　企業ポートフォリオのバランスをとる　　　いかにしてAetnaは新会社を作って自らのコアビジネスを破壊したのか　　2.4　まとめ　　　読者への質問

　　3.1　投資リスクをモデル化する　　3.2　製品開発に科学的手法を適用する　　　リーンスタートアップを社内ITプロジェクトに適用する　　3.3　探索の原則　　3.4　まとめ　　　読者への質問
　　4.1　発見　　　4.1.1　共通理解を生み出す　　　4.1.2　構造化された探索　　4.2　どのようなビジネスにいるのか？　　　4.2.1　ビジネス課題を理解してビジネスプランを伝える　　　4.2.2　顧客とユーザーを理解する　　　顧客とユーザーに顔を与える　　　4.2.3　インサイトとデータを圧倒的な優位性にする　　　4.2.4　仮説と実験を伝えるためにインサイトを使う　　4.3　MVPで実験を加速する　　　「作ることができるか？」ではなく「作るべきか？」　　　4.3.1　ビジョンとMVPをどのように連携させるのか？　　　4.3.2　最重要指標　　4.4　まとめ　　　読者への質問
　　5.1　革新会計　　　活力を与えてくれる社内の支援者　　5.2　スケールしないことをする　　　5.2.1　顧客親密度　　　顧客との共感を築く: 答えが建物のなかにある場合もある　　　5.2.2　要求ではなく疑問の滑走路を作る　　　ストーリーマップでビジョンの滑走路の物語を作る　　　5.2.3　探索のためのエンジニアリングプラクティス　　5.3　成長のエンジン　　5.4　ホライゾンを移行して成長・転換する　　　スティーブ・ベルによるリーン開発とリーン運用　　　イノベーションには時間がかかる: オークションからマーケットプレイスへ　　5.5　まとめ　　　読者への質問
　　6.1　ケーススタディ：HP LaserJetのファームウェア　　6.2　「改善のカタ」を使った継続的プロセス改善によるコストの削減　　　6.2.1　方向性を理解する　　　6.2.2　計画：現状を把握して、ターゲット状態を設定する　　　6.2.3　ターゲット状態を達成する　　　6.2.4　「改善のカタ」と他の手法の違い　　　「改善のカタ」を展開する　　6.3　HP LaserJetチームはどのように「改善のカタ」を実行したか　　　反復型開発のための設計　　　HP FutureSmartチームにおけるアジャイル変革の経済的メリット　　6.4　要求を管理する　　6.5　アジャイルな企業を作る　　6.6　まとめ　　　読者への質問
　　7.1　Maersk社のケーススタディ　　7.2　フローを増やす　　　7.2.1　製品開発バリューストリームを描く　　　7.2.2　WIPを制限する　　7.3　遅延コスト：経済的決定を分散させるフレームワーク　　7.4　まとめ　　　読者への質問
　　8.1　継続的デリバリーの基礎　　8.2　継続的インテグレーションとテスト自動化　　　テスト自動化の基礎　　　本当に継続的インテグレーションをやっているのか？　　8.3　デプロイメントパイプライン　　　FutureSmartのデプロイメントパイプライン　　　継続的デリバリーと変更管理　　8.4　デプロイとリリースを分離する　　8.5　まとめ　　　読者への質問
　　9.1　インパクトマッピングで次のイテレーションの仮説を作る　　9.2　ユーザーリサーチを実施する　　9.3　オンライン対照実験　　　ほとんどのアイデアの価値はゼロまたはマイナスである　　　A/Bテストで性能改善の遅延コストを計算する　　9.4　A/Bテストの例　　　実験を安全に失敗させる　　　A/Bテストの代替　　9.5　製品開発における実験的手法の前提条件　　　イノベーションには実験の文化が必要である　　9.6　まとめ　　　読者への質問
　　10.1　成長に対するAmazonのアプローチ　　　サービス指向アーキテクチャ入門　　10.2　「ミッションコマンド」で大規模にベロシティを生み出す　　10.3　ストラングラーアプリケーションパターンでアーキテクチャを進化させる　　10.4　まとめ　　　読者への質問
　　11.1　文化のモデル化と評価　　11.2　文化を変える　　　11.2.1　安全に失敗できるようにする　　11.3　人材不足などない　　　Googleの採用方法　　　11.3.1　人材を育てる　　　11.3.2　隠れたバイアスを取り除く　　11.4　まとめ　　　読者への質問
　　12.1　GRCを理解する　　　マネジメントはガバナンスではない　　　12.1.1　リスク管理に進化的アプローチを使う　　12.2　GRCプロセスにリーン原則を適用する　　　12.2.1　顧客視点でGRCプロセスの価値を定義する　　　ルールベースは「リスク管理劇場」につながる　　12.3　バリューストリームとフローとプルシステム　　　12.3.1　間違ったコントロールがフローを滞らせる　　　コンプライアンス活動のフィードバックループを減らす　　　ケーススタディ：EtsyにおけるPCI-DSS　　12.4　まとめ　　　読者への質問
　　13.1　はじめに　　13.2　財務のビートで踊るとイノベーションは遅くなる　　13.3　年次予算サイクルから自らを解放する　　　13.3.1　財務管理を「予算」にまとめるのをやめる　　　13.3.2　年次会計サイクルから資金提供の決定を切り離す　　　13.3.3　活動基準会計を検討する　　　活動基準原価計算で優れた判断をする　　13.4　パフォーマンスを予算で評価しない　　　WestJetの事例：効果がある金銭的インセンティブ　　13.5　「資本支出費」対「運営費」のビジネス判断をやめる　　13.6　価値デリバリーの主導権を握るためにIT調達プロセスを修正する　　　英国政府：IT調達プロセスの変更によるイノベーション　　13.7　まとめ　　　読者への質問
　　14.1　ITマインドセットを再考する　　14.2　自由と責任　　14.3　プラットフォームを作って進化させる　　　14.3.1　災害に備える　　14.4　既存のシステムを管理する　　　結合には頻繁なコミュニケーションが必要　　　Suncorpの簡素化プログラム　　14.5　まとめ　　　読者への質問
　　15.1　組織変革の原則　　　15.1.1　戦略デプロイメントを目指す　　15.2　英国政府デジタルサービス　　　政府デジタルサービスのケーススタディ　　15.3　旅を始めましょう　　15.4　まとめ

Content preview from リーンエンタープライズ ―イノベーションを実現する創発的な組織づくり

8章リーンエンジニアリングプラクティスを導入する

品質を達成するために大量の検査に頼ることをやめましょう。プロセスを改善して、最初から製品に品質を作り込むのです。

W・エドワーズ・デミング

イノベーションの能力は、本当のユーザーでアイデアを頻繁にテストできるかによって決まります。フィードバックにもとづいて、製品やプロトタイプを学習・更新し、再びテストする速度を上げることが、強力な競争優位になります。これが、本章で説明するリーンエンジニアリングプラクティスの価値提案です。オリジナルのMacintoshを開発したエンジニアのひとりであるアンディ・ハーツフェルドは、このように語っています†1。

新しいソフトウェアのアイデアを主張するのではなく、実際に試すようにしていました。簡単なプロトタイプを作り、一番うまくいったアイデアを残し、それ以外を捨てたのです。その時点で最高だと思える実際に動くものが、常に手元にありました。

[†1] http://bit.ly/1v70zdR

多くの組織では、数日間から数週間かけて、統合本番環境にソフトウェアをデプロイしています。ところが、ソフトウェアを必要悪でなく競争優位として扱っている組織は、このリードタイムの短縮にかなり投資しています。これを大規模にやると、どうなるでしょうか。2011年5月、Amazonは本番システムへのデプロイの平均間隔11.6秒、1時間あたりの最高デプロイ回数1,079回を達成しました。これは同社のプラットフォームを構成する何千ものサービスの総計です。デプロイのなかには、10,000を超えるホストに影響を及ぼすものもありました†2。もちろんAmazonは、SOX法やPCIデータセキュリティスタンダードといった規制を守っています。 ...