無料の機能仕様書テンプレート: スムーズな開発のためのロードマップ

アジャイルでは、有益な製品をユーザーに提供するための最も効率的な方法を見つけることにフォーカスしています。 アジャイル開発では、多くの場合、従来から行われている機能要件書の作成やそのプロセスは財務面から選択すべきではないと考えられます。 しかし、より詳細な計画や草案を持つことができれば、より明確な情報を得ることができます。

アジャイル要求ツールの代表的なものに、ユーザー ストーリーがあります。 ユーザー ストーリーでは、ユーザーが何をしたいのかという文脈で機能を選択します。 似たようなユーザー ストーリーをまとめて、アジャイル エピックを作ることもできます。 ユーザー ストーリーは、従来の機能要件仕様書と同様にタスクや機能を記述しますが、開発者が実装する方法は記述しません。

ユーザー ストーリーでは、 「ユーザーとしては、そこから何かの利益が得られるようなものが欲しい」という構文が採用されています。 以下はその一例です。

• ドライバーとしては、バッテリーの交換時期を知りたい。
• 料理人としては、料理を完成させるまで、タブレットの画面がスリープしないようにしてほしい。
• 猫としては、毎日夕方 4 時に自分の皿にエサを入れてほしい。

ユーザー ストーリーがうまく形成されているかどうかをテストするには、以下を適用しますが、これらは頭文字を取って「INVEST」と呼ばれています。

• Independent (独立している): ストーリーはそれだけで成り立つか？
• Negotiable (交渉可能である): プロジェクトの他の部分に影響を与えることなく、このストーリーを変更または排除することができるか？
• Valuable (価値がある): このストーリーはエンド ユーザーにとって価値があるか？
• Estimable (見積可能である): ストーリーの規模を推定できるか？
• Small (小さい): このストーリーは十分に小さいか？
• Testable (テスト可能である): このストーリーはテストできるか？

この追跡ツールでは、プロジェクト管理の観点から、ユーザー ストーリーに名前と ID を付けることができます。 また、開発の優先度、スプリント、ストーリーの状態をマークすることもできます。 ストーリーは、アジャイル プロダクトバックログ に入ります。

通常、ユーザー ストーリーのテンプレートは非常にシンプルで、 ユーザーの役割、タスク、そのタスクが達成すべきことを明確にすることに重点を置いています。 さらに、以下のテンプレートには、ストーリーや開発サイクルの情報を明確にするためのセクションが用意されています。

シンプルなアジャイル ユーザー ストーリー テンプレートをダウンロード

Excel | Word

Webサイトを企画するには、必要な技術を総体的に理解し、誰が使用するのか、(サイト オーナーの観点で) ユーザーに何をしてもらいたいのかを詳細に特定する必要があります。 アジャイル開発で採用されているユーザー ストーリーは、ユーザーのニーズにフォーカスするのに役立ちます。 その他の質問も、Web サイトの文脈を説明するうえで有益です。

以下の Web サイト仕様書テンプレートでは、一連の質問に答えていくことで、Web サイトの目的、その主な利用者、そこで実施すること、その他、クレジット カード決済のためのセキュリティ基準など特別に考慮すべき項目などを特定できるようになっています。

Web サイトの機能要件書テンプレートをダウンロード

Word

Web サイトの技術仕様書テンプレートをダウンロード

Excel

ウォーターフォール方式でソフトウェアなどの技術を開発する場合、だいたいのケースでは、従来の機能要求書や仕様書のテンプレートを使用することができます。 機能要件書には、その製品が「実現しよう」としている特徴や機能が列挙されます。 たとえば、「この真空技術では 5 mm 未満の粒子を取り出す」といったことです。

‌ 機能仕様書テンプレートをダウンロード - Word

一方で、ビジネス要件に焦点を当てたテンプレートが必要な場合もあるでしょう。 このミニマルなテンプレートには、製品やアップグレードの目的をビジネスの目標に照らし合わせて詳しく説明できるスペースや、デザイン上のより総合的な項目を検討できるスペースが用意されています。

‌ 機能要件書テンプレートをダウンロード - Word

 

ここでは、Web サイトやソフトウェアなど、さまざまな種類の製品のユース ケースを作成できます。 ユース ケースとは、ユーザーが製品を使って行うべきタスクに焦点を当てたものです。 こうしたタスクに焦点を当てることで、開発者はユーザーを中心した製品作りを実施しやすくなります。 また、こうした文書には、関係者が製品設計を誤解しないようにする効果もあります。 このユース ケース テンプレートを使って、アクター、ステップ、ブランチの観点からタスクを定義しましょう。

ユース ケース テンプレートをダウンロード

Word

