【初心者用】システム開発に用いられる設計書について

今回はシステム開発の現場で求められる、設計書の種類などについて解説していこうと思います。

設計書が読めるようになると、市場価値が上がるため高単価の案件に参画することも可能となります。

また、開発サイドではなくマネジメントサイドの仕事も行うことが可能となります。

1. プログラム設計書とは

先ず簡単に、プログラム設計書とは何かというと、必要な機能、必要なデータ、形式、フォーマット、プログラムの種類、要件などが記載されている設計書の事で、プログラマーはこの設計書を基に開発・リリースを行います。

言ってしまうと、プログラム設計書に記載されている内容を行っていればシステムを構築できる指南書の様なものです。

書式が定まっていないため、各プロジェクトごとにフォーマットは異なりますが、読み方は大方同じなので置き換えて読むことで問題なく読み解けると思います。

2. プログラム設計書は必要なのか?



小・中規模のプロジェクトにプログラム設計書は必要ないと言われることがありますが、本当にそうでしょうか?

本章ではプログラム設計書が必要な理由と、メリットについて解説していこうと思います。

2-1. ①スムーズなプログラミング作業を行える

こちらは誰もが感じる部分ではないでしょうか。

プログラム設計書には、プログラムを構築するために必要な情報が詳細に記載されており、先述したように、記載されている内容を忠実に再現すればシステムを構築することが可能です。

また、プログラム設計書を読み進めることで、プロジェクト全体の規模感やシステムのイメージを持つことができるので、スケジュール管理の部分でも大きく活用することが可能です。

2-2. ②エラーの防止

プログラム設計書が存在しない場合は、作業を行っているプログラマの裁量によりプログラムが作られます。

その結果、無駄にコードが増えてしまったり、設計者が想定していなかったバグが発生してしまいプロジェクトの進捗に大きな被害が生まれます。

設計書を作成し、品質を担保することはプログラマにとってもクライアントにとっても大きなメリットとなります。

2-3. ③保守作業の負担軽減

構築したシステムは、納品後も保守作業を行うことがほとんどです。

その際に、新規メンバーを参画させた場合に設計書をマニュアルのような使い方にすることも可能です。

また、システム障害などが起こった場合も、設計書を読むことでおおよそのバグ部分の洗い出しが出来るため、プログラム設計書は開発フェーズだけでなく、保守フェーズでも強い力を発揮してくれます。

3. プログラム設計書の具体的な記載内容

本章では、プログラム設計書に記載されている内容を、具体的に見ていきましょう。

プログラム設計書は具体的なフォーマットや記載内容が明確ではないため、内容については各プロジェクト毎に違いがありますが、ほとんどの設計書で書かれている内容は下記のとおりです。

・関数名・変数名・クラス名

・関数名・変数名・クラス名の定義について

・定数名・定数の意味・数値リスト

・プログラミングに使用するライブラリ

・データを取ってくる場所(データベース)

・実行モジュール

・必要なソースコード


上記がほぼ統一されて記載されている内容で、各プロジェクトごとに必要な内容については上記にプラスで書き足されているケースが多いです。

また、詳細なプログラム設計書を準備していない企業では、機能部分のみを記載し、詳細な仕様についてはプログラマーに一任するケースも実際には増えてきています。

上記でご紹介した項目はあくまで目安となっているため、企業の方針やプロジェクト、チーム編成など、その時の状況によってプログラム設計書の内容は大きく変化します。

そのため、ある程度状況に合わせてフレキシブルに対応する姿勢も重要です。

4. プログラム設計書と、他の設計書の違い



システム開発の現場では、プログラム設計書のほかに複数の設計書やドキュメントが整備されています。

本章では、プログラム設計書とその他設計書の違いや特性についてざっくりと紹介していきたいと思います。

5. 提案書

提案書はクライアントがシステムの導入を行う際に、提案するためのドキュメントです。

提案書にはシステム開発の全容が把握できるように、主に下記の様な無い湯が記述されているケースが多いです。

・クライアントの現状・課題

・システム導入の目的

・システム導入による効果・メリット

・システム導入後に期待できる成果・結果

・システム導入の背景や導入上の課題

・開発プロジェクトの概要・方法・方針

・開発プロジェクトのスケジュール

・業務の範囲・領域

・開発コスト


こちらもプログラム設計書と同じように、記載内容の指定や決まりがありませんが、意思決定がしやすいようにまとめられているケースが多いです。

5-1. 要件定義書

要件定義書とは、クライアントがシステムに求める機能をまとめたドキュメントのことを指します。

上記で紹介した提案書を基に、プロジェクトに参画予定のシステムエンジニアが要件定義書の作成を行います。

要件定義書は、作成するシステムについてクライアントの合意を得るためにも用いられるので、ITリテラシーが高くない方でも理解できるように分かりやすく書く事が求められています。

要件定義書をクライアントに提出し、合意を得ることが出来れば、要件定義書を基にシステムを開発するための設計書を作成します。

5-2. 基本設計書

基本設計書とは、システムを外部から見た際に画面遷移がどのようになっているのか等の動作を記述したドキュメントのことを指します。

呼び方はプロジェクトによって変化するのですが、外部設計書ともいわれており、ドキュメントの作成は上記で開設した要件定義書を基に行われます。

基本設計書には、ユーザーインターフェースである操作画面や操作方法、データ出力方法をはじめとする、セキュリティ・システム運用規定、開発コスト・開発スケジュールなど主に使用者(ユーザー)を対象とした仕様を設計することが特徴です。

基本設計書については、お客さんであるクライアントと共有する必要があるため、ユーザーならびにクライアントが理解できるように図表を用いて分かりやすく作成することがポイントと言われています。

5-3. 詳細設計書

詳細設計書は、基本設計で作成した仕様をもう少し具体的に実現する方法を記述したドキュメントのことです。

こちらも各プロジェクトで言い方は変わるものの、内部設計書と呼ばれることもあります。

詳細設計書は、基本設計書よりも一歩踏み込んで、クライアント目線では見えないシステムの内部構造や内部機能、内部動作・データベースなどを決定するため、専門知識を持ったシステムエンジニアによって作成されます。

詳細設計はこれまでの設計工程の内容を実際に実装できるレベルまで突き詰める工程であり、先述したプログラム設計書はその最後尾に存在するドキュメントとなります。

ややこしいのですが、プログラミングの方法を示したプログラム設計書とは異なるドキュメントである点に注意してください。

6. まとめ



今回の記事では初心者用に、どんな種類の設計書が存在するかについて解説しました。

設計書を読めるようになると、自分一人で開発を進めることが出来るようになるのでエンジニアとしての市場価値はグンと上昇します。

その分、習得までに時間のかかるスキルとなってくるのは間違いないのですが、設計書の簡単な読み方なども併せて、今後は設計書の具体的な読み方などを投稿していこうと思います。