【IT業界名言集】我がコードは我流。我流は無形。故に誰にも読めぬ。【10年進歩なし】

10年近く前にまとめたIT業界の名言集を久々に読み返したところ、今見ても新鮮味があるというか、IT業界の変わらなさを実感し、ちょっと残念な気持ちになりました。この10年間でIT業界は果たして進歩してきたのでしょうか。2017年版の要素も追加して、IT業界迷言集を紹介します。

【その１】-------------------------------------
「バグは夜更け過ぎに 仕様に変わるだろう」

何をやってもバグが解消せず、終電がなくなってもまだ直らない。こうなったら「仕様」と言い切るしか術は無い・・・そんな悲しい状況が目に浮かびます。私はDBコネクションプールで同じ憂き目を味わいかけました。

この迷言、10年経ってもまったく色褪せません。しかし、2019年頃と目される民法改正でシステム開発契約における「瑕疵担保責任」の考え方がさらに厳しくなります。もう仕様と言い張ることもできなくなりそうです。

【その２】-------------------------------------
「１年に１回起こる可能性が１％の問題なんて無視していい。俺は１００年後はもう居ない」

総稼働時間で考えれば、100台同時に動かすと1年で問題発生ですね。ハードディスクの耐久性能で”100万時間稼動”（MTTF）という製品の考え方と同じ理屈です。この論理で押し切れるクライアントがいたら、逆にヤバいです。

2017年現在では、クラウド運用業者は同時に数千台のサーバーを動かしますし、GoogleやFacebook規模だと毎日数台のサーバーが不良で止まります。1万分の1の確率さえ「起こり得る事象」と捉えなければなりません。もっとも、ユーザーにフェイルオーバーを感じさせない技術も発展したため、フロント側からすると「止まらないシステム」に見えるものも増えました。

【その３】-------------------------------------
「営業が出した要件が全てだと思うな」

おいおい、身内を欺いてどうするんですか。孔明の罠なんて誰も求めてませんから、さっさと仕様を聞き出してきてください。

この迷言、10年経っても変わりません。営業と現場は敵同士のところはまだまだ多いです。DevOpsで開発vs運用の戦いが収まりつつあるなら、「SalesDevOps」まで踏み込んでしまえばいいのに。

【その４】-------------------------------------
「所詮ボクらは農耕民族。誰かが開墾した畑を守るだけなんです」

運用チームにこんなことを言われると本気で泣けてしまいます。そんなに卑屈にならないで下さい。どこの業務ユーザに苛められたんですか？あなたのチームがいるからみんな仕事ができるんですから、どうか自信を持ってください。

2017年、DevOpsが徐々に世に広まり、DevがOpsの仕事を巻き取る（奪う）ようになってきました。運用チームに狩猟民族の血を入れる必要はありませんが、好奇心旺盛で開発に首を突っ込んでくるプロモーターの血は必要でしょうね。畑を守るだけの運用チームに居場所はなくなりつつあります。

【その５】-------------------------------------
「画面は青かった・・・ 」

ああ・・・哀れ、ブルースクリーンを見てしまいましたか。ダンプ情報が書かれているのに、一瞬で消えてしまうから内容を確認する間もないという冗談みたいな画面。なんのためにエラー情報吐いているんだぁ！！

2017年、ブルースクリーンを見ることはかなり減りました。オフィス製品がフリーズして作成中のファイルが失われてしまうことも、オートバックアップのおかげで減ってきたと思えます。

【その６】-------------------------------------
「論よりコード」

「UTSL(Use The Source, Luke)！」
コード至上主義の方と仕事をすると似たような話を聞きます。確かに一理ありますし、生産性も高いのですけど、官公庁の仕事でそんな無茶を言わないで下さい。

2017年、あれから10年でソースコードからの設計書自動作成技術はあまり発展していません。やはりまだまだ手動で仕様書は作らないとダメですね。もしワードで作るなら、「外資系コンサルのビジネス文書作成術」（東洋経済新報社）が役立ちますよ・・・

【その７】-------------------------------------
「我がコードは我流。我流は無形。故に誰にも読めぬ・・・」

論よりコードに似ているようで全然違います、コチラの方はコードの可読性が限りなく低い！一体誰に保守させるつもりでしょうか。我流で書けるのは分かりましたから、次はコメントの書き方やデザインパターンを学んで、可読性の高いコードをお願いします。

