『リーンエンタープライズ』を読んだ個人的まとめ

「学習する組織」

共通の考え方
　インサイト・ドリブン
　　顧客
　　自社
　　データ

「完璧を追求し、許可を求めず、許しをこうてきた君たちへ、（グレース・ホッパー准将の言葉）そして、正しいことは何かを全員が知り、正しいことをするのに誰の許可も必要としない、そんな組織を作ろうと尽力しているリーダーたちへ」

—-

はじめに

フォーチュン500企業の平均寿命
　75年→15年
　長生きするには
　　イノベーションサイクルを回し続ける能力

ソフトウェア
　プロトタイプから進化が早い
　プロトタイプが最初から使える
　プロトタイプで顧客ニーズを発見し取り入れられる

「今やあらゆる企業がソフトウェア企業」

「Appleが考えたのは必要なのはスクリーンのついた長方形のみ、あとは全部ソフトウェア」

最も危険なのは「どれも良い考え方だね。でも、うちの組織ではうまくいかないだろうね」

「これは忠実に従うべきレシピではありません」


—-

極めて不確実な状況


## 指向

「組織の目的は、凡人をして非凡なことを行わせることにある」
ピータードラッカー

企業とは「共通の目的を共有した人たちで構成された複雑適応系」

組織の目的
　「マネジャーと従業員が顧客の立場になって」
　　何かをすること

経営陣の責務
　戦略の立案
　　文化を育てる
　　　環境の変化に合わせて進化
　　　　進化の方向性を決める

「悪いのはシステムであり人ではなかった」
　善人が悪をなしてしまうシステム

チームワーク
　マネジャーの主要タスクは作業者を助けること
　作業者がラインを止める権限を持つ
　作業者はどうやって改善するかの決定に参加しなければならない
高信頼文化を築くこと
　人間を部品とするテイラー主義ではない

内発的動機
　高パフォーマンスを生む
　仕事に誇り
　　外発的動機ではない
　　　ボーナスや人事査定
　　　アメとムチ

年功序列が排除
　すべての仕事を全員が学ぶ
　　チームでローテーション
　　　文化

GMの失敗
　「変化する必要はないと大勢が考えていた」
　　従業員の50% 管理者の75% 経営陣 全員の認識必要

リーンエンタープライズは人間のシステム
　儀式やベストプラクティスではない
　　文化が重要

病的組織（権力指向）
　不安と恐怖
　低い協力関係
　情報伝達者は処分される
　責任を逃れる
　橋渡しは推奨されない
　失敗は身代わりを探す
　新規性は潰される
官僚的組織（ルール指向）
　縄張り意識
　控えめな協力関係
　情報伝達者は無視される
　責任範囲が狭い橋渡しは黙認される
　失敗は処罰につながる
　新規性は問題につながる
創発的組織（パフォーマンス指向）
　ミッションの目標達成に集中
　高い協力関係
　情報伝達者は訓練されている
　リスクを共有する
　橋渡しは推奨される
　失敗は調査につながる
　　根本問題を見つけようとする
　新規性は実行される

創発的文化
　ハイパフォーマンス
　仕事の満足度


コマンド&コントロール
　科学的管理法
　軍隊のモデル化
　　プロイセン軍
　　　創発的なナポレオン軍に敗れる
　　　　機略戦
　　　　　学習、意思決定、行動が早い
　　　　　　スタートアップが大企業を撃破
　　　クラウゼヴィッツなどが再建
　　　　訓令戦術
　　　　ミッションコマンド
　　シャルンホルスト
　　　参謀将校軍事学校を設立
　　　　現場で自律的に動く
　　モルトケ
　　　「いかなる戦術も眼前の敵には無力だ」
　　　「戦争の状況はすぐ変化する。完全に実行できるほど詳細であり、長期間にわたる指令はまずあり得ない」
　　　　命令には必ず意図を含める
　　　　命令の目的を伝える
　　　　　現場で適切な意思決定ができる
　　　　　　（法文だけでなく法意を理解している）
　　　　　　　米国海兵隊

テイラーの還元主義
　全体のふるまいが理解できない
　　相互作用

「摩擦は3つのギャップを生み出す」
　　知識ギャップ
　　　情報が不完全
　　　　指示するときは意図の定義と伝達のみにする
　　連携ギャップ
　　　計画通りできない
　　　　意図の達成方法と指示の再確認方法を決める
　　効果ギャップ
　　　期待したことができていない
　　　　意図に沿って自ら意思決定する自由を個人に与える


「複雑なルールやコントロールは、無実の人に罰を課し、悪人には巧みに回避される」

意思決定がもたらす結果を完全に予測するための情報やコンテキストは決して手に入らない
　常にリソースが足りないのと同じ

ミッションの原則
　最終状態
　目的
　最小限の制約
　　定める
　　
ミッションの意図を説明して
なぜそれに取り組むのか伝達する

ある期間内で達成すべきターゲット状態を設定
　達成方法はチームに委ねる
　　連携を生み出す
　　自律を可能にする
　（スタンフォードの10個のクリップ）

プログラムマネジメント
　検証数値の目標のみ設定
　　イテレーションごとに決める
　　　チームに任せる

コマンド&コントロール
　ミッションプロセスで置き換えていく

もっとも深刻な障壁
　組織文化
　リーダーシップ
　戦略

製品開発
　アイデアの探索
　アイデアの活用
探索方法
活用方法
組織変革の方法




イノベーター
　「とりあえず使ってみよう」
アーリーアダプター
　「他人よりも先を行きたい」
キャズム
　超えたい溝
アーリーマジョリティ
　「他人と同じにしたい」


リーンスタートアップの目的
　新規性と可能性のあるビジネスモデルを発見
　運用可能にする
　うまくいかないものをすぐ捨てる

価値仮説
　課題/解決フィット達成
成長仮説
　製品/市場フィット達成

リーンスタートアップ
　価値仮説を立てる
　　何を学習する必要があるか
　　　計測すべき数値
　　　　MVPを構築
　　　　　集中速度学習

すべてのイテレーション
　検証による学習
　　ビジネスモデルの前提
　　　テストする
　　　　継続・ピボット・中止を決める
　　　　　個々のアイデアの
　　　　　　最大投資損失（ダウンサイド）を制限
　　　　　　　オプションの原則
　　　　　　　（小さなベンチャーキャピタル？）

極めて不確実な状況
　価値仮説が間違っている可能性が高い
　　ピボットする
　　　リソースは滑走路　
　　　　飛び立てるかどうか

イノベーションのリスク管理
　アイデアはほとんど成功しない　　　　　
　　リソースを最小限に
　　　ARM CPUの例
　　　　お金もないし人もいない

リーンスタートアップの考え方
　科学的手法
　前提を明らかにして
　テストして
　ビジネスモデルをすばやく評価する
未知と不確実性がある
リスクの高い新しいアイデア
最初に適用すべき手法
　時間とリソースを制約
　ダウンサイドを抑え
　MVPを構築して
　実際の顧客でテスト
　価値仮説を検証する

「アイデアの60%から90%は改善予定の指標を改善していない」
　直感も専門家の意見も当てにならない

プロジェクト
　スコープグリープ
　　機能がどんどん増えていく
　巨大バッチの死のスパイラル
　成果
　　顧客へ届けられた価値ではない
　　時間・予算どおり完了されたか
　デスマーチに報酬を与える
　持続不可能な英雄文化を作り出す　

アウトプットよりもアウトカム
　顧客からのフィードバック
稼働率でなくスループット
　小さなバッチ
短期機能的なものでなく長期システムレベルで考える
　インセンティブを与える
　安全に失敗するシステムを構築
　間違いから学ぶ

ポートフォリオの管理
　ホライゾン1
　　現在のビジネス
　　　今日のキャッシュフロー
　　既存カテゴリの新製品
　ホライゾン2
　　高成長ビジネス
　　　今日と明日のキャッシュフロー
　　新興ビジネス
　ホライゾン3
　　成長のオプション
　　　将来の高成長オプション
　　新しいビジネスモデル
それぞれ異なるマネジメントやサポートプラクティス






