合成の誤謬（ごびゅう）

度々この言葉を使っていますが、合成の誤謬とは、
「個々が合理的に正しい行動を取った結果、全体として不合理な結果を招いてしまう」
という現象のことです。

※もともとは経済学の言葉、というかジョン・メイナード・ケインズの言葉です。

開発プロジェクトにおける合成の誤謬

開発プロジェクト（特に大規模な）でも、この合成の誤謬は発生します。

個々のチームが、自分たちのミッションを効率的に遂行したからといって、
プロジェクト全体が効率的に回るとは限りません。
自分のチームの効率化が、全体の効率化の妨げになっているケースもあるのです。

しかし、各チームに「プロジェクト全体の効率化」を義務付けるのも酷です。
なぜなら、各チームは「自分たちの業務を遂行する」ことが第一の目的だからです。


なんて通じません！
つまり、開発プロジェクト全体の効率化を考えるのは、マネージャの仕事なのです。

２つの開発プロジェクトの事例

私は、２つの会社で大規模な開発プロジェクトに携わったことがあります。

どちらも似たような規模、開発期間、開発者数のプロジェクトだったのですが、
途中でマネージャのとった行動が大きく違いました。

ひとつ目の事例

大規模な開発プロジェクトには混乱が付き物です。
前述の通り、各チームが効率的に業務を遂行していても混乱は起きます。

私が携わったひとつ目のプロジェクトでは、
マネージャが２カ月間、プロジェクトを止めました。

今のまま、無理やり先に進めても、人員が増強される下流工程で、
より混乱が大きくなることが明白だったためです。

その間、開発者はほとんど実装作業を行わず、
次のフェーズのための準備、問題の精査・解決などを行いました。

ふたつ目の事例

ふたつ目のプロジェクトでは、上流工程の時点で、
下流工程におけるスケジュールの遅延が明らかになっていました。

私は、見積りを出し「今の体制・環境では、下流工程でスケジュールの遅延が起きる」
と上層部に提言をしました。

しかし、何も対策は取られず、プロジェクトはそのまま突っ走ってしまいました。

・・・結果どうなったか？
ひとつ目のプロジェクトは、最終的には遅延せず、
ふたつ目のプロジェクトは、最終的に遅延しました（ ´＿ゝ｀）

個人的な感想になりますが、ふたつ目の事例の方が、
現場のエンジニアの能力は高かったように思います。

しかし、プロジェクトを上手く遂行できたのは、ひとつ目のプロジェクトです。
何が明暗を分けたかと言えば、マネージャの判断というわけです。

開発プロジェクトが行き詰ったとき

個人の作業とは違い、大勢の人たちが相互依存しながら進めていく開発プロジェクトは、
安易に先に進めてしまうと、問題が肥大化してしまうことがあります。

開発プロジェクトの品質ゲート

開発プロジェクトには、品質ゲートと呼ばれるものがあります。

品質ゲートとは、各フェーズ（下図の場合、上流工程と下流工程）の間に設けられている
チェックポイントのことです。



マネージャは、単に製品品質の検査だけでなく、以下のようなことを行います。

• 問題を先送りせず、対策を取る
• 開発体制や開発プロセスを見直す
• プロジェクト遂行に必要な生産性を確保する

問題を先送りせず、対策を取る

大規模な開発プロジェクトでは、「大したことない」と思っていた問題でも、
放置すると「手に負えない」という状況になってしまうことがあります。

目先の効率化ばかり優先して、「目先の面倒な問題解決」を怠ってはいけないわけです。


『ラピッドデベロップメント－効率的な開発を目指して』（Steve McConnell 著）より

開発体制や開発プロセスを見直す

開発プロジェクトでは、基本的に下流工程に行くほど人数が増えます。
「受け入れ体制の準備」や「ドキュメントの作成」などを行っておく必要があります。

また、各チームにとっては面倒なルールや規制を設けることも必要になります。
ソフトウェア開発においては、「コーディング規約」や「コード修正の手続き」などが
該当します。

各チームにとっては非効率に思えても、「完全に自由化」するよりは、
プロジェクト全体として、長期的によい結果をもたらすことがあります。

プロジェクト遂行に必要な生産性を確保する