【インフラエンジニア】詳細設計とは?レビューについて

悩む男性 ITエンジニア(インフラ)
スポンサーリンク

インフラエンジニアが行う、「詳細設計」って何?
システム設計の「レビュー」ってどんな事をやるの?

といった疑問について、本記事では説明したいと思います。

▼筆者の紹介(ITエンジニアとしての業務経験)
・IT業界経験年数 8年(営業経験:4年 SE経験:6年)

<案件,業務経験要約>
・PCキッティング・展開
・各種ネットワーク詳細設計・構築
・各種サーバー設計・構築
・ヘルプデスク(Windows、Office365製品サポート)
・仮想化設計/構築
・クラウド設計/構築

筆者のSEプロフィールの詳細については、下記記事で紹介しています。

インフラエンジニアの業務工程(システム設計)の一つに、詳細設計という工程があります。

・詳細設計とは、具体的にどんな事をするのか?

・詳細設計書、パラメーターシートとは何か?

詳細設計」工程で行う主な内容、そして取り扱うドキュメントについても説明していきます。

また、システム設計においてレビュー」という重要な施策があります。

・レビューとは?
・レビューはどんな感じで行われるのか?

レビューは主に、ドキュメント等の内容の精査、確認を目的に行われますが、
実際、どのような流れでレビューが行われるのかについても説明していきます。


今回は、筆者の経験上の解釈で、詳細設計・レビューについて説明したいと思います。

スポンサーリンク

「詳細設計」とは、「構築」に必要な情報を定義すること

詳細設計」とは、システム設計における次工程の「構築」を行うために必要な情報を定義することです。
もう少し簡略化すると、「構築に必要なパラメータ等を定義する工程」となります。

詳細設計では、一般的に「パラメータシート」等がアウトプットドキュメント※として作成されます。

※パラメータシートとは別に「詳細設計書」といったドキュメントも作成する場合があります。
また、パラメータシートを「環境定義書」として取り扱ったり、ドキュメントの命名規則は会社毎に変わってきますので、注意してください。

スポンサーリンク

工程上の詳細設計の位置づけ

システム設計の工程において、詳細設計は基本設計の後、また構築の前の工程です。

▼システム設計の一般的な工程

要件定義→基本設計→詳細設計→ 構築


詳細設計は、基本設計の情報をインプットとして作成されます。

また、詳細設計を元に、次の「構築」工程へ進みます。

前回、下記記事において「基本設計」をカレー作りに例えて説明致しました。

今回は、下記のカレー作り「基本設計」をインプットに詳細設計を説明したいと思います。

スポンサーリンク

基本設計(要件定義)のインプット

詳細設計を行うには、前工程の基本設計情報が必要不可欠です。

ここで、前回のカレー作り基本設計の結果をまず取得したいと思います。

▼きちんと精査した基本設計の結果
ピーマン、たまねぎ、オクラ、レンコン・鶏肉が入った、甘口なバー○ントカレー

【インフラエンジニア】基本設計とは?何をやるのか?
https://www.syeg.net/infrastructure-engineer/how-to-basic-design/


ちなみに、「要件」は、「野菜が入った健康的なカレー」です。

では早速、これらの情報をインプットとして詳細設計を行っていきます。

パラメータシートとは?

パラメータシートとは?一言で言えば、「構築に必要な情報」(パラメータ等)です。

今回はカレーに例えていますが、カレー作りには「正確なレシピ情報」が必要となります。
(例:肉200g、カレー粉100g 等)

システム設計においても同様です。

サーバー作り(構築)には、「正確な情報」(パラメータ)が必要となります。
(例:OSの種類、OSのバージョン、インストールするアプリの種類、ハードディスクの容量等・・・)

これらの情報をまとめたものが、「パラメータシート」と呼ばれます。

詳細設計(レシピ・パラメータ)の作成(1回目)

今回は、カレー作りに例えていますので、パラメータシートを料理のレシピに置き換えて
設計を進めます。

基本設計をもとに、「カレー作りに必要な正確なレシピ」を定義する必要があります。


今回はまず、下記のように詳細設計(パラメータ{レシピ}の定義)を行いました。