## 探索

すぐ解決策に飛びついてしまう
　人間の本能

計測可能なビジネス成果を定義
MVPを構築
顧客からのフィードバックで価値を実証する

最大のリスク
　価値のないものを作ること
　　リーンスタートアップですぐ捨てる
　　　リソース消費を最小限にする

ビジネスの変数
　既知のものはほとんど価値のないものだった
　未知のもの
　　中止されるかどうか
　　そもそも使う人がいるのか
　モンテカルロシミュレーション

「ほとんどの企業は、投資リスクの削減という意味では価値のない活動に対して、市場に到達するまでの約30%〜50%の時間を費やしています」

「あなたがやっていことに価値があるかはみんなが送金してくれるかどうかでわかる」

「ユーザーは必要としているものを正確に言うことは少ないが、必要のないものを見るとそんなものは必要ないと強く主張する」

必要なのは仮説
顧客からのフィードバックで前提をテストする
何度も実験する



課題/解決フィットの達成
　解決可能
　お金を支払ってもらえる
　　
製品/市場フィット
　MVP構築
　ピボット繰り返し


詳細な計画はやめる
　顧客を見つけて安価に実験する
　一連の実験を繰り返す

不確実な状況
　最初のアイデアが成功することはまずない


よくある反論
実験は完全な製品の代わりにならないのでは？
　確実性を得るのではない
　不確実性を減らす
実験とは？
　計測の定義
　　1つ以上の観察結果に基づいた不確実性の定量的な削減
　　確率分布
　観察結果を集める
　不確実性を定量的に減らす
　　わずかな情報
　　　大幅に減らす
　
従来のプロジェクトとリーンスタートアップとの比較
　投資判断の根拠データは？
　　未テスト仮説や前提から
　　　マーケットリサーチ
　　動作する製品を実際の顧客でテスト
　　　エビデンス
　開発は？
　　プロジェクト開始
　　　リリース
　　すでに検証されたMVP
　　　フィードバックをもとに改良していく
　アイデアが有益とわかるのはいつ？
　　プロジェクト完了後
　　　稼働してから
　　すでにある収集データ
　　　エビデンスがある


リーンスタートアップが成功する要因
　リソースが限られていること
　　食い尽くさない

情報の期待価値
　製品に100万ドルの投資
　300万ドルのリターンを約束
　大成功か大失敗
　　　　
「計測したい顧客成果を言葉にすることから始める」
課題/解決フィット
　試したがっている顧客を探す
　　強制ではない
　時間を区切る
　成功の基準
　　積極的に使いたがっているか
　　はじめの顧客成果を達成しているか
　　　達成していない
　　　　ピボットする

ジョン・ボイド大佐
OODAループ
　観察、情勢判断、意思決定（仮説）、実行（テスト）
　情勢判断から始める
　　遺伝
　　習慣や経験
　　自分が育った文化
　　活動している場所の文化
　暗黙の指示と統制
　　確証バイアス
　　協力と目標理解
　　　モニタリングディスプレイ
　　レパートリーを増やす
　　　構築、検証、学習ループ
　方法
　　まず敵の懐に入る（敵の予想に合致した行動）
　　　正攻法
　　気が熟す
　　すばやく奇襲に転換

デミングサイクル
　PDCAサイクル

「ものづくりは人づくり」

作るべきものをこれまで何度も作った
リスクが十分理解されている
　従来ウォーターフォール型でよい

従来ウォーターフォール型とは？
　計画変更は問題
　　失敗を意味する
　要求収集、分析、コスト算出、計画、政治スキル
　計画承認と資金獲得が成功
　プロセスが正しかったかが達成指標
リーンスタートアップ
　良くないものはすぐ捨てピボットする
　実験計測学習分析スキル、ボトムアップチーム
　サイクルを回して取捨選択し次のフェーズへ進む
　本当のリスクを効果的に管理できている状態

MBAにはない

リーンスタートアップの導入
「リスク、計測、不確実性への共通理解が必要」
　　不確実性が高過ぎると思いませんか？
　　現時点でリスクが大きすぎませんか？
　　計測が必要ではありませんか？

ベンチャーのほとんどが成功しない極めて不確実な状況
今までいろいろ試したがうまくいっていない
どうすればいいのか、何を指標にすればいいのかもわからない

質問
・リスクのモデル化
「ビジネスにおける投資リスクをどんな風にモデル化していますか？どんなデータですか？」

・何の不確実性を減らしているか
「計画の中で最も情報価値の高い変数は何ですか？その不確実性を減らすためにどのような計測をしていますか？」

・成果は何か
「今やっている仕事に価値があると確信していますか？それはどのようなエビデンスからですか？」

・顧客への理解
「その製品をどれくらいの頻度でユーザーに試してもらっていますか？その結果あなたは何を変えましたか？」




発見
　組織内ステークホルダーからの理解
顧客開発
　仮説
　　立案
　　検証
作るべきか？
　エビデンス
MVP
　安全に失敗する実験
　仮説中の最大リスクの前提をテスト
ピボット、辛抱、中止の決定方法
投資ポートフォリオ管理
　エビデンスに基づく
「正しいものを正しいときにつくる」



発見
　デザイン思考とリーンスタートアップの統合
　　顧客フィードバックをサイクルに入れる
　小さなチーム
　　専任
　　デリバリーオーナー責任権限
　　メンバーに顧客とユーザー
　　　ニーズが中心
　　3つの要素
　　　目的を共有する
　　　自律性
　　　専門家となる

顧客とユーザーの区別
　顧客はお金を払う

ビジョン
　まず解決する課題を明確にする
　　課題ステートメント
　やらないことを決められる
　　戦略

「個人ではなくアイデアについて安心して議論できるようにする」

Lastminutes.comの例
　イノベーションワークショップ
　　顧客を招待　　
　　　80個以上のアイデア
　ホテルロビーにイノベーションラボ設置
　　1週間
　　　フィードバックで取捨選択
　　　　グッドアイデアが3つ特定
　　　　　開発
　　　　　　コンバージョンを100%増やした

アイデア創出プロセス
　発散
　　多様でユニークで変なアイデア
　収束
　　課題に対する解決策を特定する

ビジネスモデル
　常に進化していかないといけない
　　レンタルビデオ屋とNetflix
　　CD屋とSpotify
　学習型組織

新規事業の目的
　ビジネスモデル仮説の検証
　　最もリスクの高い前提
　　　テスト
　　　　正しい道にいるエビデンスがあった
　　　　　はじめてコミットする
　　　
ビジネスモデルキャンバスをつくる
　前提を明確にする
　　主要リスクがわかる
　　　どれをテストするか決められる
　　　　当事者意識
　　　　協力体制

リーンキャンバス
オポチュニティキャンバス
バリュープロポジションキャンバス

「企業の成果は顧客の満足である」
ピーター・ドラッカー

ペルソナ
　常に更新する
　ターゲットの課題に共感するため
　　気持ちがわかる
　　　強い力となる
　　　　ソリューション仮説を特定する
　　　　　実験の開始

「現場に行き、目で見て、理解する」
　IDEO
「現地現物」
　トヨタ
「建物の外に出よ」
　スティーブ・プランク

顧客開発
　他人の言葉に耳を傾け、適切な質問をする
　　共感とインサイト
　　　すべての基盤

知的財産
　ソフトウェア
　分析
　データ

課題ステートメントキャンバス
　課題は何か？
　どんなインサイトから課題を見つけたか？
　どうやって特定した？
　どんな実験でテストする？




