アプリ開発における仕様書の概要と種類とは？要求書を書くときのポイントを解説

アプリ開発に欠かせない書類の一つが仕様書です。アプリ開発の成功は仕様書の完成度にあるともいわれています。とはいえ、初めてアプリ開発に携わる場合、そもそも仕様書がどのようなものかわからないという方もいるでしょう。本記事では、アプリ開発の仕様書の概要、記載すべき情報、目的と重要性、種類、書き方などについて解説します。

ハイブリッドテクノロジーズの
開発サービスはこちら

アプリ開発における仕様書とは？

アプリ開発に欠かせない仕様書とは、開発するWebシステムに必要な要求事項をすべてまとめた書類です。Webシステムを開発する過程では、成果物として完成するまでにさまざまな文書が作成されますが、その中でもプロジェクトのゴールを明確に示す仕様書は非常に重要です。具体的にどのような機能が必要であるか、どのページからどのページに遷移させるかなど、目指すアプリの姿を記したものです。その仕様書を開発にかかわるメンバー全員で共有することで、共同作業でありがちな認識のズレを防ぐことができます。
アプリ開発の企画プロセスとは？費用相場や発注元が知るとメリットがあるプログラミング言語の知識を解説

アプリ開発で仕様書を作成する目的・重要性

仕様書を作成する重要な目的は、開発者とクライアントの認識の齟齬をなくすことです。アプリを開発する際には、仕様の抜け漏れが生じないように、関係者間で認識のズレがないか注意することが大切です。

仕様書は、クライアントとの契約締結時の重要な書類でもあり、アプリの開発目的やイメージ、納期や予算、操作性などが具体的に記されています。満たすべき要求事項である仕様が曖昧であると、認識齟齬が生じてしまうため、開発において仕様書は必要不可欠な存在といえるでしょう。

仕様書があることで、開発者とクライアントは考え方や開発方法をすり合わせることができるので、開発者側の勝手な思い込みや相互の認識のズレをなくす手立てになります。仕様書がないと、開発途中で仕様変更が起きやすく、それに伴い工数が増えてしまいます。しかし、仕様書を作成することで、開発の際に追加費用や、追加で開発のすり合わせを実施する工数が発生するリスクを抑えられることは重要なポイントです。

仕様書と設計書の違い

アプリ開発に欠かせない書類には、設計書もあります。仕様書と似たような言葉で混同しがちですが、その違いを把握しておきましょう。

アプリ開発における仕様書とは、アプリに求める姿を明確に示した書類です。一方、設計書とは求めるアプリのイメージを完成させるためにどのように実現するかを記載した書類になります。言い換えると、完成イメージを明確にしたものが仕様書で、完成までの制作工程を示したものが設計書です。

また、仕様書は発注者が作成しますので、誰にでもわかりやすい表現が使われている場合が多いですが、設計書はエンジニアが開発作業で使用するため、開発者側が専門用語を使い、手順などを細かく記載しているのが特徴です。

ただし、Webシステムに限りませんが、開発現場では仕様書と設計書が混同して使われていることがあります。

開発工程で作成される仕様書の種類

複数の工程にスタッフが携わるシステム開発では、仕様書は1種類だけではありません。
システム開発は、要件定義、基本設計、詳細設計という3つのフェーズにわかれますが、各段階で仕様書が必要です。それぞれ目的や記述する内容が異なり、発注側が作成するものもあります。

例えば、ウォーターフォール（Waterfall）型と呼ばれる日本で主流のシステム開発では、要件定義から計画立案まで行う上流工程ごとに仕様書があります。代表的なものとしては、要求仕様書、外部仕様書、内部仕様書などが挙げられます。要件定義以降はテスト仕様書も一緒に作成されることが多いです。

要求仕様書

要求仕様書とは、開発するアプリやシステムなどの機能、特徴、特性などをまとめたものです。技術的な要件を記載するのではなく、どんな課題を抱えていて、その課題を解決するために、このような仕様のアプリを求めている、など要求事項（アプリの目的、予算、納期など）を仕様として記述します。なお作成前に社内で要求事項についてコンセンサスを取っておく必要があります。

