IT現場では必ずと言っていいほどトラブルが起きます。
「バグのないシステムなどない」という言葉があるぐらいなので、
「トラブルがない現場などない」というのがIT現場では常です。

今回は、そんなIT現場のトラブルをガンダムで学んでみようと思います。

ガンダムに関する専門用語が多々出てきます。
出来るだけWikipediaにリンク貼りますが、わからない場合は
Wikipediaで検索するか、周りのガンダム詳しい人に聞いてください(・ω<)

兵の不足により一般人までが戦争に駆り出される

これ、ガンダム全般に言えることですね。
ファーストガンダムを引き合いに出すと、いきなり第一話からこういう展開です。

IT現場でも同じことが、よく（必ず）起きます。
「要員が足りないので人を増やしてください！エンジニアであれば構いません！！」
ってような感じですかね。

エンジニアと言っても、技術分野がいろいろあるので
その現場で使われてる技術に精通してないエンジニアを連れてきた場合
教育工数がかかってしまい、さらに炎上というパターンがあります。

ガンダムでは、兵の不足を補ったのが一般人でした。
ZZガンダムでは子供がほとんどでした。。。
そんな中でまともな戦闘（開発）が出来るはずなく大変な苦労をするわけですね。

ガンダムでは終盤になると、そんな一般人（子供）も立派な兵士となって
戦場の第一線を張ってたりしたのですごいなと思います。
→もちろん死んじゃった人もいたわけですが。。。

 νガンダムの納期が間に合わない

「νガンダム 逆襲のシャア」の冒頭、主人公のアムロ・レイが乗る予定だった
新型のガンダム「νガンダム」の納期が遅れてしまいます。

そこで、アムロは調整がまだの機体に技術担当のチェーンを乗せて戦場に行ってしまいます。
→ここらでアムロが「エンジンに火を入れろ」とか言うんですが、このセリフを開発現場で一度使ってみたいと思っています。

その結果、チェーンは戦場に行くことになり戦死します。
その結果というのはちょっと無理矢理な気がしますが、戦場に行かなければ死ぬことはなかったかなと。。。

そもそもなんでνガンダムの納期が遅れた原因ってなんだったのか？というと
サイコフレームという技術の、いわゆる「仕様変更」が原因だったのです。
あぁここでも開発現場と被りますね。。。
→個人的に仕変はあって仕方ないと思いますが、その処理方法が往々にしてまずいと思っています。

開発現場でも、納期の遅れは死を意味することが多々あります。
特に業務系システムの場合そこに「稼働延期」という言葉は存在すらしない時があります。
チェーンのように戦死しないように納期はしっかり守りましょう。。。

ガンダムを簡単に強奪される

ガンダムシリーズをいろいろ見てる方であれば、うんうんと言うと思います。
ガンダムというものはよく強奪されます。それも結構簡単に。。。

機動戦士ガンダム0083 STARDUST MEMORY

ガンダム試作２号機がガトーによって強奪されます。
連邦軍の制服を着たガトーが基地に潜入、さくっとガンダムに乗り込み強奪。
あれ。。。簡単すぎね。。。？

機動戦士ガンダムSEED

ガンダムの開発工場に敵工作員が潜入。
ガンダム４機に乗り込み強奪。
あれ。。。こっちも簡単じゃね。。。

機動戦士ガンダムSEED DESTINY

上記とは立場逆になって、ガンダム３機を強奪されます。
手口的には同様( ´ー｀)ﾌｩｰ．．．

どれもガンダムに乗ってからが簡単すぎないかと。
SEED、SEED DESTINYに至っては、やられてやり返すという、学びがありません。

これ、IT現場に例えるなれば情報漏えいに該当するんじゃないかと思います。
上記はいわばサーバルームに入っちゃえば、パスワードなしでログイン出来る状態に
サーバがなっていて、USB挿してなんでも引き出せる状態なんじゃないかと。

ガンダムという高性能機体でなくても軍事的な資産であれば
強奪されたとしてもその後のケアをできるようにしておくのは必須だったように思います。
危機管理足りないよっっ。

ムダではなかった（？）ジーンの死

機動戦士ガンダムの第一話、ジオン軍の兵士ジーンは
立ち上がったばかりのガンダムを見てこう言います。

「へへ。。。こいつ、震えていやがるぜ。。。」

そして、手柄を焦りガンダムに向かっていき、結果戦死です。
見くびるのも仕方ないのことです、この時ガンダムに乗っていたのは
初めてガンダムに乗ったアムロで、手元にはマニュアルという
完全にMS乗りとしてはよちよち歩きの状態でした。

ただ乗ってたのがアムロだったのが運の尽き。
アムロはニュータイプだったので、ガンダムを一番上手に扱えます。
ジーンをビームサーベルで一突きで決着してしまいました。

IT現場で言えば、急に押し寄せるアクセス過多ですね。
「このぐらいのアクセスだろう。。。」
と見積りサーバを構築、いざリリースしてみると
予想をはるかに上回るアクセス。。。悲鳴をあげるサーバ。。。
結果ブラウザに表示されるステータスコード「５０３」

ステータスコード「５０３」、サービスとしては瀕死に近いです。
こうならないためにも、リリース前にはしっかりとした見積り、負荷テストなどが重要なのです。

カミーユが廃人になってしまう

機動戦士Zガンダム、TV版のラストシーン。
主人公のカミーユはみんなの力を借りてシロッコを倒しますが
結果をして精神疾患を患い、いわゆる廃人になってしまいます。

IT現場でも廃人とまでは行きませんが、いわゆるデスマーチでは
うつ状態になりうる場合が多いと思います。

これまでいくつかのデスマーチ的な案件を体験してきましたが
そういった感じのことは周りで多々あったように思います。

デスマーチ＝無理してという表現もちょっと変ですが
過度な労働は精神、はたまた肉体的に負荷がかかるので
できるかぎりは避けたいですよね。

バナージ、お世話になった人を戦死させる

機動戦士ガンダムUC「ep3. ラプラスの亡霊」で、主人公バナージは
かなりの興奮状態で敵であるフル・フロンタルと対峙してました。

そこで、「次は当てる」と意気込みビームマグナムを放つわけですが
フル・フロンタルはそれを回避。。。後ろにいたギルボアさんの機体にばっちり命中します。

「ギルボア。。。さん。。。」とつぶやき地球に降下していくバナージ。
おい、ちょっと待て。
これって先を予見したり、戦場をちゃんと見渡すことで回避できた悲劇なんじゃないかと。
そもそも冷静になろうよ。。。と。

これ、IT現場で言えば設計時に想定できなかった場面がリリース後に露呈するのと似てますね。
設計時にはこういったことが想定されるので、このような実装になりますなど
システムの内部構造を詰めていきます。その際、想定が甘かったりすると
リリース後に大打撃というか、リリースを取りやめなければならない自体になることもありえます。
設計時から炎上してたりするとよく起きますね。。。
炎上してて周りが見えずバナージ状態です（自戒

まとめ

いかがでしたでしょうか。
かなり無理矢理と言えばそうかもしれませんが、
悲しくも僕らのIT現場にはガンダムと似たシーンが結構あるように思います。

ガンダムシリーズを見て学ぶことでそのようなトラブルを
未然に防ぐことが出来るのではないでしょうか。
いや、防いでください。

では、また無理やりガンダムネタを放り込む次回でお会いしましょう。