システム開発において、仕様書はとても重要な資料の一つです。仕様書の精度次第でシステム開発が成功するか否かが決まるといっても過言ではありません。本記事では、システム開発において成功する仕様書の書き方及び書き方のポイント、設計書との違いについて徹底解説致します。
仕様書とは
システム開発における仕様書は、「システムのどの部分にどのような機能を搭載するのか」「システムのどの部分からどのように遷移させるのか」といった、システムの最終的なあるべき姿を記したものです。
仕様書を作成する目的
システム開発において、仕様書を作成する目的は、ベンダーがシステム開発を行うにあたり、クライアントとの間で認識のギャップを発生させないようにするためです。
仕様書と設計書の違い
システム開発における設計書は、システムに関する構造及び形、機能等を記したものです。具体的には、仕様書で定義したシステムを実現するための制作工程を記します。前述した通り、システムにおける仕様書はシステムの最終的なあるべき姿を定義することです。
システム開発における仕様書と設計書の持つ意味は異なりますが、どちらも作成しなければいけない大切な書類となっています。また、仕様書はベンダー及びクライアント双方で共同作成することになっていますが、一方で、仕様書はベンダーが作成します。
システム開発におけるフェーズごとに必要な仕様書及び設計書とは?
システム開発において、仕様書及び設計書は必ず必要な書類です。しかし、それぞれ1種類ずつ用意するというわけではないので注意が必要となります。
システム開発は、次の3つのフェーズに分けて考えることが可能です。
- 要件定義
- 基本設計
- 詳細設計
上記のフェーズ毎に仕様書及び設計書が必要となります。本項目では、上記フェーズごとに必要な仕様書及び設計書について、解説致します。
要件定義
システム開発において要件定義のフェーズで作成する成果物は、要件定義書となります。要件定義書とは、システム開発初期の段階で作成する全体の設計図のことです。
要件定義のフェーズでの仕様書とは、開発を行うシステムの概要及び目的、開発理由を記した書類を指します。一方で設計書とは、システムに搭載する機能及び機能を搭載するための手段を記したものとなります。
基本設計
システム開発において基本設計のフェーズでの仕様書とは、前述しあ要件定義書で定義したシステムをどのような手段で開発をしていくか、全体の基本的な使用を記したものです。一方で設計書とは、システム導入後の業務フロー及びシステムに実装する機能一覧、画面のレイアウト及びデータベース設計、必要に応じて外部システムとの連携について、記したものです。
詳細設計
システム開発において詳細設計のフェーズでの仕様書とは、クラス図及びモジュール図といったシステムの構造を記したものです。一方で設計書とは、アクティビティ図及びフローチャート、シーケンス図及びIPOといったシステムを実現するための手段を記します。
仕様書の種類
仕様書には様々な種類があり、ベンダーだけでなくクライアントが作成するものも存在します。本項目では次の4種の仕様書について、詳細を解説致します。
- 要求仕様書
- 機能仕様書
- 技術仕様書
- 詳細仕様書
仕様書の種類 | 記載内容 | 作成者・作成方法 |
要求仕様書 | プロジェクトに期待されるニーズ | クライアントが作成 ※内容はベンダーと共有 |
機能仕様書 | ・新システム開発:要求仕様書のニーズを実現するためのソフトウェアの機能 ・既存システム改修:既存システムの現在の仕様 | ベンダーが主体となりクライアントの要求をヒアリングして作成 ※内容はクライアント及びベンダーの全てのエンジニアと共有 |
技術仕様書 | 機能仕様書の機能を開発するための方法 | ベンダーのSEがプログラマーと相談して作成 ※内容はベンダー内で共有 |
詳細仕様書 | システムに搭載する機能 | ベンダー及びクライアントが共同で作成 ※内容はベンダー内のみで共 有 ※クライアントには開示されない |
要求仕様書のサンプル・書き方
本項目では、要求仕様書のサンプル及び書き方についてご紹介致します。
サンプル:総務省「パッケージソフトに対する要求仕様書(サンプル)」
上記サンプルの書き方(項目)
- 目次
- 件名
- 利用期間
- 本業務の目的
- 本業務の基本的な考え方
- 業務におけるサービス利用の範囲
- 作業内容
- 利用開始支援に係る納品物等
- 業務サービス要件
- ネットワーク要件
- 規模要件
- 信頼性等要件
- サービスレベル
- 情報セキュリティ要件
- テスト要件
- 移行要件
- 運用・保守要件
- 作業体制及び方法
- 特記事項
機能仕様書のサンプル・書き方
本項目では、実際の機能仕様書のサンプル及び書き方についてご紹介致します。
サンプル:株式会社 制御技研「研究環境マネジメントsystem Lab Manager System」
上記サンプルの書き方(項目)
- 目次
- 機能概要
- 基本画面
- メニュー
- サブメニュー
- アラームサマリー
- スケジュール
- ログイン
- エネルギー管理
- 平面図
- 系統図
- 状態一覧
- 履歴一覧
- アラーム設定
- ヒストリカルトレンド
- 帳票
- 発停
- 局排設備稼働状況
成功しやすい(わかりやすい)仕様書の特徴
システム開発に成功しやすい仕様書には共通した次の4つの特徴がありますので、ご紹介致します。
- イメージ画像や図が用いられている
- 画面遷移図がわかりやすい
- シーケンス図が用意されている
- 細部にわたって説明がある
イメージ画像や図が用いられている
システム開発に成功しやすい仕様書は、必ず文章だけでなく、イメージ画像や図が用いられています。クライアントと共有するための仕様書はもちろん、エンジニアやプログラマーが確認する仕様書にもイメージ画像や図を積極的に用いましょう。イメージ画像や図があると、認識のギャップがすくなくなり、共通の完成形に向けて足並み揃えて進むことが可能です。
画面遷移図がわかりやすい
画面遷移図は、システム導入後のクライアントの現場担当者の行動及び導線の把握を行う上でとても重要です。現場担当者の想定される行動パターンをきちんと考えておくことで、トラブル発生のリスクを軽減することが可能となります。
シーケンス図が用意されている
シーケンス図とは、プログラムの処理流れ及び概要を設計するために用いられる図です。時間軸に沿ったクラス及びオブジェクト間のやりとりを図で表現します。クライアントの現場担当者の行動に対し、システム上どのように対応するのかという流れを把握しておくことで、プロジェクトチーム内での認識のギャップが発生しないように準備しましょう。
細部にわたって説明がある
システムの文字数制限及びポップアップ表示される予定のメッセージ内容等、細部にわたり記されている仕様書もとても親切です。確定している部分に関しては積極的に仕様書内に記しておきましょう。
失敗しやすい(わかりにくい)仕様書の特徴
システム開発に失敗しやすい仕様書にも共通した次の4つの特徴がありますので、ご紹介致します。
- PowerPointで作成した資料のみ
- イメージ画像や図がない
- 画面遷移のイメージがない
- 細部の説明がない
PowerPointで作成した資料のみ
主にクライアントにおいて、システム開発の知識が乏しい人の場合、よくありがちなのが、社内プレゼン用に作成したPowerPointの資料(企画書)を仕様書と勘違いしているケースです。
PowerPointの資料だけでは、ベンダーには具体的なイメージが伝わらないことが多く、最終的にクライアントがイメージしていたものと違う成果物ができてしまうことも少なくありません。PowerPointで社内プレゼン用に作成した資料は仕様書とは別であるということをきちんと理解しておくことが大切です。
イメージ画像や図がない
成功しやすいシステム開発の仕様書とは逆のケースで、失敗しやすい仕様書には、イメージ画像や図がないことが多いです。文章だけでは、ベンダー及びクライアント双方で認識のギャップが発生しやすくなってしまいます。そうならないために、仕様書には必ずイメージ画像や図を用いるようにしましょう。
画面遷移のイメージがない
画面遷移はユーザビリティに直結します。しかし、失敗しやすい仕様書には画面遷移のイメージがないことが多いというのが現状です。あらかじめベンダー及びクライアントが画面遷移のイメージを共有できるよう、画面遷移のイメージは必ず用いるようにしましょう。
細部の説明がない
失敗しやすい仕様書の特徴として、仕様書に細部の説明がなく、大まかな部分しか記されていないケースが挙げられます。仕様書の時点で、不確定要素があまりにも多すぎると、明確にしなかった部分の工程において認識のギャップが発生してしまう可能性が高まります。仕様書作成時点で、曖昧な部分はない状態まで内容を詰めておく必要があります。
成功する仕様書の書き方のポイント
成功する仕様書の書き方には次の4つのポイントが挙げられます。
- イメージ画像や図を積極的に使用する
- 5W1Hに沿って記載する
- 詳細について記載する
- 仕様書作成のためのツールやテンプレートを活用する
本項目では、上記4つのポイントを解説致します。
イメージ画像や図を積極的に使用する
前述してきたように、成功する仕様書にはイメージ画像や図を積極的に使用することが不可欠です。ベンダー及びクライアント間で認識のギャップが生じることのないよう、決して文章のみの仕様書にならないよう気をつけましょう。
5W1Hに沿って記載する
5W1Hとは、「who(誰が)」「what(いつ)」「where(どこで)」「what(何を)」「why(なぜ)」「how(どのように)」の頭文字を取ったものです。この5W1Hに沿って仕様書を作成することで、読み手に伝わりやすいものとなります。クライアントはシステム開発において専門的な知識が乏しいことが多いため、IT専門用語等はなるべく使用しないといった配慮が必要となります。
詳細について記載する
仕様書は詳細を細部にわたって記せば記すほど後々の作業工程や、成果物の認識のギャップが発生しにくくなります。仕様書作成段階でなるべく不確定要素はなくす努力が必要です。
仕様書作成のためのツールやテンプレートを活用する
仕様書を1から作成するためには膨大な時間がかかってしまいます。そのため、仕様書作成のためのツールやテンプレートを活用することで効率的に仕様書を作成することが可能です。例として次の2つのツールをご紹介致します。
- moqups
- Prott
moqups
moqupsは、無料で使用できるブラウザベースのサービスです。豊富な種類の図形及びアイコン、フォントが用意されており、誰でも簡単にドラッグ&ドロップのみでワイヤーフレームを作成することが可能となっています。仕様書にイメージ図を入れたい時におすすめのツールです。
moqups ホームページ | https://moqups.com |
Prott
Prottは、ワイヤーフレームを作成するツールの中でも、スマートフォン向けのWebサイト及びアプリにおすすめのブラウザベースのツールです。注目すべきはプレビュー機能で、ジェスチャー及びアニメーションを設定するだけで、実際のサイト及びアプリのように画面を遷移させることが可能となっています。
Prott ホームページ | https://prottapp.com/ja/ |
まとめ
本記事では、システム開発において成功する仕様書の書き方及び書き方のポイント、設計書との違いについて徹底解説致しました。ベンダー及びクライアント双方の間で認識のギャップが発生しないようにするためには、丁寧でわかりやすい仕様書を作成することが必要不可欠です。仕様書作成段階で不確定要素はなくして、細部まで記すように心がけましょう。