開発を希望するアプリに何を求め、どのようなゴールを達成したいのかを決定するのは、当然ですが、発注側のクライアントです。すなわち、要求仕様書は、要求定義フェーズで作成するものなので、クライアントの責任において作成します。

一方で、要件定義の段階で、クライアントではなく、開発会社側のSEがまとめる場合もあります。システムによっては、要求仕様書を作成しないで、要件定義書としてまとめて作成することもあるのです。しかし、その場合でも、具体的なアプリの目的、予算、納期などの要求事項はクライアント側が提示しなければなりません。

外部仕様書

外部仕様書は、要求仕様書を受けて開発者が機能やシステム構造を具体化した文書で、基本設計書とも呼ばれます。このフェーズでは、具体的にユーザーインターフェース（画面レイアウトを含む）、帳票、入出力データの種類など、機能面における要求がまとめられています。
外部仕様書の作成者は開発会社です。とはいえ、開発会社にすべてを任せてしまうのではなく、クライアントも外部仕様書の作成に積極的に関わりましょう。外部仕様書は外側から見えるシステムの機能の仕様についてまとめるため、発注側の意向を反映させる最後の機会といえます。

内部仕様書（詳細仕様書）

内部仕様書は、開発者が外部仕様書の内容をもとに機能の詳細を具体的に記載したもので、機能仕様書や技術仕様書に細分化されます。外部仕様書と異なり、システムの内部のデータ処理など、クライアントやユーザーに見えない部分についての仕様書です。基本的にシステム開発の担当者やプログラマー向けの文書なので、開発会社の責任で作成されます。外部設計で決めた機能を実装しやすいように分かりやすく記載する必要があります。

機能仕様書

機能仕様書（FSD）とは、ソフトウェアの開発で用いられる、アプリ開発に必要な要件をまとめるためのフォーマットです。要求仕様書の内容を実現するために、アプリ機能、動作環境、対応プログラミング言語について定義しています。クライアント側と開発側の認識齟齬の有無を確認するために用いられますので、開発会社のエンジニアがクライアントの要望を聞き取り作成します。

機能仕様書を作成する際に、記述漏れや見落としがあると、アプリ開発に支障が出てしまうため、構造的に要件を記述することが肝心です。そのためには、文と文の主従関係が分かりやすいように、書き方は箇条書きがおすすめです。主文でまず仕様を明確に記載してから、必要な情報を補足文で追加すると、簡潔な機能仕様書が完成します。

ただし作成するにあたって、デバイスやプラットホームについての知識に加えて、ソフトウェア開発の経験が必要となるケースも少なくありません。さらに、機能仕様書は、詳細にわたる記述が求められるため、作成時間が思いの外かかるケースもあります。

技術仕様書

機能仕様書をもとに、プログラムの実装を記載した仕様書で、プログラマーの間での認識の
ズレがないように統一するために用いるものです。具体的には、プログラミングの土台となるデータ構造の設計、関係データベースの設計、機能のアルゴリズム、開発ツールなどを記載します。ただし、機能すべてについて作成する必要はなく、複雑な機能のみ作成します。

技術仕様書は、開発会社のエンジニアとクライアントが共同で作成する機能仕様書と違い、エンジニアがプログラマーと相談しながら進めていくのが一般的です。そのため技術仕様書ではクライアント側が協力できることはありません。また、技術仕様書はクライアント側に開示されることは、一般的にはありませんが、開発したアプリを自社で適切に運用していくために、開発会社に技術仕様書の提供を求めることもできます。

システム開発では、認識齟齬をなくすために、技術仕様書を作成し、定義や手法を明確にさせてから開発を進めることが重要です。

その他の仕様書

仕様書には、その他に、見積仕様書、購入仕様書、確定仕様書などがあります。それぞれどんな内容の文書か見ていきましょう。

