アプリ開発の要件定義書の作成時に確認する項目

この記事では、アプリ開発の要件定義書の書き方について解説します。
要件定義書をどのように書けばいいのかわからない事業者様は、ぜひご一読ください。

アプリ開発における要件定義とは？

アプリ開発の要件定義とは、プロジェクトの最初の段階に行われる重要な工程の1つです。
具体的には以下の項目を決めます。

• 開発目的
• ターゲット層
• 予算
• 追加する機能
• 使う技術
• 納期
• 必要な人員
• 開発スケジュール

なぜそのシステムを開発するのか、システムの目的=どのような手段を用いるのかを明確にする段階ともいえます。しかしなぜ要件定義の作成が重要であるのか、いまいちわかっていない方もいるでしょう。
次の項目では、要件定義が重要な理由を詳しく見ていきましょう。

要件定義の作成が重要である理由

要件定義では、アプリの目的や付加機能、利用者のニーズ、アプリを完成させるための必要な要素などを定めていきます。

要件定義は、開発側と発注側のアプリの完成イメージを共有していく段階ともいえます。
要件定義で発注書の要望を叶えるために、開発者は何を実現するべきか、どのような技術を用いるべきかがより明確になり、具体的な基準を確立することが可能です。

もしも要件定義を行わないと、アプリ開発の方向性が定まらず、最悪完成しても0からやり直すという事態になってしまいます。イメージしているアプリを開発するためにも、スムーズに進行するためにも要件定義は欠かせません。

要件定義に必要な要素

要件定義に必要な要素は以下の3つです。

• アプリの開発方法
• アプリの主な機能
• UI（ユーザーインターフェース）

これらは、アプリ開発をスムーズに進めるために必要な要素です。これらが決まっていないと、アプリが完成してもイメージしていたのと違う、開発がスムーズにいかないとなる可能性があります。
イメージ通りのアプリをスムーズに制作するためにも、これから紹介する要素は必ず押さえておきましょう。それでは実際にそれぞれの要素を詳しく解説します。

アプリの開発方法

まず決めるのは、アプリをどのような手段で開発するかです。アプリ制作にはさまざまな方法があり、それぞれデメリットとデメリットがあり、かかる期間は大幅に異なります。
したがって、開発するアプリによって適している開発方法が異なります。

例えば、自社の機能をつけたい、競合他社との差別化を図りたい場合は、ゼロからアプリを構築するフルスクラッチ型が最適です。しかし、フルスクラッチ型は小規模の開発でも300万から500万、企業の基幹システムとなればから3,000万円以上と、コストが非常にかかります。
高い技術を持っているエンジニアも必要になり、制作時間もかかります。
一方、クラウドサービスであれば、枠組みが既に決まっているため、コストや制作にかかる時間を大きく短縮可能です。

しかし、フルスクラッチ型よりも自由度が劣るデメリットがあります。それぞれのメリットとデメリットを踏まえて、要件定義で開発方法を明確にする必要があります。

アプリの主な機能

続いて必要な要素は、アプリの主な機能を決めることです。アプリの主な機能を決めるためには、そもそもアプリで何を実現したいのか、どういったことを解決したいのかを明確にする必要があります。アプリで実現したいことが曖昧になっていると、方向性がぶれてしまいます。

「多くの企業が取り入れている機能だから」「機能はたくさんあったほうがいいだろう」といった曖昧な理由だと、アプリの目的も曖昧になってしまいます。
アプリの機能を決めるうえで重要なのは、必要な機能をたくさんつけることではなく、まずは最小限必要な機能を決めることです。

そのうえで追加する機能を考えたほうがうまくいきます。初めから機能を追加しすぎると、開発に時間がかかってしまううえ、結局何をしたいアプリなのか分からなくなってしまいます。

UI（ユーザーインターフェース）

UIとは、ユーザーが実際に操作する画面のことでアプリの使い心地に大きく影響するものです。トップ画面・リンクボタンのデザイン、ボタンをクリックしたらどの画面に行くか、どういったコンテンツを見られるか、ユーザーがアプリを操作することを想定してデザインをしていきます。