MVP
　最小限の労力
　最大限の学習
　ソリューションが顧客課題を解決しているかテスト
　　実験の成果は学習
　　　エビデンスに基づいた判断がてきる
　　　　ピボット、辛抱、中止
　ソリューション仮説を削ぎ落とす
　MVPと公式リリースは別
　MVPテスト
　　全体のスライス
　　　実現できる
　　　価値がある
　　　使用できる
　　　魅力がある
　　デザインや美的価値も重要
　　ただのプロトタイプではない
最終目的
　「リソース消費を最小限に抑えながら、自信を持って正しい製品を見つけること。その後それを改良し製品を正しく作ること」
MVPの種類
　紙ベース
　　ワイヤーフレーム、スケッチ
　　目に見える共通理解
　　仮説をテストできない
　対話型プロトタイプ
　　LP、動画
　　定性的顧客インタビューができる
　　仮説や技術をテストできない
　コンシェルジュ
　　手作業でガイド
　　複雑さを低減、すぐ前提をテストできる
　　リソースがいる、顧客は人間のことを認識
　オズの魔法使い
　　裏では全て手作業
　　価格、価値提案の検証ができる
　　かなりのリソースが必要
　　ザッポス
　マイクロニッチ
　　最小限製品に有料トラフィック、タイトルのみ
　　特定トピックテストにフォーカスできる
　　トラフィックの費用がかかる
　動作するソフトウェア　　
　　完全なソフトウェア、ABテスト
　　実環境でテストできる
　　かなりのリソースをさく
　　

ビジョンとMVPの連携
　ビジョン
　　提供サービスの種類
　　助けようとしている顧客
　　2〜5年のタイムフレーム
　　共通理解
　MVP
　　顧客開発しながら多くのMVP構築
　　実験から何を学習したいのか
　エバンジェリスト
　　ビジョンに賛同してもらう
　　　ソリューションの欠点を想像で埋められる
　　　　フィードバックは数値の統計に勝る
　　　　
最重要指標
　OMTM : One Metric ThatMatter
　　苦痛を与えるもの
　　勝利を感じさせるものではない
　解決しようとしている課題は何か
　行動を引き起こす数値
　　行動につながる指標
　　　優れた指標は行動を変える
　分析の複雑さを単純化するツール

プロセスのどのステージにいるか
　課題の確認
　ソリューションの確認
　MVPの確認

「アイデアとは検証すべき前提にもとづいた仮説」



「まずは正しいことをしている自信をもつ」
　間違ったものを正しいやり方で作ってはいけない


虚栄の指標
　ただのアクセス数
　滞在時間、ページ閲覧数
　メールアドレスの収集
　ダウンロード数

行動につながる指標
　ファネル指標、コホート分析
　セッション数
　メールに対するアクション
　アクティベーション

海賊指標
　獲得
　アクティベーション
　定着
　収益
　紹介


初期ステージ
　重要顧客とのやりとりにフォーカス
　　情熱のあるアーリーアダプター獲得にフォーカス
　　　そのニーズに応える
　　　　（5回のなぜ）
　成長を気にかける時間を少なく　　　
　プルシステムを作る
　　無理に販売する製品ではない
　学習しているところ
　　お金を稼いでいるわけではない

「立派な数字をとることが勝利ではない。満たされていないニーズを満たすこと、顧客を喜ばせることが私たちの勝利」

滑走路をつくる
　テストすべき仮説のリスト
　不確実性を減らす
　　一連の疑問

ストーリーマップ
　ユーザーストーリー

製品が膨らまないようにする
　作ることに最適化すると？
　　重要な苦痛・体験・成功を見失う
　　　そこに気づきがある
　　　　ドアのノブ
　顧客と密にやり取りする
　　前提をテストする
　ユーザーに共感
　　同じ苦痛を体験する
　手作業で解決できる程度の苦痛
　　御用聞き
　　そのままにする
　　　ボトルネックになってから改善

安上がりのイノベーションを活用
　実験は可能だと思ってもらう
　　文化向上



MVPとテスト自動化との葛藤
　TDDとCIはやる
　ユーザージャーニー


成長エンジン
　一つ選ぶ
　　バイラル型
　　　フェラーリ
　　　バイラル係数
　　課金型
　　　Amazon、Netflix
　　　定着率
　　定着型
　　　ebay
　　　顧客離脱率
　　拡大型
　　　AmazonがECサイトへ
　　プラットフォーム型
　　　AppleのAppStore


リーン開発
　徹底的かつ継続的に顧客の声を取り込む

Amazonの学習の例
　ebay対抗のAmazonオークション
　　負ける
　マーケットプレイスの前身のzShop
　　成功
　　　さらに中古市場へ

「金銭的利益をすぐに得ることよりも、ユーザーのエンゲージメントを築くことにフォーカスする」




## 活用

探索と活用
　補完し合う

大規模ソフトウェア開発
　ウォーターフォール
　　第二次世界大戦後の米軍から
　　　
ソフトウェアの力
　プロトタイプや変更が安価

大規模リーンアジャイル開発
　明確な成果と反復継続改善
　　ミッションの原則
　やりがいある目標
　　ムダを特定して排除
　小さなバッチでサイクルを回す
　顧客をベースにした自律した疎結合チーム
　顧客開発でフィードバックループを増強する

IT部門とビジネス部門の分離
　昔の時代の名残り

チーム
　バランス
　　チームの能力改善
　　顧客への価値提供
　ともに管理する


改善のカタ
　TDDを組織に適用したもの
「目標までの道が不確実なときに目標を達成するための汎用的なフレームワークとルーティンの集まり」
　不確実状態に強い
　　反復型
　　実験的手法
　　チームが自律する
「目標を理解して、それをイテレーションできるターゲット状態に分割しチームを連携させる方法」
　単なるメタ手法ではない
　　ミッションの原則がベース
　　　最終状態、目的、最低限の制約
　　　血液を末端まで行き渡らせる
　　　　大規模プログラムでも使える
　マネジメント哲学
　　部下の能力開発にフォーカス
　カタとは？
　　意図的に実行している
　　パターン化している　
　　ルーティン作業
　　　ピアノの練習
　　　武道の型
　マネジャーの主要タスク
　　改善のカタを教える
　　日々の業務として実行できるようにする
　4つのステップ
　　方向性やチャレンジを理解する
　　　6ヶ月から3年以内
　　　リーダーが設定したビジョン
　　　　ミッションの原則
　　現在の状況を把握
　　　1週間から3ヶ月
　　　ターゲット状態設定のための事実とデータ入手
　　　現在のパターンを発見
　　次のターゲット状態を設定する
　　　プロセス機能を計測可能な詳細度で記述
　　　特定状態を達成する具体的日付
　　ターゲット状態に向かって繰り返す
　　　SMARTな目標
　　　　具体的
　　　　計測可能
　　　　達成可能
　　　　適切
　　　　期限付き
　　　A3一枚
　　　全体的には背伸びした目標
　　　　いつも80%くらい達成
　　　個別には小さなこと
　　　　わずかな改善で達成できる
　　　　　積み重ねる
　　　　影響大でも時間のかかることはやらない
　　　　Macintoshの例
　　　達成する方法は事前にわからない
　　　　「どのように達成するかは計画しない」
　　　　　実験の中で考える
　　　　　　段階的継続的
　　　PDCAはチームに任せる
　　　　毎日実験する
　　　　（習慣化することでチーム能力も上がる）
　　　　　終礼の5つの質問
　　　　　　1. ターゲット状態は何か
　　　　　　2. 現在の実際の状態はどうか？
　　　　　　3. 障害は何か。今どれに取り組んでいるか
　　　　　　4. 次のサイクルは何か。何期待しているか
　　　　　　5. 何を学習したか
　現在のプロセスを時間とともに進化させるもの
　　メタ手法
　　　カンバンのような
　　　　アジャイルの本質
　　　　　手法でチームがアジャイルになるのではない

コーチングのカタもある
　
シングルループ
　暖房オンオフのサーモスタット
ダブルループ
　計測結果からやるべきどうかまで考える
　　自己弁護のバイアスに注意
　　　組織
　　　個人

リーン手法
「Result are not the point（重要なのは結果ではない）」
　結果達成のみ
　　プロセス改善の方法は学べない
　　　（ノルマ達成のみの組織）
　　　（チームは育たない）
　　　よりよい結果を繰り返し達成はできない

