IT業界のお仕事について「基本設計」についてまとめます。
家を建てる時にハウスメイトや大工さんに「こんな家にしたい」という要望を伝えて図面を作ってもらいますね。
こんな家がいいなぁ…
IT業界も同様に何かシステムやソフトウェアを作る際もシステム屋にお願いします。
この際にシステム屋がおおよその「完成イメージ」を作ります。これが「基本設計」です。
この工程では、作成するシステムにどんな機能が求められるのかを明らかにする必要があります。
求められる性能は…
コストは…
要求点を明らかにするためには、クライアント(利用者)へのヒアリングが欠かせません。
そのため、システム開発の中で、一番クライアントと関わりが必要となる工程です。
要件を取りまとめた結果について「要件定義書」という形で記録に残します。
基本設計とは、この「要件定義書」から作る予定のシステムやソフトウェアについて、大雑把に考える工程です。
基本設計とは、作る予定のシステムやソフトウェアについて、大雑把に考える工程です。
この工程で出来るのは「基本設計書」というシステムやソフトウェアの設計図です。
基本設計書とは?
基本設計書は、システム作りを依頼、購入した「クライアント」に見せることも考えて作ります。したがって、主に外観を重視して作ることになります。
パッケージソフト等、依頼ではなく社内で作って売り出すという場合にも、見た目を意識した設計図となります。
基本設計書には、画面のレイアウトや、入力されるものの内容を記載します。やり方によっては、先に画面を作って、画面のスクリーンショットを張り付けるといったやりかたをする場合もあります。
例としては、画面の見た目、どのボタンを押すとどういうことが起きるのか、文字は何文字まで入力可能か、入力形式は半角か全角か等です。
後工程になるに連れて修正コストが莫大になるので入念な意識あわせが必要です!
基本設計工程ではここが大変!
まずつまずくのは、会社によって違う様式でしょう。これは基本設計に限ったことではなく、コーディングや要求定義、テストの段階でもそうですが、会社によって書き方、やり方が違います。
基本的には上図のような要求定義、基本設計・・・と順番に行ない、それぞれ要求定義書や基本設計書を用意し、詳細設計をして・・・というウォーターフォール形式で開発を行いますが、これは会社のルールではないので、会社毎に違ってきます。
したがって、要求定義も曖昧なまま、コーディングをやって、後で設計書を書くといったことをやる場合もありますし、一方できっちり設計書が出来るまでコーディングはさせないという場合もあります。
基本設計書をコピーして少し手直ししてマニュアルを作る、先に大まかに画面を作って、それを基本設計書に貼る等、やり方は千差万別です。
基本設計書のフォーマットや記述レベルは会社によって様々です。
ゆえにオリジナリティーを出すと嫌われるのでその企業のやり方に従いましょう!
基本設計工程でのトラブルシューティング
住めば都といいますが、この悩みを解決するには、やり方を受け入れて慣れることが一番の近道でしょう。
例えば、実際の画面を貼った方が、クライアントには分かりやすく、作る側としても、スクリーンショットを貼るだけで済んだりします。
また、小規模な開発であれば、先にソフトを作ってから設計書を書くというやり方も非効率ではない場合があります。
様式の違いは、その会社の社風や伝統、プロジェクトに関わる人数やここが持っているスキルが関わっています。
したがって、自然とその会社において、効率が良いやり方となるでしょう。
そうしてシステムを完成させると、もっと効率的に作業が進められるといった方法がおのずと思いついているので、
完成後のミーティング等の機会にフィードバックすると、なお良しです。
まとめ
基本設計とは、作る予定のシステムやソフトウェアについて、大雑把に考える工程です。
クライアント(利用者)へのヒアリングを通して、イメージ通りのシステムやソフトウェアを作るための重要な工程となります。
直接、クライアントと話して最後に納品する際に「エリ狐さんに依頼して本当によかったです!」「イメージ通りでした!」と言うようなお言葉をいただくとやってよかった!って感じます〜っ