エンジニアリング組織論への招待 の私的まとめ

エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング

昨年読み「経験から感じていたことが、言語化されてまとまっている素晴らしい書籍だ！」と感じました。 が、「具体的に何を学んだか？」と聞かれると今ひとつ心もとない状態だったので、自分の言葉でまとめ直してみました。

コミュニケーション能力と不確実性

コミュニケーション能力とは「コミュニケーションの不確実性」を減少させ、「組織内で連続的に発生してしまう不確実性の負のループを止めることができる」力を指す。

不確実性の発生源は2つ、「未来(環境不確実性)」と「他人(通信不確実性)」である。 通信不確実性はさらに下記の3種に分けることができる。

1. 他者理解の不確実性：他人や事象を完全には理解できない。
2. 伝達の不確実性：コミュニケーションが意図通り相手に伝わるとは限らない。
3. 成果の不確実性：仮に意図通り理解されたとして、発信者の予想通りに行動するとは限らない

上記を念頭に置いた上で、少しでも不確実性を減らそうとすることによって物事を前に進めることができる。 しかし現実では、人は不確実性に向き合うことに不安を覚え、向き合うことを避けてしまうことから様々な問題を引き起こしてしまう。

エンジニアがソフトウェア・製品に向き合うように、人・チーム・組織に向き合い、「どうしたら効率よく不確実性を減らしていけるか」を考えつづけることで優れたチーム・組織を作ることができる。

組織は何らかの曖昧な指示を入力とし、具体的な作業に置き換えて少しずつ完了させていくことで、プロジェクト・プロダクトを前に進める活動を断続的に行なっているといえる。組織形態は下記の2つに大別することができる。

1. マイクロマネジメント組織：具体的で細かい指示を指示者が出し、指示を受けたものがその通りに実行する組織。
2. 自己組織化された組織：抽象的で自由度のある指示を指示者が出し、指示を受けたものが考えて行動する組織。

マイクロマネジメント組織の能力は指示者に律速されてしまう。 指示者の不在で仕事が回らなくなり、指示を受ける人が増えるにつれ指示者の負荷が高まり、指示を受ける側では不確実性を大して減らすことができない。 従って不確実性を効率よく減らしていける組織を目指すのであれば自己組織化された組織となる必要がある。

またコミュニケーションの不確実性を効率よく減らしていくには下記に留意する必要がある。

1. 論理的思考の盲点
2. 経験主義と仮説思考
3. システム思考

「論理的思考の盲点」とは、人は論理的に考えていると自分で思っていても、その時の感情や誤った仮定に影響されて論理的でなくなることがあることを指す。 自分の認知がどういう時に歪むのかを把握し、客観視することでネガティブな感情の拡大再生産を食い止める。

「経験主義と仮説思考」は「行動することで「経験=情報」を得る。結果を観察し、結果を踏まえて問題解決を行う。部分的な情報しか得られないかもしれないが、全体像を想定し問題解決を進める。」という考え方である。 経験主義ではコントロールできるものを操作し、観測できるものの結果を見ることで前に進まなければならない。 面白いことに人は不安を感じると他社の気持ちなどコントロールできないものをコントロールしようとする。

「システム思考」は要素同士の関係性に注目して問題の構造を解き明かす考え方である。

メンタリング

メンタリングとは対話を通してメンターの思考力を相手(メンティ)へ一時的に貸し出し、相手の歪んだ認知を補正し、次の行動を明確にし、成長を促す手法である。 メンタリング後は「高い目標」が明確になり、その目標と今の自分の行動・習慣がどのように繋がっているかが明確にイメージでき、そのために何をすればよいかが明確になっている状態を目指す。

メンタリングに似た手法にティーチングがあるが、これは他者による説得である。 人は自分で見つけた答えに対して高い納得感と自己効力感を得て、積極的な解決行動を取ることが期待できる。 そのためメンタリングではメンティに自分自身の問題だと自覚させる。

メンタリングでは下記の3つを実施する。

1. 傾聴
2. 可視化
3. リフレーミング

