フルスタックエンジニア、見つかりましたか?
ここからは、もう少し過激な話をします。インフラ技術者が”全か無か”、そう、「NoOps」についてです。サービス事業者の、というよりは、ユーザー側のインフラ技術者の話です。
「NoOps」の背景には、クラウドサービスの存在があります。
- 日々の設備運用はクラウド事業者がやってくれる
- そしてインフラを使うために必要な設定も、クラウドであればツールやAPIを使って楽にできる
- それ、アプリ開発者でもできますよね
- よし、インフラも操作できるアプリエンジニアをフルスタックエンジニアと呼ぼう
- であればOpsは要りませんよね
なんて発想です。
このフルスタックエンジニアという言葉が生まれて時間がたちますが、いかがでしょうか。見つかりましたか?身の回りに、いますか?
私のお客様や友人に、その能力を持つ人は存在します。でも、その能力を持つ人が、フルスタックエンジニアという役割をすべきかは、疑問です。
具体例を挙げましょう。次の図は、Microsoft社のクラウドサービスであるAzureを企業で使うに当たって、まずこんなことを考慮するといいですよ、というガイドラインです。Azure Scaffoldといいます。Scaffoldとは足場のことで、検討のはじめのとっかかりとして活用されています。
Azure Enterprise Scaffold
詳細は割愛しますが、関心のあるかたは是非リンク先に目を通してみてください。英語か、とそっと閉じないでくださいね。英語はIT技術者のプロトコルです。TCP/IPを学ぶのと同じです。話すのはハードルが高いですが、読めるとプロフェッショナルとして間違いなく得です。英語については、この連載で改めて触れたいと思います。
さて、Azure Scaffoldですが、企業としてAzureを使うにあたり、検討、実装すべきインフラ要素が幅広くカバーされています。たくさんありますね。ベンダーが提供できるのは基盤までです。どう使うかはユーザーが決めなければいけません。他のクラウドサービスやオンプレミスであっても、同様の検討はしているはずです。
そしてこれはPaaSでも、「リソース」がサーバやネットワーク、ストレージから、データベース、メッセージング基盤などに変わるだけなので、インフラ技術者の出番はあります。
フルスタックエンジニアがアプリ開発チームにいたとして、これをシステム、プロジェクトごとに検討し実装すべきでしょうか? きっと同じようなことを他のチームでもするはずです。時間がもったいないです。企業としての一貫性も担保できません。
組織横断のチームが企業としての共通部分を作り、それぞれのプロジェクトがそれを利用したほうが明らかに効率的です。しかも、メジャーなクラウドサービスでは、これらの要素は設定ファイルやコードで表現できます。「コードのパラメータを各プロジェクトで考えてください、あとはツールを実行すればインフラができあがりますよ」という世界です。Infrastructure as Codeと呼ばれることもあります。リードタイムの短縮は、ビジネスにおいて絶対的な善です。
そして、楽に早くできるだけでなく、ファイアウォールのルール割り当て、コストの高いサーバタイプの作成を制限、コスト案分コードの埋め込みを強制するなど、最低限守ってほしいポリシーを確実に適用することで、ガバナンスを効かせることができます。
所属企業のビジネスを理解し、ポリシーを決め、コードに落としこんでいく。いま、そのようなインフラ技術者が求められているのではないでしょうか。そのような人材には価値があるはずですし、実際、需要があります。もしその需要がなくなるとすれば、それはITがテクノロジーではなく、皆が同じように使うコモディティになった時でしょう。わたしは、それがすぐ来るとは思っていません。
「そうありたいけど、いま所属している組織のリーダーは、評価してくれない」という声もあるでしょう。これについては、また改めて。
この連載で今後語ること
あっという間に第1回のスペースを使い切ってしまいました。次回以降も、キャリアパス、評価、プログラミング能力、英語、ロックインの是非、請負構造など、インフラ技術者にとって身近で気になる話題を取り上げたいと思います。
- 真壁徹 (まかべとおる)
- 金融系システムインテグレーターのアプリ開発者としてキャリアをスタートし、その後外資系ベンダーにてインフラとオープンソースを主戦場とした。クラウドとオープンソースの交差点であるOpenStackに注力し、コミュニティでも意欲的に活動。現在はクラウドベンダーにてソリューションアーキテクトを担当している。