「計画プロセスで最重要テストはユーザー含むステークホルダーとのコミットメントを守れるか」

改善は新規開発に追いやられる
　可視化が必要
要求と改善活動を同じ仕組みで管理する
　改善のカタ
　　要求にも使える
　　　創発的文化組織
　　　　ビジネス目標をターゲット状態として設定
　　　　　仮説実験計測学習
　　　　分野横断の仕事
　　　　　仮想のチーム
　　　　　　チーム横断の仕事の調整
　　　既存組織
　　　　イシューをカンバンで管理する
　　　　　WIP制限を明記
　　　　　　完了してから次へ
　　　　　　　テスト後マージされデプロイ可能状態
リーン
　ターゲットも更新される
　　ピボット
　　　　　
アジャイル手法
　小さなチームのためのもの
　大規模適用したい
　　チームを複数
　　　リアルタイム指標
「できていないところについて話すために指標を使う」
　現場を歩き回るマネジメント
　　何か手伝えることはないか
　　　ターゲットや指標でない部分で低評価されると
　　　　数値の見栄えだけよくする傾向が生まれる

ハイパフォーマンス組織
　有機的に進化
　　コマンド&コントロールではない


・質問
達成しようとしている短期長期的成果を全員が共有しているか？
　その成果を決めるのはだれですか？
　成果はどのように設定され伝達され見直され更新されますか？

フィードバックループはありますか？
　フィードバックにかかる時間はどれくらいですか？




「やる必要のないことを効率よくやることほど無意味なことはない」
ピーター・ドラッカー


ダメなHiPPoメソッド（高級取りの意見）
　価値の高い機能少
　価値の低い機能多
　資金調達正当化
　承認
　プロジェクト立ち上げ
　「正しいアイデア」発見と詳細分析

8つの目標
　1. 最初の優先順位を素早く行う
　2. 「遅延コスト」を使って優先順位付けを改善
　　その機能が使えないことでの金銭的損失
　　　開発コストと機能価値を比較できる
　　　　職場の最年長任せの優先順位付けから脱却
　　　　　CD3(cost of delay divided by duration)
　3. 「動的優先順位リスト」から要求をプルする
　4. 要求のサイズを小さくする
　5. すばやくコードを書く
　6. アクティブに進捗管理する
　7. すばやいフィードバックを可能にする
　8. スムーズで持続的なフローを実現する

「遅延コスト」の計算で緊張感が生まれる
CD3のためにバッチを小さくできた
べき曲線から優先するものが見つかる

バリューストリーム
　現在
　　今の状態
　未来
　　1年〜3年後のターゲット状態
　改善のカタ
　　組織レベル
　　バリューストリームレベル
　　プロセスブロックレベル
　　　バリューストリームから5〜15のブロックに分割
　　　活動とチーム名
　　プロセスレベル
　10名以下のチーム
　バリューストリーム全体を変革する
　　特定部門にアジャイルを適用しても効果薄
　WIPを制限する
　　痛みを伴う
　　　終わらなければ新しい作業に着手できない
　カンバン
　　変化への抵抗を最小限にする
　　　今やっていることから始める
　　　漸進的進化的な変革に合意する
　　　まずは現在の役割・責務・肩書きを尊重する
　　　あらゆるレベルにおいてリーダーシップを促す

スクラム
　ビジネス価値の計算方法は指針なし


遅延コストを使う
　経済性で優先順位を決める
　　遅延したときに主要指標に何が起こるかを分析
　　　機能ごと
　　　　最年長者に任せる必要はない
　　　　　コマンド＆コントロールではない
　　最重要指標は何か
　　遅延したときどうなるか
　　優先順位とスケジュールを決める
　　　ミッションの原則
　　　　最終状態
　　　　目的
　　　　最低限の制約
　　WIP制限の経済的根拠
　遅延コストの問題点
　　時間に依存する
　　　納期を守れなかったとき急に上がる
　　　　緊急プロファイルを使う
　　金額換算が難しい
　　　顧客の信頼が売上に関与
　　　　前提を明確に文書化しておく
　　　　　あとで検証できる
　やってはいけないこと
　　既存プロジェクトに遅延コストだけ追加
　　　作業が増えすぎたときの対抗手段
「優先順位付けを政治ではなく、重要指標への影響と物事の前提の検証に変えることができる」
　PMO
　　遅延コスト算出
　　　テンプレート
　　　緊急プロファイル
　　　組織全体に公表
　　　フィードバックループをつくる
　　優先順位の決定は現場チームが行なう


ハイパフォーマンス組織
　リーダーシップとマネジメント
　　組織が生み出す顧客への価値にフォーカス
　　　価値がない活動を特定
　　　　排除
　　　　　リーン思考の本質
　　　バリューストリームマッピング
　　　　仕事の見える化
　　　　　今どの状態にいるか
　　　　　　改善のカタを適用
　　　　　　　WIP制限
　　　　遅延コスト
　　　　　透明性ある優先順位付け
　　　　　　価値の低い作業を回避

質問
・あなたの組織はどうやって優先順位付けをしていますか？経済モデル？年長者？

・リードタイムはどうですか？どうすればバッチサイズを小さくできますか？

・どうやって財務部門など他部門と仕事ができますか？ビジネス成果や収支への影響は？

・バリューストリーム全体で組織がつながっていますか？




イノベーション能力
　アイデアを頻繁にテストできるかどうか
　　主張するのではなく実際に試す
　　MVP
　　一番いいものを残す
　　それ以外は捨てる
　　実際に動くものが手元に残る
　競争優位になる
　Amazonの例
　　1時間に最高1079回デプロイ
　　「安全に失敗できる」環境をつくる
　　　少数ユーザーに短時間テスト
　　継続的デリバリー
　　　安全に
　　　経済的に
　　　小さなバッチで仕事をする
　　　「ボタンを押すだけでできる安全で簡単なお仕事」


継続的デリバリー
　「変更を安全にすばやく持続的にユーザーに届ける方法」
　安全に
　　デプロイメントパイプライン
　　　自動テスト
　　　手動テスト
　　　デプロイ一発ボタン
　　　　コンプライアンスのエビデンスとなる
　すばやく
　　リードタイムを監視
　　テスト環境でデプロイ
　　包括的にテスト
　　　問題が入り込んだ時点でわかる
　持続的に
　　小さなバッチで仕事する
　　「痛みを伴うのであればもっとこまめにやって苦痛を先取りしよう」　
　　大量のテスト
　　デプロイ自動化
2つの黄金律
　完成は本番デプロイ
　　顧客フィードバックによる成果確認
　　ボタンを押すだけでデプロイ状態
　導入の難しさ
　　2つのグループ
　　　どうすればできるのか理解できない
　　　これまでと違うやり方でうまくいくと思っていない
　本当に継続的インテグレーションができているか
　　全員マスターブランチをベースに開発しているか
　　マスターを変更する際に毎回ビルもプロセスが回るか
　　失敗したときは数分以内にビルドを修正しているか



連携

改善のカタ
　ターゲット状態を設定
　達成するための作業をチームが決める
　反復型のプロセス改善手法
製品開発にも使う
　ビジネス成果にフォーカス
　　それを達成する機能アイデア
　　　テストする
　　　　達成の責任はチームがもつ
　　　　　結果を最小化
　　　　　成果を最大化
　　　　　　成果でなく結果にフォーカスすると
　　　　　　　複雑なシステム
　　　　　　　燃え尽きたスタッフ
　　　　手法やプロセスはチームが選ぶ
　　　　　チームごとに違う
　　　　　　XP、スクラム、カンバン


