未来に向けた再スキル化：開発者とインフラ専門家がコンフォートゾーンから抜け出す必要がある理由

Matthew Finio：開発者とインフラストラクチャー専門家の関係はどのように変化していますか。

Miha Kralj：「ソフトウェア定義のものすべて」、つまりソフトウェア定義ネットワーク、ソフトウェア定義ストレージ、ソフトウェア定義コンピューティングの登場により、開発業界全体が変わりました。

以前は、左側にインフラストラクチャー担当者、右側にソフトウェア開発担当者がいて、お互いに会話をすることはほとんどありませんでした。片方は基礎となる配管とアセットのすべてを提供しており、他方はあらゆるコーディングを駆使して、夢を実現していました。

今、そのすべてが崩壊しつつあります。これらいずれの専門家も、私たちが今迎えようとしている時代に対する準備ができていません。どちらもセキュリティーを理解していないので、この点についても考慮する必要があります。彼らはお互いから学び始める必要がありますが、それは双方にとって難しいことでしょう。

これはまるで書籍『チーズはどこへ消えた』ようなものです。どちらの側も、より古い世界で育った人は、居心地悪さを感じます。GmailやYouTubeとともに育った若い世代は、こうしたものが融合した新しい世界に生きています。しかし、従来のインフラ側や開発側から来た人は、キャリアの初期段階で他の領域について学ぶ機会がなかったため、苦労します。

MF：つまり、開発者とインフラストラクチャー担当者の両方が職務内容を再考する必要があるということですか。

MK：そのとおりです。開発者は、自分たちが単なるアプリケーション開発者であると考えるべきではありません。また、インフラストラクチャー担当者は、自分たちが単なる運用担当者であると考えるべきではありません。これからの製品エンジニアリング・チームでは、必要に応じて全員が他の人の仕事を代行できるようになるでしょう。まだ専門分野はありますが、開発者は必要に応じて、従来は非常にインフラストラクチャーに重点を置いたタスクであったTerraformスクリプトをすぐに作成できる必要があります。

したがって、誰かに仕事は何かと尋ねたとき、「私はソフトウェア開発者です」または「私はインフラストラクチャー/運用担当者です」と答えるべきではありません。チーム全員が製品の構築やサービス開発に貢献しますが、それらすべてが正しく組み合わされなければ、製品が世に出ることはありません。誰もが、チェーン全体、ライフサイクル全体、下から上までのすべてを理解する必要があります。

MF：今、Terraformについて言及されましたが、その他のインフラストラクチャーの概念として、開発者が学ぶ必要があるものは何でしょうか。

MK：開発者は、基盤となるインフラストラクチャーが実際にどのように機能するのか、何が永続的で何が一時的なものなのかを正確に理解していないことがよくあります。

例えば、何かを実行しているホスト、コンテナ、またはサーバーレス・コンポーネントに何らかの変更を加えた場合、そのコンポーネント、その仮想マシンが別の場所に移動しても、その変更は保持されるでしょうか。したがって、状態を他の場所に保存するシステム、つまりステートレス・システムの概念は、開発者が最初に理解することができる1つの事項です。では、どうすれば無限に拡張可能になるのでしょうか。耐久性と弾力性に優れたシステムはどのように作るのでしょうか。これらすべてのアーキテクチャーの概念はソフトウェアで実装されていますが、実際にはインフラストラクチャーのパターンがベースになっています。

また、攻撃の可能性を最小限に抑えた最小の表面領域をコードで作成する方法について、すべてのセキュリティー・パターンを理解することも重要です。さらには、遠く離れたサービスと適切に通信する方法。少しカジュアルな口調で毎秒100件のやり取りを可能とする会話が多いサービスを作成するつもりですか。それとも、すべてのリクエストをパッケージ化して、大きな塊に分けて送信頻度を下げますか。

これらはすべてのソフトウェア開発者が行う必要のある非常に重要な決定ですが、内部で何が起こっているか、つまり実際のシステムがどのように機能しているかを理解していなければ、なぜそのような決定を下すのか理解できません。つまり、システムを根本から理解することが重要です。開発者は、システムを妨害したり、データベースをロックしたり、悪いことをしたりしない、適切でクリーンなコードを書く必要があります。

2、30年前には、CPUに必要なサイクル数を最小限に抑え、データのロックを最小限に抑えるためにデータベース・クエリを最適化する専門職が存在しました。その難解な知識の多くは失われています。しかし、高性能なシステムを作成する方法とコストが最適化されたシステムを作成する方法を理解することは依然として非常に重要です。これらすべての教訓を忘れてはいけません。

こんなことを言えば、「おいおい、今は2025年だぞ、じいさんは引っ込んでろ。今の世界はこれまでとまったく違うんだ。何もわかってないくせに」という人もいるでしょう。私たちはこの現代的な世界を構築し、新しい開発者や新しいインフラストラクチャー担当者がこの新しい世界を可能な限り効率的に活用できるよう、支援しようとしています。

MF：開発者がインフラストラクチャーをコード・ツールを使用してワークフローを改善する方法について説明していただけますか。

MK：ええ。よい例は、開発者がコードを作成してリポジトリーにコミットするたびに、独自のコードが自動的にテストされ、コンパイルおよびパッケージ化される適切なワークフローを作成する方法が挙げられます。開発者は、インフラストラクチャー担当者にその作業を依頼する必要はありません。GitHubで優れたYAMLスクリプトを作成することは、すべての開発者がプロセスを可能な限り効率的にするために最適化できるコードとしてのインフラストラクチャーに関わるタスクです。

