「エンジニアリング」は不確実性を削減することです。
しかし、削減すべき不確実性がなんなのかわからなければ、それを管理することができません。
どこにどんな不確実性が宿っているかを深く観察する必要があります。
その方法を第4章で紹介しています。

第4章の備忘録としてまとめます。

書名：『エンジニアリング組織論への招待』
著者名：広木大地
出版社：技術評論社

▼関連記事

• 思考を変えて組織の問題を解決！『エンジニアリング組織論への招待』第1章【読書感想】
• メンタリングで成長を促す｜『エンジニアリング組織論への招待』第2章【読書感想】
• 開発を行うチームをどう構築していくか？｜『エンジニアリング組織論への招待』第3章【読書感想】

スケジュールマネジメントの基本

不確実性は3つに大別されます。
将来がわからないことから生じる「方法不確実性」と「目的不確実性」、他人とのコミュニケーションの失敗や不足によって生じる「通信不確実性」です。

どのくらいの時間がかかるそうなのかがわからないという、方法不確実性からスケジュール不安が生まれます。
いかに効率よくスケジュール不安とその発生源である「方法不確実性」を削減するか、というのがスケジュールマネジメントです。

現実的なスケジュールマネジメントのためには、次のような3要素が納期までに必要な期間だと考えることができます。

• 理想工期（工数人月/人数）
• 制約スラック
• プロジェクトバッファ

スケジュールマネジメントとは次の3つに注目して改善を行うマネジメントです。

• 制約スラックを再現する
• 見積もりの予測可能性をあげる
• プロジェクトバッファの消費を可視化し改善する

これらによって、できるかぎり早く「いつリリースされるのか」という時期の制度を上げていくのがスケジュールマネージメントです。

制限スラックを取り外すには

例えば、家を建てることを考えた時、基礎工事をした後でないと、柱を立てることができません。柱を建てた後でないと壁を作ることができません。
このように何かをしていくにあたって、これが完成していないと次の作業を進めることができないという、作業と作業の間の依存関係で発生してしまう無駄を「制限スラック」といいます。
制限スラックを削減するためには、「リソース制約」「依存制約」といった二つの制約を取り外していくことが重要になります。

リソース制約

リソース制約とは、「この作業は誰々にしかできない」という、いわゆる属人化した作業です。
リソース制約を削減するには、知識を要さなくても作業できる仕組みを作ることが必要です。

依存制約

依存制約は、作業と作業の間にある依存関係、つまり、2つの作業が同時並行で作業できないことによって生まれます。
この場合、クリティカルパスに含まれる作業の依存関係を解体するためのアイデアを出すことが重要です。

スケジュール不安の「見える化」

スケジュールの不安を削減するには、「間に合うか、間に合わないか」ではなく「スケジュール予測が収束していくかどうか」を管理するようにしなくてはなりません。
CCPMでは個別のタスクの見積もりには、暗黙に「一定割合のバッファ」が取られていることを前提しています。

たとえば、個別タスクには50％のバッファが積まれていると想定した場合、全体のバッファを取り除き、工期を一旦半分に短縮します。
そして元の工期の25％分のプロジェクトバッファを設定します。
その上で、プロジェクトの進捗率とバッファの消費率を定期的にプロットします。
このバッファがどのように消費されていくのかを経過観察することで、順調に推移しているかを検討します。

こうすることで、スケジュール不確実性の削減をプロジェクトバッファの消費という形で「見える化」することができます。
この方法の他に「多点見積り」があります。

マーケット不安を減少するには

プロダクトを成長させるために、本質的に納期よりも重要なのは「何を作るか」です。
この「何を作るか」という不確実性のことを「目的不確実性」といいます。

「何を作るか」が正しかったのか、間違っていたのかは、市場にリリースして初めて分かります。
そのため、この不確実性にはマーケットに対する不安が付きまといます。
この不安をマネジメントするためには、どのような機能をどのような順番でリリースしていけばよいかという優先順位付けの方法を考えていく必要があります。

たとえば、「顧客の課題」が本当に確かかということが一番の不確実性であれば、対象となるユーザーを集めてヒアリングを行います。
そして「サービスを理解して、利用してくれるのか」が大きな不確実性であれば、手書きでも良いのでUIの流れを作ってプロトタイピングツールに入力したものを用意して、顧客に触ってもらう方法があります。

このように最初に構築した仮説から、一番の不安材料となるものを洗い出して顧客に当ててみることで初めて仮説の不確実性が削減されます。
これはベンチャー企業における資本政策である「投資ラウンド」の概念とシンクロしています。

あとがき

む、むずかしい…。
ここにきて数式やら図表やら難しそうなデータが出てきます。半分も理解できず読み飛ばしました…。

読むだけではあまり理解できませんでしたが、ブログの記事を書くためにまとめていくうちに「本書が言いたいことがこれかな？」と少しずつわかるようになりました。アウトプットは理解を深めるといいますが、それをまさに単艦した瞬間です。
とはいえ、理解できていないところはすっ飛ばしているので時間を置いて改めて読んでみます。