▼野菜が入った健康的なカレープロジェクトの「詳細設計(パラメータの定義)」

・20gのピーマン 3個
・100gの玉ねぎ 1個
・10gオクラ 3本
・100gのレンコン 1/2個
・国産の鶏のもも肉 200g
・甘口バーモントカレー 100g 


さて、パラメータの定義が完了したわけですが、ここで、果たしてこのパラメータで問題ないのか?
をプロジェクトとして確認をする必要があるので、「レビュー」という工程を踏んで確認していきます。

レビューの実施

レビューとは、一言で言えば「設計書等のドキュメントが正しく作られているかの確認」です。

レビューはザックリまとめると、小学校の宿題を子供が実施し、学校に提出する前に親に見てもらい、合っているかを親に確認してもらう ようなイメージです。


通常、レビューはプロジェクトリーダーやプロジェクトマネージャー
またはシステムに精通した有識者(詳しい人)等が「レビュワー」となり、レビューを行います。

さて、さっそく今回の詳細設計(パラメータシート)をレビューしてもらいましょう。

実際のレビュー風景(ダイジェスト版)

それでは、実際に、レビューのやり取りの様子をダイジェストでお届けいたします。

レビューは、まず設計担当者が、設計したドキュメントについて説明をします。

▲設計者:今回は、「野菜が入った健康的なカレー」プロジェクトにおいて、基本設計の結果※をインプットにカレーのレシピ(パラメータ)を定義しました。

※「基本設計の結果:ピーマン、たまねぎ、オクラ、レンコン・鶏肉が入った、甘口なバー○ントカレー」

次に、レビュワーにより、「設計ミスが無いか?」「設計漏れが無いか?」などのチェックが行われます。

▲レビュワーA:今回のプロジェクト、カレーを作るんだよね?
カレーって事は普通「ご飯(ライス)」が含まれると思うけど、パラメータに「ライス」が無いのはなぜ?


おっと、さっそくレビュワーAさんからツッコミ(指摘)が入りました。

▲設計者:それは・・・たしかに、そうですね、カレーなのにライスが無いのはおかしいですね。

▲レビュワーA:今回のプロジェクトのカレーは、ライスが無いという要件定義はあるの?

▲設計者:いえ、要件定義では「ライス無し」という定義はありません。


▲レビュワーA:じゃあこれは「設計漏れ」だよね。ライスをパラメータに追加しておいてください。

▲設計者:はい、承知しました。パラメータを修正します。

レビュワーAさんからの指摘により、「ライス」というパラメータの定義が漏れていたことが判明しました。

次にレビュワーBさんからも指摘が入ります。


▲レビュワーB:ピーマン、玉ねぎ、オクラ、レンコン・・・普通カレーにこんなに野菜入れる?
野菜もっと少なくていいんじゃないの?野菜少ないほうが美味しいだろうし。


「野菜が少ないほうが美味しい」は、Bさんの個人的な感想な気もしますが・・・
設計者は答えます。

▲設計者:確かに野菜が通常のカレーより多いですが、要件定義で「野菜が入った健康的なカレー」という定義があります。
また、基本設計において「ピーマン、たまねぎ、オクラ、レンコン」の4種類の野菜を使用するという定義も行っていますので、今回は、4種類の野菜をパラメータとして定義しています。


設計者は、詳細設計のインプット情報(要件定義・基本設計)を説明し、正当性を説明します。

▲レビュワーB:あ、基本設計で決まってたの。それならそれでいいです。

レビュワーBさんはどうやら要件・基本設計をあまり知らなかったようです。
Bさんからの指摘は特に問題の無い指摘でした。

最後に、レビュワーAさんから別の指摘が入ります。

▲レビュワーA:鶏肉200g、カレー100gねぇ・・・そもそも、このカレーって何人前作るの?
この分量だと、1~2人前くらいしか作れなさそうだけど。

▲設計者あ、そういえば・・・

レビュワーAさんから、「何人前のカレーを作る想定なのか?」という指摘が入りました。
しかし、設計者はこの点について見落としていたようです。