購入仕様書

購入仕様書とは、簡単に言うと、物品購入について買い手が記載した説明書のことです。つまり、希望するアプリやシステムなどについて、発注者が受注者に要求する文書になります。要求する機能についてのみわかりやすく記載し、手段などの要求は受注者に任せるのが一般的です。また、懸案事項は明確にしますが、「詳細は協議で決定」というように記載すると、制作後に起こるトラブルを回避しやすくなるでしょう。

見積仕様書

見積仕様書は、売り手が製品の説明と見積金額を提示する書類です。購入仕様書に記載されている発注者の要望を考慮に入れながら、実現できる仕様と金額を記載します。発注者は発注先を決める際に、複数の取引先の見積仕様書を比較検討することができます。

確定仕様書

発注者が見積仕様書を比較検討して選んだ受注者に対して、制作を希望するために、最終提案内容を提示する文書のことです。内容は契約書とあまり変わりませんが、価格や仕様、数量など、項目は契約書よりも細かく記載します。

プログラム仕様書

プログラムの目的や定義、構成などを記載した文書です。製品を開発する技術者に周知するために仕様についてまとめたものです。

仕様書の種類と作成者

アプリ開発では初期の段階で複数の仕様書が作成されますが、各仕様書の作成者を確認しておきましょう。以下の表にまとめました。

以上のとおり、要求仕様書を作成するのは、アプリ開発を依頼するクライアントです。その他の仕様書は受託開発会社が作成します。

わかりやすい要求仕様書を作成するポイント

ここでは、実際に要求仕様書を作成する際に活用できるポイントを5つご紹介します。
関連リンク：アプリ開発 手順

①プロジェクトの目的や提供する価値を記載する

仕様書を作成する段階で、開発側に「プロジェクトの目的やプロジェクトを通じて提供したい価値」を伝えておくことが重要です。開発が完了するまでプロジェクトの方向性が不安定にならないように、プロジェクトの目的、解消したいユーザーの負、提供したい価値を明確にしておくことで、依頼側と開発側の間で認識の齟齬を防ぐことができます。結果的に無駄な確認や修正の工数の削減も可能です。

また、納品後に仕様書の内容と異なる箇所が見つかった場合に、責任の所在をはっきりさせるためにも目的を明確にしておくことは重要です。システム開発が進んでいき、後に要件やスケジュールの変更が必要になった際にも指針になります。

②平易な言葉遣いを心がける

仕様書は、だれにもわかりやすい言葉を使って記載することが重要です。アプリ開発にはさまざまな職種のスタッフが関わります。見た人によって解釈が違ってくるような要求仕様書では、そのアプリ開発は上手くいかなくなるでしょう。

仕様書は、プロジェクトに関わるすべての関係者と共有するための指標となるため、開発側と目線をそろえるためにも、正しい日本語で、できるかぎり平易な言葉遣いを心がけましょう。

③画面遷移図を記載する

画面遷移図も必ず記載しましょう。画面遷移とは、どの画面からどの画面に移れるかを描いた図です。アプリでは、ページ間での移動でとくにトラブルが多く見られますが、画面遷移図があれば、アプリの全体像がわかるので、画面間の相互関係も把握できます。つまり、画面遷移図を含めることで、機能などにおける考慮漏れや対応漏れなどを減らすことができるのです。

画面遷移はアプリの利用においてユーザビリティに影響を与える大切な要素です。活用されるアプリを開発するには、ユーザーがアプリを通してどのように行動し、どのような結果を期待しているのかを考え、自然に扱えるわかりやすい画面遷移図を設計しましょう。

④イメージ画像を挿入する

仕様書が文字だけで記載されていると、アプリの完成像を的確に伝えることができません。文章だけの仕様書は理解しにくく、イメージの共有が難しくなるでしょう。そこで、仕様書内にイメージ画像を挿入すると、具体的なアプリの方向性とイメージの共有がしやすく、完成像を正しく伝えることができます。