機能仕様書 (FSD) は、機能要件書 (FRD) としても知られており、プロジェクト管理やソフトウェア開発の多くの専門家は、これをプロジェクトの混乱や方向性の誤りを抑えるために不可欠なツールであると考えています。

FSD はソフトウェアや Web サイトの開発に関連付けられることが多いものの、実際は、新製品の発売やアップグレード、ソフトウェア製品や有形製品の開発、プロセスや組織の変更など、さまざまなプロジェクトで活用されています。 機能仕様書は、ビジネスとエンジニアリングの両方の期待を示すものです。 この文書のレビューと承認は、すべての関係者によって実施されます。 そうしてこの文書は、プログラマや設計者から営業担当者まで、組織のあらゆる役割に関係のある、懸案製品の参照文書になります。

開発に必要な情報を確実に文書に盛り込むには、機能仕様書のテンプレートを利用すると便利です。 それだけでなく、テンプレートを使用すれば、新しいプロジェクトが発足するたびに仕様書の設計に時間を取られることなく、製品の要件の方に集中することができます。 またテンプレートは、チームや企業のニーズに合わせてカスタマイズした方がよいでしょう。

従来 FRDは、長く、淡々として、技術的な内容が多い傾向にありました。 しかし、そのような文書が必要ない場合もあるでしょう (一方で、役に立つ場合もあるでしょう)。 FRD の目的は、すべての関係者のためにプロジェクトについて詳しく調べることであるため、FRD では長々とした技術的な議論は行わないようにします。 要件や関連情報にはさまざまな種類を含めることができますが (以下のリストを参照)、ベスト プラクティスは FRD の基本的な意図のみを記述することです。 ここでは、背景情報と、開発対象の特徴や機能を説明することを中心にする必要があります。 そうして承認された機能要件の仕様書に基づいて、技術設計書が作成されることになります。 FRDは、他の要求事項やプロセス文書と重複してはならなりません。

機能仕様書には承認プロセスが必要です。 具体的には、ビジネス ユーザーの懸念事項に対処するソリューションになっていることをそのビジネス ユーザー自身が確認し、続いて、そのソリューションが実行可能であることを技術レビュアーが確認します。 多くの場合、主要なレビュアーには、テスター、エンド ユーザー、テクニカル ライター、製品やシステムのオーナーなどが該当します。 その内容に全員が同意したら、文書を宣言することになります。 その後、システム アーキテクチャ文書の作成に移る組織もあります。

機能要件仕様書は、チーム全体の参照文書として機能します。 ここには、開発者が開発すべき製品、テスターがテストすべき内容、ライターが文書化すべきこと、営業担当者が販売すべき製品が記載されます。 文書化された機能仕様書は、開発が始まる前にその設計と意図が徹底的に検討されたことを示すものでもあります。 また、仕様の承認後、すべての関係者が同じ認識を持っていることもこれを通して示されます。 製品がコード化された後は、この文書の決定事項を逆戻しするような記述を書いてはいけません。

ビジネス アナリストや開発者の中には、機能仕様書と機能要件書を区別し、機能要件書とはそのソフトウェアで実行することを記述するもので、機能仕様書はそのソフトウェアでどのようにそれを実施するかを記述するものであると説明する人もいます。 しかし実際には、これらの 2 つの役割を組み合わせることが一般的です。

機能仕様書 (または要件書) テンプレートには、いくつかの形式があります。 どの形式を選択するかは、組織にとってどれが最適かという基準で決まります。

• 機能要件: これは従来から、ウォーターフォール型の開発手法を採用しているソフトウェアなどの技術で用いられています。 機能要件書には、その製品が「実現しよう」としている特徴や機能が列挙されます。 たとえば、「この真空技術では 5 mm 未満の粒子を取り出す」といったことです。
• ユース ケース: ユースケースは、多くの場合、他に依存しません。 しかし、ユーザー エクスペリエンスを重視する組織では、ユース ケースを機能要件に組み込むことが一般的です。 ユース ケースでは、ユーザーの行動を基準にして機能や利便性を特定します。 たとえば、「ユーザーがスマートフォンの画面をダブルタップすると、 画面が明るくなり、 ユーザーが画面を右にスワイプすると、スマートフォンとその機能のロックが解除される」といった具合です。
• ユーザー ストーリー: ユーザー ストーリーは、ユーザーが求めているものを製品設計に反映させるものであることから、アジャイル開発の核となります。 この簡潔なアプローチにより、チームは最も効率的な方法でユーザーに価値を提供することができます。 ユーザー ストーリーは、「ユーザーは xxx ができるようになる。つまりはメリットを創出している」という形式で進めます。

一般的には、ビジネス アナリストおよびテクニカル リーダーがテンプレートおよび機能仕様書を作成し、それをビジネス面やテクニカル面の関係者に共有します。共有された関係者は、期待される成果物と本来の目的が一致しているかどうかをレビューします。

