目的
以前読んだ「エンジニアリング組織論への招待」。ただ、読んだときより立場が大きくかわったためか、今読むと「あれ、この本、本当に読んだことあるのだろうか?」と感じるくらい、ひとつひとつのフレーズにはっとしたり考えさせられたり心がざわざわしたり。なので、しっかり向き合ってみようと思う。
感想
ふんわりと感じていた違和感やネガティブな状態に、過去の偉人は既に名前をつけ、かつ、いろいろな対策も提案してくれていた。ただ、重要なことは行動し、観察し、変えていくこと。もう少し課題を明晰化し、行動したい。
要約
メモより要約する
1. 思考のリファクタリング
1-1 すべてのバグは、思考の中にある
エンジニアリングを行う組織では、「思考のリファクタリング」により不確実性に向き合えるようにする。
1-2 不確実性とエンジニアリング
エンジニアリング とは 「実現する」こと。実現するには、不確実性を減少させなければいけないが、そのためには情報が必要。 不確実性は「未来」と「他人」に潜む。未来の不安は行動・実験・観察して得た情報により、他人の不安はコミュニケーションを通じて削減する。
1-3 情報を生み出す考え方
エンジニアリング で 不確実性を減少して実現していくためには、「情報を生み出していく」ことが必要である。 情報は、チームで、決まっていない答えを、探しながらといていくことにより生み出される。経験主義 と仮説思考で情報を収集し、何が正解なのか自分で設定する。
1-4 論理的思考の盲点
問題を認知するために「人は感情に囚われずに判断することは難しい」という論理的思考の盲点を理解する。
1-5 経験主義と仮説思考
問題を明晰化するために、経験主義( = わからなければ行動する)と仮説思考(= 少ない情報で大胆に考える)を実践する。
1-6 全体論とシステム思考
問題発見のために全体論とシステム思考の視点を持つ。全体 とはビジネス全体のフィードバックサイクルをもったシステムであり、「秩序だった複数要素の組み合わせ」「要素に分けても見られない性質をもつ関係性」に注目することにより、真の問題を発見する。
1-7 人間の不完全さを受け入れる
人間は不完全な思考をしてしまいがち(人は正しく認知できない / 情報がないのに行動せず考えつづけてしまう / 局所最適な思考をしてしまう) 人の傾向を理解したうえで、コミュニケーションにより不確実性を減少させ、秩序を作ろう。
2. メンタリングの技術
2-1 メンタリングで相手の思考をリファクタリング
メンタリングの目的は「相手の思考をリファクタリング」することであるが、実際は行動を変えることにほかならない。 変更するために大前提として、メンターとメンティーにHRT の関係を築かなくてはいけない
2-2 傾聴・可視化・リフレーミング
メンターは、傾聴・可視化・リフレーミングにより、「モヤモヤしていない問題に変換する」= 「明確に次にすべき行動がわかる」状態に変えていく。
2-3 心理的安全性の作り方
メンティを「ラーニングゾーン」= 「責任も高く、心理的安全性も高い」状態にもっていくために、アクノレッジメントとストーリーテリングを実施する
2-4 内心でなく行動に注目する
課題がある行動を可視化し、行動をどう変えたらいいか考える。SMART を意識して行動を言語化し合意、フィードバックと承認で行動を促進しつつ、環境や構造を変えて阻害する要因を減らす。
まとめ
メンタリングにより、問題発見、感情と分離し、行動できるようにする。具体的で高い目標を自分で設定し自ら行動できるようにすることがメンタリングのゴール。
3. アジャイルなチームの原理
3-1 アジャイルはチームをメンタリングする技術
アジャイルの考え方のベースは「チームをどのように構築していくか?」。 今事業が立ち向かう不安はスケジュールではなくマーケット。チームをゴール意識の高い状態にするにはどうしたらよいのか?
3-2 アジャイルの歴史
品質管理、生産管理、生命科学、ハッカーカルチャーなどから軽量ソフトウェア開発プロセスやアジャイルが生まれた。
3-3 アジャイルをめぐる誤解
アジャイルには5つの誤解がある。決まった開発手法をささないための誤解。
- 誤解1 : アジャイル開発は決まったプロセスである
- 誤解2: アジャイル開発では設計しない
- 誤解3 : アジャイル開発は優秀なメンバーでないとできない
- 誤解4:アジャイル開発では中長期計画がない
- 誤解5:アジャイル開発は開発者に決定権がある方法だ
3-4 アジャイルの格率
アジャイルは理想状態。チームが環境に適応して、不確実性を最も効率よく削減できている状態にするために、経験学習を取り入れたこと、実現のためにコミュニケーションや感情に向き合い、価値の流れを最適化する 。
アジャイル開発は「脱構築」される
アジャイルになるには、自分たち自身のやり方や役割を変えていく「脱構築」が必要。そのために観察 と対話 を繰り返す。
4. 学習するチームと不確実性マネジメント
4-1. いかにして不確実性を管理するか
不確実性を可視化し、マネジメントする ( 方法・目的・通信 )
4-2 スケジュール予測と不確実性
方法不確実性へどう対応するか? 納期 = 理想工期 ( 工数人月 / 人数 )+ 制約スラック + プロジェクトバッファにより決定するが、スケジュールマネージメント (制約スラックを削減する / 見積もりの予測可能性を上げる /プロジェクトバッファの消費を可視化し改善する) により予測可能。予測できれば事業を推進できる。
ただし、本当によめないのは、「何をつくるのか」の過程。エピック、テーマ、ストーリー、タスクと分解され、詳細化していく過程で不確実性がさがるため、ボトルネックを探してスループットを上げる ( 仮説検証戦略 → 開発要求 →開発→ テスト→リリース→ 効果検証)。
いずれにしろ、スケジュール不安はコントロールできるため、 ビジネス - 開発の不信を排除し、全員が「何をつくるのか」「それはマーケットに受け入れられるのか」に目を向けられるようにする。
4-3 要求の作り方とマーケット不安
何をつくるか 、という目的不確実性にどう対応するか。リリースポイントをまめにつくる / ユーザーストーリーをつくる など、価値が高くリスクも高いところから仮説検証し、少しずつマーケット不安を削減する。
4-4 スクラムと不安に向き合う振り返り
スクラムは不安に向き合うフレームワーク。WHAT / HOW / DAILY の不安を発見し仮説をたて検証していく。
不安を知りチームマスタリーを得る
不安はなくならないが、チームのゴール認識のレベルが高くなると、チームが自分たちで不安をみつけ、検証することができるようになる
5.技術組織の力学とアーキテクチャ
5-1 何が技術組織の"生産性"を下げるのか?
技術組織の”生産性" は情報処理能力 = 方法不確実性と通信不確実性への対処方法 で測る。 エンジニア組織の情報処理能力を向上させるには、権限の委譲と期待値調整、 適切な組織・コミュニケーション・外部リソース調達の設計、全体感のあるゴール設定と透明性の確保、技術的負債の見える化を実施する。
5-2 権限委譲とアカウンタビリティ
権限と責任は表裏一体/責任と権限の不一致は往々にして発生し、委譲具合は伝わっていない。権限委譲と責任を果たすことができる組織構造、不断のコミュニケーションによる期待値調整 が情報処理能力の高い組織を生む。
5-3 技術的負債の正体
技術的負債は「見えない」「マイナスの価値」。経営者にとっては「負債」=「返済すべき」ではない場合もある。見える化 = 理想システムの追加工数との差や将来要件の不確実性 などで、事業に与えうるインパクトを言語化し、情報の非対称性をなくす取り組みが必要。
5-4 取引コストと技術組織
取引コストは「探索のコスト」「交渉のコスト」「監督のコスト」に大別される。組織が大きくなると組織内外で限定合理性が高くなり、全体最適に向かわない。機能横断組織がひとつの解。
5-5 目標管理と透明性
チームのゴール認識を高め、限定合理性によらない目標を設定するために、目標管理の仕組みをデザインすることと情報の透明性を保つことが重要である。
5-6 組織設計とアーキテクチャ
ビジネスモデルにあわせて組織とアーキテクチャをデザインする。
エンジニアリングカンパニー
企業活動は、エンジニアリング。根本的な問題が「構造上の問題」であることに気づけば、対立は消える
メモ
1. 思考のリファクタリング
1-1 すべてのバグは、思考の中にある
- エンジニアリングを行う組織について考える。
- チーム開発では、理不尽や感情の対立が、思考のバグにより生まれる
- バグをなくしてゴールを達成するには、いっときの感情を取り除くだけじゃ不十分
- 「思考のリファクタリング」=「不確実性に向き合える」ようにする
1-2 不確実性とエンジニアリング
- エンジニアリング とは 「実現する」こと
- 実現とは、曖昧な要求からスタートして、具体的で明確な何かに変えていくこと
エンジニアリングでは「どうしたら効率よく不確実性をへらしていけるのか」をやること
組織構造 : 曖昧な指示 → 具体的な行動
- 曖昧を具現化する処理装置が組織
それぞれのレベルでどれくらい不確実性を除去し具現化する力をもっているか? = 自己組織化された組織
情報 = 不確実性を減少させる知識。なにが起きるかわからない から ある程度わかる
無限にある選択肢が絞り込まれて、何をどのように実現していけばよいのかわかるために必要なのが 情報
不確実性を発生させるのは「未来」と「他人」
- 未来:行動、実験して観察することにより確実にする
- 他人:コミュニケーションを通じて削減する
二つの「わからない」を「不安」でさけてしまう
1-3 情報を生み出す考え方
- エンジニアリング = 不確実性をさげて実現していくこと、ならば「情報を生み出していく」
情報を生み出すには ... というのが本書のテーマ
情報を生み出す、とは?
- チームで、決まっていない答えを、情報を探しながらとく
- 複数人 → 事実をそのまま認識することの難しさ
- 経験主義 と仮説思考で情報を収集し、何が正解なのか自分で設定する
仕事の問題を学力テストの問題に置き換える * ひとりでとけるようにする
- 必要な情報を与える
- 正解を明確にする
1-4 論理的思考の盲点
問題を認知するために論理的思考の盲点を把握する
論理的思考は「ルールと事象を正しく認知できること」「正しく演繹できること」が前提
- 事象を正しく認知できるか? ファクトと意見を分離する
感情にとらわれず判断できる? 非論理的に考えてしまう瞬間を知る
怒りを感じている = 自分ないし自分の大切にしているものに被害が及びそうだと感じている
- 自分のアイデンティティの範囲を知る / 「怒り」を「悲しみ」として伝える
1-5 経験主義と仮説思考
- 問題を明晰化するための経験主義と仮説思考
「わからないことは調べるしかない」わからないことを行動で突き止める
少ない情報で大胆に考える = 仮説思考 - 理想から逆算する / 大胆な跳躍を実現する - PDCA で重要なのは 1. 何が仮説なのかを明らかにする 2. 検証できるか を常に気にする
- リアルオプション戦略 = 成功の確率があがるまで巨額の投資判断を行わない
- MVP は「意思決定を遅延させるための「権利」を獲得するアイディアをつくること」 - 確実なものにしか投資できないなら遅い
1-6 全体論とシステム思考
- 問題発見のための全体論とシステム思考
- パーツではなくて「秩序だった複数要素の組み合わせ」「要素に分けても見られない性質をもつ関係性」に注目する
- システムとは全体の関係性を捉えること
- ネットワーク構造 で非線型な関係、要素の総和で全体の性質はわからない
- 部分だけしかみないことで対立が起こる = 物事を側面からみる
- 全体 = ビジネス全体のフィードバックサイクルをもったシステムの観点でみる
- フィードバックサイクル = 拡張と抑制がある - 拡張 = 原因増結果増の場合に原因を増やす - 抑制 = 原因増結果減の場合に原因を増やす
- 全体の関係性が見えれば対立は解消する
- 正しいと判断したときは、システムの外部性を切り捨てている
- よいプログラムには問題解決のための眼がある(視野、視座、視点)→これは前紹介したやつがよさそう
- 関係性に注目する
1-7 人間の不完全さを受け入れる
- 論理的思考の盲点 : 人は正しく認知できない
- 経験主義と仮説思考 : いくら考えても答えがでない
全体論とシステム思考 : 局所最適な思考をしてしまう
そして、コミュニケーションの不確実性 ( 他社理解、伝達、成果)
- 情報の非対称性 : 知っている人は知っている
- 限定合理性:自分の正解が全体の合理性にならない
カレー作りの寓話 - ボブは客がほしいものを知っているがカレーの作り方は知らない
- エバはカレーの作り方は知っているけれど客が欲しいものをしらない - 効率を考えた役割分担 → 限定合理性 → パーティでもてなすができなかった
- コミュニケーションの不確実性を解消できなかった
コミュニケーション能力 = コミュニケーションの不確実性を減少させる能力
情報の透明性 = 意思決定と意思決定に関わる情報が、組織内に正しく整合性をもって伝達されるように継続して努力し、なにかわからない決定があったとしても、それは隠そうとしたわけではなく、抜けてしまったのか、自分が聞き逃したのだから、直接聞いてみようという関係性を作ること
不確実性を削減し秩序を作る
2. メンタリングの技術
2-1 メンタリングで相手の思考をリファクタリング
- メンタリングは相手の思考を変えること。
- 相手の思考はコントロールできないし観察もできない
- 観察可能な「行動」を変えていくことになる
コードレビュー / ペアプロ / 障害時ハンドリング / チームマネジメント
「自ら考える人材を作る」
- 自立型人材とは 自ら問題を発見し解決することができる / 問題について、自分事として捉えている
- 「自分の問題」の境界がある = コンフォートゾーン
- となると、メンタリングはコンフォートゾーンを広げること
まずは HRT の関係が築かれていることが必要 : 関係がないと言葉がとどかない
- 階段を登る手助けをする ( 階段を認識させる / 壁に梯子をかける / 階段を上りたくさせる)
- そのためには、自己説得 = 他人が質問で促し、体感を伴わせ、行動の変化を発生しやすくさせる
- 悩んでいる場合は、悩みを聞き出し、気づきを促し考えるに変えていく
2-2 傾聴・可視化・リフレーミング
- メンターの役割は「モヤモヤしていない問題に変換する」= 「明確に次にすべき行動がわかる」
- もやもやの正体
( 問題を解かないのは緒がみつからないからかもしれない。やる気がないと思ってはいけない)
傾聴
- 空っぽのコップにしか水は入らない。不安の水は「傾聴」で取り除く。
- 人は感情の生き物なので一瞬たりとも感情から逃れることはできない。
- 傾聴 = 「相手の」感情への共感を言動で表す / 「相手の」話の内容を「可視化」をする / 「相手の」思考の「盲点」を探索しながら質問をする
- 「相手の側に立って話を聞いている」という言外の「信号」を常に送り続けている = しぐさ・うなずき・座り方・表情・あいづち
- 共感 は「相手がそのような気持ちになった理由を理解する」
可視化
明晰化のために
- 事実と意見を分ける (感情もWBに)
- フォーカスポイントを作る (紙に筆算を書き出すように、曖昧なところを順番にはっきりとさせる)
- 衝突から比較可能への変換 = 選択肢、比較軸、評価方法を明らかにする
2-3 心理的安全性の作り方
- 厳しいことを言い合える関係をつくる
- メンティを「ラーニングゾーン」= 「責任も高く、心理的安全性も高い」状態にもっていく
- メンタリングにおいてはメンター・メンティ双方が「弱さ・失敗」を開示することが必要
- acknowledgement : 存在・行動・結果
- アクノレッジメントを行動で示す
- ストーリーテリング ( 自己開示、感情の共有、価値観の共有、返報性の原理)
- ジョハリの窓、自分も他人もわかっている「開放の窓」を広げる フィードバックと自己開示
2-4 内心でなく行動に注目する
- 行動しかみることができない ( 内心に不満があるときは行動に不満があるとき)
- 課題がある行動を可視化し、行動をどう変えたらいいか考えよう
- SMART を意識して行動を言語化し合意する
- 能力は習慣の積分、習慣は行動の積分
- 成長は一足飛びにできない
- 行動しないのは促進する要因がすくなく阻害する要因が大きいから
- フィードバックと承認で行動を促進する
- 環境や構造を変えて阻害する要因を減らす
まとめ
メンタリングにより実施したいこと
- 自分のきがつかなかった問題に気がつくようになる
- 認知の歪みによる感情と問題の癒着を切り離せる
答えではなく、次の一手を生み出す行動がとれるようになる
そのために必要なことはゴール認識
- ゴール認識 = ゴールに対してどのように考えているかという認識
- wish to / have to / want to / will / be going to
具体的で高い目標を自分で設定し自ら行動できるようにすることがメンタリングのゴール。
3. アジャイルなチームの原理
3-1 アジャイルはチームをメンタリングする技術
アジャイルの考え方のベースは「チームをどのように構築していくか?」
- 日本は世界と比較してアジャイル普及率が低く、実践者がいない
- アジャイル開発が必要とされた2つの理由
- ソフトウェアが大規模化・複雑化した
- マーケットの不確実性に対応したい
- アジャイル開発は3倍の成功率 / 1/3 の失敗率
- 大規模PJ の方がアジャイル開発をするべき
- マネージメントとは、対象となるXX の資源・資産・リスクを管理し、効果を最大化する手法
- PjM 終了することを目的に、スケジュール不安を減らし、方法不確実性を除去したい
PdM 終了しないことを目的に、マーケット不安にさからい、目的不確実性と向き合う = What をどうきめるか?
ソフトウェア開発の前提が変化している
- スケジュールとマーケットという2つの不安
- アジャイルのゴールはチーム全体をメンタリングすること、チームがゴール認識をもつこと
- アジャイルをせず、アジャイルになる
- 情報の非対称性が小さい
- 認知の歪みが少ない
- チームより小さい限定合理性が働かない
- 対人リスクをとれていて心理的安全性が高い
- 課題・不安に向き合い不確実性の削減が効率良くできている
- チーム全体のゴール認識レベルが高い
PjM のスコープは方法不確実性 のみ / アジャイルなチームは + 目的不確実性と通信不確実性をあつかう
- 何をつくるか考える人とどのように作るか考える人の切断に伴う弊害
スピード言わない方がいいのか : なぜスピードいうのか = マーケットのプレゼンスが落ちているから
- やってみないとわからない のか? どれくらいわかればすすめられるのか?
今なにが課題なのかを
3-2 アジャイルの歴史
- デミング博士の4つの「深淵なる知識」 / 日本の製造業の生産性向上・品質管理に寄与
- システムの理解
- ばらつきに関する知識
- 知識の理論
- 心理学に関する知識
- トヨタ生産方式とリーン生産方式
- Just In Time : ちょうど間に合わせる
- 「カンバン」プラクティス:顧客需要から逆順に部品を要求していく = 最終顧客の要求を引き取る形で開発を進める
- 多能工
- リーン生産方式
- トヨタ生産方式からうまれた
- 無駄の排除と現場主導による改善 をマニュアル化、パッケージ化
- 生産方式から知識経営へ
- 組織学習の名著「失敗の本質」→ コミュニケーションから敗北の理由を分析 ( 1991)
- 失敗理由1 : 環境に過度に適応する現場
- 失敗理由2: 現場の情報をもとに戦略目標を明確化できなかった司令部
- 必要だったのは「前提を疑う」学習ループ / 明確な作戦目標 / 自己革新
- 「新しい新製品開発ゲーム」 (1986) → スクラムに
- 企画から製造販売まで一貫してフォローしていく体制
- 現場と司令塔の間における知識の有機的な連続
- SECIモデル
- ダブルループ学習:定期的な「リフレーミング」が重要
- 生命科学の社会科学への流入
- ハッカーカルチャーと東洋思想への憧れ
- 予定説へのカウンターカルチャー
- 禅 : 基本的な型を繰り返し繰り返し「プラクティス」することによって、あるとき全体的な理解を得て「体感的に習熟する」
- この文化が 「パーソナル」なコンピュータと組み合わさる
- 軽量ソフトウェア開発プロセス
- アジャイルソフトウェア開発宣言 : 有名な4要素
- 歴史からみる3ポイント
3-3 アジャイルをめぐる誤解
- 誤解1 : アジャイル開発は決まったプロセスである
- スケジュール不安に対応しているようではちがう
- 導入したいのはプロセスではない。解決したい課題に対して経営者に説明する
- 誤解2: アジャイル開発では設計しない
- 中間成果物 = 価値とみなさない、設計工程を進捗とみなさない
- 組織学習のための設計工程、ドキュメント、超重要
- 誤解3 : アジャイル開発は優秀なメンバーでないとできない
- メンバーに自立性を求める / チームは課題に直面させられる
- 成長を促すしかけが多い →結果優秀に
- 誤解4:アジャイル開発では中長期計画がない
- 計画はいつでも立てられる / 不確実性を考慮して検知し大胆にかえていってもいい、といっている
- 誤解5:アジャイル開発は開発者に決定権がある方法だ
- アジャイルは、目的不確実性を削減するため、仮説検証を繰り返す方法
- 仮説検証のため、開発に関わる意思決定が徐々に委譲されていく
- 権限にかかる期待値をあきらかにしないとチームは生産性を発揮できない
- アジャイルが誤解される理由
3-4 アジャイルの格率
アジャイル開発は「脱構築」される
- アジャイルになるにはどうしたらいいか?
- それに対する答えが「アジャイルな方法論」
- 手段カタログとしての「アジャイルプラクティス」。これは実践というより修行
- 対立の裏に「不確実性」あり → 対話と熟慮で解消する
- 自分たち自身のやり方や役割を変えていく「脱構築」
- そのための観察 と対話
4. 学習するチームと不確実性マネジメント
4-1. いかにして不確実性を管理するか
- 不確実性を可視化する
- 不確実性マネジメント
- 方法・目的・通信
4-2 スケジュール予測と不確実性
- 方法不確実性への対応
- 納期 = 理想工期 ( 工数人月 / 人数 )+ 制約スラック + プロジェクトバッファ
- スケジュールマネージメント
- 制約スラックを削減する
- 見積もりの予測可能性を上げる
- プロジェクトバッファの消費を可視化し改善する
- 制約スラックとクリティカルパス
- タスクに依存関係があったり、実行できるスキルを持っている人が限られると、クリティカルパスの工期が実質工期になる
- リソース制約 = 「この作業は〇〇にしかできない」をなくす / 知識がなくてもできる仕組みをつくる
- 依存制約 = 作業と作業の間にある依存関係 を解体するアイディアを
- 調整コストや意思決定を減らす ための会議のデザイン
- 悲観的見積もりと楽観的見積もり
- 「どの程度の確率で完了するのか」考える
- プリンシパル・エージェント理論
- 見積もりとエージェンシースラック
- ビジネス担当が依頼者 / 開発がエージェント
- 見積もりに不安が大きいと悲観的な見積もりになる / コミットが大きいと楽観的な見積もりになる
- スケジュール不安の「見える化」
- 管理するのは間に合うか、間に合わないかではなく、「スケジュール予測が収束していくかどうか」
- まずざっくり : 3ヶ月 / 1年 / 3年
- 最善ケースと最悪ケースの幅が狭まると、経営判断できる
- CCPM は不安量を集めて管理する
- タスクごとにのっているバッファをプロジェクトバッファに置き換える
- スケジュール不確実性の削減をプロジェクトバッファの消費という形で見える化
- 多点見積もり : 複数パターンの見積もり
- 不安 = 幅 : 不安量の大きいタスク順に問題解決する
- 不安量の大きいタスクを解体する
- 不安の解消方法 : 概念検証 / CI ・TDD / プロトタイピング
- 不安の原因を減らす相対見積もり : Tシャツサイズ / ストーリーポイント / 理想日見積もり / 実時間見積もり
- プラインニングポーカー
- 管理するのは間に合うか、間に合わないかではなく、「スケジュール予測が収束していくかどうか」
- 計画でなく実績から予測する → 見積もりからスケジュールを考えるのはPjM の仕事!
- 小さなスプリントを繰り返すことにより予測可能に
- ベロシティで評価しない
- ベロシティを用いたスケジュールマネージメントをする
- 不確実性コーンを利用する / 多点見積もりを導入する
要求粒度と不確実性
スケジュール不安はコントロールできる
- ビジネス - 開発の不信を排除し、全員が「何をつくるのか」「それはマーケットに受け入れられるのか」に目を向けられるように
4-3 要求の作り方とマーケット不安
- 何をつくるか / 目的不確実性にどう対応するか
- スケジュール不安とマーケット不安の対称性
- 納期か機能か / プロジェクトバッファかスコープバッファか
- スコープバッファの成立条件と最初の顧客 : リリースポイントをまめにつくる → 目的不確実性の減少
- 意思決定者への確認は不安が伴うので避けたい / でも後ろ倒しにしちゃだめ
- ユーザーストーリーの作り方
- 機能が必要である理由が、文脈が切断されることを防ぐ
- INVEST ( Independent / Negotiable / Valuable / Estimable / Small / Testable )でストーリーの大きさを測る
- マーケット不安はいつ削減できるか
- 仮説検証では検証するのは「不確実なところ」、数値が思い通りになることをみてはだめ
- 少しずつ「目的不確実性」を削っていく
- 価値と不確実性 : 価値が高くリスクも高いところから着手する
- リーンキャンパスで仮説を作る (顧客の課題 → 顧客セグメント→独自の価値 → 解決策 → チャネル → 収益の流れ → コスト構造 →測定項目 → 競合優位性 )
- 仮説をつくって検証するの繰り返し。正解はないけど不安に向き合い続ける
4-4 スクラムと不安に向き合う振り返り
不安を知りチームマスタリーを得る
不安はなくならないが、チームのゴール認識のレベルが高くなると、チームが自分たちで不安をみつけ、検証することができるようになる
5.技術組織の力学とアーキテクチャ
5-1 何が技術組織の"生産性"を下げるのか?
- 生産性という言葉自体があいまい。
- 経営では 労働生産性 = 付加価値額 / 従業員数 。ただ、ソフトウェアだとそれははかりづらい
- 情報処理能力で測る : 情報処理能力 = 方法不確実性と通信不確実性への対処方法が導かれる
- 個人の総和が組織の能力にならない なぜなら調整コストが発生するから
- 完全な情報伝達が必要
- コンウェイの法則:コミュニケーションコストがかからない仕組みを選びがち
- エンジニア組織の情報処理能力を向上させるには?
- 権限の委譲と期待値調整
- 適切な組織・コミュニケーション・外部リソース調達の設計
- 全体感のあるゴール設定と透明性の確保
- 技術的負債の見える化
5-2 権限委譲とアカウンタビリティ
- 権限と責任は表裏一体/責任と権限の不一致
- 権限の不確実性 : 不確実なものを確実にする力があるか?
- 権限委譲のレベルとデリゲーションポーカー : 権限の認識を一致させるためのコミュニケーション
- 命令、説得、相談、合意、助言、尋ねる、委任
- デリゲーションポーカーのあと、 権限の可視化とコンセンサスボードを作成する
- 「言うたびにひっくり返される」のに「自分で考えろ」と言われてしまう
- 権限の衝突:共有する資源、相反する目的に折り合いをつける。衝突を最小限に抑えるのが組織の力
- 権限と組織設計:どうする?
- 明示的な権限と責任の委譲を行う → デリゲーションポーカー
- 権限と責任の不一致をなくす
- 権限同士の衝突を最小にする
- 権限の衝突解消レベルを最小にする
- 衝突、最小にするには、コミュニケーションパターンに注目
- 相互依存 / 事業とプロセス / 戦略
- 権限委譲と責任を果たすことができる組織構造、不断のコミュニケーションによる期待値調整 が情報処理能力の高い組織を生む
5-3 技術的負債の正体
- 開発時間の増大を引き起こすものとして言われるがあいまい
- 経営者にとって負債は資本: アナロジーとして適切じゃないかも
- 不可解な開発速度の低下
- ソフトウェアは変えられるところと変えられないところをつくる : ジェンガっぽい
- 一回機能を変化させない形で中身の構造だけを将来像に合わせて再構築したい
- 「機能を追加しないけど、障害が発生するリスクを背負って、時間を使いたい」
- Quick & Dirty の神話 : 汚いは遅い
- 技術的負債は「見えない」「マイナスの価値」
- 見えない = 機能から発見できない
- なら、見える化 = 理想システムの追加工数との差により表現する
- システムとシステムへの変更の 技術的負債は、 システムの変更コスト と理想システムの変更コストとの差
- この考え方を使うと、技術的負債への対策にどの程度コストを費やしてよいかはわかる
- トータルコストの削減が最も合理的出ないケースにどう対応するか?
- 費やされたコストにあわせて負も作り込まれると考えると、どこからどれくらいのコストをかけて改善していけばよいのかという大まかな判断ができる
- エンジニアと経営者の情報非対称性
- 見えるようにする = 非機能要件
- 経営者に見えるようにするには?
5-4 取引コストと技術組織
- 取引コスト理論 : 取引コストは「探索のコスト」「交渉のコスト」「監督のコスト」に大別される
- 取引コストによってい会社の境界線が決まる
- 外注管理 のコスト : 探索:外注選定 / 交渉 : 契約条件 / 監督 : 品質管理
- 取引コストは限定合理性から生まれる
- ホールドアップ問題 = 取引コストが見えないコストとして累積している場合。外注業者が一つだけ、など
- アーキテクチャと外注管理 : コアコンピタンスは内製するなどアーキテクチャーと外注の構成を一緒にする
- API による取引コストの削減
- 外注とPF戦略
- 社内における取引コスト : グループ間の調整コストが発生し、限定合理性が高くなってしまうことがある
- 機能横断チームの重要性
- 機能横断チームで取引コストを下げる
- 能力をひきあげるには 地理的に近い配置 / 十分な権限委譲 / 心理的安全性の高さ / 目的の透明性
- 探索 → 機能横断 / 深化 → 機能別
5-5 目標管理と透明性
- 従業員を人間としてあつかう「目標による管理」
- MBO
- 目標設定による主体性向上 / モチベーションアップ / 問題解決能力の向上
- セルフコントロールが重要 = 不可能でないが挑戦的な目標を従業員自ら設定し従業員が納得して達成に臨む
- OKRによる目標の透明化
- MBO だと限定合理性をうみかねない / 組織システム全体への視点
- OKR のもうひとつのポイント = 透明性
- 企業全体でひとつの木になるように目標を設定する
- 透明性とは 「情報が整合性をもって、組織内に正しく伝達されること」
- 透明性には信頼関係の構築が不可欠
5-6 組織設計とアーキテクチャ
- 取引コストとアーキテクチャ : システムは企業活動の情報流通の境界にシステム境界をつくってしまう
- 組織構造とアーキテクチャが一致していないと開発しにくくなってしまう
- 逆コンウェイ作戦 : ビジネスモデルと組織構造、アーキテクチャを一致させる
- 積極的な組織設計やコミュニケーション設計をビジネス戦略に基づいて行うことで、アーキテクチャ自身をよいものに変えていく
- マイクロサービスアーキテクチャ
- マイクロサービス化をいつおこなうのか
- それは不確実性と取引コストが逆転するとき
- 腐敗防止層で決断を遅らせる
エンジニアリングカンパニー
- 企業活動は、エンジニアリング
- 根本的な問題が「構造上の問題」であることに気づけば、対立は消える