インフラエンジニアの仕事内容は？【要件定義・設計・構築・運用保守工程とは】

インフラエンジニアの仕事内容は、IT業界未経験者にはわかりにくいです。なぜならば、映画やドラマ等で見かける機会のある「プログラマー」に比べて、「インフラエンジニア」はIT業界以外の人は知る機会がないからです。

そもそも「ITインフラ」自体、世間一般の人は触れる機会がありません。

しかし実は、皆さんが普段使っているスマホアプリやSNSは、ITインフラが無くては絶対に動かず、インフラエンジニアの仕事によって成り立っています。

この記事では、IT業界未経験の人でも完全に理解できるよう、具体例を使いながらインフラエンジニアの業務内容をどこよりもわかりやすく解説しています。

この記事を読めば、インフラエンジニアの業務について圧倒的に理解度が上がり、インフラエンジニアへの転職可能性が高まります。

インフラエンジニアの具体的な仕事内容・業務内容

インフラエンジニアはシステムエンジニアやプログラマーと同様に、IT業界を支える職種の1つです。ITインフラの設計・構築・管理を担当します。

ITインフラとは

ITインフラとは、「ITシステムを支える基盤部分」を指す言葉です。

ITシステムを構成する次の3つの階層について知ると、ITインフラが理解しやすくなります。

3つの階層のうち、「プラットフォーム」と「インフラストラクチャー」がITインフラです。

ITシステムの3階層について、スマートフォンに例えながら具体的に解説します。

アプリケーションは、スマートフォンを例にするとブラウザやメールなど役割ごとにパッケージされた「アプリ」がアプリケーションの階層にあたります。

プラットフォームの階層に相当するのは、アプリを動かすために必要な基盤である「OS」です。

iPhoneであればiOS、AndroidスマートフォンであればAndroidがOSにあたります。

OSはアプリがネットワーク通信を行うための機能や、アプリが機器本体の記憶領域を使用するための橋渡しの機能などを担っています。

「インフラストラクチャー」はハードウェアの部分で、スマートフォンの例でいえば機器本体です。

スマートフォンを使う際に利用者が意識するのはアプリだけですが、OSや機器本体がなければアプリは利用できません。

インターネットサイトや業務用ソフトといったITシステムも同様に、上記の3つの階層から成り立っています。

利用者が意識していなくても、基盤のソフトウェア（アプリケーション実行基盤・データベース・OSなど）や機器本体（サーバー機器）が存在しています。

このように、ITインフラはITシステムのプラットフォーム・インフラストラクチャー部分としてITシステムを支えているのです。

ITインフラの主な構成要素と役割は次のとおりです。

各構成要素が互いに関連し合ってひとつのシステムを構成するため、インフラエンジニアには幅広い知識が必要です。いずれも利用者の目には見えにくいですが、システムの構成要素として重要な役割を果たしています。

IT業界はITの活用によって社会を支える役割を担っていますが、インフラエンジニアの仕事はその中でも裏方であるといえます。

ITサービスは利用者の目に見える部分（ブラウザで表示されるサイトや企業で使用する業務用ソフトなど）だけで成り立っているわけではありません。

目に見える画面を利用者まで届ける役割を果たしているITインフラの存在が不可欠です。

インフラエンジニアはITインフラの開発（企画・設計・構築）を行って新たなシステムの基盤をつくります。加えて、ITサービスの継続・維持・改善のためにITインフラのメンテナンスを行います。

扱う機器や製品は多岐にわたるため、幅広い知識が必要とされるのがインフラエンジニアです。

インフラエンジニアの仕事の工程

インフラエンジニアの仕事内容は、ITシステムを作り上げていく中のどの工程を担当するかで異なります。

ITシステムにはライフサイクルがあり、顧客の要望をもとに開発が始まってから破棄されるまでにいくつかの工程（フェーズ）が存在します。

ITシステムは規模が大きく利用期間が長期にわたるため、工程ごとに管理される場合が大半です。

この記事では、「インターネット通販サイト」の開発プロジェクトが発足した場合を例に、以下の各工程について解説します。

