『プログラマの慢心。IT業界の現状。』を読んで
ブラックジョークらしいのだが、完全に否定できない。
どこかしらに心あたりがあるからだ。
...と言う事ですので、より実情に沿った感じで、ソフトウェア開発にありがちな無限ループ。
1.仕様書通りにプログラマがコードを書く。仕様書は正しいと信じている。
1. プログラマがコードを書く。バグはないと信じている。
2.製品テストが行われ、10のバグと10の仕様漏れ、10の新たな要望が発生する。
2. 製品テストが行われて30個のバグが発見される。
3.プログラマは10のバグを直し、10の仕様漏れは調整が必要と放置。10の新要望は全くやる必要が無いとやっぱり放置。
3. プログラマは20個のバグを修正し、残り10個はバグではないとテストチームに説明する。
4.再び製品テストが行われ、バグ修正の結果、15の新たなバグが発見される。さらに10の仕様漏れと10の要望が実現されないとリリース出来る水準にならないと言う話になる。結局、プロジェクトリーダーが折れて追加案件が20増える。
4. 再び製品テストが行われ、バグ修正の結果5つの機能が正しく作動しなくなっていることが発見される。さらに15個の新たなバグが発見される。
5.上記の工程3、4を数回繰り返す。
5. 上記の工程3、4を数回繰り返す。
6.途中から追加機能が増えたにも関わらず、当初のボリュームに基づいて作られたスケジュールは変えられず、中途半端なままリリース、出荷が行われる。
6. マーケティング部が楽観的な開発計画に基づいた製品発表を行ったことや、営業部からの圧力により、製品が時期尚早に出荷される。
7.ユーザにより100のバグと、数多くの「使えねぇ」と言う声、そして、肝心の売り上げ自体芳しくないと言う状態になる。
7. ユーザにより100個のバグが発見される。
8.嗅覚が鋭いプログラマやSEは、この焦げ臭いプロジェクトから逃げ始めるか、出来なければ転職する。
8. プログラマが他社に転職する。
9.残念ながら逃げられなかった現プロジェクトメンバーに加え、新たなメンバーを加えた急ごしらえのチームが編成されるが、新旧メンバー間のコミュニケーション不足と、新メンバーの理解度のなさ、そして無茶なスケジュール等々の原因から、新たに500のバグが生まれる。
9. 緊急で新たに開発チームが組織され、ほぼすべてのバグを修正する。その過程で新たに500個のバグが生まれる。
10.プロジェクト全体の歪みから、リーダー格のメンバーが次々と過労やうつ病により休職する。
10. テストチームのエンジニアが過労やうつ病により休職する。
11.構造的な問題を解決するために、全体的に手を入れ、ソフトを作り直すべき、と言う結論に達し、現状やその業種自体に詳しくない、新たなメンバーが採用される。
11. 構造的な問題を解決するために一から開発し直すべきだという結論に達し、新たなプログラマが採用される。
12.現状や業種に詳しくない新たなメンバーが仕様漏れを起こしつつ仕様書を作成する。
1.仕様書通りにプログラマがコードを書く。仕様書は正しいと信じている。
以後、無限ループ。