「構築をやりたい」の前に見ておきたい地図。インフラエンジニアの仕事を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ディジタル辞典／情報処理学会）