製品開発への「改善のカタ」の適用
　計測可能なターゲット状態
　　達成したい顧客目標やビジネス目標
　　　手法やプロセスはチームが決める
　　　ゴール指向
　　　　2つの理由
　　　　　最初のソリューションはベストではない
　　　　　　改良していくことでより良いものが見つかる
　　　　　「組織が大規模にすばやく動けるには、ソリューションを構築する人がユーザーニーズとビジネス戦略の両方を深く理解し、独自のアイデアを考え出すときだけ」
　　　プログラムレベルのバックログだけではない
　　　　機能や利益の観点で作業を定義してしまう
　　　　　既に機能が決まっている場合
　　　　　　なぜその機能が必要か顧客に聞いてみる
　　　　
インパクトマッピング
　「高レベルなビジネス目標を計測可能な仮説に分解する」
　最重要目標
　　必要ないものを作らないための
　　ステークホルダー側の共通理解を生み出すこと
　技術側、ビジネス側、両方でつくる
　小さな横断型チーム
　　4つの質問で広げるマインドマップ
　　　1. なぜ
　　　2. 誰が
　　　3. どのように
　　　4. 何を
　　ターゲット状態を意図から説明
　　　ビジネス観点からの理由
　第1レベル
　　ターゲット状態に関心のある
　　ステークホルダーを列挙
　　　ユーザーだけでない
　　　仕事の進捗に影響する関係者
　　　　プラスマイナスどちらでも
　第2レベル
　　ターゲット状態に到達するために
　　ステークホルダーができる方法を記述
　　　邪魔していることも
　　これがインパクト
　　ソリューションにはまだ触れない
　第3レベル
　　ソリューション
　　最初はコードを書く必要のないものから
　　　マーケ活動やプロセスの単純化
　　　ソフトウェア開発は常に最後の手段
　　ソリューションは成果物ではない
　　　この時点のものはベストではない
　　　　改善のカタ
　　　　チームであるべき理由
　　優先順位付け
　　　遅延コスト
　　ターゲット状態までの最短パス
　　　チームで決める
　　　
今までの方法と何が違うのか？
　プログラムレベルの機能リストがない
　　機能ではなくターゲット状態を設定する
　　　熟練・自律・目的を追求する機会を与える
　　　　やる気が出る
　　　　　チームが成長していく
　詳細な見積もりがない
　　ターゲット状態は柔軟
　　優先順位の低いターゲット
　　　達成されないかもしれない
　　プロセス改善も同時に行なう
　　イテレーションは短期間
　　　2〜4週間
　　　　ターゲット状態を修正できる
　アーキテクチャエピックがない
　　アーキテクチャの変更も自由
　　あらゆる改善作業がターゲット状態
　　
ユーザーリサーチを実施
　仮説とソリューションは揃った
　　仮説テンプレート
　　　（ユーザー）に対して
　　　（機能）が
　　　（成果）を実現すると考えます。
　　　正しいかどうかは（検証数値）を
　　　見ることで判断します。
　　　　成果はターゲット状態
　ユーザーリサーチ手法
　　定量
　　　生成的
　　　　サーベイ
　　　評価的
　　　　A/Bテスト
　　　　　できるだけ少ない作業量で実験
　　　　　相関だけでなく因果関係も表す
　　　　　　Bingの例
　　　　　　　検索性能改善の効果計測
　　　　　　　A/Bテスト
　　　　　　　　人工的なサーバー遅延
　　　　　　　サーバー10msec改善の金額は？
　　　　　　　　遅延コストとして金額で出せるように
　　　　　　　常時ユーザーに15の実験
　　　　主要指標分析
　　定性
　　　生成的
　　　　コンテクスチュアルインクワイアリ
　　　　フォローミーホームメンタルモデル
　　　評価的
　　　　ユーザビリティテスト
　　　　コンセプトテスト
　実験の成果は情報
　　否定的な結果
　　結論が出ないこともある
　　　学習のための素材
「仮説を立てずに開発しない」
　　TDDの拡張
「ほとんどのアイデアの価値はゼロかマイナスである」
　　A/Bテスト
　　　60%〜90%がゼロかマイナスだった
　　　　開発前にアイデア価値テストをしないと？
　　　　　2/3は必要ないものかマイナス価値
　　　　　　加えて
　　　　　　　開発コスト
　　　　　　　機会コスト
　　　　　　　システムを複雑にしたコスト
　HiPPOのコハヴィの仕事
　　「クライアントに赤ちゃんがブサイクだと伝えること」
　　ゴム製のカバのおもちゃ
　　優れたアイデアのほとんどは優れていない
　　　データがないと事前にはわからない
　　
A/Bテスト
　完全実装しない
　できるだけ少ない作業量で
　　80/20ルール
　　　機能の20%をつくる
　　　便益の80%を届ける
　　大規模向けに構築しない
　　ブラウザ互換性は忘れる
　　　フィルタリングで適切ブラウザのみ表示
　　テストカバレッジは忘れる
　　　検証後に増やせる
　　　モニタリングの方がはるかに大事
　実験で得られる情報に期待する価値から
　　実験にかける最大時間を決定
　実験を安全に失敗させる
　　定義する
　　　制約
　　　限界
　　　域値
　　コンバージョンは限界を下回ったら停止
　　ステークホルダーと決定共有合意する
　Etsyの例
　　全てをA/Bテストしている
　　コホートで分析
　　実験予定、実験中、完了
　　　95%信頼区間で統計的有意
　　　　通知
　　　数%以上の変化は滅多にない
　　　　トワイマンの法則
　　　　　おそらく間違っている
　　　
「実験はウォーターフォール型プロセスにボルトで止めることはできない」

すべてのサンクコストを捨てる決断が必要
　苦痛を伴う

実験とは
　顧客からのフィードバックデータによって
　戦略やビジョンをすばやく進化させるためのもの
　　戦略とビジョンがなければA/Bテストの意味はない
　　　ユーザーニーズを長期的にとらえる
　　　　デザイン思考
　　　　　顧客への共感と知見
　　　　　ソリューションを生み出す創造性
　　　　　分析して合理性を組み合わせる能力

実験手法
　2つの障害
　　設計は一筋縄ではいかない
　　　お互いが干渉しない
　　　以上検知したら警告する
　　　検証作業も最小限にする
　　製品・デザイン・技術の強固な協力関係が必要
　　　ツールだけでなく実験の文化が必要
　Amazonのグレッグのレコメンドの例
　　あなたにおすすめ商品
　　　スーパーの会計レーンにある棚
　　シニアバイスプレジデントに禁止される
　　　会計しなくなるのではないか
　　グレッグは無視して本番でA/Bテスト
　　　明らかに増加
　　出てきたアイデアには客観的なテストをする
　　　インターン生でもCTOでも
　　　実験と学習サイクル
　　イノベーションを開花させる
　　　計測による統治
　クレイジーなアイデア・発散思考・仮説的推論
　　計測と実験による検証学習
　　「安価で安全に失敗できる実験」
　　　クレイジーなアイデアにお墨付きを与える
　　　良いクレイジーを支援
　　　悪いクレイジーを却下
　　　
かなりの労力をかけたアイデア
　ほとんどが意味がなくむしろ悪化させている



「最高のマネジャーは人をコントロールするのではなく、適切な場面を設定してあげることで素晴らしい成果を手に入れようとする」
NetflixCEOリード・ヘイスティングス

2001年のAmazon
　Obidos
　　巨大なモノリス
　　　DBが阻害原因
　課題を機会に
　　他の業者も活用できるプラットフォームにする
　　　究極の目標
　　　　顧客のニーズに合わせること
　　　　　サービス指向アーキテクチャ
　　　　　　コーポーネントやサービスに分解
　　　　　　APIでつなぐ
　　　　　　インターフェイスだけ知ってればいい
　　　　　　サービス間のおしゃべりを減らす
　　締め殺しアプリケーションパターン
　　　新しいモジュールをモノリスと別に作っていく
　　　　今ある課題を解決していく
　　　　　最初は新機能をモジュールで開発していく
　　　　既存の機能を移植しようとしない
　　　　　新しいビジネスプロセスの場合は1から観察
　　　　早く届ける
　　　　　小さな機能のインクリメント
　　　　テスト、デプロイ可能性を考慮して設計する
　　　　　テスト駆動
　　　　　継続的インテグレーション
　　　　　疎結合
　　　　Paasで動くように設計する
　　機能横断型チーム
　　　あなたが作りあなたが運用する
　　　すべてのチームは2枚のピザで
　　　　2PT
　　　　5〜10人
　　　　　共通理解が生まれる
　　　　　　コミュニケーションコストが低い
　　　　　成長速度を制限する
　　　　　権限を分散する
　　　　　　ミッションの原則
　　　　　　自律性を生み出す
　　　　　リーダーは経営陣とビジネス指標を決める
　　　　　安全な失敗ができる環境
　　　　　　リーダーシップ経験が積める
　　　　　　　起業家精神を引きつけ雇用し続けられる
　　コンウェイの法則
　　　システムの設計は組織を反映する