プロジェクトとは、IT業界における業務の管理単位です。

システムの規模やプロジェクトの方針によって、工程ごとに担当者が異なる場合と、一貫して担当する場合があります。上記の各工程について順に解説します。

インフラエンジニアの要件定義

「要件定義」は顧客の要望を明確にし、システム開発計画の立案を行うフェーズです。

ITシステムの開発は、顧客の要望をシステムによって叶えることを目的として始まります。

顧客の課題や要求を定義し、その実現のための計画を立てるのが「要件定義」です。

システム開発は要件定義をもとに進んでいくため、要件定義の質をどれだけ高められるかが開発プロジェクトの成功を左右します。要件定義では以下について把握・整理し、文章化（定義づけ）します。

はじめに顧客に対し、システム化により「どのような課題を解決したいか」・「何を実現したいか」について細かくヒアリングしていきます。

通販サイトの例でいえば、「インターネットで自社製品を売りたい」という大まかな要望をさらに深掘りする作業です。

ターゲットとなるサイト利用者はどのような層なのか、どのような手段でサイトに訪れてほしいのかなどを明確にしていきます。

要件定義は大きく分けると以下の2種類があり、必ず両方実施します。

• 機能要件定義
• 非機能要件定義

機能要件定義とは

機能要件定義では、顧客がシステムに求める機能を具体化します。通販サイトであれば下記のようなものが機能要件です。

システムに必要な機能とその実現方法を顧客目線で明確にします。

機能要件定義はインフラエンジニアとアプリケーション開発エンジニアが共同で実施する

要件定義はインフラエンジニアのみで実施することはありません。システムの開発は利用者の目に見える部分（コンテンツ）に対する要望から始まることが大半です。

そのため機能要件定義は、コンテンツ部分を担当するアプリケーション開発エンジニアが主導となって進める場合が多いです。

ITインフラの機能要件はコンテンツの機能要件の実現に必要な「システム構成」や「通信要件」などで、そう多くありません。

非機能要件定義とは

非機能要件定義では、性能・可用性・拡張性・運用・セキュリティなど、機能要件以外のすべての要素を定義します。

インフラエンジニアが力を入れる部分です。

通販サイト開発の場合、非機能要件の具体例は以下のとおりです。

非機能要件はシステム特有の要件であり、システムを実際に使うユーザーは意識していないことが多い一方で、システム構成を決定する上で重要な要素です。

要件定義書

機能要件・非機能要件は「要件定義書」として文書にまとめます。要件定義書は必ず顧客を含む関係者内でレビューを行い、内容を合意した上で次の工程に進みます。

要件定義書は要件定義フェーズの成果物であるとともに、次の設計フェーズで使われる重要な資料となります。

インフラエンジニアの設計・構築

「設計」は要件定義で定義した要件をさらに具体化していくフェーズです。

基本設計と詳細設計があり、基本設計では設計の方針や根拠を、詳細設計では実際の設定値（パラメータ）を定義します。定義した内容は、基本設計書・詳細設計書に記載して提出します。

基本設計とは

基本設計書はネットワーク・ハードウェア・ソフトウェアの構成を図や一覧で表現するほか、非機能要件についても具体的に記述します。

基本設計書に記載する主な内容は次のとおりです。

通販サイト開発の場合、「ウェブサーバー」と「データベースサーバー」を配置するのが一般的な構成です。

ウェブサーバーはサイトのコンテンツを人の目に見える形で提供します。
データベースサーバーは会員情報や購入履歴といったデータを保持・更新するために必要です。

サーバーの構成をシステム構成として記載し、ネットワーク・ハードウェアなどの切り口から具体的に記載するのが基本設計書です。

詳細設計とは

詳細設計書にはサーバーごとにOSやミドルウェアの設定値を一覧化します。

「この通りに設定すればシステム要件がすべて満たせる」という状態になるよう、方針を設定値に落とし込む作業です。

例えば通販サイト開発の「データベースサーバーの詳細設計書」では、使用するデータベースソフトの設定項目ごとに数値や選択項目を決定し記載します。

詳細設計書は、次に控えている構築作業で使われる重要な資料となります。