もしも、すでに具体的なUIのイメージがついているのならば、担当者にそのイメージを共有しましょう。
なぜなら、デザインは言語化できない部分が多くあるためです。
そこでイメージと近いアプリを開発者と担当することで、イメージしているインターフェースのズレがなくなり、スムーズに開発が進みます。

要件定義の進め方

ここでは要件定義の進め方を紹介します。
要件定義の進め方は、大まかに以下の3つに分けられます。

• 発注者と開発者の打ち合わせ
• 要件定義書の作成
• 要件定義書とシステム設計のすり合わせ

これから紹介する内容をあらかじめ押さえておくと、要件定義をスムーズに進められます。それでは実際に、それぞれの進め方について詳しくみていきましょう。

発注者と開発者の打ち合わせ

アプリ開発で発注者と開発者の打ち合わせは、非常に重要な工程です。アプリ開発の目的、完成イメージを開発者と共有できていないと、成果物はイメージとかけ離れたものになってしまう恐れがあります。

とはいっても、アプリ開発打ち合わせの段階では、イメージが大漠然としていることも珍しくはありません。その場合は、アプリに必要な機能を分析して、一緒にイメージを具体的にしていきましょう。

アプリの目的・機能が漠然としすぎると、後々仕様変更が出たり、追加して欲しい機能が多くなったりして、開発がスムーズに行かなくなります。まずはどのような課題を抱えていて、どのような業務に時間かかっているのか、それを踏まえた上でどう解決したいのかをヒアリングしましょう。このとき、必要な機能の優先順位も聞くようにしてください。

打ち合わせは要件定義書を作成するうえでとても重要な段階なので、疑問点を残さないようヒアリングするのがポイントです。

要件定義書の作成

打ち合わせが終了したら、要件定義書の作成をしていきます。要件定義書の作成はヒアリングの結果をもとにしますが、クライアントの要望をすべて叶えられるわけではありません。例えば、クライアントが10個の機能を追加してほしいとなっても、開発者からすればアプリの使い勝手に影響が出たり、予算オーバーしたりする可能性があることから、追加しないこともあります。そのため、ヒアリングの段階で聞いた優先順位をもとに、実装する機能を決めていきましょう。

もしも要件定義書の作成、途中でクライアントの要求に応えられない、システム上難しいといった場合は、再度ヒアリングを実施してください。疑問点が残ったまま要件定義書を作成すると、開発途中で振り出しに戻ったり、仕様が大幅に変更になったりする可能性があるためです。

要件定義書とシステム設計のすり合わせ

最後は、要件定義書とシステム設計のすり合わせです。クライアントのニーズを要件定義書に反映したとしても、技術や予算の問題もあるため、実現できるとは限りません。
そのため開発に取り掛かる前に、要件定義書に記載されている内容は設計するうえで問題ないか、実現できる内容であるかを確認する必要があります。

もしも実装できない要件の場合は、しっかりクライアントと共有するようにしましょう。要件定義書はアプリ開発の方向性、内容を大きく決めるものであるため、大まかに作成するのはNGです。要件定義書の質と成果物の質は比例していく傾向にあります。

疑問点があればヒアリングを複数回実施して、要件定義書をブラッシュアップしていきましょう。

アプリ開発の要件定義書を書くポイント

アプリ開発において、要件定義書は開発を進めるうえで重要なものです。
ここでは、アプリ開発における要件定義書を書く3つのポイントを紹介します。

ポイント①アプリ開発の目的を業務概要で明確化

要件定義書に業務概要を明記します。
これにより、どのような目的でアプリ開発を行うのか明確にすることが可能です。

業務概要は、業務要件とシステム要件の2種類にわけることができます。
業務要件で記載する内容は、アプリ化の目的や狙い・背景です。
アプリ開発投資の目的や直面している問題点や原因など、アプリ構築の背景が明確化できます。

一方、システム要件で定義する内容は、搭載する機能やインターフェース、画面要件などです。
業務概要はクライアントも確認する部分になるため、システム要件の説明は専門用語を多用せずわかりやすい表現でまとめましょう。

ポイント②ユーザーの操作手順を明記

要件定義書には、ユーザーの操作手順も記載します。
操作手順とは、ユーザーがアプリを使用する手順のことです。

たとえば、新規会員登録する手順や具体的なアプリの操作方法、課金の手順などを挙げることができるでしょう。
操作手順を明記する際のコツは、クライアントの課題解決に充填を置くことです。