官僚型組織
　目の前のフィードバックに最適化される
　　自分たちの行動の効果が見えていない
　　　人間の悪意や愚かさは関係ない
　　　　そういうシステムになってしまっている

小さく分散自律したチーム
　2PT
　たくさんつくる
　補完性原則
　　現場のことは現場で決める
　　　上位層はそれを補完するのみ
　高度に連携した疎結合なチーム

本番環境へのプッシュ権限をチームに与える
　ホラクラシー
実際の設計・実行・進化に必要な人員を確保する
　チームは仮説構築検証学習サイクルを回す
　　深い専門性を持ったジェネラリスト2名
　　DB管理者
　　UX専門家
　　ドメイン専門家
チームは自分たちが使うツールを選べる
　Iaasなど
　だが本番環境の技術スタックは例外
実験のための予算承認は不要
　一定金額以下は不要
リーダーは「ミッションコマンド」にフォーカスする
　プロセスとビジネスを簡潔にすることに取り組む

報酬評価は期待する行動と連動させる
　開発完了ではない
　発見したバグの数でもない
　ターゲット状態の実現が成果
　　顧客行動をどう変化させたか
　　　指標の改善が評価となる

小規模自律チームをつくるとどうなるのか？
　学習が高速化、顧客サービス改善、無駄な仕事が減る
　　チーム間依存関係が減る
　　　早く実験できる
　　　　最も重要な指標
　　　　　リードタイムの変化
　　　　　「どれだけ高速に学習できるか」
　ユーザーニーズの理解が深まる
　　チーム全体が日常的にユーザーと接する
　やる気が出る
　　すぐにフィードバックが来る
　　　信じられないほど強烈な体験となる
　　　　自律・目的・熟達
　利益と損失が計算しやすくなる
　　サービスコスト
　　　チームが使ったリソースコスト+自分たちの給料
　　会社にとって最高利益産出チームだと示せる
　　　人事評価が統一される
　コンウェイの法則

大企業
　巨大な泥だんご
　　大規模システムリプレースプロジェクト
　　　ビッグバン（腕を切り落とすのと同じ）
　　　　遅延
　　　　予算超過
　　　　中止
　　　紙いっぱいの見栄えの良い図
　　　　作っているうちに新しい技術が出てくる
　　　　　結局達成されない
　　　　　　もとのシステムは残ったままさらに複雑化
　　本来は継続的な活動であるべき
　　　製品開発プロセスの一環
　　　　締め殺しアプリパターン
　　　　　（徐々に細胞が入れ替わっていく）

ミッションの原則
　目標の達成方法を定めるのではない
　　ターゲット状態、目的、最低限の制約のみ
　　　改善のカタ
　　　　自分たちで達成

終わりなき継続プロセス
　エンタープライズアーキテクチャの進化
　不必要な複雑さの削減

ミッションコマンドの実行
　複数のチーム
　　小規模
　　自律
　　疎結合
　システムアーキテクチャも進化させる
変えることが難しい？
　組織にも締め殺しパターン
　　小さく漸進的な変化
　　改善した顧客成果を届ける
　　継続する
　　
　　　　　　　



## 変革

「誰もが世界を変えたいと思うが、誰も自分自身を変えようと思わない」
トルストイ

リーンの原則と概念を組織全体に広める
　熱心で勇敢なリーダー
　　顧客に届ける製品だけでなく
　　組織全体にリーン思考を広めようとした結果
　製品開発とは
　　顧客に対する責任を認識し
　　組織全体の戦略と連携し
　　リスクを伴う意思決定し
　　新しいアイデアを試す権限を与えられている
　リーダーはコンテキストと制約を設定
　　共通の目的
　　顧客第一
　　　共感
　　　ニーズの理解
　コマンド&コントロール勢からの反発
　　簡単だから
　　虚栄の指標
　　　ルールに従っていれば失敗ではない
　　　　自分の責任ではない
　リーン企業になっているかどうか
　　失敗しているかどうか
　　　あらゆる人が失敗と挫折をしているはず
　　　　失敗や悪化がコントロールされている
　　　　　実験学習ができる
　　　　　　高信頼とハイパフォーマンス
　企業を変革する


「学習とは変化についていくための生涯にわたる作業である」
ピーター・ドラッカー

「成功している会社の数だけ、成功している文化がある」

組織モデル
　評価方法
組織変革戦略
　自律的に持続することを目指す
「優れた人」を雇う方法


文化とは
　共有された暗黙の仮定パターン
　　組織が学習した方法
　　　実体がない
　　　　計測は可能
　　　　　Q12
　　　　　　たった12の重要な質問
　　　　組織文化サーベイ
　　　　　どれだけ集まるか
　　　　　母集団が大きい時のみ
　　　　　人事評価とは別にする
　　　　　半年ごと


まず組織文化を計測
　課題を見える化する
　　なぜ文化がそうなっているのか調べる
　　　シャインのモデル
　　　　人工物
　　　　　組織構造やプロセス
　　　　標榜されている価値観
　　　　　ビジョンやバリューステイトメント
　　　　背後に潜む基本的仮定
　　　　　無意識の信念・知覚・思考・仮定
　　　　　価値観と振る舞いを支配しているもの
　　観察される行動
　　　本当の価値観を示すサイン
　　　　どんな行動が奨励されるか
　　　　誰が雇用・昇進・解雇されているか
　　ボーナス
　　　パフォーマンスを大きく低下させる
　　　　テイラー主義では効果的
　　マネジャー
　　　X理論
　　　　官僚主義
　　　　　怠ける
　　　　　命じられたことだけやる
　　　　　責任回避する
　　　　　現状を改めることを嫌う
　　　　　煽動者に付和雷同する
　　　　　不当な賃上げを要求する
　　　　　給料のためだけに働く
　　　Y理論
　　　　メンバーの能力を成長させる
　　　　顧客と組織に価値を届ける
　　知識労働
　　　内発的要因で動く
　　　　自律
　　　　　自ら方向を決定したいという欲求
　　　　　　コントロールしている
　　　　熟達
　　　　　自分の能力をどんどん上達させたい欲求
　　　　　　うまくなっている
　　　　目的
　　　　　自分より大きな何かの一部になりたい切望
　　　　　　大きな何かのために
　　　（疎外感が減る）


マネジャーが時間をかけて自らの行動でそれを示す

文化
　変革が難しい
　　成功に至るまでの考え方
　　感じ方
　　世の中に対する認識
　　グループが学び蓄積したもの
　　それを象徴するものが文化

『被抑圧者の教育学』
　いまだに支配的なモデル
　　生徒は空の銀行口座
　　　教師が知識を注ぐ
　　　　自律性がない
　　　　むしろ生徒をコントロールするため
　　　　　ほとんどの会社と同じ
　　　　　　そこでは組織変革も商品
　　　　　　　高額な変革プログラム
　　　　　　　組織を「修正」する
　　　　　　　説明書を読みながら

「決定的なのは組織の形ではなく、人がどう行動し反応するか」
　リスクの許可
　自律性
　失敗への罰
　職務機能を超えたコミュニケーションの奨励

