要件定義
要件定義とは、顧客がシステム化したい業務内容をヒアリングし、実装すべき機能、必要な性能、セキュリティ要件、コンプライアンス対応などを明確に定義していく工程です。2026年現在、DX（デジタルトランスフォーメーション）はビジネスの標準となり、単なるIT化だけでなく、AIの活用、クラウドネイティブな設計、ゼロトラストセキュリティへの対応といった最新の技術視点を盛り込んだ要件定義が求められています。
顧客とシステム開発会社が合意した内容を「要件定義書」にまとめます。
この工程では「何が必要なのか」という要件を定義することを目的とし、それを「どのように設計・実装すべきか」は次の工程で検討します。
また、要件定義の手法は決まったものはなく、システム開発会社やプロジェクトの特性によってさまざまです。ウォーターフォール型開発では包括的な要件定義を先に完成させますが、アジャイル開発ではスプリント単位で要件を段階的に精緻化していくアプローチが一般的になっています。いずれにせよ、必ず押さえておくべき基本的なポイントがありますので、そこを中心に解説します。
要件定義のポイント
全体方針を決める
何のためにシステムを作るのか、といった「システム化目標」を定めます。
最初にプロジェクトの背景や基本方針を決定し、次にシステム化の範囲、利用するユーザーや外部インターフェイスの範囲などを決めていくのです。2026年では、クラウド移行による運用コスト削減、セキュリティ強化、生成AI機能の組み込みといった現代的な目標設定が一般的になっています。また、サステナビリティやESGへの対応も新たな要件となりつつあります。
業務要件を決める
業務要件とは、新しい業務のあり方や運用を定義したうえで、業務上実現すべき条件や環境のことです。
通常は現行の業務を分析したうえで、システム化する範囲を決めていきます。リモートワーク・ハイブリッド対応、マルチデバイス対応（スマートフォン、タブレット、PC）、グローバル展開への対応、24時間監視対応といった2026年の業務環境に適応した要件定義が重要です。特にリモートファースト企業では、ユーザー認証、データ保護、ネットワークセキュリティが必須要件となっています。
機能要件
機能要件とは業務においてそのシステムやソフトウェアで何ができるのかをまとめたものです。
扱うデータの種類や構造、処理内容、画面表示や操作の方法、帳票などの出力の形式などが含まれます。現代では、REST API・GraphQLによる外部システム連携、リアルタイムデータ処理（WebSocketやServer-Sent Events）、モバイルアプリとの同期、生成AIやLLMを活用したデータ分析・予測機能、機械学習パイプラインも機能要件として明記されることが一般的になっています。
非機能要件
非機能要件とは機能面以外のシステム要件をまとめたものです。
性能や信頼性、拡張性、運用性、セキュリティなどに関する要件が含まれます。2026年では、個人情報保護法（APPI）やGDPRなどの法令対応、クラウドネイティブアーキテクチャでの自動スケーリング対応、ゼロトラストセキュリティ（エンドツーエンド暗号化、多要素認証）、サイバーセキュリティ対策、災害復旧（DR）・事業継続計画（BCP）への対応が特に重要です。さらに、カーボンニュートラルやグリーンIT対応、アクセシビリティ（WCAG 2.1準拠など）も非機能要件として求められるようになっています。例えば「毎秒10万件のデータ処理を1秒以内に完了できること」「可用性99.99%（年間約52分のダウンタイム許容）を達成すること」「エンドツーエンド暗号化で全データを保護すること」「RPO15分、RTO1時間以内」といった具体的な要件を記載します。
これらをまとめたアウトプット資料が「要件定義書」となります。
要件定義で絶対やってはいけないこと
要件定義では顧客からの要望を１００％そのまま実現してはいけません。
これは肝に銘じておいてください。
顧客からの要望を１００％実現することが顧客満足度につながると勘違いされている人もいますが、それは違います。
なぜなら、顧客は自分たちの業務のプロではありますが、システム化やDXに関しては素人だからです。
顧客の求める要件をシステムに適用したときに、どのような効果があるか、それは技術的に実現可能な要件なのか、予算内に収まるのか、セキュリティリスクはないか、保守性は十分か、といったことをシステムのプロであるシステムエンジニアが判断して最善の提案をしていくことが大切なのです。
要件定義工程では顧客からシステム化したい業務要件がたくさん出てきます。
そのなかで、たとえば費用対効果の面で不要と思われる要件や、明らかに実現不可能な要件については「この要件はなくてもいいのではないですか」とアドバイスすることも大切です。
できるものはできる、できないものはできないとはっきり宣言しなければなりません。
もちろん、できないものについては、その理由や根拠を丁寧に説明しなければなりませんし、場合によっては別の提案をする必要もあるでしょう。
また、顧客の要件にあがってなかったとしてもシステム化による効果が見込める部分があれば
「この機能ではSaaS型のクラウドサービスを導入すれば保守コストが削減でき、最新のセキュリティ対応も自動で実現できますよ。」
とか
「ここはGraphQL APIで既存システムと統合すれば、追加開発なく対応できて時間短縮が期待できますね。弊社で実装いたします。」
などといった提案をすることもできるようになれば、さらに顧客から信頼されるエンジニアになることができるでしょう。
このようにシステムエンジニアはシステムへの投資効果を最大化させるよう努める必要があります。
そのためにも顧客のいいなりになるだけではいけないのです。
顧客満足度
要件定義工程での顧客満足度は以下の式で表すことが出来ます。
「顧客満足度 ＝ システム化提案 − 顧客の期待値(要件)」
顧客の期待値(要件)が１００％でシステム化提案が１００％、つまり顧客の要望をそのまま１００％かなえた場合、顧客満足度は０になるのです。
期待しているものが出てくるのは、顧客にとっては当たり前だからです。
そのため、顧客の期待値を上回るシステム化提案をすることで顧客満足度を上げる必要があります。
これは機能をふんだんに盛り込んだ豪華絢爛なシステムを提案するということではありません。
たとえば最新のクラウドプラットフォーム（AWS、Azure、Google Cloud等）を戦略的に活用することで開発工数を抑えて納期を短くする提案をしたり、DevOps環境により継続的インテグレーション・デプロイメント（CI/CD）を実現してリリースサイクルを高速化する提案をしたり、コンテナ化（Docker、Kubernetes）により本番環境での信頼性を向上させる提案をしたり、逆にシステム開発費用が多少増えたとしても投資するコスト以上のリターンが見込めるシステムを提案できれば、顧客満足度を上げることができます。
このようにシステムエンジニアとしてベストプラクティスに基づいた最適な提案が出来れば、システム開発側にとっても利益になることが分かると思います。
いわゆる「win - win」の関係が成り立つということです。
■次の記事
外部設計
■おすすめ記事
プログラミング未経験から正社員へ！
IT就職支援付きプログラミングスクールランキング
プログラミングスクール【無料／有料】の選び方＆おすすめスクールを３つずつ紹介
ITエンジニアのキャリアアップを検討しているなら
PR
