【上流工程】要件定義の仕事内容と求められるスキル

要件定義フェーズですること

一般的に、要件定義ではシステムで必要な「機能要件」と「非機能要件」を決めていきます。言葉だけだと理解できないと思うので例を上げて説明しますね。

 

たとえば、他社との契約を管理するシステム（契約管理システム）があったとしましょうか。契約管理システムには、

 

• 契約書を新規作成し、保存する機能
• 契約書の検索および一覧を出力する機能
• 契約書を帳票（PDF）で出力する機能
• 契約書の状態（作成中、作成完了、承認済、発注済）を管理する機能
• 作成した契約を別システムへ転送する機能

 

が必要です。このように、お客さんが業務を実施する上で、必要な機能を機能要件といいます。みんなが機能と聞いてイメージするものが機能要件と考えて問題ないでしょう。

 

機能要件の定義の主体は、あくまでクライアント側が行います。システム開発会社側はサポートしかできません。なぜなら、クラアントの業務を一番理解しているのは、クライアントだからです。

 

• クライアントは、業務に必要な機能は何か
• システム開発会社は、クライアントの必要な機能がシステムで実現できるか

 

を意識しながら、要件定義を進めていく必要があります。

 

続いては非機能要件についての説明です。

 

• システムは500人のユーザーが同時に利用してもダウンしないようにする
• 各機能のレスポンス時間は3秒以内とする
• システムの機能は24時間、どこの拠点からも利用できるようにする
• 障害発生から復旧するまでの時間は12時間以内とする

など、システムの性能やパフォーマンス、利用者制限など、システムの機能ではないが、
システムを開発する上で利用する前提となるものを非機能要件として定義しておきます。

 

これらの要件定義で決まったものは、「要件定義書」、「機能一覧」、「業務フロー」というドキュメントにし、
今後の工程のインプット資料となります。

 

これらのドキュメントがどこまで詳細化されているかによって、今後の開発の大変さが変わってきます。

 

要件定義に失敗すると

 

要件定義の失敗例として、

 

• クライアントの業務に必要な機能が要件から漏れている
• クライアントの業務が要件定義書に正しく反映されていない
• システムの機能それぞれの整合性が合っていない

 

などが挙げられます。

 

これらの失敗は、ウォーターフォール開発の場合、中々気づくことができません。特に機能が漏れている、正しく反映されていない等は、システム会社側は気づくことができないのです。なぜなら、クライアントの業務を正しく知っているのはクライアントだけだからです。

 

システム開発において、システム開発側のテストが完了した後に、クライアントが実施する受け入れテストがあります。もし、この段階でクライアントが「システムの機能が思っていたものと違う」なんで言い始め、システム開発側が悪いと言うことになった場合は、一気にプロジェクトが炎上します。このようなことにならないようにするのが要件定義を担当する人には求められます。

求められるスキル

要件定義では、クライアント側の業務を瞬時に理解するスキルが求められます。クライアントの業務を最初からすべて知ってるのがベストですが、システム開発会社で働いている以上はそれはありえないでしょう。

 

また、クライアント側の要件定義担当者に合わせた要件定義を実施するスキルが必要です。

 

クライアント側の要件定義担当は、クライアントの業務には精通していますが、システムについては疎いことが多いです。特に、クライアント側の要件定義担当者が要件定義の経験がはじめてというケースも少なくありません。はじめて要件定義を実施する場合、クライアントはシステム開発側へ何をどのように伝えたらいいか分からない場合が多く「伝え忘れ」が発生するリスクがあり、丁寧に進めていく必要があります。

 

逆に、クライアントが要件定義に慣れている場合、丁寧な説明はうっとしいだけなので、スムーズに実施していく必要があります。

 

クライアントの反応を確認しつつ、最適な説明・検討をするスキルが求められるのです。￥

 

要件定義のスキルが求められる会社

要件定義のスキルが求められる会社は、

 

• コンサルティングファーム
• 大手SIer
• ユーザー系SIer

など、一次請けとなる会社です。一次請けの会社は、開発より要件定義がメインとなります。もし、要件定義を実施したいのであれば、このような一次請けの会社を目指しましょう。

設計者から要件定義担当になるには

システムに関する知識については、設計できるスキルがあれば、要件定義は問題ないでしょう。後は、システムに関する知識ユーザーと共有することができるコミュニケーションスキルさえ身につければ問題なくキャリアアップできるでしょう。ただし、クライアントととのコミュニケーションは、システムの設計と全く異なる脳みそをつかうので、注意しましょう。

 

保守運用担当から要件定義担当になるには

保守担当は、システムの機能を知った上で現場からのクレームを受けており、その経験を要件定義に活かすことができます。「○○」という要件にした場合、「××」という問題が発生すると言うことを知っているのは、保守運用担当です。そんな保守担当が要件定義を行うと、クソシステムと呼ばれるものが作られるリスクを減らせるので、その辺りを充分にアピールできればキャリアアップ可能でしょう。

 

テスター、プログラマーから要件定義担当になるには

正直きついです。まずは、設計を学んだ上で、要件定義の仕事にチャレンジした方がいいと思います。