文化を変えるには
　抽象的なものではない
　　文化
　　参加
　　学習
　仕事のやり方
　　何が仕事かをはっきりさせる
　　うまくやるためのトレーニングとツール
変えていく順番が違う
　古いアプローチ
　　文化からはじまる
　　価値観や態度
　　何をするか
　新しいアプローチ
　　何をするかからはじまる
　　価値観や態度
　　文化
　　思考を変えるために行動を変える
　　　（習慣から変える）
　　　（外側からマインドセットを変えていく）
　　　（7つの習慣）

危機感が必要
　NUMMIの再雇用
　生き残れるか不安
　このままでは目標を達成できない
危機感の指標
　従業員の50%以上
　管理者の75%
　トップ経営陣の全員
　大規模な改革が絶対に必要だと認識する
　　そうでなければ？
　　　破局が足りない
　　リーンマインドセットの本質
　　　常にそうあるべきだと理解すること
　　　　真のリーン組織の習慣
　　　　　変化
　　　　　改善
　　　　　発展
変革を受け入れたあと
　学習することへの不安
　　これを減らす
　　　生き残りの不安を増やしてはいけない
　　　　改善のカタ
　　　　　新しいアイデアを実験できる
　　　　　間違いを学習の機会として受け入れる
　　　　　　今後の間違い影響を軽減する仕組みづくり
　　　　　　　（間違った人がリーダーとして
　　　　　　　　ドキュメント化）

安全に失敗できるようにする
　失敗を罰するとどうなる？
　　リスクをとらなくなる
　　　複雑適応系
　　　完全情報を持つ人はいない
　　　　リスクを完全に見積もることはできない
　　言われたことのみを行う
　　　プロセスのみを評価
　　身代わりを探す
　間違いを罰するのではない
　　マイナス影響をコントロールする方法を探す
　　間違いから学ぶ規律
　　ポストモーテムを実施
　　　システムの改善
　　　　悪いのはシステム
　　　次の似た状況のとき何ができるか
　　　ふり返り最優先条項
　　　　「今日見つけたものが何であれ、チーム全員が、その時点でわかっていたものやスキル及び能力、利用可能なリソースを余すことなく使って、置かれた状況下でベストを尽くした、ということを疑ってはならない」
　　　　事件の関係者からの経緯と説明
　　　　　ひとつの根本原因ではない
　　　　　　複雑適応系だから
　　　　　あらゆる失敗は複数のことが関与する
　　　　　　目に見えない
　　　　今後の改善のための防止検知対応のため作成物
　　　　　複数のアイデア
　　　　フォローアップ
　　　　　改善が有効かどうか

人材不足などない
　「優秀な人」を見つけるのが難しい
　　優秀な人とは
　　　昔ながらコード量
　　　　テイラー主義
　最も生産的な人とは
　　コードを書かなくても済むように
　　創意工夫に満ちた方法を見つける人
　組織では個人レベルの差異はそんなに意味がない
　　「悪いシステムが毎回必ず優秀な人を打ち負かす」
　マインドセットによって決まる
　　失敗に他する態度
　　　才能は磨けば伸びるマインドセット
　　　　失敗は新しいスキルの学習の機会
　　　才能は変化しない
　　　　失敗を恐れる
　どうしたらマインドセットは変わるのか
　　報酬を与える
　　　しなやかなマインドセット
　　　　やりがいのある課題への取り組み
　　　硬直マインドセット
　　　　既存のスキルを活用する能力
　組織の変革の目標
　　学習することへの不安の軽減
　　　サポート・トレーニング・余分な時間
　　　　背伸びした目標
　　コラボレーションを推奨
　　失敗は学習の機会
　反対する人たち
　　アイデンティティを脅かされるのを嫌う
　　自分より劣っている者を雇用する
　　安心させる必要がある
　　　学習のサポート
　　　進んで学習すれば職は失わない
　　　離職を望むなら手厚い退職金

Googleの採用方法
　既存スキルだけで採用すべきでない
　　テクノロジーが目まぐるしく変化する　　　
　何を評価するか
　　学習能力
　　　その場で処理する
　　　異なる情報の断片をまとめる
　　リーダーシップ
　　　適切なタイミングでチームをリードできるか
　　　リードをやめて他人に任せられるか
　　　　権力を手放す覚悟
　　マインドセット
　　　人間への見方
　Googleで成功している人たち
　　自分の意見を強く主張する
　　　熱狂的に信じている　　　
　　新事実に会う
　　　それなら事情が変わってくるから君が正しいよ
　　不確実な未来に対応し、それでも前進する
　　　「強い意見を持ちながらそれに固執しないこと」

人材を育てる
　従業員の自己啓発計画を支援する
　人事評価を報酬評価から分離する
　定期的なフィードバックを促す
　従業員がトレーニング経費を使えるようにする
　従業員に個人目標を追求する時間を与える
　　3M
　　　業務時間の15%を個人プロジェクトに
　　　　ポストイットが生まれる
　　Google
　　　会社のための個人プロジェクトに20%の時間
　　　　AdSense
　　　　Googleニュース
　　トヨタ
　　　トレーニングとサポート
　　　　学習することへの不安を取り除く
　　　自律性・熟達・目的を追求する機会
　　　　モチベーションが生まれる
　　　　価値を届けられる
　　　　　従業員の仕事満足度
　　　　　　組織パフォーマンスの最高の先行指標

隠れたバイアスを取り除く
　数学的科学的思考に生物学的な性差はない
　2012年の性差バイアス調査
　　同じ履歴書
　　男女がわかる名前
　　女性に対するバイアスあり
　　　男性教授女性教授ともに
　どうすればいいか？
　　公平な賃金を保証する
　　　Netflix
　　　　全ての職の賃金が業界トップ
　　採用と昇進にターゲット状態をつくる
　　　候補者の50%を女性にする
　　在職期間・昇進速度・仕事満足度を調べる
　　　短かったり長かったり低かったり
　　　　暗黙的なバイアスがある明確な指標
　　定期的に方針・やり取り・人事プロセスをレビュー
　　　外部の専門家
　　　　定期的に是正監督してもらう

完璧にできる組織はない
　最善を尽くす
　継続的に改善に取り組む

・質問
匿名調査を毎年行ない公表して改善行動をとっていますか？
間違いや失敗を学習に変える仕組みはありますか？
従業員の定期的な成長のために組織は何をしていますか？
文化の変化をどう捉えていますか？継続的なものですか？
「優秀な人」を採用しようとしていますか？それとも学習能力やしなやかなマインドセットを持つ人を採用しようとしていますか？
組織は暗黙のバイアスを取り除く投資をしていますか？その進捗はどのように計測されていますか？




「万物は解釈の対象である。どの解釈が広まるかは権力の働きであり、真実ではない」
ニーチェ
　（りんごが赤いのは真実ではない。色覚障害の人には緑に見える。赤く見える人が多いだけ。それを理解しているかどうか）

「私たちは私たちのためを思っている人を信じ、私たちの関心に耳を貸さない人を信じない」
ゲイリー・ハメル

大企業のガバナンスに使えるのか？
　ガバナンスとリクス管理プロセスは違う
　　変更管理プロセス
　　本番環境へのアクセス

リーダーの責務
　必要に応じて進路を調整
　組織を目的地へ案内する

ガバナンス
　組織をコースから外れないようにすること
　　責任
　　権限または説明責任
　　可視性
　　権限委譲

「どのリスクを進んで受け入れるか？」
　リスクはなくならない
　　本番アクセスをインフラチームのみとする
　　　インフラチームの中央集権リスク
　　　デリバリーの遅延リスク
コンプライアンス
　ステークホルダーの利益を守る
　　情報漏洩
　　物理的安全性
　　財政投資
　
マネジメント
　ガバナンスと方向性と合うように
　目標達成に向けて
　　計画、構築、実行、モニターすること

優れたGRCマネジメント
　まずいことが起こらないようにコントロールする
　実験を認めることのバランスを維持する

既存のGRCチーム
　中央集権的
　時代についていけなくなる
　デリバリー速度が落ちる
　　ボトルネックとなる

