システム開発の要件定義はどうやる？【機能要件編】

みなさん、こんにちは。

私は普段の仕事の中でDXコンサルタントとしてクライアントともにシステムの要件定義をすることが多々あります。システムに限らず一般的な製品開発でもそうですが、上流工程になればなるほど、型にはまった作業をすることが難しく、案件ごとに柔軟に対応していくことが求められます。要件定義というのは、まさにその最たるもので、なかなか一筋縄ではいきませんが、ここでは私自身のDXコンサルタントとしての経験も踏まえながら、できるだけ分かりやすく要件定義について説明したいと思います。

要件定義は「機能要件」と「非機能要件」の2つがある

まず大前提として要件定義の対象は「機能要件」と「非機能要件」に大別されます。

それぞれ違いはなんでしょうか？

まず「機能要件」というのは、アプリケーションとして実装する機能に関する要件を表します。例えば、イベントを管理するためのシステムであれば、「参加登録をする機能」や「登録者を一覧で表示する機能」などアプリケーション上で具体的に使用できる機能が「機能要件」に分類されます。

一方で、非機能要求は、名前の通り非機能要求の逆で、アプリケーションとして実装しない機能に関する要件を意味します。例えば、「障害発生時には3時間以内で復旧するようにしてほしい」や「システムがメンテナンスなどで停止するのは1ヶ月に1回までにしてほしい」などの要求が含まれます。

今回の記事では前者の「機能要件」の決め方について記述してみたいと思います。

まずは業務要件から整理する

「業務要件」という新しい用語が出てきたので、まずはこの意味から説明したいと思います。

システムを構築するには、上述の「機能要件」を明確にする必要がありますが、クライアントと「システムにどんな機能が必要か？」をいきなり話し合ってもうまくいきません。なぜなら、クライアントは自分たちの業務には詳しいですが、システムには詳しくないからです。ですので、クライアントからダイレクトに機能要件を聞き出すことは不可能なのです。では、我々がいきなり機能要件を作ればいいのかというと、当然ながらそうもいきません。現行の業務を改善するために、システム開発を行なうわけですから、業務に詳しくない人間が機能要件を作っても机上の空論になってしまいます。

ここで登場するのが「業務要件の定義」です。これは言い換えれば、クライアントが現在行っている業務の内容や流れを明確にしていく作業です。ここでは、システム開発のことは一旦脇に置いておき、ヒアリングや資料の共有を通して、顧客がどんな業務を行なっているのかを理解することに努めます。

この業務要件定義に不備があると、クライアントの業務をちゃんと理解しないまま、システム設計を始めることになり、後々になって不都合が発覚すると大きな手戻りになります。従って、ここは十分に時間をとってクライアントと認識を合わせておくべきところです。

この過程でよく作成される成果物が業務フロー図です。次は業務フロー図の書き方を具体的に説明します。

業務フロー図はどうやって書くのか？

以下に業務フロー図の例を示します。ここでは会社に来客がある場合の来客申請（来客届）の処理に関する業務フローを取り上げています。

大まかな書き方の順序は次のようになっています。

最後に実際に作成する際の注意点を1つお伝えします。それは事前に記述の細かさをよく擦り合わせておくことです。システム開発はチームでやることがほとんどなので、おそらく複数人の人間が業務フロー図を作成することになると思います。ある人は業務のステップを非常に細かく書いている、またある人は業務のステップを非常に大雑把に書いているという状況が発生すると、レビューが大変やりづらくなります。

業務フロー図を書く前にチーム内で記述の細かさについて共通認識を持っておくようにしましょう。

システムのスコープを議論する

業務フロー図ができたら、それを見ながらどの業務をシステムの中に落とし込んでいくのかをクライアントともに検討します。これがシステムのスコープ（対象範囲）決めです。

例えば、上記の業務フロー図の例で言えば、「記載した全ての工程をシステムに組み込むのか？それとも来客届の申請と承認だけをシステムに組み込むのか？」といったような議論をクライアントとやっていくことになります。

スコープはクライアントの予算や納期によるところが大きいですが、実はこの段階で予算や納期を明確に提示することは困難です。従って、この段階では少し不確定要素を含んだうえでの議論になりますが、それでもシステム化が不要な物や優先度の高いものの目安をつけておくと、後々の作業が進めやすいので、この段階で顧客と議論しておくのがよいでしょう。

場合によっては、step by stepで、例えば来客届の申請と承認をstep1、会議室の手配をstep2のように、長期スパンで実現するような計画になることもあります。

必要な機能要件を洗い出す

ここまできたところで、ようやく機能要件定義を開始することができます。

システムのスコープに含まれている業務の業務フロー図を参考にしながらアプリケーションで実現するべき機能をどんどん書き出していきます。

上記の業務フロー図で考えて一部を書き出してみると、例えば次のようなものが書けるでしょう。

最初にも述べたように、クライアントはシステムに詳しくないので、できる限りクライアントが理解しやすいように書いていくことが要求されます。これを実現するために注意すべき点としては次のようなものが挙げられるでしょう。

ごくごく当たり前のこともありますが、これらが守られていると、クライアントの理解がしやすくなるため、レビューがスムーズに進んでいくでしょう。

クライアントのレビューを通して、機能要件の追加や削除が発生したりしながら、実装すべき機能（＝機能要件）の明確化がなされていきます。最終決定に当たっては、コストや納期が問われることもありますが、機能がある程度分かってくれば、完璧とは言わないまでも、概算の見積もりができるようになってきます。見積もりの方法については、また改めて記事を書きたいと思います。

まとめ

今回の記事では業務要件から始まって最終的に機能用要件を決めていくところまでを説明してみました。

要件定義はクライアントと二人三脚で進めていく非常に重要な工程なので、少しでもみなさんのお仕事の役に立てば幸いです。