システム開発　基本設計とは

ソフトウェア開発における基本設計と詳細設計は、前者が大雑把な設計を行い、後者が細かい設計を行う工程だと誤解している方が多いでしょう。これは大きな誤解で、基本設計と詳細設計にはそれぞれ別々の役割があります。

基本設計の役割

ソフトウェアの動きを外から見た際にどういう動きをするのか？(What)を決めたもの

詳細設計の役割

基本設計で決められた動きをどうやって実現するか？(How)を決めたもの

このように基本設計と詳細設計ではそもそも決定していく事項が違います。ちなみに設計書と仕様書の違いについて触れておくと、設計書が「どうやって作るか」を考えて作成するものであり、仕様書とは「何を作るのか？」を説明するための資料です。

基本設計の前工程には要件定義があります。これは開発担当者がクライアント担当者にヒアリングした内容をもとにソフトウェアに必要な機能等を盛り込んだ資料です。基本設計ではこの要件定義にもとづいて、外側から見てどのような動きをするのかを確認します。

業務フロー図

業務フロー図とは業務の内容や処理の方法などを視覚的に表現したものです。業務の開始から完了までの各プロセスを記号や図形で示して矢印で結ばれていることが一般的です。各プロセスでどのような処理を行うのか分かりやすく示せるのがメリットです。システムを利用する際の全体的な処理の流れを把握するのに役立ちます。

システム機能設計

システム機能設計は、システムに必要な機能を決定して整理する項目です。システムの構成要素を決めて、分かりやすく図で表現します。各システムの処理の種類や処理結果を格納する場所まで詳細に決めることが大切です。最終的にはハードウェア構成図やソフトウェア構成図、ネットワーク構成図などとして資料をまとめます。

画面設計

システムの画面レイアウトを具体的に設計していくのが画面設計です。画面ごとの番号や名称、IDを定めて、画面の種類を分類した上で、各画面に備える機能を決めます。機能の目的から画面上での動きまで詳細を決めることが大切です。画面ごとに、画面名や機能を表としてまとめておくと分かりやすいでしょう。他の画面に移動する流れが分かる資料として、画面遷移図を作成することが多いです。

帳票設計

情報システムの開発で欠かせない帳票について、形式や書式、扱う情報の種類、出力の仕方などを決めるのが帳票設計です。レイアウトを決定して、出力項目一覧を整理し、編集定義の決定をするのが主な作業です。関連する機能と一緒に設計していくことが重要です。資料として開発する帳票の一覧表や帳票概要、帳票レイアウトなどをまとめます。

バッチ設計

バッチ設計ではバッチ処理の設計を行うのが主な作業です。バッチ処理とは、システムの裏で働く処理のことで情報システムに欠かせない要素となります。どのようなバッチ処理があり、どんな情報をどんなタイミングで入出力するのかといった内容を決めていくのです。バッチ設計ではシステム全体の視点で考えることが大切です。さまざまなバッチ処理を組み合わせて、一つの処理結果を導けるように設計します。バッチ機能をまとめた資料や、バッチ処理フロー、バッチ処理定義などを資料として用意します。

テーブル・ファイル設計

システムで扱うデータについてどのようにして保存し、どのように提供するのか設計するのがテーブル・ファイル設計です。システムで扱うテーブルとテーブル内の主要なデータについて設計します。最終的にはテーブル関連図(ER図)やテーブル・ファイルの一覧資料を作成するのが目的です。

インターフェース設計

システムは外部システムと連携することでユーザーが利用できるようになります。そこで、具体的にどのように外部システムと連携させるのかを設計するのがインターフェース設計です。資料としては、連携先や連携方法、連携時の参照データなどをまとめます。外部システム関連図や外部インターフェース一覧を作成すると良いでしょう。

非機能要件

要件定義で決められた要件以外にも、非機能要件について検討することが大切です。非機能要件とは可用性や性能、拡張性、移行性、セキュリティなどが含まれます。システムの使い勝手がよく、安定稼働するために求められている機能などを指します。要件定義で非機能要件について検討されていない場合も多いため、その場合は基本設計のフェーズでしっかりと非機能要件を整理して資料にまとめると良いでしょう。

基本設計はクライアントも一緒になって確認することが多いため、クライアントに見られることを想定して作ります。しかし次工程である詳細設計ではお客様にはわかりにくく、クライアントを意識せずに社内開発者が、内部の製造する担当者など開発者向けに作った設計書の場合が多いです。

設計のよくある課題

• 課題① 設計の本質を理解していない




システム開発における設計は、顧客へのヒアリング内容をもとに作成した要件定義をベースにして、顧客が持つビジネス上の課題を解決するようなソフトウェアの設計図面を作るというものです。しかしそれだけでは設計の本質を捉えきれていません。重要なこと、大切なことは「顧客の意図をくみ取り、必要な機能を導入でき、システムを実現するための手順を明確にし、かつ品質を保証すること」です。この本質を理解していないと、顧客の課題を解決することはできません。ベンダー都合の設計書は最終的に何も役に立たないです。

• 課題②設計に関する基準が無い




システムを構築するためのプログラミングでは世界標準およびお客様の思いを実現するためのは流行りの技術や言語を使用するので、ある程度の属人化は防げる傾向にあります。個人的に開発したプログラミング言語を使用することなどはありません。従ってプログラマーが言語さえ習得していれば理解は難しくありません。もちろん、それでも属人化が発生することはあるので誰もが瞬時に理解できるプログラムの生成を心掛けることは大切です。一方で設計には世界標準が存在せず、最悪の場合社内の開発チームによって設計方法が異なります。これが設計の属人化が発生する大きな理由の一つです。またお客様の知見で標準かどうかを見極めることは困難であり、ベンダーの言いなりになりがちなことも課題となります。

• 課題③標準化のための仕組みを持たない




設計から属人化を排除するためには組織が定めるルールを作成する必要があります。これを標準化というのですが、単にルールを作成するだけでは属人化は排除できません。徹底した属人化の排除には標準化の仕組みが大切です。近年ではテンプレートだけを探してそれ通りに設計を書こうとしている人もいますが得策ではないでしょう。というのもプロジェクトごとに必要なものが異なるのは当然のことであり、テンプレートで必要なものが「足りなかった」とならないようにしなければいけません。ここがシステム会社によって大きく差がでることになります。標準化に向けてどのような取り組みをしているのかはベンダーに聞かれた方がよいでしょう。

いかがでしたでしょうか。今回の記事は、基本設計で何をつくるのかを簡単にお伝えしました。しかしながら最近のアジャイル開発手法ではチーム内で協議しながらプログラムを作成していくことが多く、出来上がったものを修正追加しながら仕上げていきます。設計書は後回しで先にプログラムを作りやり方が効率的であり納期も短縮できることから流行しています。と言っても「なんのためのシステムなのか」という目標を表現した基本設計書は必ず必要です。目標や目的を明確にすることが無ければ、無駄な投資になるでしょう。当社J&Cでは上流のコンサルティングからご相談に応じています。そしてお客様と一緒になったシステム開発チームを体制化いたします。実現に向けて確実に思いを共有させていただかなければ、本当のシステム開発はできないからです。是非当社にご相談を!




ご相談はパソコンからのお申込みください。 お申込み



• Go back