要件定義とは
『要件定義』とは、ソフトウェアやシステム開発するための最初の工程で、クライアントの要求を引き出し、プログラミングからテストに至るまでの『地図』ともいえる重要な作業です。
クライアントの要求を整理し、実務に入る前に認識の食い違いがないかを確認し、『見える化』するためのツールでもある要件定義が、実際にどのような役割を果たしているのかみていきましょう。
ユーザーの要求を整理する
クライアントの『要求』と、要件定義の『要件』は似ている言葉ですが、システム開発においてはどのような違いがあるのでしょうか？
要求は単に『希望』ですが、要件は『希望をどう実現するか』であり、『要件定義書』にはクライアントの希望をどう実現していくかの『解決策』まで含めます。
要件定義は要求に対する解決策と、要求が要件に昇華され、設計に落とし込める高い品質レベルで文書化するのが望ましいです。
解決策を決めることがゴール
要件定義を『要求を明確にする作業』と勘違いしている開発者もいますが、クライアントの要求を明確にするだけではなく、その先の解決策まで決めるのが『要件定義』です。
要件定義の品質が高ければ、そのプロジェクトの品質が工程中ずっと引き継がれる可能性が高まりますが、その逆ならば結果も然りです。クライアントとのコミュニケーションを密にし、きちんと次工程に引き継ぎましょう。
要件定義書の書き方
自分がクライアントの立場にたったとき、開発側から提出された『要件定義書』がどのようなものだったらうれしいですか？
単に、要求が書かれているだけでは、メモにすぎません。しかし要件定義書に、その要求の解決策まで書かれていれば、クライアントの満足度は非常に高くなるでしょう。
『要求に対する解答の文書化』である要件定義書に、記載すべき項目には何があるか、一つずつみていきましょう。
階層構造で読みやすくする
最終成果物に必要な項目には、『システム概要や背景・システム導入による目標・システムの具体的な機能・システム要求』が、階層構造で記載されていることが基本です。
これにより、どのような目的で、求められている結果は何かという『プロジェクトの方向性』を、開発にかかわる全員が共有できるようになります。
『性能または品質要求・セキュリティ要求』は、クライアントの要求だけでなく、過去の開発データをベースに、常に最新の安全策を提示しましょう。
誰でもわかるように専門用語を省く
よりよい要件定義書を作成するためには、どのような点に気をつけたらよいでしょうか？
最大のポイントは『理解しやすさ』です。クライアントに開発エンジニアのような知識があれば、そもそも開発を依頼しない可能性があります。
専門用語の使用は最小限にし、どうしても専門用語を使わざるを得ない場合は、かみ砕いた表現を用いたり、解説を入れたり、図解表現で視覚的にわかりやすい要件定義書に仕上げられるように心がけましょう。
要件定義書に必要な項目
いざ要件定義書を作成する段階になったとき、フォーマットがわからなくて困惑することもあるでしょう。要件定義書には『四つの構成を順番に書いていく』ことになります。
四つの構成である『概要・業務要件・機能要件・非機能要件』それぞれについて、何をどのように書いたらよいのか概略を説明していきます。
概要で目的や目標を決める
『概要』に記載する内容は、『システム開発に至った背景』と『システム開発の目的と目標』です。
クライアントがそのシステム開発を希望した理由が、必ずストーリーとして存在しているはずなので、それを記述します。
そのストーリーは、実際にシステム開発が始まってから方向性を見失ってしまったとき、高い意味を発揮するでしょう。
『目的』は、システム開発によって、どのような効果や結果を求めているかという内容です。『目標』は、それがどのような結果になったときに達成されたかを定義する指標です。
定量的なゴールを決めておくことで、関係者全員の認識にズレがないようにしましょう。
業務要件で業務フローを作成
概要に記述した『システム開発の目的と目標』を達成するために、実際の業務はどうあるべきかを考えます。業務の流れを文書で書くと非常にわかりづらいため、業務フロー図を書きます。
まず『現状の業務フロー（As-Is）』を記述し、『システム稼働後の業務フロー（To-Be）』を書けば、システム稼働前・稼働後のフローが明確になります。それらを比較しながら、どの範囲までシステム化するのかも決めましょう。
機能要件で必要な機能を決める
業務要件でシステム化すると決めた範囲で、『何をどのように使うのか』という動作に対し、『システムがどのような情報を管理したり処理したりすればよいか』を規定するのが『機能要件』です。
機能要件でありがちな失敗が、SEだけで決める方式です。システム課題を優先するのではなく、実際にユーザーがどのように使うのかを確認しながら、使いやすさと、必要な機能がそなわっているかを、検討しながら決定しましょう。
非機能要件でシステムの裏側を決める
機能要件が『ユーザーの目に触れる機能』であるのに対し、『非機能要件』はシステムの品質や性能という『システムの裏側』を決めることです。
基本的にどのシステムでも、非機能要件で検討すべき内容は同じである場合が多いため、すでにあるフォーマットを転用することで、資料作成や事項の抽出にかかるコストを削減しましょう。
業務フローの書き方
システム開発関連以外でも、企業の業務遂行に欠かせないのが『業務フロー』です。
企業によって導入の目的は違いますが、多くの企業が業務フローを作成する理由は『業務の可視化』が目的です。しかし、せっかく作成した業務フローがわかりづらいと、かえって現場に混乱を招く恐れもあるでしょう。
プロジェクト進行のために、効果的な業務フローの書き方を紹介していきます。
開始や流れをわかりやすくする
業務フローでは、『開始』と『流れ』を明確にします。どこから始まっているか分からないような業務フローでは、読み始めるのが困難になるばかりでなく、肝心の業務を開始できません。
明確にした開始点から、どのような順番で業務が流れていくのかを示すために、交差線は使わず、分岐線を使うことで見やすい業務フローが作成できるでしょう。
図形の種類を増やしすぎない
業務フロー作成では、三つの図形にしぼってフローチャートを書くようにしましょう。
一つ目は、プロセスの開始と終了を表す『端子図形』です。フローの始まりに配置すれば、どこからに業務が開始するのか一目瞭然です。
二つ目は『プロセス処理図形』です。フローチャート作成でよく使われる図形で、手続きや、チャートのステップを表現するのに便利です。
三つ目は『判断図形』で、一般に『Yes・No』の選択肢から、2方向へ矢印が出ていく図形です。分岐によってどのような結果がもたらされるのか、理解しやすくなります。
アイコンや色付けをする
業務フローは、プロジェクト関係者だけでなく、エンドユーザーとの仕様検討でも用いられることが多いため、アイコンや色付けをして、視覚効果の高い業務フローを作成しましょう。
特に、判断決定が必要な分岐ポイントには、赤や青の色を使って『YES＝青・NO=赤』など直感的な仕様にすれば、人的ミス防止にも役立つでしょう。
まとめ
要件定義書は、システムやソフトウェア開発になくてはならない工程ですが、それだけに作業が煩雑になり、プロジェクトチームの方向性をバラバラにしてしまう恐れもあります。
『概要・業務要件・機能要件・非機能要件』の四つの階層構造や、色やアイコンを多用した分かりやすい業務フロー作成で、効率的で効果性の高いシステム開発をしましょう。