インフラエンジニアの仕事～オンプレミス開発案件～

今回は、インフラエンジニアの仕事について紹介します。

SIerの開発案件だと、オンプレミス（ここではクラウドの対義語として使用）の案件が多ので、その場合を例にとって紹介します。

ウォーターフォール型の開発に則った場合に各工程で行うことを説明します。ウォーターフォール型の開発についての詳細はここでは割愛します。

この記事では、一般的にイメージしやすいアプリ開発（プログラミングをしてアプリケーションを開発する）の案件との比較に重点を置いて説明していきます。

今回は分かりやすく、A社にOA基盤の開発を例にとって解説します。

ここでOA基盤とは、社員が日ごろの業務で使うPCのためのあれこれ　だと思ってください。例えばMicrosoft Officeやプリンターサーバー、メールサーバーなどです。

以下のような工程に沿って説明します。

• 要件定義
• 基本設計
• 詳細設計
• 構築
• 単体テスト
• システムテスト
• 商用移行

要件定義

開発するシステムにおいて、何をやるかと何をやらないかを決めます。

具体的には、A社のIT部門の担当者と話しながら、開発するシステムで実現することを明確にします。

OA基盤の場合だと、例えば以下のようになります。

また、この他にも以下のようなものがあります。

後に挙げたような要件を、非機能要件と呼んだりします。

この非機能要件はアプリ開発ではあまり出てこない要件であることが多いです。

なぜなら例えば、障害に耐えられるようにする（可用性担保）には、サーバーを複数台構成にしたり、定期的にバックアップを取得したりする必要があるからです。

基本設計

基本設計工程では、要件定義にて明確になった要件をもとに、具体的にどのように実現するかを決めていきます。

先ほどの要件を例にとると以下のようになります。

基本設計工程では、この粒度からさらに具体的に各サーバでどのような機能を使用するかまで決めます。

例えば、メールサーバーのOS、メールソフト、ネットワーク的な配置（DMZに置くなど）、一般的な設定項目など・・・

挙げれば切りがないのですが、基本設計で作成する基本設計書までは、一般的に顧客とのレビュー対象になっていることが多いです。つまり、お客さんと会話しながら決めていくことになります。

ここで、ある程度のシステム構成が決定します。

詳細設計

基本設計が終了したら詳細設計工程に入ります。

詳細設計では、基本設計書をもとにさらに詳細なパラメータを決めていきます。

そのようにして作成する設計書のことをパラメータ設計書・パラメータシートと呼んだりします。

また、この工程では詳細設計書と共に構築手順書も作成します。

具体的にサーバを構築するための手順となるようなものです。

このサイトで紹介いているWindows Server 2016　インストール手順のページなどをエクセルやワードなどで作成します。

構築

実際に構築を行います。SIerが受託する大規模案件などでは、大量のサーバを作成したり、クライアントPCのキッティングを行ったりするので、時には数百人で一斉に構築作業を行ったりします。

開発の折り返しくらいに当たりますが、ここまで問題なくプロジェクトが進行していれば、品質の高いパラメータシートと、構築手順書が出来上がっているはずですので、ここからはただの作業になります。

しかし、実際の開発現場でそこまで潤沢に時間とお金を割いているプロジェクトは少なく、前工程での負債を抱えたまま構築工程に入ることも多いです。

こういった中で、いかに自分の知識を活かして問題を解決していくかの見せ所でもあります。

アプリ開発案件では実際にプログラミングを行う部分に当たります。エンジニアとしては実機に触れることができる楽しい時間です。（うまくいけば）

単体テスト

構築が終わったら単体テストを行います。

ここでは主にサーバ単体で設計したパラメータ通りにサーバが設定されているかを確認します。

案件によって確認する粒度はことなりますが、基本的には設定したパラメータを全チェックします。

最近では、単体テストも自動化することが多いです。この辺はアプリ開発では当たり前となっているようですが、インフラのテストを自動化するのはなかなか難しいです。

例えば単体テストといっても、メモリダンプの設定などは、サーバにある種の障害を意図的に発生させ、ダンプをはかせるというようなことを行います。

仮想環境などでは仮想化ホスト側からカーネルパニックコマンドを発行したりもできますが、物理マシンだとそうもいきません。

なので、いまだに人海戦術でテストを消化することも多々あります。

結合テスト

単体テストが終われば次は結合テストです。

システムの構築がすべて終わった段階で、シナリオなどを用いて様々なテストを行います。

非機能要件のテストはこの段階で確認することが多いです。

例えば以下のようなテストです。

プロジェクトの終盤へ向かっている最中ですが、この段階でそもそも構成の間違いが見つかることもあります。

商用移行

結合テストまで終わったら、ほぼシステムとしては完成していますが、通常はここからリリースまでにさらに移行作業があります。

案件の規模などによって、商用の環境とは別に、開発環境やステージング環境を持っている場合があります。

この開発環境やステージング環境で構築・テストを行い、すべてバグを解消できたら商用環境へと移設します。

物理の場合は、ラック装置そのものの移行のこともありますし、仮想環境であればV2V（Virtual to Virtual)での移行の場合もあります。

まとめ

以上のような工程が一般的な大規模オンプレミス開発案件の流れです。

もちろん、案件によってこれらの工程がさらに詳細化されていたり、別の工程へと分岐したりします。

私は、オンプレミスの開発案件であっても今後はここまできっちりしたウォーターフォールは続かないのではないかと思っています。

理由は近年のプロダクトライフサイクルがどんどん短くなっていってると感じるからです。Windows UpdateのサイクルがWindows 10 / Windwos Server 2016以降から変更されたことや、他の主要なプロダクト、例えばOracleなどでも短くなっていく傾向にあります。

この辺の話はまた、別記事にしたいと思います。ここまで読んでいただき、ありがとうございました。