コーディングもテストも慣れてきた頃に、上司にこう言われた事はありませんか？
●●さん、そろそろ基本設計やってみようか
アッハイ
基本設計は開発の中でも、上流工程に近いところに存在しています。急に上流工程の仕事を任されて、何をすれば良いかよくわかってない人もいるのではないでしょうか？
ぎくっ…確かに何となくでしかわかってないかも…
そんな人のための記事を用意しました
今回は基本設計をやることになったエンジニア向けに、基本設計で押さえるべきポイントについてご紹介します。混同しがちな詳細設計との違いもお伝えしますね！
実務で使える設計書の書き方例も紹介しますよ～
＼エンジニアが大企業並みの給与と自由をGet／
改めて「基本設計」について知ろう
正直なところ、詳細設計との違いが曖昧
そんな人のために、説明していきますね
実務の話をする前に、改めて基本設計とは何か？というお話をします。基本設計が求められる理由と、詳細設計との違いを把握して自分が何をすべきか理解していきましょう。
基本設計とは開発の方針とレシピ決め
要件定義と基本設計ってセットで考えがちなんですけど、合ってますか？
うーん…合ってはいないけど、間違いとも言いにくい
そもそもシステム開発における設計作業というものは、開発するシステムのレシピづくりのようなものです。要件定義で顧客要望を吸い上げて、「要望を叶えるためのシステムってこういうものですよね？」と示すのが基本設計です。
極論、基本設計書を読めば、完成イメージとそこに至るまでの作業内容がわかればOK。この段階では、実現できるかどうかはまだ考えていません。
基本設計には、以下の要素を盛り込むことが多いです。
| 業務フロー | 業務の流れを書き出す |
| 機能一覧 | 業務の流れから開発すべき機能を書き出す |
| ネットワーク構成図 | ネットワーク構成を書き出す |
| テーブル定義・ER図 | データベース関連の情報を書き出す |
| 画面（帳票）レイアウト | 操作画面（必要なら出力帳票）のイメージ図を準備する |
業務フローのような開発に直結する内容や、機能一覧・操作画面・出力帳票などエンドユーザーが目にする箇所が多いです。
要件定義で決めたことって、結局フワッとしたままのことが多いですよね。そのフワッとした内容を具体的に落とし込むのが、基本設計と考えるとわかりやすいかも
フワッとしたまま来ると、開発中にトラブルが起きるからマジで困る
基本設計が必要な理由
基本設計がないとどうなっちゃうの？怖いのはわかる
怖いという認識は持っててOK
基本設計を行う目的は2つあります。
- 顧客との認識をすり合わせため
- 具体的な機能を決めるため
1つは顧客との認識をすり合わせるためです。基本設計書は開発者に仕様を伝えるためだけでなく、顧客側に開発システムの概要を伝える役割も担っています。
要件定義をもとに基本設計書を書いたんですけど、違うところありませんか？
ふむふむ。大丈夫ですね
もう1つは要件定義でヒアリングした内容から具体的な機能を決めるためです。どの機能が搭載されるかわかれば、あとはそれをどう実現するか決めるだけ。その機能がちゃんと定まっていないと、この後の実務に影響を及ぼします。
機能の定義がないと、作業の内容がわからなくなって超大変
スムーズに開発するためにも、基本設計はとても大切なのです。
詳細設計との違い
基本設計と詳細設計、同じ設計業務ですが担う役割が異なります。
基本設計は、要件定義の内容を具現化するためのもので、顧客も確認します。
一方で詳細設計は、開発者への指示書の役割が強くなります。基本設計で形にした機能をどのように実装するか、プログラムとして実装できるまで細かい部分まで決定。別の開発者に渡しても「あ、この通りにプログラムを組めば良いのね～了解～♪」となるようにするのが詳細設計です。
基本設計書を見せてもらったことあるけど、開発言語の記載がなかったのは役割が違うからだったのかぁ
顧客に開発側の都合を見せても仕方ないしね
基本設計を書く時に押さえるポイント4つ
前提条件を説明したので、実務レベルで気を付けるべきポイントをご紹介しましょう。今回はどのような設計書を書くうえでも、活用できる4つの要素をお伝えします。
ある業務システムの基本設計書を書き方例としてご紹介しますね
①システム概要がわかるようにする
まず作らねばいけないものは、システム全体の概要・機能一覧です。基本設計が仕上がっているのに、作るべき機能がわからなければ詳細設計が書けません。システム全体を視座高く見渡し、顧客や開発担当者、システムの連携先などあらゆる関係者に伝わるような内容に仕上げましょう。
エンドユーザー以外にも「保守運用する人が使いやすいか」「改修するとなったときに改修する人が苦労しないか」など、いろんな視点をもって概要をまとめるとみんなが嬉しい
書き方例
1.業務要件
1.1.●●システム化の背景
1.2.システム化の対象範囲
1.3.システム化業務フロー一覧
1.3.1.①●●●●●●●●…
1.3.2②●●●●●●●●…
1.3.3.③●●●●●●●●…
1.4.新業務フロー
こんな目次があると全体像が掴みやすくて良いね！
1.4.の新業務フローに、フローチャートがあるとよりイメージしやすいかも
②エンドユーザー側に立った繋がりを意識する
システムを使うのはエンドユーザーです。顧客もエンドユーザーが使いやすいシステムを欲しているので、基本設計を作る段階でエンドユーザー側に立った発想が重要です。
どのような画面を作るのか、その画面からどう操作して帳票を出力するか、出力する帳票のフォーマットはどうするか……。この時の操作性も基本設計の段階で考えておきましょう。
エンドユーザーとしては、使いにくいシステムは嫌だからね
書き方例
このあたりは図示するとわかりやすい！PowerPointなど簡易的なもので良いので、図示＋文章説明を入れましょう
| 表示ラベル | 部品の種類 | 入力 | 文字数 | 初期表示 |
| 引合先 | コンボボックス | ○ | 4 | ○ |
| 社員番号 | テキストボックス | ○ | 6 | ○ |
| 社員名 | テキストボックス | × | 10 | ○ |
| 日付 | テキストボックス | ○ | 8 | ○ |
③実現可能な構成を考える
基本設計の段階で無茶な仕様や構成を作ってしまっては意味がありません。「こうできたら良いな」ではなく、「こうしなければならない」「こうすればできる」という要素を中心に盛り込みましょう。
システムは芸術品とは違い、自己満足で終わってはいけないですからね
書き方例
外部システムとの連携が必要な場合は、以下のような関連図や一覧を作ると良いかも
| 項目名 | 型 | 可変長／固定長 | バイト数 | 項目説明 |
| 所属コード | 英数字 | 固定長 | 4 | |
| 社員番号 | 英数字 | 固定長 | 6 | |
| 社員名 | 漢字 | |||
| 注文日 | 日付 | 固定長 | 8 | yyymmdd |
④要件定義とズレていないか確認する
仮にエンドユーザーにやさしく、開発者に伝わりやすい基本設計書ができても、要件定義とズレていたら意味がありません。
基本設計で設定している機能と要件定義で求められている要望が合致しているかは、常に意識しましょう。ここがズレていると、後々大きなトラブルになります。
案件炎上の火種にもなりかねないので、できあがった基本設計書は、顧客に見せて細かいところまで合っているか確認しましょうね
基本設計を任せてもらえないなら転職してみよう
ここまで基本設計について説明してきました。基本設計を任せてもらえるのは、経験4～6年が目安といわれています。
経験6年ともなると、コミュニケーション能力やドキュメント作成能力など、ビジネススキルが十分身に付いているタイミング。もちろん経験4年以下でも、スキルが伴っていれば基本設計を任せてもらえるチャンスがあるでしょう。
仮に周りは基本設計を任せてもらえてるのに、自分の仕事内容が6年経っても変わらないなら環境を変えるのも一つの手です。上流工程も関われる案件へのチェンジも良いですし、思い切って転職するのも視野に入ってきます。
弊社リベロエンジニアなら上流工程から関われる仕事、たくさんありますよ～！
さいごに
基本設計は、開発やその後の運用における重要な指針。要件定義や顧客の要望とズレていないかしっかりすり合わせるためにも、さまざまな視野から物事をとらえて準備を進めましょう。
文章だけでなくフロー図など図表も組み合わせて、開発者側にもわかりやすくなる内容にする事も忘れずに。
SIerのように基本設計を任せられる会社なら、ある程度経験を積んだり案件を変えれば基本設計に関われるチャンスはあるはず。もしそうでない場合は、転職を視野に入れてみてはいかがでしょうか？
だとしても、どこに転職しようかな…？
その悩み、俺に話してみてよ
えぇ～！？リベロエンジニアに興味があるわけじゃないんだけど…
いやいや！そういう意味じゃなくて、エンジニア経験もある俺と話してキャリアの棚卸みたいなことをしてみようって話
そう、リベロエンジニアでは無料面談を実施しています。転職の意向に関係なく、キャリアコンサルティングのような使い方も大歓迎！お気軽にお問い合わせください。
＼エンジニアが大企業並みの給与と自由をGet／
