アプリ・システム開発時の設計書＆テスト

先日、開発環境についてまとめていた際、開発の仕方や基本的設計のお話まで入ってしまったので、今回、システム開発時の設計の考え方について簡単に記載したいと思います。

[quads id=”1″]

まずはじめに、こちらの内容は私自身が個人で調べまとめ上げたものなので、組織や本の説明などでは違う場合が多々あります。ご了承ください。※後日、更新する可能性があります。

基本的な昔ながらの設計書

それでは、まず基本的な昔ながらの設計書の考え方からはじめましょう。この考え方を抑えていくだけで、かなり具体的に見えるようになります。

１．要求定義
２．要件定義
３．基本設計
４．詳細設計

順番としてはこの流れ。この中で、一番間違えやすいのが、１と２を混同してしまうこと。１は、お客様が○○したい！という希望要求をメインに考えます。対して、２は、システムの仕様書。１に対して２が定義されると考えてください。では、更にここから落とし込んでいきます。

１．要求定義

まず、要求定義ですから、お客様の要求を纏めあげましょう。その上で絞っていき、要求を定義します。

①お客様が○○したい！という希望要求を把握する。
②行うために何が必要か記述
③（事業）運用際の「一連の流れ」を考え、実現できるコンピューターシステムを定義

例えば、社内業務用に運用していくのであれば、社内用コンピューターシステムは何にするのか？この運用までを把握してのシステム選択で、２の要件定義で決めるものが変わります。

◆要求定義で記載する一般的な項目一覧

さてここで、要求定義で記載する項目を考えてみましょう。お客様にわかりやすく提出する内容としては以下の内容になると思います。（※場合により要件定義にも含まれることもあります）

Ⅰ．要求概要
Ⅱ．現状の課題と改善案
Ⅲ．システム化の範囲・選定
Ⅳ．基本要件と優先順位
Ⅴ．到達目標
Ⅵ．システムの実現手段
Ⅶ．概略費用
Ⅷ．効果（定性/定量）
Ⅸ．体制図
Ⅹ．概略スケジュール

お客様の要求を元に、どういった部分へ到着したいのか？など纏めてみてください。

２．要件定義

それでは、１が定まったとして２の要件定義に移りましょう。ここでは、要求定義によりでた要求を行うために必要な、システム仕様書になります。

①要求実現にむけて、「～が必要」と記載するシステム仕様書
②システムが何をしなければならないのか、記述
③システムの機能・DB・通信などの利用方法など記述

ここで大事なことは、「必要なこと・やりたいこと・やらないこと」をきっちり分類把握すること。これはかなり重要です。自分は過去にシステム開発に一度触れさせて頂きましたが、抽象的なままだと、後工程の中で要件の抜けが見つかります。

普通に作っていっても起こる「抜け」の工程が生まれる中、要件が抜けているのはかなりプロジェクトが送れることを意味します。（というか遅れましたｗ）１と２を含め、きっちりと要求内容を把握し、運用時まで見据えての要件を出しましょう。（でないと赤（ぉ

といっても、あまり経験がないと、この要件内容がつかめないところがあるのも事実。

そんな時は、予めお客様がいる場合は、契約時に制作時において別途必要なフレームが生まれた場合、別費用がかかることに同意をいただくことで、難所をいくらかスムーズに進むことが出来ます。

補足：
要求案件をまとめ上げるのは、かなり大変なことがあります。そんな時は、①ビジネスモデル＋お客様のシステム運用方法＋販売手法を考えたうえで、②システム定義をつくり、「必要なこと・やりたいこと・やらないこと」をきっちり絞る。これに尽きます。お客様により、簡単にできると思っている要求「○○したい！」が、システム上ではかなりの工数や費用が生じることがあるからです。何でも小さいところからコツコツと。これは、システム開発でも同じ。大きく何でも盛り込まず、着実に進めれるところを抑えましょう

※というか過去、制作が始まってから要求追加のリピートが起こり、制作工程（日数）から見積もりまで全く合わなくなった経験が（大汗）やりたい気持ちに応え続ける姿勢だと・・システム開発受注は終焉を迎えやすいので、きっちりビジネス構成からの最低限路線で結びましょう。

◆要件定義で記載する一般的な項目一覧

それではここで、上記を踏まえた上で主に要件定義で記載する項目を眺めます（ぇ

Ⅰ．業務用件　　　　　：現状、新業務フロー等
Ⅱ．システムの目的　　：システムが何をしなければならないのか
Ⅱ．システム要件　　　：インフラ系を中心にネットワークやプロダクト等
Ⅲ．セキュリティー要件：セキュリティに関しての要求事項等
Ⅳ．機能要件　　　　　：大まかな機能や、「これを実現して欲しい」等の要求
Ⅴ．運用要件　　　　　：運用まわり、バックアップ、容量見積等
Ⅵ．その他　　　　　　：ケースバイケースで他に何かあれば

