システム開発における設計の工程と各種設計書について紹介
はじめに
エンジニアは、自社開発の場合は社内の企画チーム等から、受託開発の場合はクライアントからシステム開発の依頼を受けます。依頼を受けるとプロジェクトを発足し、適したメンバーを各チームから集め、開発を進めていきます。開発の規模が大きければ大きい程メンバーの人数は増えていき、管理は大変になります。
そういった中で、もし計画性なくプロジェクトを進めてしまった場合は、そのプロジェクトが途中で破綻してしまう可能性もあります。そのため、開発を進める前には企画チームやクライアントといった依頼者と何度も打ち合わせやヒアリングを繰り返し、システムの要件を洗い出し(要件定義)、設計を行ってから実装を開始します。要件定義や設計の粒度は、どの開発モデルで進めるかによって異なりますが、どのモデルを選ぶとしても類似する工程は必要となります。
この記事では、システム開発において重要な工程となる「設計」とその成果物である「設計書」にフォーカスして紹介していきます。なお、システム開発について初めて学習する方向けの内容となっているため、設計書のサンプルや、設計書に含める具体的な項目については詳しく紹介していないことをあらかじめご了承ください。これからSE(システムエンジニア)やPM(プロジェクトマネージャー)・PL(プロジェクトリーダー)へキャリアアップを積みたいという方、フリーランスのエンジニアとしてプログラミングだけではなく、管理に関する部分も自分でできるようにしておきたいという方は、ぜひ入門編としてご覧ください。
システム開発で必要な各工程について
システム開発では、サーバー・ネットワークの構成や、プログラムの実装を行うまでの間に様々な工程を経ることとなり、完了後にはテストも必要となります。実装前に行うこととしては要件定義や設計といった工程があり、これらは「ウォーターフォール」という開発モデルにおいて「上流工程」と呼ばれます。
開発モデルとは、開発をスムーズに進めるための手法や手順を標準化したもので、2022年時点で代表的なモデルが複数存在しています。ウォーターフォールやアジャイル、プロトタイプ、スパイラル等が有名で、それぞれに異なる特徴があります。そのためプロジェクトの管理者は、これから開発するシステムに適したモデルを都度選定し、それにならって指示・管理を行います。
プロジェクトや採用するモデルによっては、要件定義、設計といった工程に掛ける時間が異なったり、省略されたり、重要視されなかったりということもありますが、基本的には、漏れずに行うに越したことはありません。なお、これらの工程を上流工程として、特に丁寧に行う開発モデルが「ウォーターフォール」となります。
ウォーターフォールモデルとは？
今回取り上げる設計、設計書については、ウォーターフォールモデルを理解することでどのような意味を持った工程であるかが把握しやすくなるため、具体的に説明していきます。
まず、このモデルの特徴は、一つ一つの工程を完成させてから次へ進むというところにあります。その順番は、前述した上流工程(要件定義・設計)から下流工程(実装・テスト)と、滝が上から下に流れるように進めていくため、英語で滝を表す「ウォーターフォール」という名称が付いています。
このウォーターフォールの誕生は1970年代と言われていて、秩序立った製造サイクルを目的に提唱されました。他のモデルと比べて古くからあり、流れがとてもシンプルで、エンジニアなりたての方であれば開発の流れを理解しやすいというメリットがあります。また、プロジェクトのスケジュールや予算が立てやすい、バグが発生しづらい、高品質なシステムが提供できるといったメリットもあります。
逆にデメリットとしては、工程の切り戻しが発生した場合に多大な時間やコストがかかってしまう、臨機応変な追加・修正が行えない等が挙げられます。以上の特徴より、ウォーターフォールは、変更が発生することが少ないシステム、大規模なシステムで採用されることが多いです。
なお、ウォーターフォールモデルでは、実装以外の各工程ごとに成果物(ドキュメント)の作成が必要となります。要件定義では「要件定義書」、設計では「基本設計書」「詳細設計書」、テストでは「単体テスト」「結合テスト」「総合テスト」「受け入れテスト」の仕様書・チェックリスト等です。成果物は、完成したらクライアントやPM・PL等とレビューを行うこととなります。次に、各工程についてもう少し詳しく解説します。
要件定義
名称にもあるように、システム開発によって解決したい課題や、実現したい業務フロー等の要件を洗い出し、要件定義書に落とし込むまでの工程を指します。要件定義書には、システムの概要や機能化するもの、セキュリティやパフォーマンスといった、機能ではないものの非機能として取り入れるものや、プロジェクトの予算、スケジュールといった項目を含める必要があります。基本的にはPM・PL、SEとクライアント等のステークホルダーの間で実施されます。クライアント側がITに詳しかったり、システム導入に慣れていたりする場合は、あらかじめ「RFP(提案依頼書)」というドキュメントを用意してくれている場合もあるため、合わせてその内容も照合することとなります。なお、RFPとは、クライアントがエンジニア側に渡す発注書のようなものとなります。
設計
基本と詳細に分けて設計を行い、最終的に基本設計書、詳細設計書の2つを成果物として完成させる工程です。「基本設計」は、要件定義の内容をそのまま引き継いでいる部分があり、要件定義で機能化が決まったものを具体化していく他、要件定義の段階で組み込めなかった部分を補うことができる重要な工程にもなります。
基本設計に続いて行うのが「詳細設計」です。基本設計書の内容は、エンジニアではないステークホルダーであっても、ある程度は理解できる内容となっていますが、詳細設計はプログラミングの設計書に近いものとなるので、内部向けのドキュメントという面が強いです。なお、設計に関しては、改めて「設計の種類」の部分で詳細を説明します。
実装
サーバーエンジニアはサーバー構築・設定、ネットワークエンジニアはネットワーク構築・設定、プログラマーはプログラミングを行う工程です。実装に関しては、PM・PL、SEといった管理系の職種の人が関わることが少なく、一般職のエンジニアが中心となって進め、管理側は、作業の進捗を管理・コントロールすることとなります。それでも、少人数の現場では管理者が実装を兼任することがあります。
テスト
実装が完了したプログラムが、意図した通りに動作するかをテストする工程です。テストには段階があり、一般的には、プログラム1つの動作確認を行う「単体テスト」、複数のプログラムを連携して実施する「結合テスト」、エンジニア側で一連の業務フローが実現できているかの最終確認となる「総合テスト」、要望通りのシステムが実現できているかをクライアント側で確認する「受け入れテスト」の順で行われます。受け入れテストが完了したら納品となり、開発の工程は全て完了となります。ただし、実際のシステム稼働はここから開始となるため、その後の運用・保守をインフラエンジニアやSEが担当するということも覚えておきましょう。
その他の開発モデルについて
その他の代表的な開発モデルについても、簡単に紹介しておきます。まず「アジャイルモデル」ですが、こちらは「要件定義→設計→実装→テスト」というサイクルをシステム全体ではなく、プログラム単位等の小さな単位で行う手法となります。そうすることで、開発が完了した部分から先にリリースが可能になる、変更が発生した場合も短時間で対応可能というメリットが生まれます。もう一つは「プロトタイプモデル」で、こちらは開発の初期段階でプロトタイプ(試作品)のシステムを用意して、クライアントに操作を試してもらいながら進めていくモデルです。クライアント側で完成品のイメージが難しい場合に、有効な手法となります。最後は「スパイラルモデル」です。基本的にアジャイル開発と同じですが、スパイラルの場合は未完成の状態でリリースを行い、実際にクライアントに操作をしてもらって、エンジニア側と連携しながらシステムの完成を目指すこととなります。
設計の種類
設計の工程には、基本設計と詳細設計の2種類があります。企業やプロジェクトによって呼び方は様々ですが、多くのプロジェクトで同じような工程を経由します。以下で、2種類の設計について詳しく説明していきます。
基本設計(外部設計/概要設計)
前述している通り、基本設計では、要件定義で機能化が決まったものを具体化することがメインの工程となりますが、それ以外にも非機能要件の詳細、ハードウェア、ソフトウェア、ネットワークとそれぞれの構成図や、画面のレイアウト、遷移図等の画面関連、帳票のレイアウト、概要等の帳票関連、バッチ処理関連、テーブル関連、外部サービスとの連携関連等についてもまとめ、成果物として基本設計書を作成する必要があります。担当するのはPMやSEとなりますが、専門性が高い部分のみを、あらかじめ各チームのPMや一般のエンジニアに分担して進めることもあります。
なお、基本設計書は以上のようにまとめる項目のボリュームが多くなる傾向にありますが、決まったフォーマットを利用して、可読性の高い状態にしておくことをおすすめします。後々ドキュメントの更新がしやすい状態となるのと同時に、エンジニア同士や、エンジニア以外のIT知識のないステークホルダー等、誰が見ても理解しやすい状態にしておくためです。資料を見た人が、誰でもシステムの全体像をイメージできる状態が理想的とも言えます。
基本設計は、クライアント等の外部から参照されることを踏まえて行わなければいけない工程であるため「外部設計」とも呼ばれます。また、全体的に詳細設計よりは大まかな内容になるため「概要設計」と呼ばれることもあります。
最初に基本設計書に記載すべき項目を羅列しましたが、具体的には、システムに実装する「機能の一覧表」、業務の流れが把握できる「業務フロー図」、システム全体の動きがわかる「状態遷移図」、データのやり取りの流れがわかる「データフロー図」、画面や帳票とデータベースの関係性を表す「入出力関連図」といった内容をドキュメント内に含むことが多いです。
詳細設計(内部設計)
基本設計に対して詳細設計は、作業するエンジニア向けの内容がほぼ全体を占めることとなり、詳細設計書も内部向けの資料となるため、詳細設計は「内部設計」とも呼ばれます。また、クラス図やモジュール構成図、アクティビティ図、シーケンス図等を用いてプログラミングの構成や関連性、挙動について詳細を記していくので「プログラム設計」と呼ばれることもあります。実際には難しい部分もありますが、現場のエンジニアが、詳細設計書だけを見れば実装が完了できるという状態を事前に整えられるのが理想的と言えます。
なお、各種設計書のサンプル・フォーマットを無料で提供しているサイトや、基本設計書で必要となるフロー図、遷移図を作成するのに便利なツール(ソフトウェア)も提供されているので、ぜひ自分が使いやすいもの、企業で利用しやすいものを見つけてみてください。
まとめ
基本設計は、要件定義で触れられている内容を詳しく展開したものであり、クライアント等のエンジニア以外の人が見ても、ある程度理解できる内容が多くを占めています。対する詳細設計は、内部設計とも呼ばれるだけあり、そのほとんどが、実装を行うエンジニア向けの内容となるドキュメントで、その中でプログラム設計がされている場合もあります。このように非常に限定的な資料になる性質もあるため、近年のプロジェクトでは、アジャイルモデル等で、詳細設計を省略し、実装の工程に移るという現場もある程です。
そのため、詳細設計で設計したものと実装したものの間の乖離が大きかったり、更新があっても設計書を更新する程の余裕がなく陳腐化したりすることが目に見えているのであれば、無理に作成することはないと言えます。しかしクライアントに提出を求められている等の理由から、企業やプロジェクトでは作成が必須となっているところもあるので、今回の記事を参考に、基本設計、詳細設計がそれぞれどういった性質を持っているかを覚えておきましょう。