したがって、例えば、開発者が開発部門にのみ携わっていれば、完全なパッケージ化、完全な検証、完全なテストを考慮することはありません。その開発者は、「私は開発部門にいるので、本番担当部門が行うべき20個のタスクは自分にはまったく無関係です」と言うでしょう。

しかし、本番環境では、一連のオートメーションを実行し、コードの完全なセキュリティー検査や検証などを実行するマシンを起動する必要があります。コンパイルがどれだけ早く完了するか、コードをコミットした後にどれだけ早く結果が表示されるかに影響するすべての小さな決定について、すべての開発者がインフラストラクチャーをコード・スクリプトとして変更し、独自のワークフローに適合できる必要があります。

これは、開発者が独自の統合開発環境をファイン・チューニングするのと似ています。彼らは独自のフォントや色、キーボードショートカットなどを好んで使用します。また、コードをコミットした後に何が起こるかという独自のワークフローを構成できる必要があります。これらはすべて、コードとしてのインフラストラクチャー（IaC）から得られる知識です。

MF：今日のアプリ開発について、インフラストラクチャーの専門家は具体的にどのようなことを理解しておくべきでしょうか。

MK：コードとしてのインフラストラクチャー（IaC）とは、文字どおり、インフラストラクチャー担当者がコーダーになることを意味します。インフラストラクチャーはスクリプト、データ、コードで定義されます。つまり、インフラストラクチャーのスクリプトまたはコードは、開発者が記述するコードと同じソフトウェア開発ライフサイクルを経る必要があります。つまり、

• 適切に文書化する必要があります。
• リポジトリーに適切に保存する必要があります。
• 適切にバージョン管理する必要があります。

まったく同じように扱う必要があります。従来のインフラストラクチャー担当者はこれを理解できず、実行することもできませんでした。インフラストラクチャー担当者は、マウスをクリックして設定することはできました。Bashスクリプトなどを作成することももしかしたらできたかもしれません。

しかし、現在では、インフラストラクチャー担当者はインフラストラクチャーの実際のコーディング担当者であることが完全に期待されているので、Gitを理解する必要があります。コード資産としてのインフラストラクチャーのセキュリティー・スキャンを実行する方法を理解する必要があります。彼らの資産は適切にバージョン管理され、ピアレビューされる必要があり、プル・リクエストが何であるかを理解する必要があります。これらはすべて、すべてのソフトウェア開発者ならデフォルトで知っている標準的な用語とアクティビティーです。

インフラストラクチャー担当者はフルスタックになる必要があります。フルスタック・エンジニアは育成するのも、見つけるのも困難です。パケットの流れ方、ネットワークの仕組み、オペレーティング・システムのカーネルの仕組みなど、基礎から応用まですべてを理解できる人材が不足しています。例えば、複数のソフトウェア依存関係を実際にどのように記述するのでしょうか。オープンソースまたは内部のパッケージを使用しますか。非同期コードはどのように記述すべきでしょうか。これらは純粋にソフトウェア開発に関する質問です。2つの巨大な専門領域が突如として強制的に1つに合体させられました。そのための変革管理や人材の再教育、スキルアップが欠如しています。

MF：スキルの再習得やスキルの向上がそれほど難しいのであれば、インフラ専門家はどのようにして開発のトレンドやテクノロジーを最新の状態に保つべきでしょうか。

MK：そうですね、インフラストラクチャーだけに特化する人材や開発だけに特化する人材はもう存在せず、すべてが1つの専門領域として突如強制的に1つに合体させられました。この流れに関係する人はすべて、ソフトウェア開発ライフサイクルの変化、特にAIによる変化といった新しいトレンドを学んでいます。

AIネイティブ型の開発に移行すると、インフラストラクチャー担当者とアプリケーション開発者の両方がAIを学習する必要があります。誰もがFOMO効果に悩まされ、自分は既に遅れをとっていると考えてしまいます。プロンプト・エンジニアリングのやり方を学んだばかりなのに、次は早速もセマンティック・カーネルなどでエージェントを書く方法を学べと急き立てられています。

こうした専門家たちは互いに助け合い、適切なバランスを見つける必要があります。常に最新の情報に精通し、自分が最先端であるという確信を持てるようになるには、どれくらいの時間を費やす必要があるでしょうか。以前は5％でしたが、今は10％です。ここで役立つのは生成AIです。しかし、学習に必要な時間と、それを適用してビジネス価値やIT価値を創造できるよう開発にかかる時間の比率では、現在は、ますます学習にかかる時間が増えています。

MF：最後に、開発者やインフラストラクチャー専門家が最新のアプリケーションについて留意すべき重要な点は何でしょうか。

MK：分割タスクはもう存在しないということです。最新のアプリケーションにはインフラストラクチャーがほぼ組み込まれています。例えば、現代の開発者はコードを記述し、コンテナの作成を要求します。それらのためのコンテナを作成するインフラストラクチャー担当者は存在しません。インフラストラクチャーに重点を置いた作業だけでなく、開発も必要になるプロジェクトもあれば、ソフトウェア開発の度合いが大きく、さらにインフラストラクチャーの知識とアクセスも求められるプロジェクトもあります。

したがって、インフラストラクチャーの専門家が検討する必要があるのは、ソフトウェア開発者になることです。ソフトウェア開発者も同様に、インフラストラクチャーの専門家になる必要があります。

これらの役割は別々ではなく、統合されています。10年以上前には、すべてのソフトウェア開発会社には開発者とテスターがいた状況と似ています。現在では、これら2つの役割は一つとなっっており、「テスター」の話をする人はもういません。同じような役割の崩壊と統合が、今度は開発者とインフラストラクチャー担当者の間で起こりつつあります。