新しいソフトウェアの開発やアップグレードの際に、機能仕様書を使用することもできます。 また、組織やシステム エンジニアリングの変更、Web 開発などにも利用できます。 仕様書のユーザーとしては、次のようなグループが考えられます。

• 製品をプログラムする開発者
• ソフトウェアやデバイス、Web サイトのユーザー インターフェイス (UI) を作成する設計者
• コードが仕様通りに正しく機能することを確認するテスター
• 新機能に関する需要喚起のためのドキュメントを作成するマーケター
• 新しい機能や製品を販売するセールス チーム
• 管理者やエンド ユーザーなどのために、製品の使用方法を文書化する、テクニカル ライターまたはユーザー アシスタンス ライター

機能仕様書 (FSD) とビジネス要求書 (BRD) は、組み合わせたり、置き換えたりすることが多いものの、個別のものとして使用する場合もあります。

BRDは、製品に対する全体的なビジネス要件 (その製品でできること) を記述したものです。 ここでは技術的な説明を避け、その製品の開発意義を詳説します。 その製品によって何を提供できるのか、そしてなぜそれが必要なのかを明確に理解しておくと、製品の方向性に関する議論が可能になり、開発をうまく導きやすくなることが往々にしてあります。 一方 FSD は、最終的な目標を達成するために必要な、製品の特徴や機能を説明することに、フォーカスしています。

有形のものであれ、データのやり取りであれ、製品を開発するには、多くの文書を作成する必要があります。 その際、機能仕様書テンプレートは、以下のいずれとも組み合わせて使用することができます。

• ユーザー要件書: この文書には、ユーザーがその製品に期待していることを記述します。 これを機能要件書の一部であると考える人もいます。 この文書を使用する場合は、全体的な開発プロセスのなかにこれを含める必要があります。 アジャイル開発では、ユーザー要件 (ユーザー ストーリーとも表記される) が機能要件書の中心になると考えられています。
• 製品要件書: この文書は市場要件書と同じ意味で使用され、製品の目的を詳述します。
• ビジネス プロセス文書: この文書ではビジネス プロセスを詳述します。
• ビジネス ニーズ評価書: この文書には、望ましいビジネス状態と現状との差を記述します。
• 技術設計仕様書: この文書には、設計案に必要なプログラミング要素を (詳細に) 記述します。
• 検証文書: この文書には、(開発プロセス全体で機能を追跡する) トレーサビリティ マトリクス、テスト計画、運用要件を含めることができます。
• システム要件書: ここでは、システムや製品に対する全体的な期待を文書化します。
• ビジネス要件書: ここでは、製品開発やアップデートを行う大まかな理由を文書化します。
• ユース ケース: この文書では、ユーザー視点から機能の詳細と背景情報を説明します。
• ユーザー ストーリー: この文書は主にアジャイル開発に使用されます。 ここでは、その製品でユーザーが何を行うかを説明することで、その製品の意図を伝えます。

要件書は、機能的な仕様書と非機能的な仕様書 (つまり、何をするものなのかと、どう行うか) に分類することができます。

• 機能要件: 製品やシステムの開発によって得られる動作や機能性、期待される結果を示します。 たとえば、「水から粒子をろ過する」、「ページを印刷する」といったことです。 一般的な機能要件には、管理機能、承認と認証、監査上の追跡とレポート、ビジネス ルールなどがあります。
• 非機能要件: どのように機能するかを説明するもので、制約、属性、パラメータとも考えられます。 そのプロセスを表す英単語が「ity」で終わっていれば、それは非機能的となります。 これには、ユーザビリティ (usability)、メンテナンス性 (maintainability)、セキュリティ (security) などが該当します。またパフォーマンスや規制要件もここに含まれます。

SAP では、機能仕様書とは、ステークホルダーの視点から製品を説明したものとされ、そこには、その機能と SAP の組み合わせから得られる正確な期待項目も記述されます。 機能仕様書は、FSD とソフトウェア要件書を 1 つにまとめてから、作成されます。

最低限、FRD には以下の要素を含める必要があります。

• 誰に向けた製品なのか
• その製品を使用する権限を持つのは誰なのか
• システムへの入力
• 各画面の役割
• システム ワークフロー
• 出力
• その製品によって対応できる規制要件
• 自社の具体的なビジネス要件

製品開発において、求められる機能を文書化することは必要不可欠なことですが、そのための機能要件書テンプレートの形式は、そのチームにとって何があれば役立つのかによって異なります。

テンプレートを作成する場合も、既存の開発プロセスの改善を検討する場合も、その製品と関わることになる全員に、テンプレートには何が必要かを尋ねるようにしましょう。 各形式にはそれぞれにメリットとデメリットがあります。

