はじめに
システム開発をするとき、どんな開発手法であれ最初に行う重要な作業に「要件定義」があると思います。
この要件定義の品質が、その後のシステム開発およびエンジニア達の命運を左右すると言っても過言ではないと個人的には思ってます。それくらい重要です。
リーダーが質の高い要件定義を準備し、メンバーとのコミュニケーションもしっかりしていたら、エンジニアはとても安心して開発できます。
今回は、こちらの書籍を読んで参考になった要件定義の仕方をご紹介します。
要求と要件の違いを認識する
システム設計にあたり最初に行うべきことは、
- 「要求」に基づいて「要件」を固めること
- その過程でどのような分析・検討が行われ、意思決定されたかトレース（振り返り）する
「要件」がどのような経緯で意思決定されたかをトレースできることが重要で、この作業は今後の設計方針を決定づけるためにも大切です。
そして、システムに対する「要求」と「要件」の違いは以下のように定義されてます。
「要求」 = ユーザがシステムで実現したいこと、つまり欲しい機能
「要件」 = 要求に基づき、制約を踏まえてシステムに盛り込むべきもの、つまり本当に要る機能
この定義の違いはとても重要です。
これらを混合して要件定義をしてしまうと、システムの後戻りが発生したり、工数が大幅に増えて最悪デスマーチに陥ります。
こんなはずじゃなかった！！とならないために、この違いは常に意識するべきです。
つまり全ての「要求」が整理されて「要件」になり、然るべき制約の中で実現可能な「要求」だけが「要件」として纏められるべきです。
要求を丸呑みしないこと
上記を踏まえ、要件定義ではユーザの言うことを何でも丸呑みにして要件にしてシステムに実装しようとすると、結果的にシステムが破綻する恐れがあります。
繰り返しになりますが「要求」と「要件」は違うのです。
ユーザから引き出した要求に制約を加味して要件へと落とし込むことが、要件定義の最大のポイントです。
だから「要件定義」であり、「要求定義」ではないのです。
要求から要件へのトレース
次に要件に落とし込んだ手順や経緯、誰が意思決定したかなど、全員がトレースできることも重要です。
これは後から言った言わない問題や、チーム間での認識齟齬を減らすことにも有効です。
それらを踏まえて、具体的な「要件定義」の手順をステップ毎に解説します。
step1 経営の要求を把握する
まず「要求」をヒアリングなどで把握して、その内容を「要求一覧表」とでも名付けた表に纏めます。
ここでは、経営からのビジネス要求を最優先に、トップダウンの意思を優先します。
step2 要求の発生源を明確にする
要求について、発生部門および担当者を明確にします。
その際、その要求を満たすことが経営課題の解決につながるものを優先事項としてチェックします。
step3 要求の背景にある課題を明確にする
step1、2で把握した要求の背景をきちんと認識して、課題や問題点を明確にします。
step4 要求の目的、理由を明確にする
ユーザが問題としている事が、実際には問題ではない場合もあります。
あくまで経営課題の解決につながる要求について、原因や理由を明らかにします。
step5 要求のランク付け
要求を洗い出した時点で、ひとまず以下の評価基準に照らして、それぞれ重要度合を5段階にランク付けします。
「5」が重要度が最も高いものとします。
考慮すべき点はこれらです。
- 経営およびビジネスに与える規模
- 緊急度
- 課題解決に要する規模
step6 要件とすべき要求を選択する
例えば、次のような要求はすぐに要件とせず、差し戻すことも考慮します。
- システムで対応すべきはない要件
→社内の制度的制約・組織的制約・市場的制約
- システムの対象ではあるが、対応すべきではない
→既に対応中、もしくは対応することにより別案件に影響があるもの
→規模が大きい、他への影響も大きい、予算がかかる、納期まで時間がないもの
step7 要件の確定
システムで実現すべき要件を定め、実現へ向けた対応方針を要件定義書としてドキュメント化してみます。
step8 要件を要求に紐づけする
どの要求がどの要件で実現されるのか、トレースできるように一覧表へ纏めます。
step9 要件と成果物の内容を確認する
可能であれば、後の工程で作成する成果物との間で、要件がどのように実現されたかを確認できるレベルまで、詳細かつ具体的に記載します。ただしこの作業のやる・やならい、粒度などは臨機応変で構いません。
トレースできる一覧表のサンプル
書籍に掲載された、要求要件追跡書のサンプルイメージです。
またドキュメントとしてこの追跡書を作成する場合は、要件定義書に含めて作成し、管理することが望ましいです。
まとめ
- 「要求」と「要件」の違いをきちんと理解する
- 「要求」から「要件」へのトレースを可能にする
- 「要件」の実現によりプロジェクトの目的を果たせるか、メンバーのモチベーションを統率できるか確認する
さいごに
今回ご紹介したのは、システム開発におけるほんの最初の一部分だけです。
ですが、この最初の要件定義がシステム開発においてはとても重要なので、敢えてピックアップしました。
これ以降の設計工程にも興味がある方は、「システム設計のセオリー」を読んでみて下さい。
この記事が少しでもお役に立てれば幸いです。
最後まで読んで頂き、ありがとうございました。