構築

「構築」は設計した通りにシステムを設定していくフェーズです。

実際に機器を構成図通りに接続し、機器やソフトウェアを操作して設定を行い、想定通りの役割を果たせるかどうかの稼働テストを行います。

構築にあたっては事前に「構築手順書」を作成し、手順書に従って設定を進めるのが一般的です。

稼働テストについても、事前にテスト項目と期待される結果を記載した「テスト仕様書」を作成して実施します。

構築・テストはコマンドやGUIなど、それぞれの機器やソフトウェア製品が提供している方法で操作します。

構築・テストの際は操作ログや画面のスクリーンショットを取得し、作業した証拠として設定済みの機器と合わせて顧客に納品します。

構築作業の方法はサーバーの配置場所によって異なるため、「オンプレミス環境」と「パブリッククラウド環境」に分けて紹介します。

オンプレミス環境の構築作業

オンプレミス環境の構築作業は、顧客の所有機器に対して設定を実施します。

ハードウェア機器はセキュリティ設備がそろっており耐震性能の高い「データセンター」と呼ばれる施設に設置されることが多いです。

そのため、構築担当のインフラエンジニアはデータセンターに入館して顧客のハードウェアに対して構築作業を実施します。

構成図に従ってハードウェアの物理接続を行い、詳細設計書と手順書に従ってOSインストールやパラメータの設定を行います。

稼働テストや運用の際に毎回データセンターに入館しなくてもいいよう、構築の初期段階で遠隔操作ができるように設定することが大半です。

パブリッククラウド環境の構築作業

パブリッククラウド環境での構築作業は、機器を直接操作するのではなくパブリッククラウドの操作画面で設定を実施します。

インフラエンジニアは顧客からメンテナンス用のアカウントを借り、パブリッククラウドサービスが提供している管理画面から遠隔操作で設定を行います。

ネットワーク機器の配置やサーバーの起動も管理画面上で操作できるため、物理的な接触をしなくても操作できます。

事前にパブリッククラウドサービスの管理画面の操作方法を理解しておく必要がある点が特徴的です。

インフラエンジニアの運用保守・運用監視

「運用保守・運用監視」は実際に稼働しているシステムを管理する工程です。

構築が完了し、システムの利用が開始されることをサービスリリースといいます。

運用保守・運用監視はサービスリリース後のフェーズで、対応内容としては以下のようなものがあります。

システムは非機能要件定義時に定められた運用要件に従って、設計・構築段階で監視の仕組みが導入されています。

監視する項目の例としては、CPU・メモリ・ディスク（データ保存領域）の使用率や、OS・ミドルウェアのエラーなどです。

以下、順に解説します。

監視中にアラートが挙がった際の対応例

監視アラート対応について、「通販サイトのウェブサーバーのOSでCPU使用率90%超えのアラートがあがった」場合を例に解説します。

まずは実際にサーバーにログインして、現状の値を確認します。確認時点で閾値（CPU使用率90%）を上回っている場合はログを確認し、顧客に対し原因と対策案を報告する場合がほとんどです。

閾値超えが続いている場合は原因のプロセスを確認し、状況に応じていずれかの対応をとります。

• 負荷の高い処理が落ち着く見込みがあれば様子を見る
• 停止してもサービス影響がないプロセスが原因であれば停止する
• すぐに負荷を下げなければサービス影響が出る危険性がある場合は、一時的に業務を縮小してでもプロセスやサーバーの再起動を実施する

いずれの場合も、対応策を検討した段階で顧客に報告し、指示を仰ぎます。

高負荷状態が続くとサーバーが停止しサイトに支障をきたす（サービス影響が出る）可能性があるため、判断や対応は慎重に行う必要があります。

障害対応の例

アラート対応と並ぶ運用保守・運用監視フェーズの重要な仕事が、障害対応です。

システム障害が発生した場合はプロジェクト内で障害対応の体制が取られ、復旧を最優先に行います。さらに根本原因の調査を行い、再発防止のための解決策を検討・実行します。

障害によるサービス停止は顧客のビジネスに関わる部分のため、迅速かつ慎重な対応が求められます。