▲設計者何人前作るか」というのは、見落としていました。申し訳ありません。

▲レビュワーA:あ、そうなんだ。 じゃあどうする?

▲設計者顧客に確認をして、何人前を作る必要があるか(要件・基本設計)を確認します。

▲レビュワーA:そうだね、ここは要件定義・基本設計段階でも漏れてしまった項目だったね。
情報が不足しているので、顧客に確認を取ってください。

▲設計者:はい、承知しました。

レビュワーAさんからの指摘により、「何人前のカレーを作る必要があるのか」について設計漏れがあった事が判明しました。顧客に要件を再確認し、パラメータへ反映させていく事となりました。


今回のレビュー結果

以上で今回の詳細設計(カレーのレシピ)の第1回レビューが終了しました。
レビューの結果は以下の通りです。

野菜が入った健康的なカレー 詳細設計 第1回 内部レビュー

【指摘1】
・カレーのレシピだが、「ライス」のパラメータが入っていない。
ライスが無いのは要件に含まれているのか?

「対応内容」
ライス無しは要件には含まれていない。よってライス有りが正しいパラメータとなる。
ライスをパラメータに追加する。

指摘区分:「設計漏れ」

【指摘2】
・ピーマン、玉ねぎ、オクラ、レンコンと多くの野菜がパラメータに定義されているが、
野菜の種類はもっと少なくてもいいのではないか?
 →野菜は要件定義・基本設計で定義された通りとなるため、これ以上少なくすることはできない。

指摘区分:「非該当」

【指摘3】
・このカレーは、そもそも「何人前」を作る想定なのか?
現在の分量では1~2人前程度しか作れないが、構築結果の量は1~2人前で問題ないのか?

「対応内容」
作成後の「総分量」については確認が行われていなかったため、
顧客に「総分量」について確認を行い、パラメータへ反映されていく。

指摘区分:「設計漏れ」


レビューの結果、「ライスの追加」「何人前を作るのか?(総分量)の確認」という指摘が判明しました。

今回の判明をもとに、詳細設計の修正を行っていきます。

詳細設計書の修正、そしてレビューの2回目へ

前回のレビュー結果を下に、詳細設計を下記のように修正しました。

▼野菜が入った健康的なカレープロジェクトのパラメータ(修正後)
前提条件:大人4人分の分量を作成

・20gのピーマン 6個
・100gの玉ねぎ 2個
・10gオクラ 6本
・100gのレンコン 1個
・国産の鶏のもも肉 400g
・甘口バーモントカレー 200g 
・ごはん 600g

【変更点】
・ライスが抜けていたため、ライスを追加しました。
・4人前を作るという事が改めて判明したため、全体的に分量を変更しました。

詳細設計の修正が完了したため、再度、レビューを実施し、詳細設計書の確認を行っていきます。。。


詳細設計は、基本設計をインプットに、構築に必要なパラメータを煮詰めていく大事な工程

いかがでしたでしょうか。

今回もシステム設計を「カレー作り」に例えて説明をさせていただきました。

インフラにおけるシステム設計でも、基本的には同じように当てはまります。

例えば、「小学校生徒に配布するのノートパソコンのシステム設計(ハードウェア設計:ドライブ容量)」では、

OS領域として50GB、アプリケーション領域として50GB、予備領域として30GBという基本設計をインプットに、
容量130GBの領域をCドライブに割り当てる」という「詳細設計(パラメータ)」を定義するといった感じです。

実際はパラメータシートとして、下記のようなパラメータが定義されていきます。

ドライブ名:ローカルディスク
領域:130GB
ドライブ文字:C

これらの詳細設計の情報は、次工程の「構築」を行う上で非常に重要な情報となってきます。

なぜなら、パラメータは構築を行う上で絶対に必要な情報となるからです。

また、今回はシステム設計において重要となる「レビュー」についても、一例を記載させて頂きました。
レビューは、システム設計において設計漏れや設計ミス等を防ぐために、必ず必要となる過程です。

今回もザックリな説明となりましたが、ITエンジニアの「詳細設計」について理解が深まれば幸いです。

システム設計の他工程については、下記記事も参考にしてみて下さい。