まずは相手の話を「傾聴」し、相手が今の状態になった理由を理解する。 傾聴で必要なのは「同感」ではなく「共感」である。

次に相手が問題を客観視できない状態を可視化してあげて、「問題と私たち」に構造を変える。 相手が問題を客観視できない状態にあることは下記のキーワードに着目することで気がつくことができる。

• こちら系：この会社は…この人は…、一体感を持っていない時に出てくる。
• あちら系：あの部署は…あの人は…、相手は自分と違う、線引きされた異なる存在として認識している。
• 極端系：いつも…すべて…絶対に…、ゼロイチで物事を捉えている。間の状態が認識できていない。
• すべき系：普通…〜すべき、〇〇でないとならないという考え方が頭にあり、そこに限定して考えている。
• 決めつけ系：どうせ…、感情的になっている。事実を捉えられていない。

相手の問題を一足飛びに解決することはできない。バグの原因を切り分けするように、話を聞きながら少しずつ問題の範囲を再定義(リフレーミング)して限定していくとよい。

メンターの役割はメンティを自律的な問題解決に導くことであり、メンティの問題を解決することではない。

メンタリングでは次に取るべき行動がはっきりするようにする。下記を参考に行動を設定すると良い。

• Specific : 具体的である
• Measurable : 測定可能である
• Achievable : 達成可能である
• Related : メンティの課題と行動が関連している。
• Time-Bound : 時間制限がある。いつまでにやるかが明確になっている。

プロダクト開発とアジャイルな状態

プロジェクトとプロダクトは似た文脈で使われることが多いが、目的が異なる。 プロジェクトは「始まり」と「終わり」があり、「成果を出して終了する」ことが目的である。 最大のリスクは「終了しないこと」であるため、スケジュールに対する不確実性を減少させるように取り組む。 プロダクトは「継続的に収益をあげ」、「終了しないこと」が目的となる。 最大のリスクは「終了してしまうこと」であるため、市場に対する不確実性を減少させるように取り組む。

ソフトウェア開発の前提が変化し、プロジェクト型開発からプロダクト型開発への変化が迫られている。 ウォーターフォールはどう作るか(方法不確実性)と何を作るか(目的不確実性)の削減を目的としていた。 アジャイルはさらにチームが同じゴールに向かって動けているか(通信不確実性)の削減を目的としてる。 アジャイル開発は従来の開発よりも広いスコープを対象として、開発チームを捉え直す動きと言える。

アジャイルとは「チームが環境に適応して、不確実性を最も効率よく削減できている状態」のことである。自己組織化とも呼ばれる。自己組織化は下記が達成されているかを指標に判断することができる。

• 情報の非対称性が小さい
• 認知の歪みが少ない
• チームより小さい限定合理性が働かない
• 対人リスクを取れていて、心理的安全性が高い
• 課題・不安に向き合い、不確実性の削減が効率よくできる
• チーム全体のゴール認識レベルが高い

アジャイルな開発では下記に取り組んでいる。

• 不安に向き合う
• 少人数の対話を重視する
• 役割を分けない
• 経験したことのみを知識に変える。
• 意思決定を遅延する
• 価値の流れを最適化する

アジャイル開発のフレームワークで定義されているプラクティスは実行さえすれば問題が解決するものではない。 チームの背景・コンテキストが異なっても有効な銀の弾丸は無く、自分たちのやり方や役割を見直し変えていく「脱構築」機能をチームが身につけられるようになることを要求している。

スケジュールマネジメント

スケジュールマネジメントは、いかに効率よく「スケジュールに対する不安」とその発生源である「方法不確実性」を削減するかを考えることである。 具体的にはスケジュール通り終わるか、少し伸びてしまうかの間の幅をどのようにして見える化し、効率よく削減できるのかを考え、経営と現場の間で進捗に関して透明性を保つことを継続的に行う。

以下の3つに注目して進めると良い。

1. 制約スラックを削減する。
2. 見積もり予測可能性を上げる。
3. プロジェクトバッファの消費を可視化し改善する

「制約スラック」とは作業に順番があったり、特定のスキルを持つ人に依存している状態を指す。 これらを削減し、作業に取り組むにあたっての制約を取り除く。

