エンジニア

システム開発における基本設計とは?基本設計書の成果物や進め方について

2020年5月21日

基本設計

 

こんにちは、古賀です!

今回は「基本設計」についてお話します!

 

システム開発プロジェクトは要件定義を終えると、

「基本設計」工程に移っていきます。

 

基本設計工程で決めたことが、

詳細設計の基となり、

実際にシステムが作られていくことになります。

 

自分が設計した内容で、システムが出来上がっていくことは、

システムエンジニアとして嬉しくもあると思いますが、

責任も感じると思います。

 

1つ1つの決定に勇気がいる場面も多いですし、

初めて基本設計を担当する時は不安になるかと思います。

 

そんな方向けに、

本記事では基本設計工程の、

「目的」

「基本設計の成果物である基本設計書の内容」

「基本設計の進め方」

などについて、お話していきたいと思います。

 

まずは、

「基本設計の目的やゴールとは何なのか?」

を理解して、不安を取り除いていきましょう!

 

自己紹介が遅れましたが、

わたしは大学卒業後、上場IT企業に就職し、プログラマー、システムエンジニアとして

約10年間働いておりました。

プロフィールの詳細はこちらです。

基本設計とは?

基本設計のV字モデル

基本設計は何をする?基本設計の目的!

基本設計工程では、要件定義で決めた内容を基にして、

「画面のレイアウト」

「帳票のレイアウト」

「各プログラムの使い方」

などを決めていきます。

 

最終的に基本設計の成果物である

「基本設計書」

を作成し、お客さんへ提出します。

お客さんが基本設計書の内容を確認承認後に、

次の工程である「詳細設計」へ移っていきます。

※基本設計レビューという打合せで、

基本設計書の内容を互いに確認して承認を得るやり方が一般的です。

 

要件定義の内容が基本設計の基となったように、

基本設計は詳細設計の基になります。

詳細設計する上での「材料」が全て揃っていること

が、基本設計の目的でありゴールです!

 

詳細設計以降の工程は、

開発を担当する企業内で、プロジェクトを進めていくことになります。

システム開発前のお客さんとの打合せは、この基本設計が最後の場になります。

 

お互いがイメージするシステムに相違がないように、

基本設計を終えることがポイントです!

基本設計の進め方!各プログラムの詳細を決めていく!

会議

企業や個人によって、打合せの進め方は異なると思いますが、

わたしの経験をベースにお話していきます。

 

打合せを進める上でのポイントは、

ポイント

「お客さんがシステムを理解しやすい順番で打合せ内容を決める」

です。

 

基本設計は要件定義と違い、

打合せ内容のシステム色が強くなっていきます。

お客さんがシステム担当者のみであれば、問題ないかもしれませんが、

システムを実際に使用する現場の担当者の方が、参加されることもあると思います。

 

現場の方にも理解しやすいように、業務の流れに沿って、

打合せの順番を決めましょう!

以下は例です。

「入力プログラム」⇒「帳票などデータ確認系プログラム」

「日次処理」⇒「月次処理」

間違っても、

注意ポイント

「簡単なプログラムから」という進め方

はやってはいけません。

 

打合せに間に合わないなら、リスケしたほうがいいです。

自分勝手な順番で打合せをすると、逆にスケジュールが伸びてしまいます。

 

打合せ内容ですが、

入力プログラムであれば、

「入力項目の過不足」

「必要なエラーチェック」

「入力の補助機能の要否」

などを決めていきましょう。

 

そして、

「いつ使うのか?」

「何のために使うのか?」

も、忘れずに説明しましょう。

 

基本設計のキモは、

「設計に実現性があるかどうか」

です。

お客さんの言いなりになってしまい、

プログラムで作れないような設計にならないように注意しましょう!

 

実現性に注意しながら、

上記のような内容を、各プログラム毎に打合せを1~3周くらい繰り返し行います。

そうすると、設計内容が徐々に固まってくるはずです。

決めた内容を基に、成果物「基本設計書」を作成して基本設計は終わりです!

基本設計の成果物!基本設計書とは?

本

基本設計は最終的に「基本設計書」を成果物として、お客さんに提出します。

企業によって提出物は異なりますが、わたしの経験上から回答させて頂きます!

※インフラ要件は割愛します!

要件定義の成果物も基本設計書の一部

要件定義時の成果物も、基本設計書の成果物になります。

基本設計工程の打合せによって、修正が発生した内容もあると思います。

修正分も含め、基本設計書として以下のものを改めて提出します。

  • システム全体図
  • 業務フロー
  • 使用プログラム一覧
  • 非機能要件定義書
  • 議事録
  • 課題管理表

要件定義の成果物については、こちらの記事からどうぞ!

システム開発における要件定義とは?要件定義書の中身や要件定義の進め方について

プログラム基本設計

基本設計書のメインとなる成果物が

「プログラム基本設計」

です。

 

