はじめに
筆者は実務経験3年目の開発エンジニアで、現在は2社目の会社に在籍しています。
1社目2社目ともに要件定義を担当する機会があったのですが、
どちらの現場も要件定義のフォーマットが存在しないか、あるいはフォーマットがあっても明らかに項目が足りないような状態でした。
要件定義のクオリティは完全に属人化してしまっており、
担当するたびに
「抜けや漏れがあったらどうしよう」
という不安を感じていました。
そんな中でふと、
「要件定義はどこのシステム開発現場でも必要なのに、規格としてまとめられていないのだろうか？」
と疑問に思い調べたところ、ISO/IEC/IEEE29148という規格の存在を知りました。
この規格については、大手SIerなどでは社内フォーマットとして活用されていることが多いためか、
1個人のエンジニア視点で紹介している記事はあまり多く見当たりませんでした。
そのため、本記事ではこの規格について、
特に現場で役に立った 「要件を種類ごとに分けて整理する」 ということを中心にまとめました。
実際にこの考え方を取り入れてみたところ、要件定義工程に対する不安はかなり軽減されました。
本記事が、要件定義が属人化した現場で悩んでいる方の一助となれば幸いです。
想定読者：こんな人に読んでほしい
・未経験、または経験が浅く、要件定義を任されることに不安を感じている方
・要件定義の経験はあるものの、やり方に自信が持てない方
・要件定義に国際規格が存在することを知らなかった方
免責事項
本記事は ISO/IEC/IEEE 29148 の全文を解説するものではありません。
本規格が扱う内容のうち、筆者が実務で役立ったと感じた考え方を中心に、できるだけ噛み砕いて紹介します。
要件定義の国際規格：ISO/IEC/IEEE29148とは？
ISO/IEC/IEEE29148は要求工学の国際規格で、
「要件にはどんな種類があるのか」
「良い要件と悪い要件の違いは何か」
など、要件定義に関する様々なトピックを扱っています。
この規格は有償規格ですが、各種技術記事や企業サイトを通じて、実務上で重要となる考え方や内容の一部を知ることができます。
また、日本語版が見当たらず恐縮ですが、こちらには、この規格を参考に要件を整理するためのテンプレートも公開されています。
要件は分割せよ
ISO/IEC/IEEE29148が扱う内容の中で、実務上特に役に立ったのが、
「要件を種類ごとに分けて整理する」
という考え方です。
ISO/IEC/IEEE29148では、要件を以下の三段階に分けて整理します。
①ステークホルダ要件
②システム要件
③ソフトウェア要件
これらの要件の間には序列があり、
ソフトウェア要件はシステム要件に、
システム要件はステークホルダ要件に依存します（ステークホルダ要件の優先度が最も高い）。
それぞれの要件がどのようなものなのか、以下に順を追って記載します。
ステークホルダ要件
ステークホルダ要件は、
文字通りステークホルダ（=利害関係者）、つまり「システムに携わる人・組織」を中心として整理した要件です。
システムに携わる人が、システムに何を期待しているのか=システムの価値を整理します。
例：
・在庫管理担当者が、在庫確認に時間がかかって困っているので、解決したい
ステークホルダ要件では技術的な話はせず、ある程度曖昧な記載（「困っている」など）でも大丈夫です。
このステークホルダ要件をどのように満たしていくのかを、システム要件やソフトウェア要件で定義していきます。
システム要件
システム要件は、システム（人・手順・ソフトウェア・ハードウェアを含む全体）がどんな要求を実現するか、という視点で整理した要件です。
ソフトウェアで自動化する作業はもちろん、人が運用でカバーする内容や、他システム（外部システム）に委ねることなども、システム要件のスコープとなります。
特に、障害発生時の対応や、実務上稀ではあるが起こりうるケースへの対応については、業務担当者やシステム担当者が運用でカバーすることも多いため、システム要件の中で明文化しておくと安心です。
例：
・システムは、担当者が必要なタイミングで、在庫状況をオンライン上で確認できるようにすること
・システムは、在庫情報の更新/確認手順を明確に定義すること
・システムは、在庫状況のオンライン確認が実用的な応答時間で行えるようにすること
各要件は検証可能であることが望ましいですが、
システム要件はステークホルダ要件（抽象的）とソフトウェア要件（具体的）の中間なので、
「定量的だと望ましいが、定性的に整理してもよい」くらいで整理しておくのが良いかと思います。
ソフトウェア要件
ソフトウェア要件は、システム要件のうちソフトウェアが実現する内容を、検証可能な形で定義する要件です。
例：
・ソフトウェアは、商品コード指定で在庫を検索できる機能を提供すること
・ソフトウェアは、在庫検索機能について、検索対象件数1万件以下であるとき、検索要求から3秒以内に結果を表示することができること
・ソフトウェアは、在庫検索機能について、同時に50ユーザーまでアクセス可能であること
また、システム要件のうち
・ソフトウェア要件で実現しない部分は何なのか、
・その部分はソフトウェア以外でどのように実現するのか
までを併せて明記しておくと良いと思います。
おわりに
要件定義のフォーマットが決まっていない現場では、
以下のようなことがよくあるのではないかと思います。
・ステークホルダ要件よりも先に、システム要件やソフトウェア要件が飛んでくる
・ステークホルダ要件を発注者-受注者間で共有できておらず、目的から外れた要求が飛んでくる
ISO/IEC/IEEE 29148 に沿うことで、
システム開発の本来の目的を明確にし、
レイヤーの異なる要件同士が混ざってしまうことを避け、
「誰のための・何のための要求なのか」を意識しながら、要件を整理することができるかと思います。
参考サイト
Sky TechBlog「ISO/IEC/IEEE 29148、JIS X 0166を活用した要件定義」最終参照日：2026年1月22日
NTT DATA_DATA INSIGHT 「要求定義に関する国際標準（ISO/IEC/IEEE 29148）の影響力」最終参照日：2026年1月22日