「構築をやりたい」の前に知っておきたい、インフラエンジニアの仕事の5つの工程

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

インフラエンジニアの求人を見ていると、こんな言葉がよく出てきます。

「要件定義から運用まで一貫して担当」「設計・構築経験者歓迎」「運用・保守からスタート」。

なんとなく意味は分かるけど、それぞれ具体的に何をするのかと聞かれると答えにくいですよね。

この記事では、インフラエンジニアの仕事を「工程」ごとに分けて説明します。 工程の流れを知っておくと、求人票の内容や、今やっている勉強が現場のどこで使われるのかが分かりやすくなります。

インフラエンジニアの「工程」とは？¶

システムは、次のような順番で作られていきます。

「何を作るか決める」→「どう作るか決める」→「実際に作る」→「確認する」→「動かし続ける」

この一つひとつの段階を、現場では工程（フェーズ）と呼んでいます。

工程とは、システムを企画してから使い終わるまでの流れを、作業のまとまりごとに区切ったもの。日本では情報処理推進機構（IPA）が「共通フレーム」として、作業の範囲と内容を整理しています。

インフラエンジニアの場合は、サーバーやネットワークを、お客さまや社内の業務で使えるように用意して、その後も止まらないように面倒を見るのが仕事です。 その流れを工程で区切ると、次のようになります。

5つの工程を一覧で見てみよう¶

細かく分けるともっとありますが、最初は次の5つを覚えておけば十分です。

表を見ると分かるとおり、どの工程にも書類がついてきます。 インフラエンジニアはコマンドを打つ仕事というイメージが強いですが、実際は書類を読んだり書いたりする時間もかなり長いです。

上流工程と下流工程¶

現場では、要件定義や設計を「上流工程」、構築・テスト・運用を「下流工程」と呼ぶことがあります。 上の工程で決めたことを、下の工程で形にしていくという意味です。

ただ、上流のほうが偉いというわけではありません。 設計がよくても、構築でミスがあればシステムは正しく動きません。 逆に、運用で起きるトラブルを知らない人がいい設計をするのも難しいです。

それぞれの工程で何をしているのか¶

ここからは、工程ごとの作業をもう少し具体的に見ていきます。 順番は、工程の流れに沿って説明します。

要件定義：お客さまの希望を数字にする¶

要件定義では、利用者の希望をインフラの条件に置き換えていきます。

たとえば「夜中も止まらないでほしい」と言われても、そのままでは設計できません。 そこで「稼働率は何％にするか」「止まってもいい時間は月に何分までか」「データは何日分残すか」といった数字に決めていきます。

ここで決めた数字が、後の工程すべての基準になります。 お客さまと直接話す場面も多いので、経験のあるエンジニアが担当することがほとんどです。

設計：誰が作っても同じ環境になるように決める¶

設計では、要件を満たすための具体的な構成を決めます。

サーバーを何台置くか、ネットワークをどう分けるか、IPアドレスをどう振るか、OSの設定をどう変えるか。 全体の方針を決める基本設計と、設定値を一つずつ決める詳細設計に分けることが多いです。

詳細設計でよく作られるのが、パラメータシートです。 設定値が一覧になっている表ですね。 読み方は 設計書の中でいちばん地味な表、パラメータシートの読み方 で詳しく書いています。

設計では構成図も必ず作ります。 構成図を描きながら理解する方法は コマンドを打つ前に、1枚の図を描いてみる で紹介しています。

構築とテスト：設計書どおりに作って確認する¶

構築では、設計書に書かれた内容どおりにサーバーやネットワーク機器を設定していきます。 たとえばLinuxサーバーなら、こんな作業をします。

# 設計書で決めたホスト名とタイムゾーンを設定する
sudo hostnamectl set-hostname web01
sudo timedatectl set-timezone Asia/Tokyo

# 設計どおりの値になったか確認する（テストの証跡にもなる）
hostnamectl
timedatectl

構築で気をつけたいのは、自分の判断で値を変えないことです。 「こっちのほうがいいのでは」と思っても、設計書と違う設定を入れると、後から誰も経緯を説明できない環境になってしまいます。 気になる点があれば、設定する前に設計した人に確認しましょう。

構築が終わったらテストです。 設定値が設計どおりかを確認するテストと、サーバーを1台止めてもサービスが動き続けるかなど、組み合わせで確認するテストがあります。

構築もテストも、手順書に沿って進めるのが基本です。 手順書を受け取ったときに確認しておきたいことは その手順書、そのまま実行して大丈夫ですか？ にまとめています。

運用・保守：いちばん長く続く工程¶

システムが本番で動き始めると、運用・保守の工程に入ります。

監視画面を見て、アラートが出たら対応する。 決められた日にパッチを当てる。 障害が起きたら原因を調べて、報告書を書く。

構築は長くても数か月で終わりますが、運用は何年も続きます。 システムが使われている期間で見ると、いちばん長いのは運用・保守の期間です。

運用中も、利用者が増えてサーバーを追加したり、OSのサポート期限が近づいて入れ替えたりすることがあります。 そのたびに小さな設計と構築が発生するので、運用を担当している人も、実はいろいろな工程に関わっています。

未経験者はどの工程から入ることが多い？¶

一番気になるのはここだと思います。

結論からいうと、未経験者の多くは運用・保守（特に運用監視）から始めます。 次に多いのが、先輩が作った設計書や手順書に沿って作業する、構築の補助です。

要件定義や設計は、「どんなことが起きると困るのか」を知らないとできません。 これは実際に動いているシステムを見て経験しないと、なかなか身につかないからです。

運用からのスタートは遠回りではない¶

「運用ばかりで構築をやらせてもらえない」と悩む人も多いです。 ただ、運用で得た経験は設計をするときにかなり役立ちます。

