2021年 12月 の投稿一覧

システム開発事例から見る成功する仕様書の書き方とは?書き方のポイントを徹底解説!

システム開発において、仕様書はとても重要な資料の一つです。仕様書の精度次第でシステム開発が成功するか否かが決まるといっても過言ではありません。本記事では、システム開発において成功する仕様書の書き方及び書き方のポイント、設計書との違いについて徹底解説致します。

仕様書とは

システム開発における仕様書は、「システムのどの部分にどのような機能を搭載するのか」「システムのどの部分からどのように遷移させるのか」といった、システムの最終的なあるべき姿を記したものです。

仕様書を作成する目的

システム開発において、仕様書を作成する目的は、ベンダーがシステム開発を行うにあたり、クライアントとの間で認識のギャップを発生させないようにするためです。

仕様書と設計書の違い

システム開発における設計書は、システムに関する構造及び形、機能等を記したものです。具体的には、仕様書で定義したシステムを実現するための制作工程を記します。前述した通り、システムにおける仕様書はシステムの最終的なあるべき姿を定義することです。

システム開発における仕様書と設計書の持つ意味は異なりますが、どちらも作成しなければいけない大切な書類となっています。また、仕様書はベンダー及びクライアント双方で共同作成することになっていますが、一方で、仕様書はベンダーが作成します。

システム開発におけるフェーズごとに必要な仕様書及び設計書とは?

システム開発において、仕様書及び設計書は必ず必要な書類です。しかし、それぞれ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/

まとめ

本記事では、システム開発において成功する仕様書の書き方及び書き方のポイント、設計書との違いについて徹底解説致しました。ベンダー及びクライアント双方の間で認識のギャップが発生しないようにするためには、丁寧でわかりやすい仕様書を作成することが必要不可欠です。仕様書作成段階で不確定要素はなくして、細部まで記すように心がけましょう。

『要件定義とは?』システム開発における要件定義の流れや進め方を徹底解説!

システム開発において、最も重要であるといっても過言ではない要件定義。要件定義がきちんとまとまっていなければ、システムが完成したとしてもクライアントのイメージとは違う成果物ができてしまうといったトラブルに繋がりかねません。

本記事では、要件定義の概要をはじめ、要件定義の流れや進め方、要件定義において実施すべきことや注意点等を徹底解説致します。

要件定義とは

要件定義とは、システム開発及びソフトウェア開発等において、クライアントの要求を実現するために必要な方法について検討を行い、開発のプロセスを文章としてまとめたもののことです。システム開発において、必ず最初に取り組むべきこととして、要件定義が挙げられます。要件定義がなければ、プロジェクトのスタートは不可能であると言っても過言ではありません。

要件定義・要求定義の違い

要件定義と似ている言葉として、要求定義があります。要求定義とは、クライアントが求める最終的なシステムの完成形及び希望等を明確にすることです。前述した要件定義は、この要求定義の内容を加味してまとめられます。さらに、システム開発中に要求定義の内容が変更となる場合があり、その際には要件定義も併せて変更する必要が生じます。

要件定義と基本設計の違い

基本設計とは、要件定義で決定した機能を具現化するための設計作業のことです。要件定義では、systemに搭載する機能を文章で表現していますが、基本設計では、systemに搭載する機能を画面イメージとして設計することで、開発を行うsystemにおいてvender及びclientの間に大きな認識のズレが生じていないかを確認していくことになります。

なぜ要件定義が必要なのか

前述してきた通り、要件定義とは、クライアントが求める成果物をスムーズに納品するために必要な開発のプロセスです。要件定義がなければクライアントの要望と全く違う成果物を納品してしまったというトラブルが多発してしまいます。このようなトラブルが発生するリスクを軽減するために、ベンダー及びクライアントは密な連携を取り合うことが大切です。

要件定義の流れ及び進め方

本項目では、システム開発における要件定義の流れ及び進め方について、解説致します。

  1. 業務要件の整理

業務要件とは、システム開発及びソフトウェア開発等の初期の工程において、クライアントの現状の業務について詳しく分析を行い、将来新しく実現するべき業務の流れを明確化したものです。

要件定義をまとめる初期の段階で、業務要件の整理を実施することで、開発するシステムに搭載される機能を決定していきます。

  1. クライアントへの聞き取り調査

前述した業務要件の整理を実施する際にも必要となりますが、要件定義において、ベンダーからクライアントへの聞き取り調査は必須事項です。クライアントが構築し運用していきたいと考えているシステムや、解決したい実務の課題等の要求をきちんとベンダーは認識する必要があります。

