できる人はやっている要件定義の進め方とは？

こんにちは！

ITエンジニア・webディレクター・webデザイナーなどのIT人材の自立・キャリアを支援するITプロパートナーズのCTOの柳澤（やなぎさわ）です。

弊社は、独立精神旺盛な優秀なエンジニアの方々の独立・起業サポートや、フリーランス支援を行っている会社です。

こちらのジョブウィズでは、企業の新規事業開発担当者の方や、システム開発責任者の方、事業責任者の方達に向けて、事業開発のコツや、自社プロダクトやWebサービスを立ち上げる際にポイントや注意点について、弊社ノウハウを包み隠さずにお伝えしています。

さて、今回は「要件定義」をテーマにお話しします。

システムを導入する際、絶対に避けて通れないのが要件定義です。
この要件定義に失敗してしまうと、システム開発すべてに支障をきたし、最悪の場合、プロジェクトを失敗させてしまいます。

そこで今回は、要件定義について、しっかりと確認していきたいと思います。

そもそも要件定義とは？

そもそも、要件定義とはなにかを確認しましょうか。

システム開発はよく家作りに例えられるので、まずは家作りを例にして整理してみます。

実際に大工さんたちが家を建てる前に、家の造り、間取りであったり内装であったりを決める必要があります。

いわゆる設計やデザインの仕事ですが、設計士さんやデザイナーもいきなり自分たちの好き勝手に設計・デザインするわけではありません。

まずは営業などを介して、購入者の思いや好みを聞き出し、方向性をはっきりさせます。

例えば、家の外壁はクリーム色にするだとか、トレイは2Fと3Fそれぞれにあるようにする、あるいは窓は防犯用に金網入りにする、といった類のことを、設計より前に購入者と合意しておく必要があるのです。

他にも購入者に対して、いつ家を引き渡すのかについて確認し、同意することも重要です。

そして、その引き渡し日に向けて、どういったスケジュールで家を建てて行くか、スケジュールを組み立てて購入者に知らせておくのがベターです。

システム開発においての要件定義とは、家作りと同じで、どういった機能を持つシステムを、いつまでに、どういったスケジュールで作っていき、いつ納品するのかを顧客とシステム開発側で合意することです。

そして、この合意の内容をまとめたものが要件定義書となります。

この要件定義で、顧客とシステム開発側の間でボタンの掛け違いが発生すると、深刻な事態を招くのは想像に難くないでしょう。

要件定義に必要な工程と内容って？

では、要件定義の概要が理解できたところで、改めて要件定義の工程とその内容を見ていきましょう。

最終的なゴールを設定

まずはゴール設定が重要で、それを要件定義でも記載しましょう。

要件定義でもっとも大切なことの一つは、最終的なゴール設定あるべき形の確認です。

ここで言う、あるべき形はシステムにどのような機能を持たせるかといったレベルではなく、顧客の現在の業務フローのどこに問題が潜んでいるのかであったり、WEBサイトを含めた顧客の営業ツールには、なにが足りていないのかを模索することから始める必要があります。

場合によっては、既存システムの改良で対応可能で、新たなシステムを開発しなくても良い場合もありますし、ひょっとしたら社内手続きのフローを見直すだけで、顧客がハッピーになるかもしれません。

やっぱり新たなシステムを開発するのが最適解だ、という結論に至ってから、新たなシステムにどういった機能を持たせるのかを検討します。

顧客への理解・ヒアリング

また、あるべき形を理解するためには、顧客について、よく理解しておく必要があります。

どのような業務をしていて、どこに問題があると感じているのかといったユーザー目線でのヒアリングも必要です。

こういったことができると嬉しいという機能だけでなく、レスポンスや今後の拡張性など、いわゆる非機能要件にも意識しなければいけません。

もともとあったシステムを新規構築システムで置き換えるとなると、旧システムについても理解、多岐に渡る事前調査が必要です。

スケジュール（ロードマップ）の設計

そして、スケジュールというよりも、この場合はロードマップと呼ぶ方が適切だと思いますが、今後の段取りについても明確化しておくのも要件定義のポイントです。

いつが納品日なのか、各フェイズにどれだけの日数、ひいては工数をかけるのか分かるマスタースケジュールがなければ、プロジェクトはプロジェクトの体裁を成しません。

要件定義と要求定義って何が違う？

ところで、要件定義に似た言葉で要求定義というものがあります。

この違いをみなさんはご理解しているでしょうか？

ざっくり言ってしまうと、これまで見た通り、要件定義がシステム発注者とシステム開発側で、どんなシステムにするか方向性や今後の予定を取りまとめるのが要件定義。

対して、要求定義はシステム発注側が、こんな機能が欲しいだとか、いつまでに納品して欲しい、といったシステム開発側になにを期待しているかをまとめることを要求定義です。

そして、要求定義をまとめたものを要求定義書と呼びます。

要求定義書と同じように、システム開発側に期待することを書き表すドキュメントとしては、RFP（提案依頼書）と要求仕様書があります。

RFPは主に発注者がシステム開発を受注してくれそうなベンダーに打診する際に作成・配布するもので、これを持って各社は提案書を作成し、コンペをすることになります。

システム開発を決意するに至った時点での要求をまとめたものなので、通常は要求定義書より粒度が荒かったり、実際に受注してから渡される要求定義書と内容が異なることも多少あります。

