この記事から得られること
この記事では、「UI向けの要件定義書」の書き方として、「最低限おさえたい3つのポイント」を学ぶことができます。
要件定義書の作成には「正解」が無く、企業によっても作成方法がさまざまなのですが、今回ご紹介しますポイントをおさえますと、要件定義書が読みやすくなり、メンテナンスがしやすくなると考えますので、ぜひ試してみてください。
この記事の前提
- この記事は、スマホアプリの開発プロジェクトを想定して、説明しています。
- 要件定義書の作成方法には正解がなく、企業によって作成方法も異なるため、もしみなさんの企業のルールがある場合は、今回の記事の内容と矛盾するケースもあるかもしれません。その点もふまえた上で、この記事を読んでいただければと思います。
結論
「UI向けの要件定義書」では、以下の3つのポイントを最低限おさえながら作成しますと、読みやすく、メンテナンスがしやすい要件定義書になると考えます。
- ポイント1：まずは目次レベルの大枠から作成していく
- ポイント2：さまざまな関係部署の方に、定期的に要件定義書をレビューしてもらう
- ポイント3：今後も内容をアップデートしていく前提で書いていく
それでは、それぞれのポイントについて、具体的に説明します。
ポイント1：まずは目次レベルの大枠から作成していく
まずは、UIとして実装する予定の「大枠の機能」や「メイン画面」単位で、目次を作成することをおすすめします。
最初に目次を作成しますと、要件定義書の全体のボリューム感や、書いていくのが難しいと想定される箇所を洗い出しておくことができるからです。
つい、自分自身が書きやすい箇所から、具体的に書き出してしまうかもしれませんが、まずは、全体像を把握することに注力することをおすすめします。
ポイント2：さまざまな関係部署の方に、定期的に要件定義書をレビューしてもらう
要件定義書のレビューについて、基本的には、UIデザインチームのメンバーや上司、そして、プログラマーにレビューをしてもらいますが、その他にも、さまざまな関係部署の方にもレビューしてもらうことをおすすめします。
例えば、プロジェクトのマーケティング担当の方や、QA（アプリの評価）担当の方などです。
注意していただきたいのは、要件定義書の全ての内容をレビューしてもらう必要はありません。
例えば「今回の売りとなる、アプリの新機能」の内容のみをレビューしてもらうことにより、それぞれの担当者の視点から、認識違いや考慮不足が見つけられ、要件定義書の内容の精査につながります。
ポイント3：今後も内容をアップデートしていく前提で書いていく
「プロジェクトの方針変更」など、要件の変更が発生することを考慮し、アップデートしやすい書き方にすることをおすすめします。
例えば、
- 各要件に対して、個別のID（管理番号など）を付与し、IDで、要件の追加や削除を管理する
- 変更箇所の文字色を変える（通常は黒文字で、変更箇所は赤文字にする、など）
- 変更履歴を書くページを用意しておく
などがあります。
さらに、アップデートされる可能性が高い要件については、「まとめて色々な機能を書く」のではなく、変更しやすいように「要件を分解して、細かい機能に分けて書いておく」といった対応も、のちのちアップデートしやすくなり、効果的です。
まとめ
繰り返しとはなりますが、「UI向けの要件定義書」では、以下の3つのポイントをおさえながら作成しますと、読みやすく、メンテナンスがしやすい要件定義書になります。
- ポイント1：まずは目次レベルの大枠から作成していく
- ポイント2：さまざまな関係部署の方に、定期的に要件定義書をレビューしてもらう
- ポイント3：今後も内容をアップデートしていく前提で書いていく
今回ご紹介しましたポイントをおさえますと、要件定義書が読みやすくなり、メンテナンスがしやすくなると考えますので、ぜひ要件定義書を作成する際は、試してみてください。