ただし、ベンダーはクライアントの言いなりになってはいけませんし、クライアントはベンダー任せにしてはいけません。ベンダーはクライアントの要求が実現可能か否かを判断する必要があります。一方で、クライアントはベンダーに任せきりにしてしまうと、成果物がイメージとかけ離れているといったことになりかねないのです。

  1. クライアントの要求を細分化

ベンダーはクライアントへの聞き取り調査を実施した後、要求の整理を行い、課題を見つけたり、実現可能性を検討したりする必要があります。

現在の業務フローの作成

クライアントの現状を把握し、現在の業務フローを作成します。

将来の業務フローの作成 

新しく開発するシステムを導入することで想定できる将来の業務フローを作成します。この際、前述した現在の業務フローよりも、現場担当者の業務が軽減されていた場合、システムによって効率化されたフローと言えるでしょう。

業務要件一覧の作成

クライアント側が主導となって、現在及び将来の業務フローをさらに一段階掘り下げていき、Excelシートなどに業務要件一覧を作成します。

機能要件一覧の作成

機能要件とは、クライアントの要求を実現するためのシステムを構築するために、必要となる最低限の機能のことです。将来の業務フローの実現に向けて、実際のシステムに搭載する機能の一覧を作成します。

システム構成

機能要件一覧を元に、ベンダーはシステム構成を考案します。

外部システムとの連携

開発するシステムが、クライアントの現在使用している既存システム及び外部サービス等との連携が必要か否かを明確にします。

データベース構造

ベンダーのエンジニアによるプログラミングを効率よく進行していくために、システムに最適なデータベース構成を決定します。

画面構成

ベンダーは、開発していくシステムの完成形をクライアントがスムーズにイメージできるよう、システム開発に詳しくない人でも分かるような画面構成図(どのようなシステムがあるかという一覧)及びワイヤーフレーム(システムのレイアウトを定める設計図)を作成します。

非機能要件

非機能要件とは、システム開発において、クライアントが潜在的に持っているユーザビリティ及びセキュリティなどの要件のことです。前述した機能要件とは違い、クライアント側が明確に意識している要件ではないことが多く、ベンダーは地道な聞き取り調査やコミュニケーションから非機能要件を正確に洗い出す必要があります。

ライセンス一覧

クライアントは、外部のシステムツールを活用する場合、ライセンス取得のため、一覧表を作成し整理する必要があります。

  1. 要件定義書の作成

前述した1〜3の工程の後、実際に要件定義書を作成します。要件定義書に記載すべき最低限の項目としては、「システム」「機能要件」「非機能要件」の3項目が挙げられます。

システムに関する項目

要件定義書の要とも言われるのが、システムに関する項目です。開発するシステムはどのようなものになるのかをクライアントに詳しく説明する必要があります。

システムの概要

クライアントに対し、開発するシステムがどのような機能を搭載しているのかという点を説明します。

システムを導入する目的

開発するシステムに搭載する機能によって、クライアントのどの要求を実現していくことができるのかという点を説明します。

システム導入後の業務フロー

開発したシステムが導入されると、現在の業務フローに対し、将来の業務フローがどのように効率化できるのかについて説明します。

機能要件に関する項目

開発するシステムの種類及び構造、処理することができる内容について説明します。

非機能要件に関する項目

開発するシステムのユーザビリティ及びセキュリティ等について説明します。

要件定義の成果物とは?

要件定義の成果物は、前述した要件定義書です。システム開発において、要件定義及び要件定義書の作成は、ベンダー及びクライアントの間での認識のギャップを少なくするためにとても大切であると言えます。

しかし、要件定義書には定められたフォーマットがないため、クライアントによって仕様が変わってくるケースが多いです。仕様が変わったとしても、ベンダーはクライアントから見てわかりやすい要件定義書を作成しましょう。

具体的には、階層構造で文章をまとめたり、IT専門用語を使用しないように気をつけたりといった点に気をつけることが大切です。また、要件定義書はベンダー及びクライアント双方の協力の元作成されるべきものであるため、双方の成果物であるとも言えます。

要件定義の成果物サンプル・例

要件定義の成果物は要件定義書であると述べましたが、要件定義書を細分化すると次のような成果物に分けることが可能です。

  • システム概要
  • 全体図
  • 機能一覧
  • 業務フロー図
  • 非機能要件
  • 納品対象
  • 現状分析資料
  • 用語集 など

実際の要件定義書のサンプルは下記の通りです。

要件定義を行うためにベンダーに必要な4つのスキル

要件定義を行うために、ベンダーに必要とされる4つのスキルについて解説致します。

クライアントの意図を組むコミュニケーションスキル

ベンダーには、システム開発の能力だけでなく、クライアントの意図を汲み取って、引き出していコミュニケーションスキルが必要です。前述した通り、クライアントにはクライアント自身が気づいていないような潜在的な要求が必ず存在します。

