インフラエンジニアって、ちょっと悲しい性質があって。自分から顧客に「この技術使いましょうよ」とは言えないことなんだよね。
顧客は、何か業務上、システム実装しなければいけない要件があって、そこでその要件をSIできる業者を探す。探すと言ってもだいたいお抱えの業者があって、その営業に相談するのがファーストステップ。
その相談が商談になり、もし弊社のソリューションを利用したければ、こういうインフラをご用意できますか、と言う話がやっと出てくる。
そこで、そのインフラ要件について顧客が業者から入手し、そしてインフラエンジニアたる私に相談してくる、という図式になる。
「この形式なら、大丈夫ですよ。見積もりますよ。」
なんて気のいい返事をするんだけど、この時点で私からできる技術的提案は限られる。それより、いかにそのインフラ要件を具体的に素早く実装でき、かつリーズナブルに用意できるかの情報をいち早く伝えてあげる方が、顧客目線で良い。
＜業者（アプリベンダー） ⇔ 顧客 ⇔ インフラエンジニア（私）＞
というという関係性の中で、私が顧客にいくら細かい技術情報を伝えたところで、顧客にはあんまり専門的なことはわからなかったりする。
それより、業者のインフラ要件はちゃんと飲める？ということのほうが間違いなく大事だろう。私がごちゃごちゃ言うことで、業者がやるべきことができなくなると、顧客が満たさなければいけないミッションが宙に浮いてしまう。
インフラ技術が全ての先に決まることなんて、基本的にない。アプリケーション側主導で、その後にインフラとなる。インフラエンジニアとしてできることは、その制約の中でもコストパフォーマンスを守りつつ、最大のセキュリティー（機密性・可用性・完全性）を担保する提案を行うことである。
ここ数年は、インフラは「オンプレミス vs クラウド」という対立軸が常に意識された。かつ、「マイクロサービス vs モノリシック」という論争もおき、コンテナ技術を今後本格的にアプリケーション開発に取り入れるのかどうかも話題となった。
ここ数十年をインフラエンジニアとして経験した上で、上記の論争はどうなったかというと、対立軸の形をしていたが、結局両方残ったということだ。どちらか片方がもう片方を駆逐するということは全くなくて、両方が適材適所で選択されて利用されるようになった。
電子書籍が生まれたから紙の本は無くなるのだ、みたいな話と似ている。結局両方みんな使っていて、買う人は状況により使い分けている。
インフラエンジニアはいつも、全ての要件が決まった後に情報が振ってきて、これよろしく、という感じなものだから、どんな対立軸があろうが結局は自分の頭で考えて、適切な実装方法を確立し、安定運用させなきゃいけないよね。その方針だけは揺るがないので、まあインフラエンジニアという仕事がなくなることだけはないな、なんて現場においてはそう思うのである。
顧客だって、アプリ業者がむちゃくちゃなインフラ条件を出してきているんじゃないか、ということについて専門家にジャッジして欲しい。そこでクラウドだろうがオンプレだろうが、マイクロサービスだろうがモノリシックだろうが、相談相手としてのインフラエンジニアである。
また明日には、違う対立軸が生まれるかもしれないのがこの業界。どう動いたって、インフラエンジニアの立ち位置は変わらない。
