ITインフラ開発者を目指す方へ
1. ITインフラ開発者となるためにはまずなりたい自分をイメージする
1.1. どうステップを踏んでいけば？
私の経験上、独学でITインフラを学ぶための技術的な資料はいくらでもある一方で、それを設計するために、どのような考え方を元に設計すべきかという参考資料が少なく、試行錯誤するしかないのが現実でした。
また実際、さまざまな会社で行われる新人研修でもITインフラの内容が薄く、実務につながる設計思想を教えるわけではなく、技術理論ばかりが優先されます。
では、考え方(設計思想)や導き方はどこにあるかというと、それは先人の経験の中にしか存在しないのです。
もちろん、設計書にしっかりと理念や導き方を記載している人はいますが、その背景までは伺い知ることは出来ません。
思考の中ということは、具体的に考えているわけではないので、資料として残らず、後輩にはうまく伝わりません。
結局、職人と一緒で先輩の背中を見て成長の糧とするしかなかったのです。
もちろん、優秀な先輩の配下に配属されれば今まで培った技術、設計思想を教えてくれるでしょうが、もしそうでなければ、同期との技術的な差はあっという間に拡がるでしょう。
結局、手探りで仕事を覚えていくことになります。
そんな非効率な時間を過ごさないために、ITインフラ開発者を目指す人に少しでも参考になるように、私の考えを書き記します。
もちろん私の経験則から書き残すので
色々なベンダー、SIer、エンドユーザによって違うので、一概に記載した内容が全てマッチするとは思ってません。
(私もさまざまな現場で、困惑した覚えがあります。)
ですが、少なくとも流れや考え方は、基本的に同じだと考えていますので、参考になると思ってます。
(本当は、試行錯誤した方が身につくのですがｗ)
1.2. そもそもSEとは？ITインフラ開発者とは？
友人や親族に『お仕事は？』と聞かれると、多くの人はSEと答えるでしょう。
(私は、具体的にこんなシステムを作っていると話すことの方が多いですが)
SEと言っても、役割はいくつあるのでしょうか？と思うほど、多種多様です。
SE(システムエンジニア)職にはさまざまな種類があります。それぞれの役割を簡潔ですが以下に一覧を示します。
-
インフラ開発者(インフラエンジニア)
サーバ、ネットワーク、データベースなどのITインフラの設計・構築・運用を担当します。 -
アプリケーション開発者（アプリケーションエンジニア）
ソフトウェアやアプリケーションの設計・開発・テスト・保守を担当します。 -
営業（IT営業、セールスエンジニア）
ITソリューションやサービスの販売を担当し、顧客とのコミュニケーションを通じてニーズを把握し、提案を行います。 -
保守エンジニア（運用保守エンジニア）
システムやアプリケーションの運用・保守を担当し、トラブルシューティングやシステムの安定稼働を支援します。 -
サーバーエンジニア
サーバーの設計、構築、運用、保守を担当します。 -
ネットワークエンジニア
ネットワークの設計・構築・運用・保守を担当し、ネットワークの安全性とパフォーマンスを確保します。 -
データベースエンジニア
データベースの設計・構築・運用・管理を担当し、データの整合性とパフォーマンスを維持する。 -
セキュリティエンジニア
システムやネットワークのセキュリティ対策を担当し、不正アクセスやデータ漏えいを防ぐ。 -
クラウドエンジニア
クラウドサービスの設計・構築・運用を担当し、クラウド環境の最適化を図る。 -
プロジェクトマネージャー(PM)
プロジェクトの計画・進行・管理を担当し、目標達成のためのリソース配分やスケジュール管理を行う。 -
システムアーキテクト
システム全体の構造設計を担当し、技術的な指針を提供する。 -
テストエンジニア
ソフトウェアやシステムの品質保証を担当し、テストの計画・実施・評価を行う。 -
DevOpsエンジニア
開発(Development)と運用(Operations)を統合し、継続的デリバリーやインテグレーションを実現する。 -
AIエンジニア/データサイエンティスト
AI技術や機械学習モデルの開発を担当し、データ解析や予測モデルの構築を行います。 -
UI/UXデザイナー
ユーザーインターフェースやユーザーエクスペリエンスの設計を担当し、使い易いシステムやアプリケーションを作ります。 -
フロントエンドエンジニア
Webシステムのユーザーインターフェースの見える部分の設計を担当し、使い易いだけでなく、購買意欲が沸くような利便性の優れたシステムを作ります。 -
バックエンドエンジニア
WebシステムのユーザがWebの画面上で行った操作に応じて、内部で行われる処理の設計や開発、構築などを行います。 -
広告エンジニア
Web広告の提案から設計、開発を行うことはもちろん、そのWeb広告が問題なく機能するか否かのテストも行います。 -
ITコンサルタント
ITを活用して企業の課題を解決する専門家です。問題を明確にし、解決のための助言や提案を行います。 -
プログラマー
SEなどが作した設計に基づき、プログラミング言語を用いてシステムやソフトウェアを作成する。 -
テクニカルサポート
企業が提供する製品・サービスに対する消費者からの問い合わせに、電話やメールで対応する。 -
社内システム(社内SE)
社内の情報システムの開発、運用、管理が主な仕事。企業によってはIT関連全てが業務範囲となる。 -
製品開発／研究開発
新しい技術およびIT製品の開発を担当するポジション。ハードウェア・ソフトウェア双方の開発に関わる。 -
品質管理(QC)/品質保証(QA)
企業が提供する製品・サービスの品質を客観的にチェックする仕事。品質向上のための提案なども行う。 -
SEOエンジニア
検索エンジンの実験・研究を行い、SEO実行計画の策定や指示、開発をする。
そんな中、ITインフラ開発者とは？
1.3. ITインフラ開発者の仕事とは？
多分、会社もしくは会社の先輩に『業務内容は？』と尋ねると『システムの基盤となる、「ネットワーク」「サーバ」「ストレージ」などのハードウェア関連や「OS」「通信制御」「ミドルウェア」「セキュリティ」「運用」などを設計・構築・試験・移行が主な業務』と答えるでしょう。
それだけ、聞いただけでも、学ぶべき事柄が多く、それは大変そうだと感じると思います。
でも、それだけが全てではありません。
仕事をする上では、以下のようなことも必要なのです。
- アプリケーション開発者の要望をヒアリング
- アプリケーション開発者にOSやミドルウェアの機能や使い方をレクチャー
- アプリケーション監視のためのヒアリング
- 既存システムとの接続のための環境をお客様からヒアリング
- オンプレでの機器設置の場合は、データセンター管理者との調整
- 設置作業をするCE(カストマーエンジニア)と調整
- 既存システムとの接続試験の際には、お客様や既存システム保守エンジニアとの調整
1.4. 技術向上するためには
技術的な知識を会得するなら以下を参考にするとよいだろう。
まずは、基本的なことをしっかりと学ぶほうが、結果的に上達の近道だと思います。
2.ITインフラ設計とは
ITインフラ設計とは、システムのインフラ、すなわち業務アプリケーションが搭載される情報システムの環境(コンピュータやネットワーク等)を設計することです。
ソフトウェア基盤、ハードウェア基盤をまとめてシステム基盤(システムインフラ)と呼びます。
情報システムの全体構成を以下に示す。
| 種別 | レイヤー | 具体例 | アプリケーション | アプリケーション | Java、PHPなどのプログラム言語を使用した業務プログラム |
| 業務通信機能 | 業務通信の送達確認や再送、非同期通信、通信障害解析ログの生成など | |
| アプリケーション 共通の制御機能 |
業務のエラーハンドリング、文字コード変換、ユーザ認証、プリンタ制御など | |
| ソフトウェア基盤 | システムの制御機能 | クラスタリング、ホットスタンバイによるフェイルオーバなど |
| ミドルウェア | データベース、メッセージ連携、データ連携、トランザクション処理、ジョブ管理など | |
| 仮想環境 | 仮想マシン、仮想I/F、仮想ディスク、割り当てCPU、メモリなど | |
| OS | ファイルシステム、デバイスドライバ、OS機能設計、起動デーモンなど | |
| ハードウェア基盤 | ネットワーク | 回線、ルータ、スイッチ、負荷分散、ファイヤウォールなど |
| ストレージ | ディスク装置、テープ装置など | |
| サーバ | CPU、メモリ、I/Fなど |
2.1 インフラ設計の大まかな流れ
従来のウォーターフォール型開発の場合は提案、要件定義、基本設計(外部設計)、詳細設計(内部設計)、構築、試験(テスト)、移行というそれぞれの開発工程の境が明確なのに対し、アジャイル開発やプロトタイプ開発などは、これらの各工程の境目が曖昧で、「目に見えるモノを作りながら仕様を固めていく」というスタイルを取ります。
一般的にウォーターフォール型開発は、ベンダーやSIerでは提案、要件定義、基本設計までは上流工程と呼び、詳細設計(内部設計)、構築、試験(テスト)、移行を下流工程と呼びます。
ウォーターフォール型開発の大まかな流れとしては以下のようになります。
<インフラ開発>
2.2.上流工程から下流工程までの詳細な流れ
上流工程から下流工程までの顧客とのやりとりを踏まえた詳細な流れは以下のようになります。
-
RFI(Request for Infomation,情報提供依頼書)
お客様が契約や調達、予算調整の事前準備として、ベンダーに情報の提供を求めるための依頼書。 -
RFP(Request for Proposal,提案依頼書)
ベンダーにシステムの提案書を作成してもらうための依頼書。
提案の範囲、骨組みとなる要件、必要条件、十分条件、予算、納期、スケジュールを明確に定義する。逆に、ベンダーから自由に提案してもらう部分は限定的にする。 -
情報提供、概算見積もり
RFIの回答は、製品カタログ、パンフレット、事例集などで、価格は詳細な見積もりではなく標準価格や参考価格となる。そのため、回答期限は１～２週間程度。
インフラ開発者としては、ざっくりとしたハードウェア、ソフトウェアの選定、システム構成を見積もりの元ネタとして作成。 -
提案書
RFPを元に、システムの提案だけでなく、プロジェクト推進に関わる合意ポイント、方法、納品物の取り決めをします。
それに伴うハードウェア、ソフトウェア、納品物、期間や人件費の見積もりも含めた資料を提示します。
インフラ開発者としては、見積もりに必要なハードウェア、ソフトウェアの選定、システム構成、インフラにかかる人件費の見積もりが必要となります。 -
要求定義(要求仕様書)
「～がしたい」という利用者の希望、ビジネスで何が必要かを記述したもので、事業運用をオペレーションレベルで考え、それを実現するコンピュータシステムへの要求仕様書を作成する。RFPとほぼ同じですが、違いがあるとすれば、RFPにはプロジェクト要件や見積もり条件が含まれる一方、要求仕様書には含まれない。要求仕様書には機能要求、非機能要求が記載されています。 -
要件定義書
システムの範囲を決定します。何を作るか、何を作らないかを明確にします。
システムの機能やDB・通信などの利用方法を開発する側が作成します。
RFP/要求仕様書を元に、要求の粒度をそろえ、要求に対する仕様を記載して要件とし、顧客の利害関係者と合意を取ります。
※ITインフラのRFPや要求定義書は本来、顧客が作成するものですが、実際はRFP、要求定義書から開発側が作成し、顧客と合意の上、次の行程に移ることが多いです。
最近では、非機能要求グレードに沿って資料を作成することが多いです。
-
要件確認書
要件定義書を元に、ベンダーとしての実現方法と実現可否を合意するための資料です。(実際は、レビュー指摘表や課題表で終えることが多いですね。) -
正式見積もり
要件確認書で合意した、ハードウェア、ソフトウェア、開発工程にかかる人件費を見積もる。 -
開発計画書(プロジェクト計画書)
要件を合意した後に正式に契約となります。ベンダー側のプロジェクトマネージャは、今後の進行方針、日程、技術者のアサイン、開発環境の準備、納品物(検収内容)の取り決めた内容を計画書にまとめ、お客様と合意し、その内容を開発メンバーに周知します。 -
基本設計書(外部設計書、非機能設計書、概要設計書とも言う)
システムの目的と概要を含め、要件定義書に書かれた内容を開発者として具体的にどう実現するかを記載し、詳細設計書の指標とする。 -
詳細設計書
基本設計書をもとに更に詳細に取り組む必要がある内容を詳細に設計し、パラメーターシートを作成するうえの方針を記載する。
パラメーターシートは、設定すべき項目を洗い出し、設定値を設計する。
実際の構築の際の手順書となる構築手順書も作成する。
また、運用で使用するスクリプトをコーディングする。 -
構築
構築手順書およびパラメーター設計書を使い実機を構築する。 -
試験計画書
試験の日程、試験の概要とその方針、試験の評価方針を計画書に記す。
結合試験やシステム試験をする際の他システムとの連携内容や実施する内容も計画書に記載し、お客様に調整いただく内容を明示的にする。
また、基本設計書で設計した性能試験の詳細な負荷方式や試験ツール、試験データ、試験を実施するさいの既存システムの影響度などを記載し、お客様と合意するための資料。 -
試験データ準備
各試験を実施する際に必要となるデータを作成し、システムに配置する。 -
単体試験項目書、試験シナリオ
ITインフラの単体試験は、他システムおよび他機器との接続を伴わない試験を実施する。詳細設計書やパラメーターシート、運用スクリプトが設計通り設定・動作するかを試験する。
また、試験を効率的に実施するため試験シナリオ書も作成する。 -
結合試験項目書、試験シナリオ
ITインフラの結合試験は、他システムおよび他機器との接続を伴う試験を実施する。
また、基本設計書(可用性、性能、運用、セキュリティ、拡張性、保守性)に記載している設計が、想定通りの動作をするかの試験も実施する。 -
システム試験項目書、試験シナリオ
ITインフラのシステム試験は、システム全体として要件定義書の内容を満たしているかの確認のための試験を実施する。 -
試験結果報告書
試験結果と試験計画書で策定した評価基準を満たしているかの報告書を作成する。 -
受入れ試験
お客様が実際にシステムを使用し、要件を満たしているかの確認のための試験する。 -
リリース判定結果
お客様が受入れ試験結果を踏まえ、リリース判定の合否を連携し、合格の場合は移行工程に移る。 -
移行計画書
システムの移行方式を設計し、移行の日程、移行概要とその方針、移行の評価方針を計画書に記す。 -
移行手順書
システムの移行に必要な手順書、タイムスケジュールを作成する。 -
移行リハーサル
移行手順書とタイムスケジュールに実機を使用し確認する。 -
移行
移行リハーサルで確認した手順書とタイムスケジュールを使用し、サービス開始に向けての作業をする。 -
検収
プロジェクトの納品物をまとめ、結果を報告し、お客様との合意により契約終了となります。
3.おわりに
インフラ開発者を目指す方がこれを読んだら、仕事の範囲が非常に広いと感じたかと思います。
しかし、その広さからこそやりがいも面白みも感じるでしょう。
ただし、ありがちな問題として、お客様が求める『期待』を忘れシステムを構築することが目的化してしまい、魂のこもっていないシステムができあがってしまいます。
お客様の期待は、「売上を増やす」こと、「コストを削減する」ことです。
さらにはそのシステムをエンドユーザが使うことで利便性を感じ、それを見たお客様が満足できることが、本当の我々への『期待』なんです。
この『期待』こそが、我々インフラ開発者の糧であり、プロフェッショナルとしての責務だと認識してください。
だからこそ、お客様本位、SIerもしくはベンダー本位でもなく、お互いの観点でエンドユーザが使い易いシステムを創出するための意見を出し合い考えるべきなんです。
プロフェッショナルなのだから、ベストは当たり前なんです。
ベストではなく、エクセレントを目指しましょう。
エクセレントを目指さなければ、ベストにも届かないと、心に刻みましょう。