システム開発と詳細設計について

はじめに

企業でシステム開発を行う場合は、個人ではなくチームで進めていくことがほとんどなので、同じ目標に向かって共通認識を持って情報を共有し合っていかなければいけません。稼働してからも改修やアップデートする際に振り返ることができる資料が必要になります。そのために、SE(システムエンジニア)やプロジェクトマネージャーは開発における上流工程の段階で今回紹介する「詳細設計」を含めた各種資料を作成してシステム開発の指針を決めます。この記事では開発モデルについて、そして詳細設計の役割や必要となる項目について解説していきます。

開発モデル「ウォーターフォール」とは

システム開発の方法について調べていると、要件定義や設計を行なったうえで実装やテストに入るという流れが紹介されていることが多いですが、この方法は「ウォーターフォール」と呼ばれ、複数ある開発モデルの一つとなります。ビジネスを始める際に参考とするビジネスモデルがあるように、開発にも先人達が作り上げたモデルが存在します。このウォーターフォールモデルは長い間様々なシステム開発の現場において繰り返し利用されてきたものですが、近年はアジャイルという方法を採用する現場も増えてきました。今回の主旨とずれるため詳細は省きますが、アジャイルはPDCA(Plan→Do→Check→Action)のサイクルを短期間で繰り返して開発を進める方法で、リリースまでにスピード感が必要な場合に採用されることが多いモデルです。

ウォーターフォールは一般的に、上流工程、下流工程とその段階を大きく2つに分けます。上流工程は、要件定義や概要、基本、詳細といった設計が行われるフェーズで、下流工程では実装やテストが行われます。上流工程で定められたことを元に下流工程が進められていくので、両者は切り離して考えることができないうえに上流工程はシステム開発を成功に導くための非常に重要なフェーズとなります。後からシステム開発の依頼者(クライアント)による要望の追加があったとしても、この上流工程がブレなく定まっていれば作業の切り戻しが発生する可能性は少なく、結果的に進捗具合が良好になりやすいです。

それだけ重要な部分に位置する詳細設計ですが、同じく上流工程の段階で必要となる「要件定義」について簡単に紹介します。

要件定義

要件定義のフェーズは、クライアントと打ち合わせやミーティングを行なって要望を整理していきます。なお今後話を進めて行きやすいように、必須となる機能と、可能であれば実現したい希望を分けて設定することもあります。その後に要望を実現するため必要となる機能やハードウェア類を挙げ、またスケジュールもある程度定めてクライアントとの認識合わせを繰り返していきます。すでに把握できている実現可否項目についてはこの時点で回答し、代替え案がある場合は提案をしながら最終的な形をイメージして作り上げていきます。要件定義の段階で予算についても話し合われることが多く、正確なヒアリング・提案ができる能力はもちろん、交渉力が必要となる場合もあります。そのため要件定義は経験の浅いエンジニアで対応することは少なく、プロジェクトリーダーやマネージャー、経験豊富なSE、プログラマー等が同行して話を進めることが多い部分です。内容が固まったら最終的に書類やデータに落とし込んで、プロジェクトメンバーに共有します。

なおアメリカに本部を置くIEEE(アイトリプルイー)と呼ばれる団体は、電気通信関連の様々な規格を標準化していますが、要件定義や設計といったシステム開発の上流工程で作成される書類も同様に標準化しています。ただし毎回型通りに作成されることは少なく、大抵の場合は規格で定められた必須内容を取り入れつつ、その企業内で利用されるテンプレートがある程度形作られ、そのテンプレートが流用されます。

詳細設計の役割について

設計のフェーズは基本設計と詳細設計に分けられることが多く、企業やプロジェクトによって基本設計の部分に関しては「概要設計」「外部設計」、詳細設計は「内部設計」「プログラム設計」という呼ばれ方もすることにご注意ください。

基本設計では、要件定義を受けて改めて必要なハードウェアやソフトウェアを洗い出し、サーバーやネットワークの構成、さらにはシステムを構成するために実装する機能、扱うデータの種類等を図や文章で取りまとめ、基本設計書を作成します。ユーザー側が利用することとなる画面設計、出力する帳票等がある場合は、そのフォーマットも定めて行きます。基本設計は要件定義に比べるとエンジニア寄りの内容にはなりますが、どちらかというと、どういうシステムが出来上がるかというユーザー側の視点がメインとなって構成されます。設計書とは別に、システムの概要やスケジュール等を分けて記した「基本仕様書」を別途作成することもあります。

対する詳細設計は、そのほとんどがプログラマーやエンジニア向けの内容となります。基本設計に記載した内容をどのようなプログラムを組んで実現するかという詳細を決めておき、プロジェクトメンバーが実装を進める際に直接目にすることが多くなるのが詳細設計です。なお詳細設計書はプログラムの処理内容等の専門的で具体的な記述が必要となるため、各分野を担当するエンジニアが手分けして作成することも珍しくありません。作成には時間がかかる傾向にあるため、スピードを重視する現場では省かれることもあります。

詳細設計で決めるべきこと

詳細設計では実装する機能をプログラムごとに分けて、それぞれの具体的なプログラミング内容を記述します。また各処理が進められる順を目視できるフローチャートや、基本設計で大枠を決めておいた画面や出力物のフォーマット等の設計を詰めてきます。データベースの設計もこの段階で行われます。また詳細設計では、UML(Unified Modeling Language)と呼ばれるデータ構造や処理内容に関する記法に沿って、アクティビティ図、シーケンス図、クラス図等を駆使して詳細設計書を作成します。アクティビティ図は処理の実行手順を図示したもので、シーケンス図はシステムの構成要素を記述するとともに、それぞれのライフライン(要素の有効期間)も示しておく必要があります。クラス図では各構成要素の相互関係を表します。相互関係とは、関連、依存、継承等です。

詳細設計は設計書が作成された後はそのまま実装に進んでいく段階となるので、各エンジニアが実装を滞りなく進めていけるように文章は極力複雑にならない箇条書き等で簡潔にまとめ、表や図で直感的に把握できるように、また認識齟齬が発生しないように名称・呼称は表記を統一するという点に気を配って作成する必要があります。

以上が詳細設計に関する説明となりますが、ウォーターフォールモデルで「実装」の後段階となる「テスト」でもテスト関連の仕様や設計、計画を別途実施して、テスト実施時のチェックリストを含めた書類作成が必要になります。このようにウォーターフォールモデルは実装以外の部分にたくさんの時間を要するというデメリットもありますが、綿密に計画されて構築が行われるため、高品質の開発物を納品できるというメリットも持ち合わせていると言えます。

まとめ

ウォーターフォールモデルは各フェーズで仕様決めや書類作成等、実作業以外の部分が多く発生し、システム開発において覚えることも多くなりますが、品質のよいシステムを構築するには欠かせないモデルです。詳細設計は上流工程の中でも特にテクニカルな知識が必要とされ、慣れるまでは作成に多くの時間をかけてしまう可能性もありますが、一度覚えてコツを掴んでしまえば汎用的に使える部分も出てくるので次第に負担も減っていきます。実装を行うエンジニアの助けになるものでもあるので、ぜひみんなが理解できる詳細設計書作成のスキルを身につけてみてはいかがでしょうか。