要件定義（インフラ）タスクの進め方の概要

今回はインフラ構築における要件定義タスクの進め方について、概要を解説します。

システム構築フェーズの最初の工程は要件定義工程です。
要件定義工程はアプリケーション開発、インフラ構築、移行、運用保守、ユーザー教育、それぞれの観点に対して各種要件を固め、計画を具体化する工程です。
システム構築フェーズの一番最初の工程であり、お客様との密なコミュニケーションが必要で難しい工程でもあります。

今回は要件定義工程の中でもインフラ構築で実施する要件定義を解説します。
要件定義工程は経験がものをいう上流工程ですので、上流工程に強くなりたいと思うなら、先輩について経験できるよう、知識を吸収して機会があれば積極的にチャレンジしてみると良いと思います。

尚、ここではインフラ構築の担当者のことを基盤担当、アプリケーション開発の担当者のことをアプリ担当と呼ぶことにします。

インフラ構築における要件定義では、基盤要件定義と基盤設計を行う

インフラ構築における要件定義の作業は、基盤要件定義と基盤設計になります。

それではひとつずつ詳しく見てみましょう。

基盤要件定義では非機能要件を定義し、アーキテクチャー設計やサイジングを行い、処理方式を定める

基盤要件定義のゴールは、大きく以下の3つです。

非機能要件と実現方針を定義する

まずシステムに対する非機能要件を定義していきます。

非機能要件定義を実施する際の役割分担はプロジェクトによって異なりますが、私の経験では基盤担当が主担当をすることが多かったです。

ただ、非機能要件はシステム全体の視点で要件整理が必要になりますので、基盤担当だけで実施することはできません。基盤担当が旗振り役になり、アプリケーション開発など他の担当者から要件となる情報を吸い上げて、要件を整理します。

また各要件に対する実現方針（どのように実現するかの概要）もあわせて検討し、次のアーキテクチャー設計のインプットとします。

各要件を基にアーキテクチャー設計・サイジングを行い、必要な製品のスペック・数量を確定する

要件定義（アプリ）タスクでも記載しましたが、要件定義工程における重要なポイントの一つに、構想立案フェーズで実施した見積を再見積し、見積精度を上げることがあります。
インフラ構築観点で言えば、基盤担当の作業量（工数）と製品コストの見積精度を上げることになります。

見積精度を上げるためには、アーキテクチャー設計を行い、システム構成や利用する製品を決め、サイジングを行って各製品のスペックや数量を決める必要があります。

アーキテクチャーはシステム構成の全体像を表すものであり、どんなサーバーや製品を利用してシステムを構成するかを示したものです。
構想立案フェーズで見積をする際に事前に仮置きしたシステム構成をベースとして、機能要件、非機能要件、テスト要件、移行要件、運用要件を加味して設計します。

尚、ここで設計したアーキテクチャーやサイジングは机上評価であり、いわば想定（仮決め）です。
最終確定となるのは、プロジェクト終盤のシステムテストにて実機を使って要件を満たすことができるかを検証し、必要に応じて調整を施した時点になります。

アーキテクチャーには、システム毎に基本の型のようなものがあります。
例えば、

のような感じです。

アーキテクチャー設計では、機能要件や非機能要件、他社事例などを基にアーキテクチャーの基本型を選定し、各要件を加味して加筆・修正していきます。

アーキテクチャー設計でアーキテクチャーが定まったら、ユーザー数やデータ量などの非機能要件を基に各サーバー（PaaSの場合はPaaSサービス）のサイジング（スペック、エディションの選定）を行います。

サイジングの仕方についても、ベンダーが提供するサイジングツールや他社事例などを参考にします。
例えばSAPで言えばSAP社がサイジングツールを提供しています。その他の場合も、SIerや製品ベンダー担当者に情報提供を依頼すると教えてくれることもあります。

また、テストや移行の要件（やり方）も加味し、どんな環境を用意する必要があるかも検討します。
例えば、開発環境、テスト環境、本番環境、トレーニング環境のような情報です。

これらの情報が揃うと、基盤担当の作業量（工数）、購入が必要な製品のスペックと数量が導出できるので、より精度の高い再見積が可能になります。

各種処理方式を定める

プロジェクトのメインストリームに視点を移すと、次工程ではアプリケーション開発の基本設計が行われます。

基本設計を効率的に進めるには、採用したアーキテクチャーや利用する製品によって技術的に実現可能・不可能なこと、得意・不得意なことを頭に入れておく必要があります。

製品独自の仕様については製品のマニュアルやベンダー問合せで把握できますが、それだけでなく製品の使い方も標準化しておくと、出来上がったものがバラバラになることを防ぎます。

また、製品を複数組み合わせたアーキテクチャーはそのプロジェクトのオリジナルなので、採用した製品群を利用した処理の流れの概要を頭に入れておくと、技術的な手戻りリスクが低減できます。

このあたりを基本設計が始まる前に基盤担当が整理して、アプリ担当に伝えるのがベストです。

今回のアーキテクチャーに対し処理の流れを整理したものを処理方式と言います。
具体的には、製品・フレームワーク・共通部品・プログラムなどを通じた処理の流れを定義したものであり、処理方式には

などがあります。