潜在的な要求をきちんと引き出すことができなければ、システムが完成した後に、実は必要だった機能が搭載されていないといったトラブルに発展してしまうことがあるので、密なコミュニケーションが必須となるのです。

開発業務に関する知識及び経験

要件定義をまとめるベンダーには、当たり前ではありますが、システム開発業務に関する豊富な知識及び経験が必須となります。知識や経験が浅いと、実際に実現不可能なシステム開発に着手してしまったり、無理なスケジュールを立ててしまったりと、後々クライアントに多大な迷惑をかけてしまうことに繋がりかねません。

スケジュール及びリスク管理のスキル

システム開発において、要件定義をまとめる作業はとても大切ですが、時間がかかりすぎると作業スケジュールに支障をきたします。そのため、要件定義をまとめる立場のベンダーには、プロジェクト全体の進捗状況を把握し、適切に動けるスキル及び経験が必須となるでしょう。

さらに、クライアントの要求を全て実現することが不可能である場合もあり、その際には納期及び予算、実際にシステムに搭載できる機能等も含めて検討を行うリスク管理が行えることも求められます。

ドキュメント作成のスキル

ベンダーにはプロジェクトメンバー全員が、共通の認識を持つことが可能なドキュメント作成のスキルが必要です。見る人によって、捉え方が変わってしまうようなドキュメントを作成してしまうと、ミスやトラブル等の原因となってしまう場合もあります。

要件定義においてクライアント側が実施すべきこと及び注意点

要件定義をまとめていくのはベンダーですが、クライアントはベンダーに任せきりではいけません。本項目では要件定義において、クライアント側が実施すべきこと及び注意点について解説致します。

社内見解の統一

クライアント側に複数の担当者がいる場合、特に重要となってくるのが社内見解の統一です。クライアント側で意見がまとまらない状態で、ベンダーにシステム開発を依頼しても意図しない成果物が完成したり、運用する現場の人間のことを考えて作られなかったりといった弊害が生じてしまう可能性があります。

事前に解決すべき課題を明確化

クライアントは、自社で解決すべき課題を明確化し、ベンダーに詳細を伝えることが必要です。自社でどんな課題を解決したいのかという点が明確になっていなければ、ベンダーもどのようなシステム開発を行っていいのかわからない上、工程に優先順位を付けることも困難となってしまいます。

現場のニーズを汲み取る

クライアントは、システム導入後、実際に運用していく現場のニーズをきちんと汲み取ることが大切です。プロジェクトメンバーに現場担当者も複数名入れ、現場担当者の意見を反映できる体制を整えましょう。

要件定義においてベンダーが実施すべきこと及び注意点

要件定義をまとめていくのはベンダーですが、ベンダーはクライアントの言いなりではいけません。本項目では要件定義において、ベンダーが実施すべきこと及び注意点について解説致します。

クライアントの真の要求を引き出す

ベンダーは、クライアントの潜在的な真の要求を引き出すことが必要です。真の要求を引き出すことができないまま、要件定義をまとめ、システム開発を行ったとしても、成果物がクライアントのイメージと乖離してしまっていてトラブルに発展してしまうといったことになりかねません。

クライアントの要求が実現可能か否かの判断

ベンダーは、クライアントの要求をそのまま鵜呑みにせず、現実的に実現可能か否かを判断する必要があります。技術的な面だけでなく、予算や納期スケジュール等も加味することが大切です。

誰でも理解できるドキュメントの作成

ベンダーは、システム開発に詳しくない人が見たとしても理解可能なドキュメントを作成し、クライアントと内容を共有する必要があります。IT専門用語等を多用したようなドキュメントだと、クライアントは完成後のシステムのイメージを描くことが困難です。また、イメージできたとしても、ベンダーと認識のギャップがある可能性があります。ベンダー及びクライアント双方の認識が共通となるようなドキュメントを作成しましょう。

担当者を明確にする

ベンダーはクライアントの担当者を明確にしておく必要があります。曖昧なままプロジェクトが進行してしまうと、不要な業務が増えてしまう可能性があり、さらに本来クライアント側が実施すべき業務までベンダーが引き受けてしまうことにも繋がりかねません。

まとめ

本記事では、要件定義の概要をはじめ、要件定義の流れや進め方、要件定義において実施すべきことや注意点等を徹底解説致しました。要件定義は、ベンダー及びクライアント双方が密に連携しあってまとめていくことで、クライアントにとって本当に必要なシステム開発に繋げていくことが可能です。ベンダー及びクライアントはどちらかに任せきりにすることなく、積極的にコミュニケーションを取り合って要件定義をまとめましょう。