• 「～するものである」という従来の機能要件書で使用される書き方では、背景情報が不足しがちで、開発者の解釈に左右される傾向が強くなります。
• ユース ケースでは背景情報も詳細も押さえることができます。しかし、実際のユーザー要件が明確になるにつれ、スコープが狭くなる可能性があるなど、詳細であることがマイナスに働くこともあります。 小さな要件は、ユース ケースの中で迷子になる可能性があります。
• ユーザー ストーリーには、ユーザーのニーズをビジネス要件の文脈のなかで記述できるという利点があります。 しかし、それにはさらなる労力が必要となる場合があります ( 適切な導入の調査など)。 また、開発者も他のメンバーも、個々のストーリーに集中しすぎて、製品の大きな文脈を見落としてしまう可能性もあります。

繰り返しになりますが、ソフトウェア要求書を作成するためのツールを検討する際には、組織のニーズが最も重要になります。 他の企業で効果的であっても、自社には適していないかもしれないからです。

• 文書管理ソフトウェア: テンプレートの作成や文書の表示のための、最も簡単で最も一般的なツールの 1 つです。 多くの機能要求文書は、文書テンプレートとして提供されます。
• スプレッドシート ソフトウェア: スプレッドシートを使用すると、必要に応じて列を追加できます。 また、適切な製品を作るために必要な基本情報を提供するだけで済むため、完璧な文章を作成するというプレッシャーからも解放されます。
• アジャイル プロジェクト管理プラットフォーム: 多くの専用プラットフォームは、要件やユーザー ストーリーを入力できる仕組みや、開発状況を追跡できる機能を提供しています。

要件の中には、製品の意図を伝えるための基本的かつ不可欠な要件がある一方で、それ以外の要件は、製品を開発するうえでは価値のあるものもあれば、そうでないものがあります。 どのような形式を選ぶかは、開発する内容によっても異なります。 以下に、機能要件を作成する際にガイドとして使用できるものをご紹介します。

• 冒頭

  • メタデータ ページ: 文書に関するすべてを要約したものです。
  • 作成者への指示: 特定の文書に記述することを組織で規定している情報について、説明します。 こうした指示は、導入部やテンプレート全体に表示される場合があります。
  • バージョン番号
  • 変更記録/改訂ページ: テンプレートおよび公開済みの要件文書には、すべての変更点、詳細、日付、承認者のイニシャルを記載する必要があります。
  • 承認ブロック: ここには、各変更に対する署名による決定と、各要件に対する署名での承認があります。
  • 配付リスト: チーム メンバーによっては、その文書を確認する必要があるメンバーもいます。 一方で、一部のチーム メンバーのみに閲覧が制限される場合もあります。

• 概要

  • 製品の説明
  • ビジネス要件の概要
  • 作業範囲 (作業対象内と対象外の内容)
  • 現行のシステムの説明
  • 文書の規則
  • 用語集 (略語を含む)
  • 参照
  • 一般的な制約と仮定
     

• 機能性

  • ビジネス プロセス
  • 提案される手法
  • ユーザーの役割/ユーザー コミュニティ
  • ユース ケース
  • ユーザー ストーリー
  • システム内のワークフロー
  • プロトタイプの設計
  • ワイヤーフレームまたはストーリーボード
  • 機能一覧や機能性の説明
  • データ要件
  • 管理機能
  • 構成管理
  • プラットフォーム
  • 導入
  • ポータビリティ
  • 拡張性
  • カスタマイズ
  • 印刷
  • エラー対応
  • サポートとメンテナンス
  • 国際化
  • ヘルプとドキュメント
     

• その他のソフトウェア

  • 入力、出力、処理
  • 外部インターフェイス
  • ユーザー インターフェイス
  • ハードウェア インターフェイス
  • ソフトウェア インターフェイス
  • コミュニケーション インターフェイス
  • データベース サポート
     

• 属性

  • セキュリティ
  • 信頼性、可用性、メンテナンス性、ユーザビリティ、互換性
  • 規制要件
     

• 付録

  • 分析モデル

ニーズに合わせ変化に対応できるようデザインされた、柔軟性のあるプラットフォームで、チームの能力を最大限に引き出しましょう。 Smartsheet プラットフォームなら、いつでもどこでも簡単に作業の計画、保存、管理、およびレポート作成が可能なため、チームはより効率的かつ効果的に仕事を進めることができるようになります。作業に関して主要なメトリックを表示したり、リアルタイムの可視性を提供したりするために、ロールアップ レポート、ダッシュボード、および自動化されたワークフローを作成する機能も装備されており、チーム メンバーをつないで情報共有を促進することが可能です。 やるべきことを明確にすると、チームの生産性と作業達成能力が向上します。ぜひこの機会に Smartsheet を無料でお試しください。