アプリ開発エンジニアにインフラの基礎をどう教える？開発部門向けの研修範囲と進め方

こんにちは、インフラエンジニアのryuです。

開発部門の責任者や教育担当の方から、「アプリの開発メンバーにも、インフラの基礎を身につけてほしい」という相談を受けることが増えてきました。クラウドの上で動くサービスでは、デプロイの失敗、権限のエラー、ログの読み方など、開発者が自分で切り分けたほうが早い問題がたくさんあるからです。

ただ、開発エンジニアにインフラエンジニア研修をそのまま受けさせると、範囲が広すぎて続かないことがよくあります。この記事では、開発者向けにインフラの研修範囲をどう絞るか、どんな順番で進めるか、身についたかをどう確かめるかを、開発部門の責任者・教育担当者向けにまとめます。

結論を先に書くと、ポイントは3つです。インフラエンジニアを育てる研修とは目的を分けること、自分たちのサービスが動く経路に沿って範囲を決めること、そして実際のトラブルを題材にして手を動かす時間を取ることです。

なぜ開発エンジニアにもインフラの基礎が必要なのか¶

以前は、開発チームがアプリを作り、別のチームがサーバーを用意して運用する、という分担が一般的でした。今もこの分担の会社は多いですが、クラウドやコンテナが広がったことで、開発者がインフラの設定に触れる場面は確実に増えています。

AmazonのCTOであるWerner Vogels氏は、2006年のACM Queueのインタビューで、開発者が自分の作ったサービスの運用にも責任を持つやり方について語っています。この考え方は「You build it, you run it」という言葉で知られるようになりました。すべての会社がこの形を取る必要はありませんが、開発と運用の距離が近くなっている流れは押さえておきたいところです。

国内でも、IPA（情報処理推進機構）と経済産業省が2022年12月に策定したDX推進スキル標準（デジタルスキル標準の一部）では、ソフトウェアエンジニアの類型の中に、フロントエンドエンジニア・バックエンドエンジニアと並んで、クラウドエンジニア/SREというロールが置かれました。デジタルスキル標準はその後も改訂が続いているので、最新の内容はIPAのページで確認してください。開発とインフラを、同じ「ソフトウェアを届ける仕事」の一部として整理しているわけです。

開発者がインフラで困りやすい場面¶

開発エンジニアが実際につまずくのは、高度な設計よりも、日々の作業の中の小さな場面です。たとえば次のようなものです。

こうした場面で毎回インフラ担当に聞いていると、開発側も運用側も待ち時間が増えます。開発者が一次切り分けまでできるようになると、問い合わせの中身も具体的になり、チーム全体の対応が早くなります。

インフラエンジニア研修とは、目的を分けて考える¶

ここで大事なのは、開発者向けの研修を、インフラエンジニアを育てる研修の短縮版として作らないことです。

インフラエンジニア研修のゴールは、サーバーやネットワークを設計・構築・運用できるようになることです。一方、開発者向けの研修のゴールは、自分たちのアプリが動く環境を理解し、問題が起きたときに一次切り分けをして、インフラ担当と同じ言葉で会話できるようになることです。

この違いを表にすると、次のようになります。

目的を分けておかないと、開発者が「サブネットの設計」や「ルーターの設定」のように、普段の仕事で使わない内容に時間を取られてしまいます。学ぶ意味が見えないまま進むと、研修は途中で止まりやすくなります。

すでにいる社員をインフラエンジニアとして育て直したい場合は、目的がまったく違います。その場合の進め方は社内人材をインフラエンジニアにするリスキリングの記事で整理しています。

研修範囲は「自分たちのサービスが動く経路」から決める¶

開発者向けの研修範囲を決めるときは、一般的なカリキュラムから選ぶより、自社のサービスに沿って決めるほうがうまくいきます。具体的には、利用者のリクエストがアプリに届き、データベースに保存されるまでの経路を1本書き出して、その経路に登場する技術を研修の範囲にします。

経路を書き出して、学ぶ技術を拾う¶

たとえば、AWS上のWebサービスなら、経路は「ブラウザ → DNS → ロードバランサー → サーバー（またはコンテナ）→ アプリ → データベース」のように書けます。そのうえで、それぞれの段階で開発者が知っておくべきことを拾います。

DNSなら名前解決の確かめ方、ロードバランサーならヘルスチェックの意味、サーバーならLinuxのログとプロセスの見方、データベースなら接続先とポート、といった具合です。経路に登場しない技術は、最初の研修では扱わないと決めておきます。

この作業は、インフラ担当者と一緒にやるのがおすすめです。開発者が普段見ていない部分を説明してもらえるので、それ自体が研修の最初の1回になります。

3つの段階で進める¶

範囲が決まったら、次の3つの段階で進めると無理がありません。

1つ目は、Linuxの基本操作です。ログの場所、プロセスとサービスの状態の確認、権限の読み方を、コマンドを打ちながら覚えます。開発者は普段からターミナルを使っていることが多いので、ここは比較的早く進みます。

2つ目は、通信の基本です。IPアドレスとポート、DNS、ファイアウォールの関係を理解し、「アクセスできない」ときにどこまでは届いているのかを確かめられるようにします。

3つ目は、クラウドの仕組みと権限です。自社が使っているサービスに絞って、リソースの関係と、IAMの権限の考え方を学びます。権限エラーの切り分け方は、AWSのAccessDeniedの原因を絞る手順の記事のような実務の題材を使うと、仕組みと結びつけて理解しやすくなります。

