第2回:要件定義という名の「宗教」を焼き払え。紙の山がシステムを殺す。

前回のコラムでは、IT業界を蝕む「人月商売」という腐敗した利権構造を告発した。今回は、その利権を正当化するための最大の「聖域」であり、最も多くの無駄と嘘を塗り固めている**「要件定義」という名の宗教**を解体する。

大手システム開発会社(SIer)との打ち合わせで、分厚いバインダーに綴じられた数百ページの資料を突きつけられ、「これが完成図です。合意の印鑑をください」と迫られたことはないだろうか。

断言しよう。その「紙の山」が積み上がれば上がるほど、あなたのシステムは死に近づき、予算は無慈悲に溶けていく。 革命の炎で、この無益な経典を焼き払う時が来た。

1. 「紙」を拝む司祭たち:ドキュメント信仰という名の免罪符

なぜ、彼らはこれほどまでに大量の資料を作りたがるのか。それは、彼らにとって要件定義書が「システムを正しく作るための設計図」ではなく、自分たちの身を守るための**「免罪符(しるし)」**だからだ。

大手SIerのコンサルタントやディレクターは、高額な報酬を受け取りながら、コードを一行も書かない。彼らの仕事は、クライアントの言葉を「IT用語」に翻訳し、綺麗にレイアウトされたExcelやPowerPointに落とし込むことだ。このプロセスに数ヶ月、数千万円が費やされる。

これは、中世の教会がラテン語の聖書を独占し、民衆に「理解できずとも、これを拝めば救われる」と説いた構図と同じだ。彼らはあえて難解な図表を並べ、クライアントに「よく分からないが、プロがこれだけ書いたのだから大丈夫だろう」という錯覚を植え付ける。彼らが守りたいのは品質ではない。「自分たちが介在しなければプロジェクトが動かない」という不透明な聖域なのだ。

2. 「紙」の上に真実はない:実装とテストだけが唯一の答えだ

システム開発において、最も残酷かつ不都合な真実はこれだ。**「実際にコードを書き、動かし、テストしてチェックするまで、何一つとして確定していない」**ということである。

大手SIerが作る要件定義書は、言わば「一度も現地に行ったことがない人間が想像だけで書いた地図」だ。実際に開発を進めてみれば、想定外の仕様漏れ、データ構造の矛盾、ユーザーインターフェースの違和感が次々と露呈する。

現場で起きるのは「ドキュメント通りの構築」ではない。泥臭い「バグとの戦い」と「土壇場の仕様変更」だ。紙の上でどれだけ精緻な合意を形成したところで、実際に動く画面を見た瞬間に「何かが違う」と感じるのが人間である。「実際に作って試す」というプロセス以外に、真実を突き止める術はない。 それを認めず、紙の上での空論に時間をかけるのは、単なる資源の略奪である。

3. 「切り戻し」の悲劇:ゴミを引継ぐための墓標

さらに滑稽なのは、多大な工数をかけて実装した挙句、致命的な欠陥が見つかって「切り戻し(元に戻す)」が決まった瞬間だ。その瞬間に、あの大層な要件定義書や設計書はどうなるか? ただの「燃えないゴミ」に変わる。

引継ぎドキュメントとしても、それらは全く役に立たない。後任のエンジニアがその資料を読んだところで、そこに書かれているのは「過去の妄想」であり、「現在の動いているシステムの真実」ではない。結局、後任もまたコードを読み解き、テストして、自分の目で真実を掘り起こすしかないのだ。

つまり、あの紙の山は引継ぎのためですらなく、「過去にこういう経緯で失敗しました」という言い訳を保存するための墓標に過ぎない。

4. 「大手への安心」の正体:サラリーマンたちの責任なすりつけあい

では、なぜこれほど無意味なプロセスが、今なおIT業界のスタンダードとして君臨しているのか。そこには、発注者・受注者双方の**「サラリーマンとしての責任のなすりつけあい」**という醜悪な力学が働いている。

  • 発注者(担当者)の心理: 「大手SIerに頼み、これだけ分厚い要件定義書に合意したのだから、失敗しても私の責任ではない。彼らがプロとして合意を求めてきたのだ」という保身。
  • 受注者(SIer)の心理: 「要件定義書通りに作りました。ハンコももらっています。問題が出たのはお客様の要件が漏れていたせいです」という盾。

彼らにとってのドキュメントは、システムを成功させるための道具ではない。**「失敗したときに誰が悪いかを決めるための裁判資料」**であり、責任を回避するための防壁なのだ。

「大手に任せれば安心」という言葉の正体は、品質の保証ではない。**「最悪、失敗してもお金で解決できる体力がある」「責任をなすりつける相手として格好がつく」**という、極めて後ろ向きな保身の論理である。発注者のビジネスの成功など、この「保身システム」の中では二の次、三の次だ。彼らはビジネスを加速させるどころか、責任回避のためにブレーキを全力で踏んでいるのである。

5. 革命システム「バイブコーディング」:ドキュメント宗教の処刑

革命システム「バイブコーディング」は、この「紙の山」と「責任のなすりつけあい」をすべてギロチンにかける。

これまでの開発が「要件定義(3ヶ月)→設計(3ヶ月)→実装(6ヶ月)」という長い巡礼の旅だったのに対し、バイブコーディングは**「対話=実装」**という即時性を実現する。

  • 「紙」で合意するのではなく、「動くもの」で対話する。
  • 数ヶ月後の納品を待つのではなく、毎日その場で実装し、テストし、チェックする。
  • 責任をなすりつけるための資料を作る暇があるなら、一秒でも早く価値あるコードを書く。

バイブコーディングが1/10のコストを実現できる理由。それは、魔法を使っているからではない。サラリーマンたちが保身のために浪費していた膨大な「裁判準備費用(ドキュメント作成と調整)」をゼロにするからだ。

結び:偶像崇拝を辞め、現実を直視せよ

親愛なるビジネスリーダー諸君。

重厚な要件定義書を抱えて安心するのは、もう終わりにしよう。それは、沈みゆく船の上で免罪符を買い集めているのと同じだ。

切り戻しが起きても、金で解決できるからいい? そんな考えは、ビジネスの機会損失という最大のコストを無視している。あなたが本当に欲しかったのは、責任の所在を明確にするための「紙の山」か? それとも、ビジネスを加速させる「生きたシステム」か?

旧世界の「ドキュメント宗教」を焼き払った跡地には、無駄のない、筋肉質な、そして圧倒的に高速な新秩序が生まれる。

革命は、あなたの「決別」から始まる。


「その印鑑は、システムの完成を約束するものか? それとも、あなたのクビを守るための盾か?」

次回、第3回は「10人のエンジニアは、もういらない。バイブコーディングがもたらす『個の軍隊』」。多重下請け構造という名の封建制度を解体し、真のプロフェッショナルがもたらす破壊的生産性を暴く。