プログラミングだけが仕事じゃない！「機能を作る」と「動かす土台」の違いから理解するSIプロジェクトの工程(後編)

前編の振り返り

前編はこちらから。

前編ではSI案件の初期段階である「要件定義」「基本設計」「詳細設計」の3つのフェーズについて解説しました。

これらのフェーズは、お客様の要望を深く理解し、それを具体的なシステムの設計図へと落とし込んでいく、いわば「システムを考える」工程でしたね。

後編では、いよいよ設計されたシステムが実際に形になり、お客様の元で稼働するまでの「開発/構築」「検証」「本番導入」の3つのフェーズについて、さらに詳しく掘り下げていきます。

皆さんが「エンジニアの仕事」と聞いてイメージするコーディングや構築作業が、どの段階で行われるのか、そしてその後の重要な工程について見ていきましょう。

フェーズ4：開発/構築

基本設計、詳細設計が完了したら、いよいよ「開発/構築」フェーズへと突入します。

このフェーズで、設計書に基づいた実際のシステムが作られていきます。

「エンジニアの仕事」と聞いて多くの方が想像されるであろう、プログラミングや機器のキッティング作業がここで行われます。

これまでのフェーズが「システムを考える」仕事だったのに対し、このフェーズは「システムを作る」仕事と言えるでしょう。

開発/構築作業は、一部の例外を除き、基本的にお客様の実際の稼働環境とは分離された環境で行われます。

これは、お客様の業務に影響を与えないようにするため、そして、開発中のシステムが安定稼働するまで十分にテストを行うためです。

アプリケーションエンジニアの視点
アプリケーションエンジニアは、詳細設計書に基づいてプログラミング言語を用いてコードを書き、システムを開発していきます。
お客様の業務ロジックを正確に実装し、ユーザーが利用する画面や機能を作り上げていくのが主な役割です。いわゆる「コーディング」と呼ばれる作業がこれにあたります。

インフラエンジニアの視点
インフラエンジニアは、詳細設計書に基づいてサーバー機器の設置、OSのインストール、ネットワーク機器の設定、ミドルウェアの導入などを行い、システムが稼働するための基盤を構築していきます。
これは「キッティング」や「環境構築」と呼ばれる作業です。

どちらのエンジニアも次のフェーズである「検証」を行うための準備として、設計通りのシステムや環境を正確に作り上げることが求められます。

フェーズ5：検証

開発/構築フェーズが完了したら、次に「検証」フェーズに入ります。

ここでは、実際に開発・構築されたシステムが、お客様の当初の要件をきちんと満たしているか、期待通りに動作するかを確認する非常に重要な工程です。

このフェーズでは、様々なテストケースを用いて、システムの品質と信頼性を徹底的にチェックします。

単に正常に動作するかだけでなく、異常な状況や例外的な操作に対するシステムの挙動も確認します。

アプリケーションエンジニアの視点
アプリケーションエンジニアは、作成したテストデータを用いて、システムが要件通りの処理を正確に行うかを確認します。
例えば、入力されたデータが正しく処理され、期待通りの結果が出力されるか、画面の表示は正しいか、といった点を検証します。
また、ユーザーが誤った操作をした場合に、システムが適切にエラーを検知し、分かりやすいメッセージを表示するか、といった例外パターンや異常時の動作も確認します。

インフラエンジニアの視点
インフラエンジニアは、構築したインフラ環境が設計通りに機能しているか、安定稼働するかを検証します。
例えば、ネットワークの疎通テスト、サーバーの負荷テスト、データベースの接続テストなどを行い、各機器やソフトウェアが正しく連携しているかを確認します。
さらに、機器の故障やネットワーク障害といった事態を想定し、あえて障害を発生させて、システムが自動的に復旧するか、あるいはサービスが維持されるかといった、耐障害性のテストも行います。

この検証フェーズで問題が発見された場合は、開発/構築フェーズに戻って修正を行い、再度検証するというサイクルを繰り返すことでシステムの品質を高めていきます。

フェーズ6：本番導入

厳密な検証フェーズをクリアし、構築したシステムに問題がないことが確認できたら、いよいよ「本番導入」フェーズです。

このフェーズでは、開発・検証環境で作り上げたシステムを、お客様が実際に業務で利用する本番環境へと組み込み、稼働を開始させます。

本番導入は、お客様の業務に直接影響を与えるため、とても慎重に行われる必要があります。

多くの場合、事前に詳細な導入計画が立てられ、万が一の事態に備えたバックアップや切り戻し（元の状態に戻す）の準備も行われます。

アプリケーションエンジニアの視点
アプリケーションエンジニアは、主に論理的な切り替え作業が中心となります。
例えば、新しいシステムへのデータ移行、旧システムからの切り替え、ユーザーアカウントの設定、業務フローの変更に伴う物理的な作業（例：新しいシステムを利用するためのPC設定など）も含まれることがあります。
場合によっては、お客様の業務時間外である休日や夜間に作業を行うこともあります。

インフラエンジニアの視点
インフラエンジニアは、物理的な機器の設置や配線、ネットワークの切り替え、サーバーの起動といった、物理的な作業がメインとなるため、基本的に現地での作業が前提となることが多いです。
インフラは様々なシステムの土台となっているため、本番導入作業は、お客様の業務に与える影響を最小限にするため、休日や夜間など、ユーザーが稼働していない時間帯に行われることが比較的多くなります。
これは、対象のシステム以外にも影響を及ぼす可能性があり、作業時間帯に厳重な制約が発生するためです。

一般的に、インフラ環境が整ってからその上でアプリケーションが稼働するため、実際のプロジェクトではインフラエンジニアの方が先に本番導入フェーズを迎えることが多いです。

まとめ

前後編にわたり、SI案件におけるシステム開発の流れを「要件定義」から「本番導入」まで、6つのフェーズに分けて紹介しました。

各フェーズにおけるアプリケーションエンジニアとインフラエンジニアの視点の違いも、ざっくりご理解いただけたでしょうか。

SI案件のエンジニアの仕事は、単にコードを書いたり、機器を設定したりするだけでなく、お客様の課題を深く理解し、それを解決するためのシステムを「考え」「設計し」「作り」「検証し」「導入する」という、多岐にわたる工程の連続であることがお分かりいただけたかと思います。

この記事が、これからITエンジニア業界を目指す皆さんにとって、SI案件の全体像を掴む一助となり、キャリアを考える上での参考になれば幸いです。

IT業界は常に進化しており、新しい技術や働き方が生まれていますが、この基本的なプロジェクトの流れは、多くの現場で共通する大切な考え方です。ぜひ、皆さんの今後の学習や就職活動に役立ててくださいね。