エンジニアリング組織論への招待④～学習するチームと不確実性マネジメント～

こんにちは。たけぶち(@k_takebuchii)です。

久しぶりに「エンジニアリング組織論への招待」（著：広木大地さん）について共有します！！

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

インプットの量が多いので、章ごとに重要なポイントをまとめていきます。今回は第四章「学習するチームと不確実性マネジメント」について。
第一章、第二章、第三章はこちら。

不確実性マネジメントとは？

第一章から繰り返し述べられていることですが、本書のテーマは「いかに不確実性と向き合っていくか？」です。

本書では不確実性を以下の3つに分類しています。

①方法不確実性：方法（HOWに関する）不確実性。「やってみないことには、どのように作っていくかわからない」というスケジュール不安に依拠している。
②目的不確実性：目的（WHATに関する）不確実性。「やってみないことには、何を作っていけばマーケットに受け入れられるのかわからない」というマーケット不安に依拠している。
③通信不確実性：継続的なチームマネジメント、コミュニケーションの不安に依拠している。
(p.142,181)

これらの不確実性を減らす手法として、本章では以下のものが紹介されています。

①方法不確実性：スケジュール予測と見積もりの手法
②目的不確実性：要求と仮説検証の手法
③通信不確実性：振り返りの手法
(p.181)

それでは、順に追ってみましょう！

スケジュール予測と不確実性

方法不確実性（スケジュール不安）に対しては、「納期に間に合うか、間に合わないか」という視点よりも、「スケジュール予測をいかに収束させていくか」という視点での対応が重要です。

プロジェクトの最初期に大まかにどれだけかかるものかの予測がつけば、実施の可否も含めて考えることもできます。それは3カ月なのか1年なのか、3年なのかという粒度でも十分な場合が多くあります。精度があまり高くなくても大いに経営判断をすることができます。そして、プロジェクトが進むにつれて、最善のケースと最悪のケースの幅がどんどんと狭まっていけば、その状況に応じて必要な経営判断をすることができます。
(p.191)

いかに、最善のケースと最悪のケースの幅（=不確実性）を狭めていくかがスケジュールマネジメントのポイントということです。

具体的には以下のような手法や事例が定量的に示されていました。

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

要求の作り方とマーケット不安

目的不確実性（マーケット不安）に対する向き合い方を考えるにあたっては、まず時間境界型プロジェクトと機能境界型プロジェクトの違いを確認する必要があります。

時間境界型プロジェクトは、ある時期までに一定の機能をリリースできることに価値があります。逆に言えば、リリースがある時期を過ぎると価値が落ちてしまうプロジェクトです。

一方で、機能境界型プロジェクトは、ある機能のパッケージが固まってリリースされないと仮説検証にならないようなプロジェクトを指します。仮説検証ができる最低限のラインのことをMVP（Minimum Value Product)と呼びます。

機能境界型プロジェクトをマネジメントするためには、「優先度の高い機能ごとに、提供できるレベルまで完了していく」ように運用する必要があります。必要に応じてMVPの基準をずらすことができるからです。

機能が完成して提供できるタイミングが多いと、リリース判断や仕様変更の意識決定はしやすくなります。（スクラム開発下では）プロダクトオーナーがプロダクトに触れる最初の顧客の役割を果たすことで、「目的不確実性（マーケット不安）」を減少させることができるわけです。

本章では上記以外にも、「目的不確実性（マーケット不安）を減少させる」ための手法が記されています。

・ユーザーストーリーの作り方
・価値と不確実性
・リーンキャンパスによる仮説の作り方

スクラムと不安に向き合う振り返り

以上の「いかに不確実性を減らすか？」という文脈の中で、現実を直視し不安に向き合えるようなチーム作りとして「スクラム」が取り上げられています。

本章では、スクラムにおける「プロダクトオーナー」「スクラムマスター」「開発チーム」の役割や、スプリントを中心とした各イベントについて記しています。

個人的に印象に残ったのは以下の部分です。

チームの中の「ゴール意識のレベル」が高くなると、そこから自然と不安の正体が明らかになっていきます。それは、多くの場合、ただ単に「わからない」というところから出発しているのです。チームが、自分たちが今わからないものを「どのようにしたらわかるようになるのか」「わかったものからどのようにしたら改善するのか」を意識できるようになると、自分たちを役割に閉じ込めること自体がおかしなことだと気がつくようになります。
(p.226)

ゴールを共有し、各チームメンバーが不確実性を減少させていくチーム。それが自己組織化されたチームに繋がっていくと感じました。

個人的な見解

不確実性マネジメントというと、「不確実性の高いものがボトルネックなら、それを集中的に削減する仕組みがあればよい」と考えがちです。

ところが、不確実性マネジメントでは「そもそも何が起こるかわからない」「わからないことが不明確」といった曖昧な課題を扱うので、課題を認識することすら難しかったりするわけです。

そのため、この章で取り上げている不確実性マネジメントでは、一貫して「不確実なものは不確実として、その上でどのように現状の認識とのギャップを狭めていくか」に焦点を当てていると感じました。

エンジニアリングに限らず、あらゆるプロジェクトに応用できそうです。

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

【関連記事】エンジニアリング組織論への招待①～思考のリファクタリング～

【関連記事】エンジニアリング組織論への招待②～メンタリングの技術～

【関連記事】エンジニアリング組織論への招待③～アジャイルなチームの原理～