プログラミングやIT技術の知識を披露しあうのがQiitaの醍醐味ってのは知ってるんだ。
だから、こんな売れない、煮ても焼いても食えないブログ記事みたいなのを書くのは決まりが悪いんだけど、ここらでどうしても言っとかないといけないなって、そう思ったんだよ。
少女には向かない職業
ブラック企業なんてものがまるで戦後の闇市みたいな存在だったころ、ぼくはこの業界に入った。知っている人はよく知ってて、知らない人は存在すら思いつかないような会社だけど、あの頃にしてはホワイトで、一次受けもできるとこだったわけ。
とは言え、年に一人はJR東日本や高層建築の”お世話”になっていたし、課に一人はお薬とカフェインがトモダチってやつがいたんだけどね。ぼくは今のところ彼らの”お世話”にはなっていないけど、お薬とは三年来のトモダチだ。
聡明なきみのことだから、とにかく、そういう環境ってことはわかってもらえたと思う。
ワンス・アポン・ア・タイム・イン IT
そんなところが何をやってたかっていうと、ITなんて言葉からは程遠い案件さ。
そりゃ、確かに仮想化が流行ってた頃はVmwareだのHyper-Vだのだったし、このころはもっぱらクラウドだの、いわゆる”最先端IT”の後ろあたりを追っかけちゃいるけどさ、ここいらの文化はまだ９０年代なんだよ。
どういうことかって顔してるね。そりゃそうさ、ぼくだって何でこんな状態になっているのか、最初はちっともわからなかったんだもの。
ウォーターフォールと予算のあいだ
ぼくはTwitterでイキっているアジャイル信者どもとは違うってことだけは、まず言っておきたいな。ウォーターフォールプロセスでもうまくコトが進む開発があることや、プロセスの一部にウォーターフォールを取り入れることもできるのも知っているよ。
でも、ウォーターフォールを選ぶ理由が”予算取り”だけに基づいているなら、そいつは間違いなんだ。ウォーターフォールモデルがうまくいくのは、"既にうまく行った"プロジェクトに適用するときだけだ。
例えば、プロトタイピングしたソフトウェアの本格開発をやるとき、あるいは、オンプレミスの環境をクラウドにリフトするときなんかさ。成功する見込みが高くて、どれぐらいの規模となるかの見積もりも正確でないとだめなんだ。
新しいビジネスをやりたいからって、お金をドンって取ってさ、構想1Q、開発4Qみたいなやり方をするのには向いてないんだよ。君がケツで椅子を磨きながら半年過ごしている間に、新しいライブラリとツールはリリースされるし、クラウドじゃ新しいサービスが数個は登場するんだ。君がエスパーじゃなきゃ、秋ごろには客が文句を言い出して、計画変更必須なのはわかるだろ？ そうじゃなきゃ、賞味期限切れの生卵をおっかなびっくりデプロイすることになる。
勘違いしないで欲しいんだけど、オンプレミスにあるのをそのままクラウドに持っていくってのは、文字通り”そのまま”じゃないといんだぜ？ Web - DBの冗長性のないシステムを、PaaSや、間違っても 可用性たっぷりのVM構成にしようなんて考えてないよな？
願い事は１回に１つだけ、小さいことをこつこつと、だ。
製造のメリークリスマス
パラメータシートというものを君は見たことがあるかな？ 見たことがないなら幸いだ。見たことがあるならご愁傷様だ。
ぼくはこいつが大っ嫌いだ。特にExcelで書かれていたときには実家に帰りたくなるぐらいにね。
こんなことを言うと、Twitterじゃ「Excelの何が悪い」っていう奴がクソリプを送りつけてくるんだけど、ここはQiitaだ。幸い、書き逃げができるし通知もOffにしておけば平和に暮らせる。まあExcelでも済んだ時代があることは認めるし、Excelがベストな開発ってのはあるさ。でも、そいつは物理サーバの調達の時とか、スイッチの配線とか、そういったフィクスドで、人間がそのデータを見て処理するときに限るんだ。
クラウドで仮想マシン払い出すのに、君はいちいちExcelにサーバスペックを書くべきだと思うかい？ 仮にそうしたとして、払い出した仮想マシンと、そいつがExcelの値と一致することを睨めっこして確かめるのかい？
馬鹿いっちゃいけない。君が丹精込めて作ったそいつは、デプロイしたクラウドのリソースに対して何の保証もしないんだ。君か、それとも他の人かは知らないけど、そいつが作業の途中でとち狂って、Webサーバって書いてあるのに、データ処理用のリッチな仮想マシンを出してないことを保証しないんだ。
それに、Excelを広げ立ててお客さんといちいちその値があっているかどうかを確認し合うなんて、まったくマトを外しているだろ？ 重要なのは処理時間、応答時間そして可用性なんかが満たせるかどうかであって、個別の仮想マシンのサーバスペックが合っていることじゃないんだから。
運用なき戦い
世の中はDevOpsで持ちきりだけど、その隅っこにはDevもOpsもないところがある。
特にひどいのはOps、つまり運用の”う”の字もない現場と人間がいると最悪だ。
何が最悪かって、彼ら自身は今まで運用をやってきたという自負を持っているところさ。
彼らが何をやってきていたかというと、CPU使用率を日夜眺めることを監視、ディスクの残り容量が少ないっていうメールを受け取ることをアラートって言って、さてどうしようとバタバタすることさ。彼らの中では、２４３６５という魔法の数字が運用を表しているんだ。つまり24時間365日不停止って意味。２４３６５かどうか、これを監視することが彼らに取っての運用なんだな。
つまりね、彼らの中では、アプリやパッチの更新の時にどれぐらい影響があるか、災害時にどうやったら早くサービスを回復できるかとか、そういう観点での開発への参加っていうのはスコープの外でさ、そこは「開発」に入るんだな。
彼らがやるのは、晩飯が出てくるのを待つステレオタイプなオヤジのように待って、変なところがあればちゃぶ台をひっくり返して知らせる。そういう決まり切ったことしかやらないんだよ。
じゃあ、開発、つまりDevの人間は何をやっているかって言うと、出来上がったら終わりなわけ。これはお客さんも一緒さ。いっぺん作って仕舞えばあとは何とかなるって考えてるんだな。そこで大事なのは、機能が満たされているか、パラメータシートの値が合っているか、そんなところなわけ。
ほら、「運用」のない現場のできあがりだよ。
ぼくたちの沈黙
ぼくは、すくなくとも今の時代に、というよりも技術に合った開発と運用、そして何よりも、お客が今の時代との向き合い方をなんとかしたいって、そう思ってたんだ。
でも、「現行踏襲」、「既存と同じ」っていうメジャーのデッドボールみたいな暗黙の約束がいつでもついて回るんだな。そして、便利なドラえもんの道具と同じように、技術が何かを解決してくれる便利道具ぐらいにしか考えてない。彼らに必要なのはドラえもんの道具であって、ドラえもんは言われた道具を出すだけの自販機でよかったわけさ。
そして、「○○はダメだ」「バズワードだ」と技術にケチをつける。
ERP盛りしころ、いろんなとこが同じような吹っ飛び方をしたんだけど、残念なことに学ぶところはなかったと見える。問題は技術自体にあるわけじゃなくて、そいつを使う側が技術に対しての向き合い方を考えなかったせいなんだけどね。
物事に影響を与える要素が複数あったとして、いろいろ変えてみても結果が変わらないなら、まだ変えてないところを疑う。そういうのはすぐ思いつくはずなんだけど、彼らが気がつくのはいつになるだろうね？
今そこにある危機
２０２５年までもうすぐそこだ。
危機を回避するには何をするべきか、僕らはまずそこに気がつくべきなんだ。
だから、ぼくはこの長ったらしく、たいくつで、中学生の妄想みたいなモンをここに残しておくよ。
いまのところ、ぼくはお薬と付き合っちゃいるが、”そういう”関係ってのは長続きしないモンだからさ。