システム開発の作業は多数のスタッフが共同で行うため、認識のズレが生じやすいものです。このようなミスコミュニケーションを解消するには、画像の活用が効果的といえます。

内容を瞬時に判断しやすいこともビジュアルイメージのメリットです。特に、言語で細かなやり取りがしづらいオフショア開発の際にも有効と考えられています。アプリ開発の仕様書にトップページのイメージ写真や画面遷移図などを盛り込めば、だれにとってもわかりやすい仕様書に仕上がるでしょう。

⑤説明を詳細に記載する

仕様書は細部まで詳細に記載することが重要です。要求事項が詳しく、かつ具体的に記載されていれば、開発中に起きやすい関係者間の認識のズレを抑えられます。この要求仕様書を確認して、開発側はプログラミングの設計書とすることが多いこともあり、細かく詰めることが必要です。コンテンツの文字数やフォームに使用する文章など、明確化できるところは可能な限り明確にしましょう。

仕様書の内容に不確定な要素が多く見受けられる場合、開発側が随時確認することになるため、コミュニケーションコストの増加につながります。無駄なコストを減らすためにも、細部の情報をまとめた仕様書が必要です。

仕様書の目次サンプル

仕様書は目的によって異なりますが、基本的にどの仕様書でも構成は同じです。まず目次を記載し、全体について説明してから、システム開発の前提条件やシステムの概要など、それぞれの項目について説明していきます。仕様書を作成するときは、次の目次サンプルをぜひ参考にしてください。

ハイブリッドテクノロジーズの提供サービス

ハイブリッドテクノロジーズでは、ビジネスデザイン、UIUXデザイン、設計、実装、テスト、リリース、運用、保守まで一気通貫してサービスを提供しております。500名以上の経験豊富なエンジニアにより、迅速かつ高品質なシステム開発が可能です。 アジャイル開発、ウォーターウォール開発、ハイブリッド開発と言った様々な開発手法に対応しており、契約形態に関しましてもラボ型契約と受託型契約の2つから選択いただけます。お客様の状況や開発内容に応じて、開発手法と契約形態を柔軟にご指定いただけますが、それぞれの開発手法、契約形態の特徴の親和性から、アジャイル開発ではラボ型契約が、ウォーターウォール開発とハイブリッド開発では受託型契約を選択されるクライアント様が多数を占めます。

ラボ型開発について： ラボ型開発 サービス

受託型開発について： 受託開発 サービス

ハイブリッドテクノロジーズが選ばれる理由

弊社ではクライアント企業様及びエンドユーザー様の声を聞き、UIUXを意識したビジネスデザインを行なっております。 テーマを決めて分析し、仮説を立ててビジネスデザインを行い、プロトタイピング、検証、フィードバックを受け、再度分析から始める。 この一連の流れを、アジャイルスクラム開発に精通した500名以上のエンジニアが高速で回していくことにより、最速でより良いものを実現していきます。 ハイブリッドテクノロジーズには市場の声を現実にするための仕組みとメンバーが揃っています。

システム開発の成功事例

システム開発での成功事例をご紹介します。

補助金クラウド(株式会社Stayway) サービスURL：https://www.hojyokincloud.jp/

サービス内容

補助金活用を検討する企業が、専門家に採択可能性や申請できる補助金の種別などの相談をすることができるWEBプラットフォーム

サービス上の課題/目指したいサービス

課題
コロナ発生以降、既存事業の立て直し、新規事業の創出が重要になった世の中に対して、行政が支援している補助金活用のニーズが増加している。 エンドユーザー側は多くの企業に行政書士などの専門家が不在のため各企業のニーズが満たされる補助金の種類や可能性が相談できる場面がなく、一から探すのもかなりの工数がかかっている状態が発生している。 金融機関/士業/事業会社おいても、補助金活用ニーズのある顧客との商談を円滑に進めるのが難しいという課題も存在している。

