要件定義書の作成手順を学ぶ！アイデアを形にするプロセスとは
本稿は、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つのストーリーから複数のサブストーリーに分割して詳細を定義することができます。例えば、PDFエクスポートのストーリーから以下のように分割することができます。
- ユーザーとして、画面の右上にある共有ボタンをタップしてオプション（PDF・テキスト・画像で共有）を表示させたいと思っています。
- 共有オプションを選択したときに、iOSのDate Pickerを使用して共有される計算のタイムフレームを選択したいです。
ユーザーストーリーは簡単で柔軟性があるため、最も便利で一般的なフォーマットのひとつになっています。
スケッチとワイヤーフレーム
アプリケーションの要件を説明する他の方法は、スケッチあるいはワイヤーフレームでそれらを視覚化することです。
iOSの開発では、開発期間の約70％がインターフェイスの実装に費やされるため、すべての画面を目の前に置いておくことで何をするべきであるのかという作業の範囲が分かるようになります。
モバイルアプリケーション用の適切なワイヤーフレームセットを作成するためには、画面を相互にリンクする方法・各画面に表示できる状態・プッシュ通知から開いたときにどのように動作するかというユーザー体験の基本を知っておく必要があります。
フォーマットを融合させる
適切に融合することでそれぞれのフォーマットの強みを生かすことができます。私たちの経験では、ユーザーストーリーとワイヤーフレームを混合させることが最も理にかなっています。
ユーザーストーリーはアプリケーションの機能を説明し投資対効果検討書を規定しますが、ワイヤーフレームはこれらの機能がアプリケーションの画面にどのように表示されるかを示します。さらにユーザーストーリーとワイヤーフレームを混合させるのはFSD作成よりも時間がかからない上に、その相互作用の詳細と説明はすべてまとめられた状態になります。
まず、アプリケーションのワイヤーフレームをスケッチすることから始めましょう。
ワイヤーフレームが完成したら各画面に2つ以上のユーザーストーリーを追加し、ユーザーがその画面上で何ができるか説明します。私たちはこの方法がモバイルアプリケーションの開発に最も適していることを発見しました。
練習してみましょう
What I Eatアプリケーションを例として取り上げます。アプリケーションを一から開発しているというシチュエーションで要件定義書を作成してみましょう。
まず、スティーブ・ブランクのXYZパターン「ZによってXがYするのを支援する」を使ってアイデアを形にしてみます。そのアプリケーションの前提はユーザーが一日に食べるものとカロリー摂取量をコントロールできるようにすることです。XYZメソッドで置き換えると「What I Eatアプリケーションは、簡単な食事履歴の機能によって体重を気にする人がカロリー消費をトラッキングするのに役立ちます」となります。
前述の通り、ユーザーストーリーとワイヤーフレームを融合させるのが一番効果的です。
次にWhat I Eatアプリのユーザーストーリーを各画面ごとに記述します。まずアプリケーションの開始・ホーム画面から始めましょう。
- ユーザーとして、アプリを開いてすぐに今日の食事の記録と消費カロリーを見たい。
- 今食べた食事とそのカロリーを、すぐに追加したい。
- アプリ内のカレンダーにアクセスして、それまでの履歴を表示したい。
あいまいさを回避するために、この画面のワイヤーフレームを作成します。
ホーム画面に「新しい食事を追加」機能を入れることはできませんでした。代わりに、この機能を行う別の画面に移動するためのボタンを付けます。ここで、この新しい画面についてのユーザーストーリーをまとめます。
- 今食べた食事の名前を入力したい。
- そのカロリーも入力したい。
ホーム画面にはカレンダーを開くボタンがあります。
色々なカレンダーアプリがあるので、まずそれらのデザインをチェックするといいでしょう。iPhoneのデフォルトカレンダーアプリがお気に入りなので、ここではそれを参考にします。
- ユーザーとして、今日の日付をすぐに選択したい。
- 日付を選択すると、iPhoneのカレンダーアプリのようにその日の食事のリストが表示されるようにする。
- 次の月、または前の月に切り替えられるようにする。
iPhoneカレンダーのユーザーインターフェイスをワイヤーフレームに配置します。
最後に、アプリにいくつかの設定を追加する必要があります。
- 食事記録のためのiCloudバックアップの有効・無効を切り替えたい。
- カロリー摂取量をトラッキングするリマインダーの有効・無効を切り替えたい。
これで、ほぼ完了です。
最後のステップではワイヤーフレームとユーザーストーリーをひとつのドキュメントにまとめ、各ワイヤーフレームとそれぞれのストーリーを配置します。
さらに、それぞれの画面がどのように繋がっているかを視覚化するマップを描くこともできます。
マップを作成している際に設定画面に移動するボタンがないことに気付いたため、ホーム画面に追加します。
まとめ
ここでは、ユーザーストーリーとワイヤーフレームを含むPDFと、それを補完するスクリーンマップを作成しました。これらによってアプリケーションに必要とされている機能が詳細に説明できます。
これで要件定義書を開発者に送ることができる状態になります。今度は、開発者の作成したアプリケーションはあなたの思っていたものになるでしょう。
一般的に言えば、要件定義書を書くことはあなたのビジョンを他のチームに伝えることです。上記の方法だけに限定せず、自由に試みて一番いい解決方法を見つけてください。
TechAcademyでは初心者でも最短4週間でオリジナルWebサイトを公開できるWebデザインオンラインブートキャンプを開催しています。
現役のWebデザイナーがパーソナルメンターとして受講生に1人ずつつき、マンツーマンのメンタリングで学習をサポートし、最短4週間でオリジナルWebサイトを開発することが可能です。
独学に限界を感じている場合はご検討ください。