GRCプロセスにリーン原則を適用する
　バリューストリームを見える化
　フィードバックを増やす
　学習を強化する
　チームに権限委譲する
　ムダと遅延を減らす
　WIPを制限する
　小さく漸進的な変更を行なう
　継続的に改善する

創造力
　特定の場合のみ
　　関係者全員が同じ目標をもつ
　　満たそうと努力する
　　同じ標準によって評価される

GRCチームとデリバリーチームがつながる
　管理ではなく共に価値を提供する
　厳しいルールチェックだけではどうなるか？
　　ステークホルダーに価値を届けられなくなる
　　　皮肉
　　　　本来コンプラはステークホルダーのためのもの
　　リスク管理劇場となる
　　　7つのタブのスプレッドシートをチェックしていく
　　　　マネジャーに送信
　　　　　マネジャーは理解していない
　　　　　　開発者に直接聞いている
　　　　　　　何の意味もない
　　　　　　　　文書ができるだけ
　　　
優先順位付けはあくまで遅延コストで行なう
　最悪の状況を想定してそれを防ぐのではない
　　「もしこうなったら型リスク管理」を防ぐ

儀式的プロセスがボトルネックになっている
　プロセス設定者に連絡
　　目的意図を確認する
　　共通理解
　　　ミッションの原則
　　　　ターゲット状態をどうしたいのか
　　　　目的意図は何か
　　　　最低限の制約は何か

予防的コントロールがより効果的というバイアス
　より厳しくする
　　（法律では厳罰化の効果は逓減する）
　　アングラ、抜け道が増える
　　　創造性を抜け道発見に使う
　　　反体制的文化を扇動する
　　　　本番環境に入れない
　　　　　パスワードの共有
発見的コントロール
　モニタリング
　すばやいテストやレビュー
　成果計測の可視化

「信じよ、されど確認せよ」
　適切なモニタリング
　頻繁なレビュープロセス
　　チームの仕事に透明性と可視性を組み込む

Etsyの例
　新人研修で本番へデプロイ
　クレジットカードを扱っているのは？
　　クレジットカード部分を本番環境から完全に分離
　　　チームは同じ場所で働いている
　「規制に準拠しながら理想のアーキテクチャと文化に対して行なう最小限の変更は何か？」
　　漸進反復プロセス
　　　改善のカタ

GRCを継続的デリバリーに組み込む
　GRCをチームメンバーとする
　コマンド&コントロールからリーン原則へ
　　取締りから貢献へ
　　　製品チームと同じ評価基準で評価できる
　　　　（リファクタリングやテストを日々の改善にするのと同じ）
　　　　（コンプラも日々の改善に取り込む）
　　　　（ターゲット状態の達成が報酬評価となる）



19世紀を基盤にした経営管理と
21世紀のビジネスプロセスが共存している

プロジェクトベースの財務管理プロセス
　プロダクトベースのイノベーションの足かせ
　財務チームと協力

中央集権的予算管理プロセス
　協力よりも競争を生む
　　縦割りになる
　イノベーションが減る
　　チームワークがないから
　　　心理的安全性
　脱予算経営

SOX法
国際財務報告基準
　意図していること
　　透明性や可視化

イノベーションを阻害する要因
　ビジネス判断が年次予算サイクルに基づいている
　　カレンダードリブン
　　　イベントドリブンにする
　予算目標をパフォーマンス指標として使う
　　プロセス管理となる
　ビジネス判断が設備投資費 対 運営費に基づいている
　　MVPを作ったり捨てたりできない

次年度予算の詳細な計画
　ムダ
　　製品開発には実行と発見が必要だから
短期的計画を絶えず調整する

財務管理を年次予算から分離する
　「やれと言われたが予算はあるのか？」
↓
「これは本当に必要なのか？」

リソース配分の決定を年次予算から分離する
　従来の方法だと？
　　実験を行うため
　　　最高のプレゼンをするようになる
　　　　リソースがムダになる
　　　予算獲得の政治をするようになる
　ダイナミックなリソース配分
　　資金提供のチェックポイント
　　　複数ある
　　　　探索フェーズコストをサポート
　　プロジェクトでなくプロダクトのパラダイム
　　撤退させたサービスの数にボーナス
　　　サンクコストをボーナスで消す

プロジェクトの承認
　長期的な運営費は計上されず

サプライヤーと協力する

「病的文化を埋め合わせるために新しいコントロールをつくってはいけない」
　顧客成果に責任を持つ文化を作る
　　
Netflixのchaos monkey

最適なパフォーマンス
　組織が不要な出費をしない
　作業が遅延なく流れる
　組織が法律を100%遵守している
　組織が顧客の定義した要求をすべて満たす
　従業員が安全で敬意を持って扱われる



今いる場所から始めよう

大規模な組織のもうひとつの未来
　従業員、顧客、製品が中心

最大の障壁
　思い込み
　　でも何も行動しなければ確実にマイナスの結末

組織変革の原則
　アイデンティティに立ち向かう
　　イノベーションや変革は日常的な仕事
　　　イベントではない

継続改善の唯一の道
　改善のカタ
　　新しいスキルを学習して　　　
　　今やっていることをもっとうまくやれるように
　　さらに
　　学習への不安を解消するためにサポートを整える
　コーチングのカタ
　　
CEO含む先行チームで運用
　組織内の導入ガイドとなる

依然残る課題
　コーチングのカタの適用方法
　実験サイクルの計画法
　改善のカタ実施のキャパシティの確保
　　ただやることが増えるのでは意味がない
　物事は改善される前に一度悪化する
　　以前のやり方ではなくなる
　　　生き残りの不安が必要
　　　破局が必要

改善のカタを適用するために
　組織の目的に合意する
　　顧客のために目指すことは何か
　　真に重要な目標は何か
　フォーカスしないものを決める
　　遅延コストを計算する
　ターゲット状態を設定する
　　成功が明確にわかる
　　KPIが入っている
　　　全体で10〜15程度のKPIのどれか
　戦略レベルのターゲット指標
　　1つ下の組織の方向性
　　　解釈して変形
　　　　ただ落とすだけではない
　　　組織レベル間での連携
　　　　戦略デプロイメント
　　　　　キャッチボール
　トップレベルの戦略
　　6ヶ月〜数年
　レビューミーティング
　　1ヶ月ごと
　　　1週間ごと
　　　　毎日
　先に文化の醸成

イギリスのGOV.ukの例
　アルファ版はたった14名
　　スタッフは公務員
　　アジャイル
　　　どれくらい安価にすばやく作れるのか
　分野横断チーム
　　自己完結型の小さなチーム
　　　成長していく
　一日平均6回のリリース
　ストラングラーパターン
　ガバナンス原則
　　デリバリーを遅延させない
　　必要なタイミングで適切なレベルで決める
　　適切な人たちでやる
　　自分で確かめにいく
　　価値の高まる場合だけやる
　　信頼して、確認する
　イノベーションぶん
　　自律性、熟達、目的を求める心


旅を始める
　方向性が明確に定義されていることを確かめる
　　達成したい成果
　　数値で
　最初のスコープを定義して絞る
　　組織全体を変えようとしてはダメ
　　一部から改善のカタ
　継続的改善のハイパフォーマンス文化を追求する
　　継続的改善が習慣となった組織　　　　　　
　適切な人から始める
　　しなやかなマインドセット
　　実験心
　　そこからアーリーアダプターへ
　　さらにアーリーマジョリティーへ
　　レイトマジョリティはついてくる
　　　マイノリティであることを嫌うから
　価値のある計測可能な結果を早い時期から届ける方法を見つける
　　結果を素早く見せる

巻き込みたいセグメントに実演する


不確実な状況でイノベーションを追求する規律ある厳格な姿勢
　リーンスタートアップの学習サイクル
　ユーザーリサーチと継続的デリバリー
　改善のカタ

反復型で漸進的な進捗が必要
　不確実性に直面
　予測できない変化
　複雑適応系を扱う

常に問う
　自分達の目的は何なのか？
　どうすれば組織と顧客と従業員のポテンシャルを高められるのか？