インフラエンジニアとアプリケーションエンジニアの混沌の歴史
昨日の記事が、自分の中で過去最高のアクセスとスキをもらってしまい、こわくてエゴサもすることのできない、小心者なしょっさんです。
おかげさまで、フォローしていただいたりして、とても嬉しいことです。なんでこんなことになったのかと、首を傾げていたら公式の「#エンジニア 系記事まとめ」にとりあげていただいてました。ありがとうございますです。励みになります。
インフラエンジニアとアプリケーションエンジニアは仲が悪い？
さて、インフラエンジニアの対極というべきか、対となるものとしてアプリケーションエンジニア(開発者)がいます。各々いがみ合う光景も何度も見てきました。21世紀になり、DevOps が提唱されることによって、一部歩み寄りの姿勢が見られますが、アプリケーションエンジニアから見た、インフラエンジニアへのひどい扱いに辟易することは多くありました。
大抵のケースでは、開発者がマウントすることが多く、インフラエンジニアは日陰者の扱いだった時代も長く、苦労しました。
時に、わたしより以前のハードウェアエンジニアは、開発者よりも重宝され「CEがきたぞー、みんなー、お茶を出せー、直してくれるぞー」「「「「「「わーーーーわーわーー」」」」」」なんて時代もあったそうです。聞いたところによると、ファンクラブのあった先輩もいたようです。昔はハードウェアというものは、壊れて当然で、しょっちゅう壊れてました。それでも、ハードウェアエンジニアが来て、該当するパーツを瞬時に見破り、とっとと交換するその姿に、世の女性たちは惚れ倒すような、そんな時代があったというのです。ほんまか。
汎用機一強時代の終わりとダウンサイジング
しかし時代はダウンサイジングへと移行し、誰もがPCを準備して構成できるようになってくると話が変わってきます。実際にお客様が期待している機能を作るのは開発者のみなさんです。要件定義を行い、実装する機能を動かすためのインフラというものは、とっとと準備されて然るべきものであり、その正確性と速さが求められるようになってきました。1日で何十台もセットアップしたあの頃が懐かしい。1台のサーバで大抵のことが実現できた20世紀末、開発者の期待する通りのサーバセットアップを求められる時代がやってきたのです。
クライアント・サーバ型の構成も一段落してくると、PCサーバで稼働するシステムの重要度が高まってきました。冗長化やクラスタリングが当然となる21世紀を迎えます。Webサービス2.0 の時代です。PCサーバがオフコンや汎用機と同等の可用性を求める謎の団体が現れます。
このようにインフラの重要度が増していくごとに、実際に上で動くアプリケーションを開発する開発者側の立場は、より強まっていったのです。なぜだ。
開発者の立場が強まったのはなぜか
何度も言うように、お客様の期待する機能を実現するのは、アプリケーションを開発する側です。お客様と仕様を詰めていくのは、開発者側ですね。インフラエンジニアは、そのアプリケーションの仕様に合わせて構成を行う側です。当時のアプリケーションエンジニアには、冗長構成とクラスタリングの区別のつかない方もおり、会話が成り立たず立ち行かない場合もありました。ネットワークで障害が発生したときの障害対策も、アプリケーション側で実現することのできない人たちもいたのです。しかし、それでも、機能を実装する側たる開発者は、お客様側にいることで、立場的に優位にあったのです。
インフラエンジニア側には、少なからず否もありました。アプリケーションの実装にあたり、インフラでどのように実現するべしかはプログラムがどのように動作するのか、障害発生時にどのような現象が発生するのか、うまく伝達のできないインフラエンジニアが当時も多かったのです。
実のところ、プログラムを書いたことのないインフラエンジニアというものは意外に多く、ジョブやバッチファイルは書けるけれども、アルゴリズムの考え方や、障害が発生した時に、どのようにしてプログラムを持続させるべきかを開発者側に伝える能力がなかったのです。
そうなると、より立場の強い側たる開発者は、さらに強い力を持つようになります。それが「落ちないサーバを作れ」命令事件です。レジリエンスの考え方がすこしは浸透してきた昨今では信じられないかもしれませんが、障害の発生しない、アプリケーションが継続して動き続けるサーバを準備しろといい出す人が絶えなかったのです。高可用性やクラスタリングとかではないです。いわゆる「フォールトトレラント」なシステムです。PCに何を望むんだお主。いや、UNIXサーバだってきついがな。メインフレームにせいや。
こうなってくると、インフラエンジニアの立場は異常に弱くなります。サーバが障害で落ちただけでも、報告書です。ハードディスクが死んだだけでも、報告書です。「なんで故障するようなサーバを持ってくるんだ」とまでどやされる始末。おい、あんただってやがて死ぬんだぞ、サーバなんてすぐにいつだって死ぬわ。
新しい時代の到来
こんな不遇の立場にも脱却の芽が出てきました。それが、クラウドです。「落ちることが大前提」として提供されるサーバ群は強かった。これにより、業務継続性の考え方が、「おちない」から「かいふく」へと移り変わります。落ちることは当然なんだから、それをいかにすぐに発見し、すぐに回復することができるのか。やぁめでたし、めでたし。
とはいきません。
この問題は、不遇なインフラエンジニアの話ではないのです。インフラエンジニアも、開発者も、お互いに想像力が足りなすぎるのです。
インフラエンジニアは、アプリケーションがどのように動作されるのかを理解する学習を怠りました。
開発者は、インフラがどのようなものか知らず、ただプログラムを書いて動作させることしか学習しませんでした。
お互いに完全に自分の領域だけの視点を持ち、自分たちの実現していることの正当性を認めてもらうことに尽力した結果、対立が始まったのだと考えています。自分の領域のスペシャリティを高めることは重要ですが、そこに付随するさまざまな仕組みを理解もせずに突き進むのは、そのスペシャリティを遺憾なく発揮する場面をも失っているのです。
すべてのエンジニアがユーティリティプレーヤとなれるような、フルスタックのエンジニアになれというわけではありません。求めてもいませんし、そうなれる輩もごくごく一部でしょう。ただ、自分の領域外のことは、相手もわからないことがあるという前提に立って、相互認識を高める方法を模索することも重要ではないかと考えています。その方法として、自分にない知識を得ることも一つ。自分のわからない分野・領域については、お互いにけなすことなく、教え合う。ある程度の基礎を理解できてさえいれば、ITの領域における理解度は、それほど低くはないはずです。相手がわからないと決めつけるのではなく、どのようにして理解をしてもらうのか。どうやって協力して、より良いものを作り上げていくのか。協力していく姿勢が重要なのです
いいなと思ったら応援しよう！