2017年、今でもこうしたコードを見かけます。開発費をケチられたといっても、保守できないレベルのコメントしか残していないというのは開発者の矜持に欠けますよ。

【その８】--------------------- ※「SEの格言・迷言・ことわざ集」引用
「いつまでもあると思うな保守のカネ」

2人月×12か月で積んでもらった保守費用なのに、わずか6か月で使い切るとはなんということでしょう。バグだらけのシステムを無理やりリリースしたばっかりに。この後半年間、どうやって過ごすつもりでしょう。

【その９】--------------------- ※同上
「嘘から出た受注」

IT業界は慢性的な人不足。それは昔から変わっていません。なのに、受注金額はなぜこんなにも低いのでしょう。裏を返せば、単価を高くしたら仕事をもらえないということ。だったらお断りする前提で高値入札しちゃいますよ、と勇んで出した提案書が通ってしまったとき、営業は青ざめるのです。やばい、空売りだ！その結果、頭数は10人しかいないのに20人分の働きをしなければならなくなることも。

しかし、2017年は働き方改革の影響で残業規制がすさまじいです。月残業が45時間を超えると指導が入りますから、130％以上働く月が続くとアウト。IT業界特有の働き方がこの機に改まることを願います。

【その10】--------------------- ※同上
「弘法、言語を選ばず」

一説によれば、15以上の言語を操れるレベルで一人前のプログラマーらしいです。Java、JavaScript、C、C++、C#、PHP、Python、Ruby、Objective-C、HTML5、CSS、Perl、Haskell、Go、COBOL、R、VBA…これだけできれば一人前か。そんな人いるんですかね？

【その11】--------------------- ※同上
「電話いそげ」

メールでコミュニケーションしたい気持ちはわからんでもないんですけど、そのメールを1通書くより先に電話を一本したほうがいいんじゃないでしょうか。そのメール、障害報告ですよね？

【その12】--------------------- ※同上
「転ばぬ先のテスト」

それな。テストドリブンでもテストファーストでもどっちでもいいですから、テストしてないものを本番環境で動かすのはやめましょう。やってないテストコンディションを「やった」と言い張るのも、1回目のテストエラーは全部ノーカウントで、2回目からトラッキングするとかいうのも怖いからやめてあげてください。運用保守チームが死にます。

【その13】--------------------- ※同上
「風が吹けばコンサルが儲かる」

ちょっとしたことを大事にして案件に仕立て上げる。そんな悪いことをする人は最近のコンサルにはいません。そんなことをせずとも、クライアント企業の企画部門は人員不足に苦しんでいます。予算さえ確保できれば、すぐにコンサルに声をかけるのです。何せ日本のIT部門の生産性は指折りの低さ。やることはどんどん増えるのに残業規制で働きたくとも働けない。そんな状況では、外部のコンサルに仕事を切り出すしかないんです。案件の絶対量と納期がもっと緩くなればいいのに。

【その14】--------------------- ※同上
「納品良ければすべて良し」

いくらたくさんのテストエラーが出ようとも、課題検討会で相手にボコボコにされようとも、サービスインがうまくいって、納品完了すればよいのです。雨降って地固まるよろしく、苦労を共にするとベンダーとクライアントの一体感は激増します。だからといって家に帰れないデスマーチに陥ると納品にたどり着かないことには注意！

【その15】--------------------- ※同上
「Do IT Yourself」

「Do it yourself」（自分でやれ）ではなく、「Do IT（アイティ） yourself」（ITは各自で取り組むように）です。もはやITを情報システム部門に頼る時代は終わりました。クラウド活用が叫ばれる昨今、ユーザーは自分でクラウドサービスを申し込んで、自分でサービスを利用開始してしまいます。そう、Salesforceのように。そういう勝手ITはユーザー自身の手で後始末してくださいね、と言えたらどんなに楽でしょう。

 

最後はまともな名言で締めましょう。

「プログラムを書いたことのない者、情報システムを語るべからず」

一を聞いて十を知る人も確かにいますが、多くの人は一を聞いて一を理解する程度です。いや、確実にその一を達成できる人はやっぱりそんなに多くないでしょう。だからこそ、書籍や伝え聞いた話で理解した気になるのではなく、実際にソースコードがどんなものかを感じ取ってからITを語ってほしいです。そういう点で、最強のIT戦士になるためのスタート地点はプログラマーなのだと思っています。

ITコンサルもSEも、原点はプログラマーにあり。