目指したいサービス
今回提供する補助金クラウドにより、エンドユーザー、士業事業経営をしている企業において以下の価値を提供が可能に。 エンドユーザーは、気軽にどの補助金が活用できるか、支援してくれる士業者とのマッチング、補助金採択の可能性を上げる申請相談が可能になります。 金融機関/士業/事業会社は、有効顧客の発掘、最新の補助金情報の入手、申請サポートによる採択率の増加が可能になり、売上増加が見込めます。

クライアント課題/要望

・新規事業の立ち上げ体制のリソースが不足
・UI/UX、システムの要件定義などの上流工程から体制構築したい
・自社の開発チームと組み合わせながら、擬似内製チームを構築したい
・事業状況に応じて柔軟にリソースを調整したい

当社ご提案内容

日本人によるUI/UXデザイナーの設計から運用保守まで一気通貫で対応できるハイブリッド型サービス ストックサービス

DocIT (株式会社ドキットメディカルサービス)

サービス内容

働き口を探す医療従事者と、働き手を求める病院をつなぐマッチングプラットフォーム

サービス上の課題/目指したいサービス

課題
高額な紹介料がネックとなりスポットで人が必要な際に苦心をする病院の課題解決

目指したいサービス
休日や長期出張の空き時間を有効活用したい医師と、長期連休などで一時的に人手が必要となる病院をマッチングすることで医師の働き方の多様化を実現するサービス

クライアントの課題/要望

・サービス構想はあるが、実現させる開発パートナーが必要
・上流工程からの開発サポートが必要

当社を選択していただいた理由

開発にあたってサービス設計から本開発まで、一緒に伴走し考えながら開発してくれるパートナーとして安心感を感じて頂き、当社を選ばれました。

当社ご提案内容

ラボ型（ストック）開発にて提案
1.医療求人の性質を鑑みた機能提案、システム設計・開発

本サービスでは失敗の許されない医療系求人を取り扱うため、求人マッチングをする前に信頼のできる医師・病院であることを確認できることが重要となります。 そこで、実際に求人マッチングした医師・病院による相互レビュー機能を実装することで、信憑性の高いレビュー情報を蓄積することを提案・実現しました。 また、求人マッチング前に病院担当者と直接チャット出来る機能も実装することでレビューでは分からない定性的な情報確認も可能としました。 アジャイルスクラム手法の開発を取り入れることにより、システム開発の進捗報告を実際に動くシステム画面をお見せしながらデモンストレーション形式で毎週行いました。

2.定期的なスプリントを繰り返し、顧客と一緒に品質を高めるプロセスにて進行

実際に動くシステムを毎週見ていただくことで、開発進捗についての安心感やお客様も気がついていなかった新たな改善点がを発見でき、それを修正して再度デモンストレーションを行いました。この一連の流れを回すことで、お客様の求めるものを高い品質でご提供しました。

3.デザインを用いた視覚的なアウトプットで、具体的なシステムイメージを共有

Webサービス開発に初めて挑戦するお客様のため、お客様が思い描くビジネスを実現するためのシステムイメージを具体化していくデザインサポートも担当。求人情報サービスという特性上、さまざまな情報要素が混在する中で、目に見える形でデザインを整理・提案し、お客様からのフィードバックを受け、再提案を繰り返すことで、よりユーザーにとっての最適なWebサービスのための設計・提案・実現を行いました。

まとめ

アプリ開発における仕様書は、開発者と発注者の認識の齟齬をなくすために欠かせない重要な文書です。仕様書は開発工程ごとに作成されるため、複数のタイプがあります。要求仕様書は発注者が作成しますが、詳細な説明とともに画面遷移図の記載が必要です。また、イメージ画像の挿入や平易な言葉遣いなどを心がけて、開発者側が見てわかりやいものを作ることがポイントです。要求仕様書をもとに開発者は外部仕様書や内部仕様書などを作成するため、情報の過不足のない完成度の高い要求仕様書が求められます。