OS・ミドルウェアのバージョンアップ対応

OSやミドルウェアは、製品の提供元が機能追加やセキュリティの向上を目的に定期的に新しいバージョンを提供しています。

例えるなら、スマートフォンアプリで利用しているアプリについて定期的にアップデートがかかるのと同様です。

OSやミドルウェアの新しいバージョンが提供されたら、原則はバージョンアップしていく必要があります。なぜならば、古いバージョンを使い続けていたら外部からの攻撃に弱くなってしまう等のセキュリティ上のリスクがあるからです。

OSやミドルウェアのバージョンアップは、インフラエンジニアが担います。

OSやミドルウェアのバージョンアップにおいても、ITインフラの構築作業と同様に手順書を作成して入念に準備した上で作業を実施します。

なぜならば、不用意にバージョンアップした結果システムが動かなくなってしまえばビジネス上の大きな損害を被るからです。

インフラエンジニアはとにかく「システムを止めないこと」が求められます。ITインフラに対して何か作業をしたい場合はその作業による影響を慎重に調べ、どうしてもシステムを止める必要がある場合のみ責任者へ相談するのです。

「よく調べないまま作業したらシステムが止まってしまいました」なんて事態を起こしたら、インフラエンジニアのマネージャーは責任を問われ降格や左遷されるのがIT業界では常識です。

週次/月次報告書の作成

運用要件によっては週次や月次でシステム利用状況などの報告書作成を行う場合があります。インフラエンジニアは報告資料を作成して顧客に提出・報告します。

日常の問い合わせ対応

顧客からの技術的な問い合わせへの回答や、必要に応じたログの調査も運用保守・運用監視フェーズを担当するインフラエンジニアの仕事です。

インフラエンジニアの1日・やること

インフラエンジニアの1日の仕事内容の例を紹介します。

リリースされた通販サイトにおけるウェブサーバーの運用担当者を想定しています。

9:00～10:00 チャットツール/メール確認・アラート対応

チーム内や顧客とのやりとりはチャットやメールが中心となるため、出社して最初にチャットやメールの確認をします。

前日の退社後から出社までの間に監視アラートがあがった場合は、必要に応じて確認・対応を行います。

緊急性の高いアラートが夜間に発生した場合は、夜間対応の担当者が調査して緊急対応する体制となっている場合が多いです。

10:00～11:00 定常業務：月次報告書の作成

運用保守担当者は月次報告書の作成などの定常業務が割り振られる場合があります。月次報告書の例としては、月間のリソース状況や、アクセス数の推移をまとめたものなどです。

報告書は顧客がシステムの状況を把握したり、拡張などの改善を行うための判断材料となります。

11:00～12:00 ミーティング

運用上の課題や未解決のアラート対応策などを話し合うために、プロジェクト内や顧客を交えてのミーティングが定期的に設けられている現場も多いです。

13:00～14:00 設定変更手順書の読み合わせ

例に挙げた1日では、午後にミドルウェアのバージョンアップを実施しています。

事前に準備しておいた作業手順書について共同作業者と最終読み合わせを実施し、作業に抜けや漏れがないよう備えてから作業を実施します。

14:00～16:00 設定変更（アプリケーション実行基盤のバージョンアップ）

サーバーの設定変更作業は作業者・再鑑者の2名体制で行うのが一般的です。

作業の内容によってはサーバーの停止起動が発生することがあるため、関係者へ作業予定を事前に周知し、作業開始時に開始連絡を実施します。

16:00～17:00 設定変更のエビデンスまとめ・報告

作業後は終了連絡を行い、エビデンスを報告書にまとめたうえで上長や顧客に提出して作業完了です。

17:00～18:00 スクリプト修正案の作成

日中にアラートが発報された場合は適宜対応します。アラート対応の一環としてサーバーのスクリプトの修正が必要な場合などは、検証を行ったうえで修正案を作成する仕事が発生することもあります。

まとめ

以上、インフラエンジニアの仕事内容について具体的に解説しました。改めてまとめると以下の通りです。

インフラエンジニアへの転職を検討している人は参考にしてください。