要件定義
要件定義とは、システムや製品を開発する前に、発注者が実現したい機能や性能、守るべき制約条件を文書にまとめ、開発範囲を確定させる工程である。システム開発の上流工程に位置付けられ、ウォーターフォールモデルでは最初のフェーズにあたる。成果物は「要件定義書」と呼ばれ、後続の基本設計や受入テストの判断基準となる。国際的にはISO/IEC/IEEE 29148、国内ではこれに対応するJIS X 0166:2014が、要求を引き出し、分析し、文書化する手順の枠組みを定めている。
上流工程が重視されるようになった経緯
開発の初期段階を重視する考え方は、1970年代のソフトウェア工学の研究から広まった。バリー・ベームは1981年の著書『Software Engineering Economics』で、要件段階で混入した欠陥を運用後に直すと、初期に直す場合の最大100倍のコストがかかると示した。この数字は今でもよく引用される。米Standish Groupが1994年に公表したCHAOSレポートでは、予定どおりに完了したITプロジェクトは16.2%にとどまり、失敗の主な原因として要求の不完全さや仕様変更が挙げられた。上流での決め漏れが、そのまま下流の手戻りになる。この認識が業界に定着したことで、要件定義は独立した工程として扱われるようになった。
「要求」と「要件」の違い
現場ではよく混同されるが、両者は別の段階を指す。要求は利用者や経営層が口にする「こうしたい」という希望で、要件はそれを関係者が合意し、実現すべき条件として確定させたものである。たとえば工場長の「検査記録の紙をなくしたい」は要求にあたる。これを「検査工程の測定値をタブレットで入力し、5秒以内にサーバーへ登録する」と具体化したものが要件となる。要求をそのまま仕様書に写すと、解釈の幅が残ってしまう。
機能要件と非機能要件
要件は大きく2つに分けられる。システムが「何をするか」を定める機能要件と、「どの程度の品質で動くか」を定める非機能要件である。発注者は機能のほうに目が行きやすく、非機能要件は抜けやすい。
| 区分 | 定める内容 | 製造業システムでの例 |
|---|---|---|
| 機能要件 | 業務処理、画面、帳票、外部連携 | 製造指図の発行、ロット別の実績集計、出荷ラベルの印刷 |
| 非機能要件 | 性能、可用性、セキュリティ、運用 | 24時間稼働ラインでの稼働率99.9%、画面応答3秒以内 |
| 制約条件 | 予算、納期、使用技術、法令 | 既存サーバーOSの継続利用、稼働開始は期初の4月 |
非機能要求グレードの6大項目
非機能要件の決め漏れを防ぐため、IPA（情報処理推進機構）は2010年に「非機能要求グレード」を公開した。項目ごとにレベルを選んでいく方式で、次の6つの大項目で構成される。
- 可用性
- 性能・拡張性
- 運用・保守性
- 移行性
- セキュリティ
- システム環境・エコロジー
ヒアリングから合意までの進め方
最初に関係部署へのヒアリングで現状業務（As-Is）を洗い出し、業務フロー図にまとめる。そのうえで、あるべき姿（To-Be）との差を整理し、システムで解決する範囲を絞り込む。利用者とシステムのやり取りを表すには、UMLのユースケース図がよく使われる。UMLは1997年にOMGで標準化された記法である。画面操作のイメージが共有しにくい場合は、プロトタイピングで簡単な試作画面を見せると認識のずれが早く表面化する。要件の数が多い場合は、Must・Should・Could・Won’tの4段階で優先度を付けるMoSCoW法が使える。最後にレビュー会を開き、発注者と開発者の双方が承認して確定させる。
製造現場のシステム導入で起きやすいこと
生産管理システムやMESを導入する際の要件定義には、事務系システムにはない難しさがある。熟練者の段取り判断や、品番ごとの例外処理が暗黙知として残っていることが多く、ヒアリングだけでは出てこない。設備側のPLCからデータを集める場合、OPC UAや三菱電機のMCプロトコルなど通信方式の指定も要件に含めなければならない。タクトタイム60秒のラインで実績登録に10秒かかれば、作業者は入力を後回しにするようになる。実務では、要件定義の工程だけを準委任契約で切り出す発注形態が一般的である。これは経済産業省が2007年に公表した「情報システム・モデル取引・契約書」の考え方に沿うもので、2020年にはIPAが民法改正に合わせた改訂版を出している。工数は全体の1割前後を見込む例が多い。しかしERPパッケージのFit&Gap分析を伴う案件では、帳票レイアウトの確認だけで数か月かかることも珍しくない。
アジャイル開発との関係
2001年の「アジャイルソフトウェア開発宣言」以降、最初にすべてを決めきらない進め方も広がった。アジャイル開発では、要件はユーザーストーリーとしてプロダクトバックログに積まれ、1〜4週間のスプリントごとに見直される。ただ、要件定義が不要になったわけではない。性能やセキュリティのような非機能要件は、後から変えると構成全体に影響するため、初期にある程度固めておく必要がある。
失敗しやすいポイント
よくある失敗は、「速く」「使いやすく」といった測れない言葉が要件書に残ることである。「月末締め処理を30分以内に完了する」のように数値に置き換えれば、受入時に合否を判定できる。もう1つは、確定後に要件がじわじわ増えるスコープクリープで、変更管理の手続きを事前に決めておかないと、納期とコストが膨らんでいく。V字モデルでは要件定義と受入テストが対になっており、要件とテスト項目を対応付けたトレーサビリティマトリクスを作ると、確認漏れを防ぎやすい。この対応表は、ISO 9001に基づく品質保証の監査で開発記録として提出を求められることもある。
コメント（β版）