各プログラム毎に、

  • 「画面(帳票)レイアウト」
  • 「画面(帳票)項目一覧」
  • 「使用用途」
  • 「機能」
  • 「エラー内容」
  • 「使い方」

などを記載したものになります。

画面のないバッチ処理も1つのプログラムとして、基本設計を作成します。

 

企業によっては、

「画面レイアウト」で1つの成果物、

「帳票レイアウト」で1つの成果物、

というように分ける場合もあるかと思いますが、

わたしの場合は、1つのプログラムに対して上記の内容を記載していくスタイルでした。

 

また、プログラム毎ではなく、システム全体に関わるような処理については、

プログラム毎の設計書には記載せずに、

外だしの資料を別途作成します。

区分・コード一覧

システム上の入力項目には、「区分」や「コード」といった項目があります。

その「区分」や「コード」によって、

「データ集計に使用する」

「プログラム上で制御を掛ける」

といった場合がありますので、

基本設計の段階で各区分とコードの内容を決めておきます。

※後で追加する場合もあります。

 

消費税項目を例にすると、

「0:非課税」

「8:8%課税」

「10:10%課税」

というような内容になります。

テーブル設計書・ER図・CRUD図

データベースの設計内容となる、

  • テーブル設計
  • ER図 ※1
  • CRUD図 ※2

※1 ER図は、各テーブルの繋がりを示した資料
※2 CRUD図は、各テーブルがどのプログラムから更新、取得されるかを示した資料

ですが、内部設計の部分になるため、提出しない場合もあります。

 

わたしの経験上ですと、提出したことがあるのはテーブル設計書のみです。

テーブル設計書も、お客さんがデータを出力して活用できるように、

必要最低限の情報のみ提出をしてました。

 

システムの内部に関する資料は、お客さんに理解してもらうハードルが非常に高いです。

担当者が優秀な方であれば問題ありませんが、

あまりシステム経験がない方の場合、

内容を理解してもらうために膨大な時間を使ってしまいます。

そのため、上記のようなデータベース設計は提出しない場合も多くあります。

まとめ

ここまでの話をまとめます。

まとめ

<基本設計とは>

要件定義した内容を基に、

「画面のレイアウト」

「帳票のレイアウト」

「各プログラムの使い方」

などを決めていき、「基本設計書」を作成する。

<基本設計の進め方>

・実際の業務をイメージしてお客さんが理解しやすい順序で打合せを進める

・実現性を考慮して設計する

・設計だけでなく、プログラムの「使用タイミング」や「目的」も説明する

<基本設計書の内容>

・システム全体図

・新業務フロー

・使用プログラム一覧

・非機能要件定義書

・議事録

・課題管理表

・プログラム基本設計

・区分・コード設計

・テーブル設計書・ER図・CRUD図

 

わたしがシステムエンジニアになって間もない頃、

作成した基本設計は、自分よがりのものであったかもしれません。

 

基本設計はお客さんが実際にシステムを使っていく上で、

どのようにシステムを使っていくかをイメージさせるための資料です。

お客さんがシステムを使って業務を行うイメージが浮かばなければ、

基本設計の内容に、良いも悪いも判断できません。

 

基本設計書は「お客さんのための設計書」です。

開発企業が自己満足で作成する資料ではありません。

 

無駄にファイルを分割させたり、膨大な量にする必要はないのです。

システムの内側を全て見せる必要もありません。

 

基本設計書を作ることだけを目標にしてはいけません。

基本設計書は、システムを使ってお客さんの業績を上げるために作るのです。

 

「業績を上げる」

が目的で、

「基本設計の作成」

は手段です。

手段が目的にならないように注意しましょう。

 

お客さん目線になって打合せを進めてみましょう!

進めた先には、

「より良いシステム」と「お客さんとの信頼」が

待っているはずです!

 

システムエンジニアの記事へ戻る

SIer業界の記事へ戻る

おすすめ記事

道のり 1

※本記事は、各記事のまとめ記事です。   こんにちは、古賀です!   本記事では、 「プログラミング未経験者がエンジニアとして働き、 年収1000万に到達するまでの道のり」 をご説 ...

成長するエンジニア 2

  エンジニアになったけど、いまいち成長を感じられないなぁ。。 作業スピードも品質も平凡。 この先成長していけるんだろうか。。   こんにちは、古賀です!   エンジニア ...

闘病記 3

※本記事は、各記事のまとめ記事です。   こんにちは、古賀です!   わたしは25歳の時に、悪性リンパ腫になりました。 不安な気持ちになって、たくさん泣きました。 本気で「死ぬかも ...

プログラミングスクール 4

  プログラミングを本格的に勉強して仕事に繋げていきたいけど、 プログラミングスクール多すぎる。。 どういう目線で選べばいいんだ。。   こんにちは、古賀です。   プロ ...

-エンジニア
-, ,

Copyright© Koga Masao's LifeBlog 〜Alive Today〜 , 2020 All Rights Reserved.