ガジェット通信 GetNews

見たことのないものを見に行こう

体験を伝える―『ガジェット通信』の考え方

面白いものを探しにいこう 本物を体験し体感しよう 会いたい人に会いに行こう 見たことのないものを見に行こう そしてそれをやわらかくみんなに伝えよう [→ガジェ通についてもっと詳しく] [→ガジェット通信フロアについて]

要件定義書の作成手順を学ぶ!アイデアを形にするプロセスとは

本稿は、Smashing magazineのブログ記事を許可を得て日本語翻訳し掲載した記事になります。

本記事は、モバイルアプリ開発の会社のCEO Eduard Khorkov氏によって投稿されました。

 

なぜ要件定義書を書くのでしょうか。仮にあなたがモバイルアプリをプロデュースしたいと思っていながら、プログラミングスキルがないとします。

そのためあなたは、アプリを作成することができる開発者を見つけ、その人にアイデアを説明します。最初に開発者にアプリを見せてもらったとき、意外にもあなたが望んでいたものと違うのに気付きます。なぜでしょうか。それはアイデアを説明するときに充分な説明がされていなかったからです。

このような事態を防ぐため、アイデアを形式化してはっきりした姿にする必要があります。そのための一番の方法は要件定義書を書き、開発者と共有することです。

要件定義書は開発プロセスの結果をあなたがどのように見ているかを示し、それによってあなたと開発者は同じ認識を持つことができます。

 

この記事では要件定義書を作成するための最も一般的な方法を説明します。

モバイルアプリケーションの要件定義書を書くための基本的な手順と、良い要件定義書はどのようなものなのかを学びます。

 

どのように要件定義書作成に着手するか

入念に作成された要件定義書は、不明確な点を排除し、開発者が何をするべきかをはっきりとさせます。さらにその文書は作業の範囲を明確にし、開発者は必要な時間と労力を見積もることができます。

どのように文書を作成するのでしょうか。以下は、要件定義書を作成する際に守るTIPSです。

 

1. 総括的なアイデアを説明する

アイデアに関する適切な説明は1つの文でまとめることができます。その文章にはアプリケーションの中心となる機能が書かれており、読んだ人はアプリケーションの内容をすぐに理解することができます。

例えば、カロリー・トラッキングを行うモバイルアプリケーションの場合なら「カロリー消費量を統計分析して体重を気にする人を支援するアプリ」という風にすることができます。

 

2. 順番を考える

ナビゲーションの基本パターンを学び、そのアプリケーションについてユーザーが実際に体験する順番通りに説明します。アイデアの要素が完成したら、オンボーディング画面やユーザー登録などアプリケーションの最初の手順を説明します。

続いてアプリケーションのホーム画面などの部分に進みます。文書を読んだ人は、実際にユーザーがどのように操作を進めるかということを理解することができます。

プライバシーポリシーや「パスワードを忘れたとき」などの基本的な機能や画面のことを忘れないようにしましょう。

 

3. 既存のアプリケーションを調査する

App StoreとGoogle Playの既存アプリケーションを調べて、アプリの説明の際に参照してください。アプリAとアプリBの「パスワードを忘れたとき」機能が好きな場合は、それを文書内で説明します。

 

4. 細かい部分は省く

アプリケーションの機能に焦点を合わせ、ボタンの色などの詳細は省略します。ほとんどのユーザーは細かい所を気にしません。ユーザーにとって関心があるのはそのアプリケーションが問題を解決するのに役立つかどうかです。

要件文書を作成するときは、ユーザーがアプリで何ができるかということに集中して書いてください。

 

5. 機能の優先順位を決める

どの機能が他より重要かを伝えることで開発者は最初に何に焦点を当てるべきかを知ることができます。「Must(必須)」、「Should(推奨)」・「Could(可能)」・「Won’t(先送り)」のMoSCoWメソッドに従います。

 

6. テキストをワイヤーフレームで補う

アプリケーション画面のワイヤーフレームを作成し、テキストに添付します。4つ以上のワイヤーフレーム画面がある場合、マップを作ると効果的です。

この記事の後半でスクリーンマップについて説明します。

 

要件定義書のフォーマット

要件を記述する方法が分かったら、ドキュメントの適切なフォーマットを選びましょう。

モバイルアプリの要件を記述するための基本的なフォーマットとして機能仕様書(FSD)・ユーザーストーリー・ワイヤーフレームなどがあります。

 

機能仕様書(FSD)

FSDはおそらく、ソフトウェア開発業界においてデフォルトのフォーマットです。

製品が何をするべきか、どのようにするべきかを取り扱う標準的な項目リストで構成されています。

簡単な電卓アプリケーションを例として、その機能をFSDで説明してみましょう。
アプリケーション画面には基本的な算術計算ボタン(加算・減算・乗算・除算)と結果ボタン(「=」で示されている)が追加されたデジタルキーボードが表示されます。
数字ボタンをタップすると、その内容が画面内のディスプレイ部分に表示されます。新しい桁の数字は右側に追加されていきます。
算術計算ボタンをタップすると、現在ディスプレイ部分に表示されている数字がメモリに与えられます。また、次の数値入力のためにディスプレイ部分はクリアされます。
結果ボタンをタップすると、それまでの操作に従ってメモリ内の数値と表示されている数値が結合されます。結果の数値がディスプレイ部分に表示されます。

このように機能仕様書のフォーマットでは、開発とビジネスの両方で使用されるため製品の詳細な説明が書かれています。そのため皆が同じ認識を持つことができます。

FSDを作成する人は、ソフトウェア開発の経験が豊富で構築しているモバイルや他のプラットフォームの仕様を知っている必要があります。また、要求される詳細レベルが高いため、完成させるのにはかなりの時間がかかります。

 

ユーザーストーリー

ユーザーストーリーはFSDほど正式なものではありませんが、強力なフォーマットです。ユーザーがアプリでできることをリストにし、ユーザー観点から記述します。この文書ではユーザーがなぜそれをしたいのかを簡単に説明します。

電卓の例で、いくつかの機能を追加しユーザーストーリーで説明してみましょう。
ユーザーとして、非常に小さい数値や非常に大きな数値を取り扱うために10進数から指数関数に(またはその逆も)数値の表記を変更できるようにしたいと思っています。
ユーザーとして、同僚と共有するために計算の履歴をPDFファイルで出力したいと考えます。

この形式は技術的な要件の概要だけでなく、優れた投資対効果検討書も生み出します。そのため、ビジネスにとって重要でない機能が特定されている場合はその機能を取り除くか、将来のリリースに先送りにするかを決めることができます。

1 2次のページ
TechAcademyマガジンの記事一覧をみる
  • 誤字を発見した方はこちらからご連絡ください。
  • ガジェット通信編集部への情報提供はこちらから
  • 記事内の筆者見解は明示のない限りガジェット通信を代表するものではありません。