例えばオンライン処理方式は、ブラウザ上の画面でボタンを押したら、クライアントのプログラムからネットワークを介してサーバーへ伝わり、サーバーでは製品・フレームワークなどを通じて業務処理プログラムが呼ばれ、共通部品などを利用しながらDBへアクセスし、結果をクライアントへ返す、などの一連の処理の流れを定義したものになります。

またバッチ処理方式は、ジョブ管理基盤上にスケジュールされたジョブからスクリプトが呼び出され、スクリプトから製品・フレームワークを介してバッチプログラムが呼び出され、プログラムがDBやファイルにアクセスしてデータ加工・データ出力を行う、というような流れを定義したものになります。

いずれも採用したアーキテクチャー・製品により基本型があるので、過去の事例などを参考に今回用の処理方式を定めます。

大きなプロジェクトではアプリ担当と基盤担当が分かれているので、基盤担当が処理方式をベースに設計ガイドラインにまとめて、アプリ担当がそれを作業上のお作法として理解し基本設計を進めていく流れになります。

基盤作業の難しさはアプリケーション開発の一歩前を常に走り続けること

基盤担当の作業の難しいところは、アプリケーション開発が作業するのに必要な情報や環境を整理して提供する必要があり、常にアプリ担当の一歩前を走り続けないといけないことです。

例えば、基盤要件定義ではアプリケーション開発や移行、運用保守の要件定義と並行で進む一方で、次工程におけるアプリ担当の基本設計作業に先んじて必要な情報をまとめ提供する必要があります。

また、アプリケーション開発の開発・単体テストをするにあたっては、（必要に応じて）開発環境用のサーバーを作業が始まる前までに用意します。

そのため、基盤要件定義はある程度決め打ちで進め、各要件が固まってきたら矛盾や不足がないかを確認し、必要に応じて修正するようなやり方をせざるを得ません。
周りとコミュニケーションを図りながら、気を遣う作業になります。

基盤要件定義のアウトプット

基盤要件定義のアウトプット（成果物）としては、要件定義書の内、以下のパートが挙げられます。

基盤設計では環境構築に向けたパラメーター・スクリプト設計や、基本設計で必要なものを準備する

基盤設計は、環境構築に向けたパラメーター・スクリプト設計や、アプリケーション開発の基本設計で必要になるものを準備します。

環境構築に向けたパラメーター・スクリプト設計

次工程におけるインフラ構築の作業としては、アプリケーション開発の開発作業に先立って、各環境の環境構築に着手します。
（一番最初は開発環境の構築から着手します）

環境構築は、以下のステップで実施し、必要があります。

プラットフォームについては、最近はクラウドを利用することが多くなりました。
アーキテクチャーと今回選定したクラウドベンダーの仕様に合わせて、まずはプラットフォームやサーバーOSを手配します。

サーバーOSが手配できたら、まずOSの設定を行う必要がありますので、OSのパラメーター設計を行います。

OSの設定ができたら、ミドルウェアのインストールが必要になりますので、インストーラーや導入手順書を用意します。

ミドルウェアを稼働させるためにはパラメーター設定が必要になりますので、ミドルウェアのパラメーター設計を行います。
クラウドのPaaS環境を利用する際は、PaaS環境に合わせたパラメーター設計を行います。

パラメーター設計はミドルウェアの中の話ですが、逆にミドルウェアの外側として、製品を起動・停止したり、バックアップ・リストアのために、スクリプトを用意する必要があります。ジョブ毎にスクリプト設計を必要に応じて行います。

また、Java言語のようにフレームワークや共通部品を利用する場合は、フレームワークや共通部品の設計作業も行います。

アプリケーション開発の基本設計で必要になる設計ガイドラインを準備する

アプリケーション開発の基本設計では、画面・バッチ・帳票・インターフェースの各機能に対して仕様を詰めていきます。

その際に、基盤（ミドルウェアやフレームワーク、共通部品）で技術的にできること・できないこと、得意なこと・不得意なことを踏まえて、使い方や設計時の考慮点をまとめた設計ガイドラインを作成します。

設計ガイドラインは、処理方式をインプットにして作成します。
画面・バッチ・帳票・インターフェース毎に設計作業で考慮すべき点や、設計をする上での設計書フォーマットや記載例、命名規約を載せます。

設計ガイドラインのポイントは、シンプルかつ具体的に記載し、ボリュームを最小限にすることです。
ボリュームが多いと、アプリ担当が理解するのに負担になりますし、せっかく記載されたことも守ってくれなくなる為です。

基盤設計のアウトプット

アウトプット（成果物）としては、以下が挙げられます。

• 基盤設計書（パラメーター設計、スクリプト設計）
• 設計ガイドライン（画面・バッチ・帳票・インターフェース）

まとめ

要件定義（インフラ）タスクでは、

を行います。

次工程以降を見据えて、要件定義（インフラ）を通じて、行うべきことは以下の2つです。

より詳しい内容を知りたい方は、以下の書籍をオススメします。

システム開発のプロセスを記載している書籍で、個人的にバイブルになるほど良い本は正直出会えていないのですが、以下は比較的全体像が書いてある印象です。
そのまま使えるほど具体的なところまで踏み込んではいないものの、参考にはなると思います。

プロジェクト実行大全 Kindle版