目次
インフラエンジニアが行う、「詳細設計」って何？
システム設計の「レビュー」ってどんな事をやるの？
といった疑問について、本記事では説明したいと思います。
▼筆者の紹介(ITエンジニアとしての業務経験) ・IT業界経験年数 8年(営業経験:4年 SE経験:6年) ＜案件,業務経験要約＞ ・PCキッティング・展開 ・各種ネットワーク詳細設計・構築 ・各種サーバー設計・構築 ・ヘルプデスク(Windows、Office365製品サポート) ・仮想化設計/構築 ・クラウド設計/構築
筆者のSEプロフィールの詳細については、下記記事で紹介しています。
インフラエンジニアの業務工程(システム設計)の一つに、詳細設計という工程があります。
・詳細設計とは、具体的にどんな事をするのか？
・詳細設計書、パラメーターシートとは何か？
「詳細設計」工程で行う主な内容、そして取り扱うドキュメントについても説明していきます。
また、システム設計においてレビュー」という重要な施策があります。
・レビューとは？
・レビューはどんな感じで行われるのか？
レビューは主に、ドキュメント等の内容の精査、確認を目的に行われますが、
実際、どのような流れでレビューが行われるのかについても説明していきます。
今回は、筆者の経験上の解釈で、詳細設計・レビューについて説明したいと思います。
「詳細設計」＝パラメータ(構築に必要な情報)を定義すること
詳細設計＝パラメータシートの作成 と認識頂いて大まかには差し支えありません。
「詳細設計」とは、システム設計における次工程の「構築」を行うために必要な情報を定義することです。
言い換えると、「構築に必要なパラメータ等を定義する工程」となります。
詳細設計では、一般的に「パラメータシート」がアウトプットドキュメント※として作成されます。
※パラメータシートとは別に「詳細設計書」といったドキュメントも作成する場合があります。
また、パラメータシートの事を「環境定義書」と読んだり、ドキュメントの呼び名は会社毎に変わってきますので、注意してください。
工程上の詳細設計の位置づけ
システム設計の工程において、詳細設計は基本設計の後、また構築の前の工程です。
▼システム設計の一般的な工程 要件定義→基本設計→詳細設計→ 構築
詳細設計工程は、基本設計の情報をインプットとして実施されます。
一般的には、「基本設計書」を元に、「パラメータシート」を作成するといった具合です。
詳細設計工程が完了したのち、次の「構築」工程へ進みます。
前回、下記記事において「基本設計」をカレー作りに例えて説明致しました。
今回は、下記のカレー作り「基本設計」をインプットに、詳細設計の具体的な流れを説明したいと思います。
詳細設計の具体的な流れ(基本設計のインプット)
詳細設計を行うには、前工程の基本設計情報(基本設計書)のインプットが必要不可欠です。
ここで、前回のカレー作り基本設計(基本設計書)をまず取得したいと思います。
▼きちんと精査した基本設計の結果(基本設計書)
【インフラエンジニア】基本設計とは？何をやるのか？
ピーマン、たまねぎ、オクラ、レンコン・鶏肉が入った、甘口なバー○ントカレー
https://www.syeg.net/infrastructure-engineer/how-to-basic-design/
ちなみに、「要件」は、「野菜が入った健康的なカレー」です。
では早速、これらの基本設計情報をインプットとして詳細設計を行っていきます。
詳細設計で主に行われるのは、構築に不可欠な「パラメータシート」を作成することです。
パラメータシートとは？
パラメータシートとは？一言で言えば、「構築に必要な情報が記載されたドキュメント」(パラメータ等)です。
今回は、システム設計をカレーの作り方に例えていますが、カレー作りには「正確なレシピ情報」が必要となります。
(例:肉200g、カレー粉100g 等)
システム設計においても同様で、サーバー作り(構築)には、「正確なパラメータ情報」が必要です。
(例:OSの種類、OSのバージョン、インストールするアプリの種類、ハードディスクの容量等・・・)
これらの情報を明確に記載し、ドキュメントとして可視化したものが「パラメータシート」と呼ばれます。
詳細設計書とパラメータシートの違い
パラメータシートとは別に、「詳細設計書」なるドキュメントを作成することもあります。
では、詳細設計書とパラメータシートの違いは何なのでしょうか？
⇒これは、会社や案件によって、「詳細設計書」の定義が異なるため、一概には定義できないのが筆者の経験上の答えです。
詳細設計書＝パラメータシート(環境定義書と読んだりもする) の場合もあれば、
詳細設計書＝基本設計書をよりかみ砕いて記載したドキュメントの場合もあります。
詳細設計書では、どのようなドキュメントを作成すればいいのか？悩んだときは、
参画している案件のPM・PLや、会社関係者に確認をするべきでしょう。
正し、「パラメータシート」 は、構築に必要なドキュメントなので、基本的には必ず存在します。
「詳細設計書」(基本設計書をよりかみ砕いたドキュメント)は、無いプロジェクトもあるかと筆者の経験上は感じています。
詳細設計(レシピ・パラメータ)の作成(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回 内部レビュー 【指摘１】 ・カレーのレシピだが、「ライス」のパラメータが入っていない。 ライスが無いのは要件に含まれているのか？ 「対応内容」 ライス無しは要件には含まれていない。よってライス有りが正しいパラメータとなる。 ライスをパラメータに追加する。 指摘区分：「設計漏れ」 【指摘２】 ・ピーマン、玉ねぎ、オクラ、レンコンと多くの野菜がパラメータに定義されているが、 野菜の種類はもっと少なくてもいいのではないか？ →野菜は要件定義・基本設計で定義された通りとなるため、これ以上少なくすることはできない。 指摘区分：「非該当」 【指摘3】 ・このカレーは、そもそも「何人前」を作る想定なのか？ 現在の分量では1～2人前程度しか作れないが、構築結果の量は１～２人前で問題ないのか？ 「対応内容」 作成後の「総分量」については確認が行われていなかったため、 顧客に「総分量」について確認を行い、パラメータへ反映されていく。 指摘区分：「設計漏れ」
レビューの結果、「ライスの追加」「何人前を作るのか？(総分量)の確認」という指摘が判明しました。
ここで重要なのが、「基本設計に上記の情報が無かった事」です。
どういうことか？
今回、詳細設計を始めにしたときを振り返ってみましょう。
【重要】基本設計での定義が甘く、後の詳細設計フェーズで設計漏れが発覚した
今回、基本設計の情報が不完全と思われる状況 で詳細設計に臨みました。
もう一度基本設計を振り返ってみたいと思います。
▼基本設計(基本設計書) ピーマン、たまねぎ、オクラ、レンコン・鶏肉が入った、甘口なバー○ントカレー
上記の情報だけで、カレーのレシピが作れるでしょうか？
カレー作りに精通した、経験豊富な料理人 であれば、今回の1回目のパラメータ制定のように、
「経験に基づいてレシピの考案」ができるかもしれません。
しかし、カレー作りの経験が無く、料理経験も無い人 の場合はどうでしょうか。
恐らく、詳細なレシピは考えつかない でしょう。
つまり、今回のような不完全な基本設計だと、後続の詳細設計が正確に行われるか否かは料理人(エンジニア)のスキル次第となってしまうのです。
これは、実際のシステム設計においてもよくある設計漏れのケースです。
熟練のエンジニアや、システムに精通したエンジニアの場合、基本設計を見て詳細設計に入った時点で、
何人前なのか？ライスは要らないのか？といった観点で、基本設計漏れを事前に指摘できるかもしれません。
このように、「設計漏れや要件漏れが無いか？といった観点を持ちながら設計できるか否か」が、
スキルが高いエンジニアと低いエンジニアの違いだと、筆者は感じています。
詳細設計書の修正、そしてレビューの2回目へ
前回のレビューの結果、「ライスの有無、何人分が必要なのか」といった基本設計・要件の確認漏れも発覚したため、再度、クライアントに上記の確認(ヒアリング)を行いました。
確認の結果、下記のように再度パラメータの修正を行いました。
▼野菜が入った健康的なカレープロジェクトのパラメータ(修正後)
前提条件:大人4人分の分量を作成
・20gのピーマン 6個
・100gの玉ねぎ 2個
・10gオクラ 6本
・100gのレンコン 1個
・国産の鶏のもも肉 400g
・甘口バーモントカレー 200g
・ごはん 600ｇ【変更点】
・ライスが抜けていたため、ライスを追加しました。
・4人前を作るという事が改めて判明したため、全体的に分量を変更しました。
詳細設計の修正が完了したため、再度、レビューを実施し、詳細設計書の確認を行っていきます。。。
詳細設計は、基本設計をインプットに、構築に必要なパラメータを煮詰めていく大事な工程
いかがでしたでしょうか。
今回もシステム設計を「カレー作り」に例えて説明をさせていただきました。
インフラにおけるシステム設計でも、基本的には同じように当てはまります。
例えば、「小学校生徒に配布するのノートパソコンのシステム設計(ハードウェア設計：ドライブ容量)」では、
OS領域として50GB、アプリケーション領域として50GB、予備領域として30GBという基本設計をインプットに、
「容量130GBの領域をCドライブに割り当てる」という「詳細設計(パラメータ)」を定義するといった感じです。
実際はパラメータシートとして、下記のようなパラメータが定義されていきます。
ドライブ名:ローカルディスク 領域:130GB ドライブ文字：C
これらの詳細設計の情報は、次工程の「構築」を行う上で非常に重要な情報となってきます。
なぜなら、パラメータは構築を行う上で絶対に必要な情報となるからです。
また、今回はシステム設計において重要となる「レビュー」についても、一例を記載させて頂きました。
レビューは、システム設計において設計漏れや設計ミス等を防ぐために、必ず必要となる過程です。
今回もザックリな説明となりましたが、ITエンジニアの「詳細設計」について理解が深まれば幸いです。
システム設計の他工程については、下記記事も参考にしてみて下さい。