これを元に、内容を定義してみてください。

３．基本設計書

基本設計書

それでは、いよいよ要求・要件定義も揃い、基本設計へと移ります。基本設計は，これまでの内容を開発者の視点で書き直していく作業です。お客様も読みやすいほど良い設計書になりますので、わかりやすく、具体的に落としこんでいきましょう。

基本設計は主に外部設計とも呼ばれます。外部設計書とは、システムの使い勝手にかかわる部分を主に設計し、そのシステムが外部とどういう関係をもつか、どのような業務の流れの中で、どのように使われ、他のどういったシステムと連携をとるのかなどを詰めた設計書のこと。業務運用時に核になる部分となります。

基本設計は３つのプロセスがある。

基本設計には、「機能要件設計」「システム方式設計」「アプリケーション方式設計」というプロセスがあります。

機能要件設計

どのような機能をアプリケーションに求めるかを設計する。その際「画面」「業務プロセス」「データ」という三つの切り口に分ける。

システム方式設計

性能や信頼性などの非機能要件を整理する。それを踏まえて，ハードウエアやソフトウエアなどの構造や実装方式を練る。

アプリケーション方式設計

非機能要件を考慮しつつ，機能要件設計で明確にした機能（画面，業務プロセス，データ）を適切なサイズのモジュールに割り当てる。

各設計書に関しての説明は、ここでは割愛します（何）。知りたい方は、各設計名目を調べてみてください。

◆基本設計（外部設計）で記載する項目一覧

それでは、基本設計（外部設計）に記載する項目内容を見てみましょう。

Ⅰ．システム設計　　　　：インフラ、ネットワーク、機器構成、プロダクト構成等
Ⅱ．画面設計　　　　　　：デザイン、項目定義等
Ⅲ．ＤＢ設計　　　　　　：論理／物理設計、ＥＲ図等
Ⅳ．インターフェイス設計：他システムとの外部インターフェイス、ファイル、帳票設計等
Ⅴ．処理設計　　　　　　：ＤＦＤ、ＩＰＯ、ＣＲＵＤ、コード設計等
Ⅵ．業務・運用設計　　　：サービススケジュール、バックアップ、リカバリー方法
　　　　　　　　　　　　　新業務フローの詳細等
Ⅶ．テスト設計　　　　　：テスト方法、ツール等の設計
Ⅷ．その他　　　　　　　：補足資料他

主に上記な内容になります。ここで大事なのは、開発手法にもよりますが、テスト設計までをきっちりと構築してしまうこと。というのも、ツールなどの設計とここにありますが、最初の開発時の環境設定でテストツールを組み込むことがあるから。

最初に組み込むことで、開発時にエラーが瞬時に掴め、開発速度が上がる利点があります。また、テストしたい項目を基本設計時に書くことで、項目が抜けることもありません。しっかり組み立てましょう。

４．内部設計

さて、基本設計がおわりましたら、いよいよ内部設計に入ります。内部設計は、外部設計で設計した内容を、具体的にどのように実装するかを設計する場所。プログラム設計の基盤となる設計です。

求められる機能やデータの流通を実現するためのソフトウェアの動作や処理、ソフトウェアの構造、ソフトウェア間でのデータの受け渡しなどを記述します。

◆内部設計で記載する項目一覧

それでは具体的な項目内容一覧を見てみましょう。

Ⅰ．開発環境　　　　　　：各技術のバージョン指定（サーバー、DB、言語、フレーⅡ．ムワーク、その他）
Ⅲ．機能分割
Ⅳ．モジュール設計書　　：処理手順やワークフロー
Ⅴ．内部データ　　　　　：入力と出力でフロー、モジュールの分割・結合度、強Ⅵ．度、情報隠蔽度合
　　　　　　　　　　　モジュール間でもデータの受け渡しを明記
Ⅶ．クラス設計書　
Ⅷ．データベースのテーブルの項目定義
Ⅸ．通信プロトコル設計書-：データのやりとりについてまとめる
Ⅹ．単体テスト仕様書

はい、これらの内容をみて詳細設計に感じる方もいるかもしれません。事実、内部設計は詳細設計と同意とされる場合もあります。この記事ではあえて、内部設計として記載します。

５．詳細設計

それでは、詳細設計とはどういったものなのでしょう？通常上記に含まれるものが詳細設計とされますが、ここではあえて、UI／UX部分を詳細設計に入れたいと思います。

