【第１回】社内インフラエンジニアのために（企画～リリース①）

前回：【連載】社内インフラエンジニアのために

お疲れ様です。
しらせです。

『社内インフラエンジニアのために』
最初は「企画～リリース」のフェーズ①です。

何事にもお金はかかるものです。

「ｘｘを導入したいのでｘｘ万円の稟議承認してください。」

こんな風に「ガチャガチャやりたいから100円ちょうだい」とねだる小学生のような話には誰も耳を傾けません。
効果・メリットデメリット、コスト、期間、いろいろなものを考慮して計画的に進めなければいけません。

今回は計画から実際にシステムの導入までをまとめます。

もくじ

計画（企画書）

何よりもまずは何を企んでいるのかを説明して、人の協力やお金を集める準備をしなければいけません。
パワーポイントやワードを利用して、企画書として資料にまとめることが一般的です。

「資料なんか作ってる時間がもったいない。」

という話を時々耳にしますが、相手に伝わることが大事であって資料の是非は問いません。

私の場合は、相手に伝えるためにまず自分の中で整理ができていないと嫌（というか苦手）なので毎回パワポで作っています。
この計画にはどんな未来があってどんな効果を出してくれるのか、参画者にも分かりやすく理解してもらって協力を得ることが重要です。

＜主な内容＞

1. 目的
2. 課題
3. 解決策とゴール
4. 効果
5. 費用（人、モノ）
6. スケジュール
7. リスク
8. 体制図、ステークホルダ

要件定義（要件定義書）

晴れて企画書のレビューが成功しプロジェクトとしてスタートができる状態になりました。

次は企画を実現するための細かな「要件」を詰めるフェーズです。

要件の定義は要件定義書という形で１つのドキュメントにまとめます。
プロジェクトを進める中で方針のズレや想定外を少なくし、最終的に出来上がるシステムに一貫性を持たせるために重要です。

個人的に要件定義で特に重視したいのが「どこから（誰から）」の要件なのかという点です。（要求定義といったりします）
会社のポリシーで決まっているのか？法律で決まっているのか？オレオレルールなのか？

要件にないことは記載する必要はありませんが、この後設計に進むにつれて「なぜこんな設計になったんだ？」とならないように理由を明記するようにすると後で救われたりします。

＜主な要件項目＞

1. はじめに
   
   1. 本書の目的
   2. 用語
   3. 別紙
2. プロジェクト概要
   
   1. 全体概要（内容、スケジュール、予算）
   2. スコープ（誰に対する、どんなシステム）
   3. 体制
   4. 連絡手段
   5. 成果物
3. 機能要件
   
   1. ユーザー機能
   2. 管理者機能
4. 非機能要件
   
   1. 性能要件
   2. 拡張要件
   3. セキュリティ要件（監査、ウイルス、暗号化、）
   4. 運用要件（定常、非常、）
   5. 設置場所要件
   6. 災害対策要件
5. 外部システム連携

システム構成検討

開発では後続作業として設計に入りますが、インフラの場合は先に必要となるハードウェアなどの基盤の整理を行います。

基本的に、企画の時点である程度のシステムの選定は終わっている必要がありますが、要件に沿って機器構成や保守サポートを決めておくと精緻な見積が可能です。

構成パターンが複数考えられる場合は、比較が可能な状態にしたうえでプロジェクトメンバー（もしくはそれ以上）で吟味して決めます。
導入する大まかな概算や納期が確定したら会社のフロー（稟議、契約、発注）に沿ってシステムの導入ができるように準備を進めます。

利用する機器やソフトウェアが確定していたり、スケジュールに対して納期が厳しい場合などは、後続の設計に影響のない範囲で事前に手配してしまうということも場合によっては検討します。

＜構成検討資料＞

1. システム構成パターン
2. メリット・デメリット
3. 費用比較
4. 納期
5. 方針

今回は企画からシステム構成検討までを通してまとめました。
次回からは具体的な設計に進みます。

以上
お疲れ様でした。