6週間で進める場合の例¶

開発の業務と並行して進めるなら、1回あたりの時間を短くして、期間を長めに取るほうが続きます。参考までに、週2時間を6週間続ける場合の組み立て例を載せておきます。これは説明のための仮定の例で、人数や経験によって調整してください。

最初の週に経路を書き出しておくと、2週目以降に学ぶ内容が、自分たちのサービスのどこに当たるのかを毎回意識できます。各週の終わりに、学んだことを使ってチームのサービスを1か所だけ実際に確かめてもらうと、知識が業務とつながりやすくなります。

本番環境と検証環境の違いを説明できるようにしておくことも大切です。考え方は本番・検証・開発の3つの環境の使い分けの記事が参考になります。

進め方：実際のトラブルを題材にして手を動かす¶

開発者向けのインフラの基礎研修は、座学だけで終わらせると、ほとんど身につきません。開発者は「何に使うのか」がはっきりした知識ほど早く覚えるので、過去に自社で起きたトラブルを題材にするのが効果的です。

過去の障害を、切り分けの練習問題にする¶

障害の報告書や、インフラ担当への問い合わせの記録から、開発者が関わったものを選びます。そこから、原因や対処を伏せて「この症状が出たら、どこから確かめるか」を考えてもらいます。

たとえば「デプロイ後に画面が開かない」という題材なら、名前解決、ロードバランサーのヘルスチェック、サーバー上のプロセスとポート、アプリのログ、の順に確かめる流れを、実際にコマンドを打ちながら追ってもらいます。最後に、実際の原因と対処を共有して振り返ります。

ログの見方に慣れていないメンバーが多い場合は、ログの読み方入門の記事を事前に読んでもらうと、題材に入りやすくなります。

壊しても困らない練習の場を用意する¶

手を動かす研修では、本番やチームの共有環境を使わないことが前提です。研修用のアカウントや環境を用意するか、ブラウザで動く学習環境を使います。研修用環境のコストや権限の考え方は、研修用サンドボックスの設計の記事にまとめています。

身についたかを確かめる方法¶

研修の効果を確かめるときは、受講したかどうかではなく、切り分けができるようになったかを見ます。開発者向けの研修なら、次のような確かめ方が現実的です。

1つは、研修の最後に新しい障害の題材を1つ出し、どこから確かめるかを説明してもらう方法です。正しい原因にたどり着けたかより、確かめる順番に筋が通っているかを見ます。

もう1つは、研修後の実際の問い合わせの変化を見る方法です。インフラ担当への問い合わせが「動きません」から「ポートは開いているが、アプリのログに接続エラーが出ている」のように具体的になっていれば、研修が役に立っていると判断できます。この変化はインフラ担当者に聞くのがいちばん確実です。

進捗のばらつきも把握しておきましょう。開発の締め切りが近いメンバーは学習が止まりやすいので、誰がどこまで進んでいるかを定期的に確認し、止まっている人には時期をずらす相談をします。

InfraAcademy の法人プランでは、管理画面から受講者ごとの講座の進捗率や学習日、練習問題の正答率を確認できます。契約中は受講者が全講座から必要なものを選んで学べるので、Linuxのログとプロセス、ネットワークの基礎、AWSのIAMといった開発者に必要な範囲だけを指定して進めてもらう使い方ができます。ブラウザ上のLinuxの演習環境で、コマンドを打ちながら確かめられる点も、手を動かす研修と相性がよい部分です。

管理画面の操作感は、登録不要の管理画面のデモで確かめられます（デモは架空のデータです）。社内で検討するための資料が必要な場合は、資料請求のページをご利用ください。

研修を進めるときの注意点¶

最後に、開発者向けのインフラの基礎研修でよくある失敗を挙げておきます。

1つ目は、インフラ担当者の負担が増えすぎることです。講師役や題材づくりをインフラ担当者に任せきりにすると、本来の運用業務が回らなくなります。題材の選定だけを手伝ってもらい、進行は開発側の教育担当が持つなど、役割を分けておきましょう。

2つ目は、研修で学んだことを使う場面が無いことです。研修のあとも、開発者がログやサーバーを見る権限が無いままだと、せっかくの知識が使われずに薄れていきます。どこまでの範囲を見られるようにするかは、セキュリティの方針と合わせて事前に決めておく必要があります。

3つ目は、全員に同じ内容を同じペースで進めることです。インフラの経験は開発者によって大きく違います。最初に簡単な確認をして、すでに分かっている部分は飛ばせるようにしておくと、経験者が退屈せずにすみます。

まとめ¶

アプリ開発エンジニアにインフラの基礎を教えるときは、インフラエンジニアを育てる研修とは目的を分けて考えることが大切です。ゴールは設計や構築ではなく、自分たちのサービスが動く環境を理解し、一次切り分けができるようになることです。

研修範囲は、自社のサービスのリクエストが通る経路を書き出して決め、Linux・通信・クラウドの権限の順に進めます。座学で終わらせず、過去の障害を題材に手を動かし、研修後の問い合わせの変化で効果を確かめましょう。

まずは、インフラ担当者と一緒に、自社のサービスの経路を1本書き出すところから始めてみてください。それだけで、開発者に何を学んでもらうべきかがはっきり見えてくるはずです。

参考¶

• A Conversation with Werner Vogels（ACM Queue, 2006）
• 「DX推進スキル標準」を策定（IPA 情報処理推進機構 プレスリリース）
• デジタルスキル標準とは（IPA 情報処理推進機構）