たとえば、夜中に同じアラートが何度も出るとします。 原因を調べていくと、「しきい値の設定が厳しすぎる」「この構成だと1台止まっただけでサービス全体が止まる」など、設計の問題点に気づくことがあります。

こういった経験は、設計書を読んでいるだけではなかなか得られません。 運用監視の仕事をしながら何を意識すればいいかは 未経験の入り口は、たいてい運用監視 で書いています。

求人票の言葉を工程に当てはめてみる¶

工程の流れが分かると、求人票の内容も読みやすくなります。 よく見る表現を工程に当てはめてみました。

ただし、同じ言葉でも会社によって中身は違います。 面接で「入社後の半年くらいは、どの工程を担当することが多いですか？」と聞いておくと、入社後のギャップを減らせます。

下の工程から上の工程へ進むには？¶

では、運用や構築から始めた人は、どうやって設計や要件定義を担当できるようになるのでしょうか。

ポイントは、今の作業について「なぜこうなっているのか」を一つ上の工程の立場で考えることです。

運用なら、手順書の操作が設計書のどの部分をもとにしているのかを調べてみる。 構築なら、パラメータシートの値がなぜその値になっているのかを考えてみる。

工程ごとに考えてみたい質問¶

具体的には、次のような質問を自分にしてみてください。

最初は答えが分からなくても大丈夫です。 分からなかったことを先輩に聞いていくうちに、設計の考え方が少しずつ分かってきます。

基礎知識はどの工程でも必要¶

上の工程に進むほど、Linuxやネットワークの知識は知っていて当然という扱いになります。 設計書にコマンドの打ち方は書かれていませんが、コマンドで何が起きるか分からないと設計はできません。

たとえば、サブネットの分け方やルーティングが分かっていないと、ネットワークの設計で必ずつまずきます。 ネットワークの基本を確認したい方は ルーティングとは？ から読んでみてください。

何から勉強すればいいかの全体像は、インフラエンジニアの学習ロードマップ にまとめています。

工程の間でよく起きるトラブル¶

ここまで工程を一つずつ見てきましたが、現場のトラブルは工程と工程の間で起きることも多いです。 前の工程で決めたことが、次の工程に正しく伝わっていないケースですね。

よくある例¶

たとえば、設計書に「ログは90日保管」と書かれていたとします。 ところが構築のときに、ログのローテーション設定が初期値のままになっていた。 運用が始まって3か月後に障害調査をしようとしたら、必要な期間のログがすでに消えていた、というケースです。

これは誰か一人のミスというより、工程の間での確認が抜けていたことが原因です。 設計した人は「設計書に書いたから大丈夫」と思っていて、構築した人は「手順書に書かれていなかった」と思っていた、ということがよくあります。

工程の間で起きやすい問題を、表にまとめてみました。

右の列の確認は、どの工程にいる人でもできます。 新人のうちは「こんなこと聞いていいのかな」と遠慮しがちですが、こういう確認はむしろ感謝されることが多いです。

資格の勉強も工程に当てはめてみる¶

資格の勉強も、どの工程で使う知識なのかを意識すると目的がはっきりします。

LPICやLinuCは、主に構築や運用で使うLinuxの知識を問う試験です。 CCNAは、ネットワークの設計や構築のベースになる知識を扱います。 基本情報技術者試験では、今回説明したような開発の工程そのものも出題範囲に入っています。

「この資格の知識はどの工程で使うのか」を意識して勉強すると、暗記だけで終わらず、現場の作業と結びつけて覚えやすくなります。 LPICの勉強の進め方は LPICの勉強方法 で解説しています。

勉強中の今からできること¶

「まだ現場に出ていないから関係ない」と思うかもしれませんが、自宅の練習環境でも工程を意識して勉強することはできます。

たとえば、Webサーバーを1台立てる練習をするとします。 いきなりコマンドを打ち始めるのではなく、次の順番で進めてみてください。

1. 要件：「社内向けの小さなWebページを、HTTPSで公開したい」と一文で書く
2. 設計：ホスト名・IPアドレス・使うソフトとバージョンを表にまとめる
3. 構築：表のとおりに設定し、打ったコマンドを記録する
4. テスト：ブラウザと curl で、要件どおり表示されるか確認する
5. 運用：ログの場所と、再起動の手順をメモに残す

こうすると、ただのコマンド練習ではなく、工程を一通り経験した練習になります。 面接で「どんな勉強をしてきましたか？」と聞かれたときにも、具体的に説明しやすくなります。

InfraAcademy の Linuxロードマップ では、サーバー構築の基礎を実際に手を動かしながら順番に学べます。 まずは構築とテストの作業に慣れておきたい方におすすめです。

ネットワークから勉強したい方は ネットワークロードマップ も用意しています。

まとめ¶

今回は、インフラエンジニアの仕事を5つの工程に分けて説明しました。

• 仕事は、要件定義・設計・構築・テスト・運用・保守の順に進む
• どの工程にも書類があり、前の工程で決めたことが次の工程の基準になる
• 未経験者は運用・保守や構築の補助から始めることが多いが、遠回りではない
• 今の作業を「なぜこうなっているのか」と一つ上の工程の立場で考えると、設計の力がついていく

今の作業がどの工程のどこにあたるのかが分かると、地味に見える作業にも意味があることが分かってきます。 焦らずに、目の前の作業から少しずつ経験を積んでいきましょう。

参考¶

• 国際規格SLCP：システム＆ソフトウェアのライフサイクル・プロセス（IPA 独立行政法人 情報処理推進機構）
• エンタプライズ系事業／ライフサイクルプロセス（IPA アーカイブ）
• 共通フレーム2013（ISディジタル辞典／情報処理学会）