関係のない情報を記載してしまうとわかりづらくなる可能性もあるため、テキストの色や大きさなど不要な部分はできるだけ取り除きましょう。

ポイント③搭載したい機能に優先順位をつける

アプリに搭載する機能は要望をヒアリングして把握します。

要件定義書に機能を記載しますが、すべての機能を要望通りに搭載できないことも少なくありません。
また、容量や予算の関係で特定の機能が搭載できないケースもあるでしょう。

搭載すべき機能に優先順位をつけておくことで、納期や予算に合わせて適切な機能を搭載することが可能です。

優先順位をつけるときは、モスクワ分析を活用しましょう。
モスクワ分析を使うことで下記の4段階にわけて優先順位をつけられます。

ヒアリングした機能をMust、Should、Could、Won’tにわけます。
そして、Mustと判断された機能から優先的に採用していくという形です。

モスクワ分析を活用すると優先順位がつけやすくなるのでおすすめの方法になります。

ポイント④ワイヤーフレームの活用

要件定義書を書くときは、ワイヤーフレームを活用しましょう。

ワイヤーフレームとは、レイアウトの構成を決める設計図のことです。
ワイヤーフレームを活用することで、ボタンが配置される箇所やレイアウト同士の間隔が明確になるためテキストよりも理解しやすいです。

ワイヤーフレームはアプリのレイアウトを決めるためのものなので、なるべくシンプルに書くとよいでしょう。
細かくデザインを記載してしまうと時間がかかるため、簡単なデザインにとどめましょう。

ポイント⑤費用の目安を共有する

アプリ開発の費用は、ジャンルや希望によって大きく異なります。打ち合わせの段階では具体的な金額を言うのは難しいかも知れませんが、要件定義書の作成時点になればおおまかな費用がわかってくるはずです。

トラブルを避けるためにも、費用の目安が分かり次第、クライアントと共有してください。もしもヒアリングの予算を超えているようならば、予算内に収める方法がないかの相談も行う必要があります。

アプリ開発の要件定義書に使用されるフォーマット

アプリ開発の要件定義書は、1から自分で書くのではなくフォーマットを活用することが一般的です。
要件定義書の作成で使用される主なフォーマットは2種類あります。

FSD

FSDは機能仕様書とも呼ばれ、システム開発等では標準のフォーマットになります。

基本的にFSDは項目リストで構成されており、アプリがどのような動作をするのかわかりやすいです。
補足などを付け加えることで、さらにわかりやすい要件定義書になります。

ユーザーストーリー

ユーザーストーリーの特徴は、アプリの活用でできることをリスト形式かつユーザー目線で記述できることです。

具体的には、課金機能やログイン不要など、要望をリストでまとめる書き方です。
FSDよりも柔軟性があり、要件定義書を作成する際の強力なフォーマットになるでしょう。

アプリ開発は個人でも対応できる？

予算を抑えるために、アプリ開発を個人で取り組もうと検討している方もいるでしょう。結論から述べると、アプリ開発は個人でも出来ます。

ただし、工数がかかったり、実装したい機能によっては高い専門性が必要になったりして、スケジュール通り開発が進まない恐れがあります。
そのため、基本的には専門的な知識がある外注へ依頼するのがおすすめです。外注先によっては、予算内に収められるよう提案をしてくれます。
自分に専門知識がある場合は、一部作業を外注する方法もあります。
基本的にリソースの確保が難しい、専門知識がないといった場合は前向きに外注の検討をすることをおすすめします。

4つのポイントを押さえてアプリ開発の要件定義書を作成しよう

以上、アプリ開発の要件定義書の書き方を解説しました。

要件定義書の書き方は業務概要、操作フロー、機能の優先順位を内容に含めることです。
また、わかりやすくするために、補足を追加したり、ワイヤーフレームを活用したりするといいでしょう。
しかし、要件定義書を書くためには、経験と技術が必要です。

「どのように書けばいいのかわからない」
「要件定義書を作成する時間がない」

という悩みを抱えている事業者様は、ぜひEMEAO!にご相談ください。
要件定義書の作成から開発までサポートしてくれる業者を完全無料でご紹介します！

アプリ開発会社・業者をお探しならEMEAO!