増殖するマニュアル

いろいろなものを文書化するのは悪い事ではありません。文書化というのに抵抗があるならシステム化でもいいです。整然としていたチームも，人が増えればカオスは増えます。これはどうしようもない事で，カオスが大きくなるにつれて，それをもとに戻そうと文書化やシステム化が行なわれます。

今回Aチームは人がドンドン増えてきました。当初は１０人のチームだったのに，いつの間にか１００人のチームです。このプロジェクトのリーダのFさんは、カオスの増大に危機感を募らせ始めました。このままいくと，プロジェクトは迷走すると思い始めました。まずは，開発プロセスを見直しから始めました。
「まず，ここに機能説明書を書いてくれ！」
子羊たちは従いました。
「最後にリリースノートを書くのが大変なので，バグの各担当者はバグ修正したらリリースノートにその項目を追加してくれ」
子羊たちは従いました。
「デザインは大切なので、デザインができたらフィードバックのミーティングを開いてくれ」
子羊たちは，プロジェクトの終わりになってデザインができたので，フィードバックのミーティングを開きました。でも，フィードバックをもらっても、フィードバックをいれる時間はもうありません。
「機能説明だけでは不十分なので，機能説明の説明会を各機能ごと開いてくれ」
子羊たちは、何がたりないかわからないまま、説明会は無視しました。
「テストを始める前にテスト仕様書が機能仕様書とは別に必要だ。テスト仕様書がないとテストが始められないじゃないか。」
子羊たちは，せっせとテスト仕様書を書きました。テスターは開発者が作ったテスト仕様書をもとにテストしました。でも，開発者が作ったテスト仕様書は，すでに開発者がテストしたものなので，バグはほとんど見つかりません。
おー、なんと素晴らしいのでしょう。バグが少ないソフトウェアが出来上がった。

で、開発者は一体どこに何を書けばよくって、いつミーティングすればいいのでしょ？再び混沌が訪れそうになったので，チームリーダーのFさんは開発プロセスをマニュアルにしました。マニュアルにしただけでは開発者は無視しちゃうので，説明会も開きました。そうして，一人の子羊が一つの機能を実装するのに必要なプロセスが１００個になりました。プロセスが増えても，子羊たちは自分たちが何をやっているかわからず，何が必要とされているかも分からないままでした。

ちなみに，これは僕の働いている会社の話じゃないです。そもそも１００人もいないし。