もう一つの要求仕様書は、最近使われるようになってきた言葉で明確な定義はありません。

人や案件ごとにどういった感覚で使われているか良く確認した方が良いでしょう。

筆者の知っている環境では、プロトタイプ開発でプロトタイプを見たシステム発注側が、改めて新規開発されたシステムに求めるものをまとめた資料を要求定義書と呼んでいました。

いずれにせよ、要件に対して要求とつくものは、その名の通り、あくまでシステム発注側の求めることであり、まだ本当にシステムに機能として実装されるのかはわからないものという認識があれば問題ありません。

できる人がやる要件定義の進め方

では、いよいよ本題です。できる人の要件定義の進め方をお教えいたします。

とにもかくにも重要なのは、要件定義で“顧客がこんな機能が欲しいと思っている”だとか“納期は半年後だ”と頭に記憶しているだけでは、要件定義とは呼べません。

要件定義は、それをまとめた要件定義書が作成され、その定義書についてシステム発注側とシステム開発側双方が納得し合意して、はじめて完了するのです。

そして、その後のシステム開発はすべて、要件定義書を根幹とします。

つまり、特別な事情が発生して、システム発注側とシステム開発側双方が臨時の取り決めを行わない限り、要件定義書のロードマップに従ってスケジュールは組まれますし、途中で実装される機能が追加される、なんてこともありません。

要件定義の上手い人とは、顧客の要求を聞き出し、整理して巧みに要件として書き表す能力だけでなく、ドキュメントとして高い完成度を持つ要件定義書を作る能力のある人と言えます。

もう少し噛み砕いて見てみましょう。

ヒアリング能力

顧客の要求を聞き出し、整理して巧みに要件として書き表す能力は、もっと具体的に言えばヒアリング能力といった営業的センスです。

ここでいうヒアリング能力とは、単に聞き出すだけでなく、聞き出したことの真の問題点が理解できるように発注者の業務についての理解も重要です。

同時に自分は要件定義書を作るエンジニアであり、営業ではないということについてもしっかり自覚が必要です。

要求定義書にも出てきにくい、いわゆる非機能要件について確認したり、顧客の思いと最新のトレンドを踏まえてどういったシステムにするのか提案して、納得していただくのが重要です。

場合によっては、RFPや要件定義書にあったけれど、難易度や工数や納期の都合、実装が困難な機能があることもあります。

そうった機能を、はっきりと実装できないと宣言し、実装しないことに了承していただく“腕力”も必要になるでしょう。

ドキュメント能力

ドキュメントとして高い完成度を持つ要件定義書を作る能力は、簡単に言ってしまえば、誰が見ても同じ意味に理解できる要件定義書にする能力です。

現実問題として、システムの規模や状況によりけりですが、要件定義から納品・ローンチまで同じメンバーとは限りません。

実装時のみ増員されるプログラマーもいるでしょうし、ひょっとしたらシステム発注側の担当者が、突然の異動で別の方に変わることだってあります。

最初からいたメンバーにはわかるけれど、新規参入者が見たら分からない、異なる意味にとらえてしまう要件定義書だと非常に困ったことになります。

例えば、「家の外壁を白っぽい色にする」と書いてあった結果、顧客をはじめ当初からいたメンバーは暖かいクリーム色をイメージしていたのに、途中から参加した作業者の判断で家の外装は月白と呼ばれるような、青みかかった白が塗られていた、ということになりかねません。

曖昧で判断の余地が残る内容にしないことが重要です。

要件定義書の作成段階では決まっていなければ、「次の仕様書作成時に決定する」といった風に、いつ決まるのかを書いておいた方がベター。

なにが決定の制限になっているのかも明確化しておくと完璧です。

リスクヘッジ能力

また、RFPや要件定義書にあったけれど、難易度や工数、納期の都合、実装が困難な機能が発生し、実装しないことで合意した場合、なぜ実装できないと評価されたのか、システム発注側のどのクラスの方が合意したのかまで、はっきりと明示しておくことも重要です。

後で、その機能がないことが問題視されて、追加で実装を指示されるといった形で案件をかき回されるのを防ぐ意図と、システム開発側は正しいフローに則り機能の実装をしなかった証拠となるので、身を守る意味もあります。

成功する要件定義の手法と成果物

要件定義の進め方について見てきましたが、中には具体的な手法を知りたいという方もいらっしゃるかと思います。

そして成果物についても、必要な項目はどのようなもので、どのような最終成果物を納めればいいのかを詳細に説明しているので、気になる方は以下の記事も合わせてご覧ください！

まとめ

今回は要件定義について見ていきました。

要件定義書も言ってしまえば、一つのドキュメントでしかありませんが、システム開発の命運がかかる重要なドキュメントです。

簡単に作成できるものではなく、慣れた方でも正しく5W1Hが伝わるか、全体として変なところや矛盾がないか、何度も推敲して仕上げるようなドキュメントです。

逆に言えば、要件定義書が正しく作ることができるようになれば、一流ITエンジニアの仲間入りと呼べるのではないでしょうか。

それだけに一朝一夕でできるようになるものではありません。

周りの上手な人に技術を教えて貰ったり、テクニックを盗んでいきましょう。