こんにちは。今日は、要件定義のまとめ方について書いてみます。
要件定義とは、システム開発のウォータフォールモデルで最初に行う工程です。
実際にお客様とどの様なシステムを開発するのかを話し合い、文章に起こす作業になります。
ウォータフォールモデルとは
今回は、要件定義を書く前のまとめ方について、私の経験を元に書いていきます。
なので、これが正解という内容ではないのでご了承ください。
結論から言うと以下になります。
- 業務の流れを理解する
- 言葉の定義を明確にする
- 業界について理解する
大きく分けると上の３点になります。
要件定義は、どんなシステムを作るのか、相手がシステム企業かエンドユーザかによって変わってきますので、その辺も分けて書いていきます。
業務の流れを理解する
まず必要となるのは、現在の業務の流れを理解する事です。
私は、ここが一番大事だと思っています。
相手がシステム企業の場合は、その先にエンドユーザがいるのですが、システム企業が相手の場合、この辺は分析されているので、ざっくりとした説明を聞くのみとなります。
相手がシステム企業で、エンドユーザの業務の流れを理解していな場合もたまにありますが、その場合は、大体プロジェクトが炎上してしまいます。
相手が悪いと言ってしまう事もできるのですが、作る方としても良いものをエンドユーザへ提供したいので、どうしても時間をかけて本当に必要なシステムを開発します。
そして、時間がかかりすぎて赤字になる事がよくあります。
では次に、相手がエンドユーザの場合です。
相手がエンドユーザの場合は、実際に作業している方からヒアリングをします。
まずは、大きな業務の流れを理解します。
その後で、各作業の詳細を理解していきます。
相手が実作業をしている方の場合は、業務の流れを絵に書いて話し合うのが経験上効果的です。
たまに、大きな業務の流れだけを要件定義にして、詳細は設計で行うプロジェクトがあるのですが、業務の中には、例外的な作業も含まれているので、手作業でする方が良い作業と、システム化する方が良い作業を要件定義の段階で分ける方が良いと私は思います。
言葉の定義を明確にする
これも重要です。
言葉の定義が違っていて、炎上するプロジェクトって思った以上に多いのです。
私が経験したプロジェクトでも、言葉の定義を間違えて設計書をOKとしたために、試験工程でNGとなって炎上した事が何度かあります。
相手がシステム企業の場合は、言葉の定義に違いがないだろうと思うかもしれませんが、同じ業界だからこそ起きる言葉の違いがあります。
なので、曖昧な言葉は、お互いに意味を共有し、要件定義書にまとめておくことをお勧めします。
相手がエンドユーザの場合は、業界用語の意味を把握する必要があります。
一般的な用語でも、エンドユーザ特有の意味が含まれる事があります。
そのため、Webで意味を調べて推測して要件定義書を作成しても、あと工程で機能の不足が出てきたりします。
また、これは相手がシステム企業でもエンドユーザでも同じなのですが、「あたりまえ」と言う言葉には注意した方が良いです。
私の当たり前は、相手の当たり前ではない事がよくあります。
業界について理解する
これが、一番難しいところです。
業界を絞ったシステム企業の場合は、業界についての知識も充分にあると思いますが、請負でシステム開発を行うと、いろいろな業界から依頼を受けるので、新しく知識を着けないと、深い内容まで聞けなかったりします。
相手がシステム企業の場合は、業界に詳しい事が良くあるので、調べて分からない時にその都度聞く事ができます。
なので、要件定義書を書きながらでも聞けますし、その後の工程でも、分からない時は聞く事ができます。
相手がエンドユーザの場合は難しいです。
実作業されている方は、業界については知識が少ない事も良くあります。
実際、業界については、相手企業の社長様に聞くことになる事もあります。
そのため、時間が限られてしまうので、なるべく必要な業界知識は、要件定義の話し合いまでに調べておき、分からない部分を聞く様にしましょう。
また、同じ業界でもエンドユーザによって認識が違う事がありますので、曖昧なところは明確にする様にしましょう。
まとめ
要件定義をまとめる時は、相手が同じシステム企業でもエンドユーザでも、言葉の意味を明確にし、作業の流れを明確にしないと、システム開発は上手くいかない様に思います。
上手くいったとしても、エンドユーザは新たな作業が増る事も良くあり、システム化したけど作業は楽になってなかったりします。
正直、その場合は、プロジェクトは成功でも開発は失敗だと私は考えます。
では、今日はこの辺で。
