発注の基本

システム要件しすてむようけん

要件定義機能要件非機能要件RFP仕様書システム発注

システム要件について教えて

簡単に言うとこんな感じ！

「新しいシステムに何をしてほしいか」を言葉にしたものだよ！家を建てるときの「間取り図」みたいなもので、これがあいまいだと完成したシステムが全然使えない…なんてことになるんだ。発注前にしっかり整理しておくのが超重要！

システム要件とは

システム要件とは、開発・導入するシステムが「何をできなければならないか」「どのような条件を満たさなければならないか」を定義したものです。発注者と開発者の間で共通認識を持つための”約束の文書”であり、プロジェクト全体の設計図の出発点となります。

システム要件は大きく 「機能要件」 と 「非機能要件」 の2種類に分かれます。機能要件は「〜ができること」という具体的な動作に関する要件、非機能要件は「どれくらい速く動くか」「どれくらい安全か」といった品質・条件に関する要件です。どちらが欠けても、使い物にならないシステムが出来上がる原因になります。

ビジネスパーソンとしてシステムを発注する立場では、この要件をあいまいなまま開発会社に渡してしまうことが最大のリスクです。「なんとなくこんな感じで」という発注は、なんとなくこんな感じのシステムしか生まれません。 要件を明確にすることが、コスト超過・納期遅延・品質不満を防ぐ第一歩です。

機能要件と非機能要件の構造

分類	意味	具体例
機能要件	システムが「何をするか」	商品を検索できる、注文を確定できる、CSVで出力できる
非機能要件	システムが「どうあるべきか」	1秒以内に画面が表示される、99.9%稼働する、不正アクセスを防ぐ

非機能要件の主な分類（URPS+で覚える）

非機能要件は種類が多く見落としがちです。「URPS+」 という覚え方が便利です。

頭文字	英語	意味	例
U	Usability（使用性）	使いやすさ	スマホからも操作できる
R	Reliability（信頼性）	壊れにくさ	月1回以上の障害を起こさない
P	Performance（性能）	速さ・処理量	同時100人が使えること
S	Security（安全性）	セキュリティ	パスワードは暗号化して保存
+	その他	保守性・移植性など	将来の機能追加がしやすい設計

システム要件を整理する「5W1H」アプローチ

Who（誰が）    → 利用者は誰か？社内の経理部門だけ？外部のお客様も？
What（何を）   → どんな機能が必要か？
When（いつ）   → 納期・リリース時期は？
Where（どこで）→ PC？スマホ？特定の拠点のみ？
Why（なぜ）    → その機能が必要な業務上の理由は？
How much（いくら）→ 予算の上限は？

歴史と背景

1960〜70年代：コンピューターが大企業・官公庁に普及し始め、「何を作るか」を文書化する必要性が生まれる
1970年代：ソフトウェア工学の確立とともに「要件定義」というプロセスが体系化。ウォーターフォール開発の最初のフェーズとして定着
1984年：IEEE（米国電気電子学会）がソフトウェア要件仕様の標準規格 IEEE 830 を策定。要件の記述方法が標準化される
1990年代：インターネットの普及でシステムの利用者が「社内の専門家」から「一般ユーザー」に拡大。使いやすさ（非機能要件）の重要度が急上昇
2001年〜：アジャイル開発の台頭により「最初に全部決めなくていい」という考え方が広まる。ユーザーストーリーという形式で要件を小さく書く手法が普及
現在：DX推進・クラウド活用が加速し、ゼロから開発するのではなくSaaSを選定・カスタマイズするケースも増加。「このSaaSで業務要件をどこまで満たせるか」を評価する用途でも要件整理が必須になっている

要件定義との違いと発注プロセスの中での位置づけ

「要件」と「要件定義」は混同されがちですが、役割が違います。

用語	意味	誰が主役か
システム要件	「何が必要か」の内容そのもの	発注者（あなた）が整理する
要件定義	要件を整理・文書化するプロセス・作業	発注者＋開発会社が協力して行う
RFP（提案依頼書）	要件をまとめて開発会社に提示する文書	発注者が作成・配布する
仕様書	開発会社が要件をもとに技術的に落とし込んだ文書	開発会社が作成する

よくある落とし穴：「暗黙の要件」に注意

発注者が「当たり前すぎて書かなかった」要件を開発会社が実装しないことがあります。

❌ 書かなかったために起きたトラブルの例：
- 「スマホで使えること」を書かなかった → PCサイトしか作られなかった
- 「既存の会計システムと連携すること」を書かなかった → 手入力が必要になった
- 「1万件のデータを扱えること」を書かなかった → 100件で動作が重くなった

✅ 対策：
「業務の流れ」をそのまま書き出し、システムがサポートすべき全作業をリストアップする

規格番号	内容
IEEE 829	ソフトウェアテスト文書の標準（要件とテストの対応関係に影響）
ISO/IEC 25010	ソフトウェア品質モデルの国際規格。非機能要件の分類基準として広く参照される
ISO/IEC/IEEE 29148	システム・ソフトウェアエンジニアリングにおける要件プロセスの国際規格