IT業界にいる人に向けた内輪ネタなんですが、関係ない人でも結構笑えるかと思います。
以下のキャプションは僕が勝手に付けました。IT業界人でない人のために日本語でも補足を書いておきますね。
To all who work in IT industry.
1. How the customer explained it.
=> Requirement definition by customer? Forget it, they are no professional.
顧客の求めるものをソフトウェアで構築するのが基本ですが、どんなものが欲しいですか？といった漠然とした質問をして要件定義を任せると三段ブランコのような用を足さないものをリクエストしてきたりします。
2. How the project leader understood it.
=> Why do our projects always underestimate the workload? This is the reason.
プロジェクトマネージャーは難しいことがわからないので、本当の要件に全然足りてない機能でスコープを決定してしまいます。問題はこの人が費用見積もりの責任者なところで、プロジェクトが赤字になる原因はまずここにあります。
3. How the analyst designed it.
=> Our brilliant system architect employs unique, cutting-edge, state-of-the-art technology, regardless of feasibility.
今の僕のポジションもこれに近いですが、最新技術に詳しい人ほど元々何を求められていたのかをすっかり忘れて自分の使ってみたい技術に突っ走ります。その点僕は技術に全く疎いので安心！（←ポジティブ思考の弊害）
4. How the programmer wrote it.
=> The specification says a tree, a rope and a swing. So, what's wrong with my code?
日本のプログラマーは優秀な人が多いのでそんなにひどくありませんが、海外のプログラマーは完全分業制で仕様書に書かれていないことまで気を回してくれると期待してると痛い目に合います（経験談）。
5. What the beta testers received.
=> Yeah, maybe better killing myself than testing it...
期限に追われて開発したソフトウェアの最初のテストはまー死にたくなるくらいひどいものです。
6. How the business consultant described it.
=>Saying is one thing, who cares the doing part? Not me!
これも日本では技術も把握してるSE（System Engineer）がカバーしてるのでそこまで問題になりませんが、海外ではビジネスアナリストとかビジネスコンサルタントが顧客の業務要件をまとめて開発に渡す形を取ることがほとんどです。で、そいつらが技術をわかってないと顧客にドンドン夢のような提案をして期待を膨らませるので、後でケツ拭くのがすごく大変になります。
7. How the project was documented.
=> Can't find the document when you need it? No such thing exists!
設計書が顧客レビューの後に承認されるまでは開発に着手しないのが原則です。が、最近はAgile開発といって先に動くソフトウェアを作って改良していく方法が主流なのでドキュメントが後回しになるか、ひどい時にはそんな面倒なもの一切書かれないことも。いざ問題が起きて「なんでこんなふうに動くようにしたの？」と過去を振り返る段階になって初めて絶望を味わいます。
8. What operations installed.
=> Right first time? Never heard of it.
あんなにテストしたのに、初回本番導入で一部しか動かない！なんてことで同様していたらこの業界では生きていけません。徐々に良くしていけばいいんです。
9. How the customer was billed.
=> Because it includes overhead cost, T&L, feasibility assessment, etc. etc. (list continues forever)
固定金額（Fixed Price）で受注したプロジェクトは別ですが、T&M（Time & Material）で請求が発生するプロジェクトでは顧客が請求金額を見て腰を抜かすこともしばしば。プロジェクトマネージャーはなぜその金額が請求対象なのか？が説明できるネタを探すことに日々血眼になってます。
10. How it was supported.
=> Have you turn it off and on again?
品質が悪ければ悪いほど稼働後のサポートが重要ですが、タイトなスケジュールで回してるプロジェクトでそんな将来のことを考えてる余裕はありません。
11. What marketing advertised.
=> Start with the letter i, whatthefuckever it is.
ソフトウェア業界のトレンドですね、「i-なんちゃら」って名前付けるの。僕も「i-wannabe」に改名したらちょっとトレンド先取りしてる感じがしますかね？
12. When it was delivered.
=> Where's the passion when we started the project?
ソフトウェアプロジェクトって開始からリリースまでに1年以上かかることも多いので、リリースする頃にはその業務を取り巻く状況が変わってて不要になったり、全然要件を満たせなくなったりすることもあります。「機を逸する」って本当に恐ろしい・・・
13. What the customer really needed.
=> Remember the picture #1.
ほら、やっぱり。（笑
14. What the digg effect can do to your site.
=> Did you know that there are also 'bury' button?
この「digg」ってサイト、実はこのマンガで初めて知りました。「いいね！（digg）」ボタンと「悪いね！（bury）」ボタンでサイトを評価してランキングするものらしいんですが、一般に公開するシステムなんかだと勝手にガンガン評価されてて、気が付くと炎上。。。みたいなこともあるらしいです。
15. The disaster recover plan.
=> Itself is a disaster.
アメリカの911テロ以降にIT業界で盛り上がりを見せたDisaster Recovery Plan（DRP）とかBusiness Continuity Plan（BCP）と呼ばれるもので、例え本番システムが壊滅してもバックアップシステムで業務が継続できるようにする、というのがコンセプトです。でも、本番システムと完全に同期を取るのって難しくて、結局「似てないモノマネ」みたいなものしか用意できてない会社は山のようにあります。
さて、今回IT業界の魅力を紹介することでこれからIT業界を目指してみよう！と思った方も増えたと思いますが、人を信じない力、3日徹夜しても倒れないな体力、壊れてもいい家庭をお持ちの方であればきっとサバイブできるはずです。
Welcome to IT industry!ヽ(ﾟ◇ﾟ )ﾉ