「エンジニアリング組織論への招待」をチームに活かす2
1. 今回読んだ本
タイトル: エンジニアリング組織論への招待
著者: 広木 大地
発行所: 技術評論社
2. 概略
このnoteは、エンジニアリング組織論に関する知識を、私の会社にいかに活かすかをまとめたものである。
note用に体裁を整えていないため、一部読みにくい部分があるかもしれない。
3. 知識・方法論
3.1. メンタリング
3.1.1. SMARTの原則
メンタリングにおいて、「言葉の真意は相手に正しく伝わらない」という前提のもとで、少しでも解釈の差を減らすフレームワーク。以下の5つの原則がある。
Specific（具体的な）: 解釈が一意に定まるように
メンターとメンティで、解釈が一致している必要がある。
解釈が一致しているかは、行動でしか観測することができない。
Measureable（測定可能な）: 結果の測定方法の合意
Achievable（到達可能な）: 達成可能な範囲で
Related（関連した）: メンティが課題と対策を説明できるように
Time-Bound（時間制限のある）: いつまでに
3.1.2. コントロールできる領域とできない領域
人の成長サイクルは、メンターがコントロールできる領域とできない領域がある。メンタリングでアプローチするのは、コントロールできる領域
行動: コントロールできる
習慣: コントロールできる
能力: コントロールできない
成果: コントロールできない
3.1.3. フォースフィールド
人の行動は、「促進する要因」と「阻害する要因」のバランスによって決定される。
促進要因:
痩せたいという思い
痩せた結果の実感
周囲からの評価
阻害する要因:
友人との予定や飲み会の誘惑
周囲からのからかい
上記は、ダイエットのフォースを書き出したフォースフィールド。促進要因が短期的に観測できないことに問題があると考え、毎日体重計に乗るなどの対策が考えられる。
3.1.4. 結果に対するフィードバック
セクション3.1.3.のフォースフィールド等によって、メンティが課題と向き合えているが結果が伴わないことがある。
このような時は、叱責するのではなく、潜在的な阻害要因があると考える。
3.1.5. ゴール認識
メンターの最終目標は、メンティがレベル4のゴール認識を持つことである。レベル4の状態をセルフマスタリーといい、自分自身で目標に向かって率先的に学習していく。
レベル0（願望）: 〜だったらな
レベル1（義務）: 〜にならないといけない
レベル2（欲求）: 〜になりたい
レベル3（意思）: 〜になるぞ
レベル4（必然）: 〜になっている
セルフマスタリーの例: 本田圭佑選手
「僕は大人になったら、世界一のサッカー選手になりたいというよりなる。世界一になるためには、世界一練習しないとダメだ。だから、今、僕は頑張っている。」
3.2. アジャイル開発
3.2.1. プロジェクトマネジメントとプロダクトマネジメント
マネジメントとは、対象となる〇〇の資源・資産・リスクを管理し、効果を最大化する手法である。
プロジェクトマネジメント: プロジェクトが期限内に終わることにフォーカスする
スケジュールに対する不安がある
プロダクトマネジメント: プロダクトが継続的に効果をもたらすことにフォーカスする
マーケットに対する不安がある
3.2.2. チームマスタリー
チームが総体として、チーム自体のゴールに対して高い「ゴール認識」を持ち、チーム自体がチームをメンタリングしている状態を目指す。
必ずしも、個人がセルフマスタリーを習得する必要はなく、支え合いの結果、チーム全体としてチームマスタリーを得れば良い。
3.2.3. アジャイルな状態
アジャイル開発とは、チームが効率よくアジャイルな状態になるための方法である。
アジャイルな状態:
情報の非対称性が小さい
認知の歪みが少ない
チームより小さい限定合理性が働かない
対人リスクを取れていて心理的安全性が高い
課題・不安に向き合い不確実性の削減が効率よくできている
チーム全体のゴール認識レベルが高い
3.2.4. SECIモデル
組織において知識が獲得されている過程を示している。全ての過程が実施されることで知識が獲得される。
共同化: 暗黙知の普及
経験や思い、信念のストーリーテリングが必要
表出化: 暗黙知から形式知へ
メンタリングによって表出
連結化: 形式知の普及
共有の場が必要
内面化: 形式知から新たな暗黙知が生まれる
実践を通して生まれる
3.2.5. ダブルループ学習
組織学習のサイクルには2つのタイプがある。
シングルループ学習: 過去学習から「ものの見方・考え方」に基づいて、改善を繰り返す学習
ダブルループ学習: シングルループ学習に環境の不確実性を取り込み、前提を変えていく学習
スクラム開発も、ダブルループ学習が根底にある
「Howに関する学習ループ」と「Whatに関する学習ループ」を繰り返す。
3.2.6. リーンソフトウェア開発
以下3つの贅肉を減らすことで引き締まったソフトウェア開発を実現する。
ムダ: 付加価値のないもの
ムラ: 不均一によるばらつき
ムリ: 過負荷な労働、不合理なストレス
以下7つの原則によって実現される。
全体を最適化する: 目的を明確にして必要なことに労力をさく
ムダをなくす: 顧客に価値のない機能やタスクをなくす
チームに権限移譲する
学習を強化する: 経験的に得られた知識のみを重視し、不確実性を減らす
早く提供する: 目的の不確実性を減らす
品質を作り込む: 継続的に品質を確認する
決定を遅らせる: 必要な情報が揃ってから、意思決定をする
3.2.7. アジャイルソフトウェア開発宣言
前項に価値があることを認めながらも、以下を重視する。
プロセスやツールよりも、個人と対話を
包括的なドキュメントよりも、動くソフトウェアを
契約交渉よりも、顧客との協調を
計画に従うことよりも、変化への適応を
3.2.8. プリンシパルエージェント問題
これまで「プロセスやツール」「包括的なドキュメント」「契約交渉」「計画に従う」ことが重視されてきたのは、発注と受注の関係が起因している。
発注者と受注者には情報の非対称性があり、責任の境界を作る必要がある。
受注者の責任は、言われた通りに完成物を作ることである。「指示通りのものを作ったことの証明」のために防衛的な振る舞いを取ることを、プリンシパルエージェント問題という。
この状況は、発注者・受注者ともに不幸な結果を招く。
この課題への問題解決こそ、以下のアジャイルソフトウェア開発宣言である。
個人と対話を: 情報の非対称性へのアプローチ
変化への対応を: 計画に縛られない
4. 思ったこと
4.1. メンタリングと組織マネジメント
メンタリングの技術を組織に適応させることが、組織マネジメントではないか
4.2. 目的に最短でアプローチする
アジャイル開発とは決まった開発フレームワークではなく、アジャイルなチームを構成する方法論である。
アジャイルなチームとは、目的に対して最短でアプローチできることである。
アジャイルを取り入れる、取り入れないではない。「チームとしてどうすべきか」という基本的な問いに対して、コミットすることが大切である。
4.3. フィーチャー組織の矛盾
既存機能発展Gと、新規機能Gに分割する。
情報の非対称性による部分最適の防止のために、目標を共有する。
それぞれが目標に基づいて行動する時、もう片方にも影響を与える。これは部分最適と捉えることができる。
部分最適の防止のために逐次共有するなら、組織分割の意義がない。
この問題解決の鍵は、「情報の非対称を完全に排除することはできない」である。情報の非対称性をどこまで許容するかを考えるべきである。
4.4. 情報の区分け
情報の非対称性に伴って、以下のような疑問を持った。
bizとdevの区別は必要なのだろうか
bizが理解しなくても良いdevが存在する。
情報の非対称性は良くないのではないか。
この疑問解決の鍵は、情報の区分けではないか。
全員が理解すべき情報: 情報の非対称性を排除すべき
一部だけが理解すればいい情報: 情報の非対称性があって良い
大切なのは、この情報の区分けにもコミュニケーションが必要であること
5. チームに活かせること
5.1. ダブルループ学習とリーンソフトウェア開発
レトロスペクティブにおいて、不必要なものを排除する。
メタワークは、前提によって価値が変わる。
チームで部分最適が発生している: 目標の共有というメタワークに価値が生まれる。
チームで部分最適が発生していない: 目標の共有は必要ない。
今まで価値のあったメタワークは価値がないものに変わる可能性がある。
ダブルループ学習は、「環境の不確実性、すなわち前提の変化を考慮すべき」という主張である。