UI:ユーザーインタフェイス　：ユーザーが触れるインターフェィス画面機能設計
UX:ユーザーエクスペリエンス：ユーザが使ったときに得られる経験や体感！

どういった画面配置で機能をおくか。それらはどういった動きをして、お客様にはどのように感じて頂けるようにするのか。こういったことを設計します。具体的に決まるほど、ユーザーのシステムの使いやすさは向上し、満足度も高くなります。

BUT！不要な動きはいれないこと。アニメーションが今流行ですが、どんな端末を利用した場合を想定しているか、対象はだれか？など内容により、良いと思った動きが、不必要なものになりかねません。良いシステムほど、シンプルにわかりやすくできているもの。ふとした時に、ほんとうに必要かどうか？考えてみましょう。

６．プログラム設計

最後にプログラム設計に入ります。設計書を書く場合と、このまま設計に入るパターンとがあります。大規模でプログラム分割などを大きく分けながら動かなくてはいけない場合を除き、ここまでの内容でほぼ設計は可能かと思われます。

というか、ここまで設計書を書くだけでもどれだけの構想が必要か？

そして、その後のテスト項目もあります。こういった流れにより、一般的にオリジナルシステムほど高くなっていくわけです。

テスト　ーシステムの挙動確認ー

ここまで、昔ながらの基本設計書の作り方を要求定義から見てきました。ここからは、各設計書で記載した、テスト項目についてまとめていきたいと思います。（V字テスト法）

こちらでは、外部設計で規定したテスト方法、ツールなどを用いて、各テストを行っていきます。

１．コードレビュー

まず、プログラムで書いたコードをレビューし、内容の確認をします。こちらはテストというより、プログラムコードを書きながら行う作業となります。

２．内部設計（詳細設計）で記載したテスト

内部設計（詳細設計）で記したテストを行います。こちらでは詳しくは以下のテストを行います。

Ⅰ．ユニットテスト：ソフトの振る舞いの検証
Ⅱ．単体テスト：ソフトウェアからバグを検出する
　　　・ホワイトボックステスト
　　　・ブラックボックステスト

よく、ユニットテストと単体テストは、同意に認識されることが多いですが、正しくは、上記の通り内容が異なります。まず、小さなユニットの振る舞いを検証した後、次に単体でバグが起きないか？を確認します。

３．基本設計（外部設計）テスト

次に、基本設計（外部設計）のテストを行います。こちらは一般的に結合テストと言われ、２で確認した単体モジュールを結合した際のテストとなります。テスト項目は以下の内容です。

Ⅰ．結合テスト
　　　・トップダウンテスト
　　　・ボトムアップテスト
　　　・サンドイッチテスト
　　　・ビックバーンテスト

結合してテストする項目はこの４つ。名前のとおりなのですが、詳しくは検索してみましょう。

４．要件定義のテスト

ここまで終われば、ほぼ動きます。が、ここからはシステムとしてどうか？の確認を取っていきます。

Ⅰ．総合システムテスト
　　　・性能テスト
　　　・負荷テスト
　　　・例外処理テスト
　　　・操作テスト

総合システムテストでは、このシステムの性能・負荷はどれくらいまで耐えられるか？例外の処理があった場合には？操作上はどうか？などを見ていきます。

５．要求定義テスト

要求定義テスト。要は要求を頂き、これを作りましょう！と決めた定義テストを行います。一般的には運用テストと呼ばれています。要求で決めた通りのものが出来上がっているか？運用しながら確認を行います。

６．本番テスト

運用テストである程度、システム全体の仕組みができあがったら、本番として正式に運用開始です。テストとあるのは、通常システム開発をして出来上がったプロダクトの場合、１年以内は保守するものになるため。

本番で動かしながら、何かあった際には修正をしていく形になります。（新たに機能追加などは保守には含まれません。あくまで要求定義内内容に限られます。）

７．保守

では、保守ではどの様ものが含まれるのでしょう？実は、完成したシステムもその後のハードウェアの問題や、運用上により起きた変化への随時対応が行われているんですね。なので、オリジナルで構築した場合、その後の保守費用がかなりかかる場合があります。

通常、保守費用はトータル費用の５％から２５％を年額として見積もります。よくあるのが、ここの見積もりを建てずに制作費用のみでいけると思っている方があること。ここの見積もりを持たずに制作を頼みますと、数ヶ月でシステム運用は終わりますので、開発を頼まれる方は、必ずこちらの見積もりもアバウトながらも提出、もしくは概算をご自身で出していくことをお勧めいたします。

もし保守を受けずに運用した場合、なにか起こった際の費用は高額になる可能性がございます。こちらも考慮の上、開発へと動きましょう。