見積もり予測を上げる方法はいくつかある。 不確定性の大きいタスクは分解する。初めての取り組みであれば概念検証をプロトタイピングで行い、あたり検討をつける。 絶対見積もりにするとノルマ・約束になってしまうため、相対的に規模を見積もるようにする。 また小さくスプリントを繰り返すのも良い。開発サイクルを決め、人員を固定し、制約スラックが発生しにくいように要件を切っていくことで再現性の高い開発ができるようになる。

最後にバッファは作業・タスクごとに個別に取るのではなく、全体でまとめて1つのバッファを持つようにする。 これによりスケジュール不確実性の削減をプロジェクトバッファの消費という形で見える化できる。

ユーザーストーリーは「どのような人が」「何ができる」「そのことでどのような感情になる」の3点で構成する。 誰が、何のためにという文脈を最終顧客の観点から記述することで思い込みを排除する。

開発に着手できる状態になっているかを判断するフレームワークにINVESTがある。

• Independent：独立している。他のストーリーと依存関係がない。
• Negotiable：交渉できる。実現可能方法について交渉の余地がある。
• Valuable：価値がある。ストーリーを完了させることでユーザに価値を届けることができる。
• Estimable：見積もりできる。ストーリー完了までに必要な作業、要する時間が見積もれるだけの情報がある。
• Small：小さい(≒適切な大きさである)。固定期間のスプリント内で回していくのにちょうど良い。
• Testable：検証可能である。ストーリーが完了したことを客観的に判断できる。

生産性を出すための組織編成

生産性の定義は「投入したリソースに対してどれだけの付加価値を得られたのかを測ったもの」である。 問題は個人の能力の総和が必ずしも組織全体の能力とはならない点である。 組織がメンバの能力を完全に引き出すためには、「1.その中で行われるコミュニケーションが100%の完全な情報伝達である」、「2.構成員が完全に同一の目的・思惑で動いている」必要がある。現実にはどちらも前提条件として成り立たない。 従って組織拡大を行う際は、誰が、誰と、どんなコミュニケーションを、どの頻度でとるようにするかという設計を行い、コミュニケーションコストを一定に保つように組織を分割していく必要がある。

具体的には下記に留意する必要がある。

• 権限の委譲と期待値調整
• 適切な組織・コミュニケーション・外部リソース調達の設計
• 全体感のあるゴール設定と透明性の確保
• 技術的負債の見える化

メンバを職能で組織を分けると組織間でのコミュニケーション・取引コストを増大させてしまう。 ある事業やプロダクトに対して、職能・職種を横断してチームを組成することで、コミュニケーション・取引コストをできる限り下げたチームを作ることができる。書籍では機能横断型のチームと呼んでいるが、アジャイル開発の分野では「クロスファンクショナルチーム」や「フィーチャーチーム」と呼ばれていることが多い。

複数のチーム・チームメンバを一つのゴールに導くには目標設定と管理が欠かせない。 旧来の組織で広く使われている目標管理(MBO:Management By Objectives)は本来、「目標による管理、およびセルフコントロール」であり、自ら立てた目標を達成していくことによるモチベーションの内的動機付けを重視していた。 しかしいつの間にか後者が抜け落ちてノルマ感だけが残ってしまった。

組織全体への理解がなければ誤った最適化が進んでしまうため、近年ではOKR(Objectives and Key Results)が広がっている。 OKRの重要なポイントは透明性の重視にある。目標設定を通じて、従業員一人一人が組織全体を見渡して、自分が何のために仕事をしているのかを深く理解するのがOKRの果たす重要な役割である。

感想

まとめた結果でも1章の分量が多く、不確実性の考え方が一番学んだことなのだなと思う。2章以降はマネジメントに関する知識が広範に網羅されているが、どこかで聞いた話も多く、単独で理解を深めるには少し足りないし、他資料へのポインタとするには引きにくい印象を持った。

マネジメントに関わる人には読んで欲しいが、開発者などに紹介するにはまとめた内容+他書籍へのポインタとするのが良さそう。