こんにちは。真壁徹と申します。とあるイベントでインフラ技術者への愛を語ったことがきっかけで、この連載のお話をいただきました。
インフラ技術者はいま、向かい風を受けています。ハードウェアのコモディティ化が進み、設備投資は縮小傾向です。設備が減れば、担当する組織全体の予算も減りがちです。また、パブリッククラウドの浸透が「NoOps」につながる、と主張する人もいます。下を向いてしまいがちな状況です。
ですが、能力や意欲のあるインフラ技術者にとっては、むしろ活躍の場が広がっていると考えています。それをお伝えしたく、この連載オファーを受けました。
わたしは日系システムインテグレーターでのアプリ開発でキャリアをスタートしました。その後、外資系でインフラに強いベンダーに移り、インフラとオープンソースに注力し、現在はクラウドベンダーでソリューションアーキテクトをしています。これまで、多くのお客様のプロジェクトをお手伝いしました。今はプレイヤーですが、マネジメントも経験しています。縁あって、多様な機会を得られたことを感謝しています。
インフラ技術者のみなさんと同じ目線で、かつ経験を生かし客観的にお伝えできれば、と考えています。
Opsという呼び方が嫌い
さて、『Opsの味方』というタイトルで連載を始めたわけですが、私はOpsという呼び方が嫌いです。とっても。連載のしょっぱなから取り乱して申し訳ありません。
Opsという呼び方はDevOpsから来ています。DevOpsの定義はやや曖昧ではありますが、言葉の通り、開発（Development）、運用（Operations）という2軸が根っこにあります。
そしていつの間にか、アプリ開発者をDev、インフラ技術者をOpsと呼ぶ人が多くなりました。これが問題です。
インフラ技術者にとって、運用がすべてではありません。維持運用作業、対応はもちろん重要ですが、拡張性高く堅牢な、そしてアプリを動かしやすい仕組みを設計して作る、「エンジニアリング」も重要な仕事です。DevとOpsが協力するというコンセプトは好きなだけに、言葉の一人歩きが悔やまれます。
とはいえ、OpsはITインフラ技術者を表す一般用語になってしまった感があり、通りがいいので、ぐっとこらえてタイトルはそのままにします。タイトルに反抗するロックな感じで進めたいと思います。
名は体を表す
インフラ技術者は、企業や組織によって呼称がさまざまです。インフラチームの人、基盤担当、方式屋、etc。アプリ担当はだいたいアプリ＋αなので、インフラのそれはバリエーションに富んでいます。
そこにOpsという言葉が飛び込んできました。先にも書いた通り、運用、事後対応のイメージが強すぎる言葉です。エンジニアリングはどこに行ってしまったのでしょうか。名は体を表します。それだけでくくられたくはありません。
一方で、最近話題になりかけている役割、呼称に「Site Reliability Engineer（SRE）」があります。米Google社が、自社サービス基盤を支える技術者をそう呼んだのが始まりと言われています。書籍が出版されたり、カンファレンス（SRECon）が開催されたりと、にわかに注目を集めています。カンファレンスには米Microsoft社や米Facebook社も参加しており、インフラ技術者にとって注目する価値があるトレンドです。
Google社においてSREは、インシデントや問い合わせへの対応など「Operational Work」が業務時間の50％を超えないようにコントロールしているそうです。残りの時間は、サービスの信頼性や拡張性の向上、そして対応スピードを高め、工数を軽減するために、運用を自動化するソフトウェアを書くとのこと。
私のイメージするインフラ技術者像は、このSREに近いです。エンジニアリング、と入っているだけでポイントが高い。50%は大胆としても、5%でも、10%でも仕組み作りに時間を使いたい。一般的な呼称になるかは若干疑問ですが、その役割や込められた意図は、もっと認知されて欲しいな、と思います。
