[{"data":1,"prerenderedAt":1012},["ShallowReactive",2],{"article-\u002Farticles\u002Fyoken-teigisho-kakikata-kinou-hikinou":3,"article-series-yoken-teigi":993},{"_path":4,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"title":8,"description":9,"date":10,"category":11,"author":12,"thumbnail":13,"series":14,"seriesNo":15,"seriesLabel":16,"tags":17,"faq":21,"body":34,"_type":987,"_id":988,"_source":989,"_file":990,"_stem":991,"_extension":992},"\u002Farticles\u002Fyoken-teigisho-kakikata-kinou-hikinou","articles",false,"","要件定義書に書くこと｜ビジネス要件とシステム要件（機能要件・非機能要件）の違いと、要件定義の4ステップ","要件定義は「何を作るかを決める」工程で、発注側と開発側の両方が関わる唯一の工程です。企画構想・要求定義との関係、発注側が担うビジネス要件と開発側が担うシステム要件の二層、要件定義の4ステップ、抜けやすい非機能要件の観点、効果的な要件定義の3つの戦略と変更管理を、発注側の視点で図解つきに解説します。","2026-10-07","要件定義","K.S.ロジャース株式会社","\u002Fimg\u002Fcontents\u002Fnews\u002Fthumb140.jpg","yoken-teigi",4,"第4回",[11,18,19,20],"要件定義書","非機能要件","システム開発",[22,25,28,31],{"q":23,"a":24},"要件定義とは何をする工程ですか？","一言でいうと「何を作るかを決める」工程です。要求定義で言葉にした「何を求めているか」を、システムが満たすべき条件（機能・性能・データ・運用など）に落とし、要件定義書として文書化します。ここが曖昧なまま進むと、設計・実装・テストのすべてが曖昧になります。",{"q":26,"a":27},"要件定義書には何を書きますか？","大きく二層です。ビジネス要件として、企画の要望、要求仕様書の内容、現状（As-Is）とあるべき姿（To-Be）を書きます。システム要件として、機能要件、非機能要件、外部システムとの連携、データの構造、運用の設計を書きます。前者は発注側が主に決め、後者は開発側が主に決めます。",{"q":29,"a":30},"機能要件と非機能要件の違いは何ですか？","機能要件は「何ができるか」、非機能要件は「どのくらいちゃんと動くか」です。応答速度や同時利用者数などの性能、止まってよい時間などの可用性、認証や権限などのセキュリティ、監視やバックアップなどの運用・保守、使いやすさ、拡張性が非機能要件にあたります。抜けやすい一方で、あとから直しにくいため、要件定義の段階で数字を伴って決めておく必要があります。",{"q":32,"a":33},"要件定義の途中で要件が変わったらどうすればよいですか？","変更が起きること自体は自然です。問題なのは、変更が正式な手続きを通らずに口頭で積み重なることです。変更が出たら、影響（費用・期間・他の要件）を評価し、採否を決め、記録して関係者に通知する、という変更管理の流れを、要件定義の最初に決めておきます。",{"type":35,"children":36,"toc":961},"root",[37,62,75,82,87,99,104,128,133,149,168,173,218,223,235,251,258,263,268,274,279,331,336,341,346,351,367,411,423,428,433,438,453,458,521,526,538,543,548,564,570,575,581,586,592,604,615,621,626,642,647,652,657,663,668,674,679,685,690,696,707,719,724,764,770,784,891,896,933],{"type":38,"tag":39,"props":40,"children":41},"element","p",{},[42,45,52,54,60],{"type":43,"value":44},"text","要求仕様書ができたら、いよいよ要件定義です。要件定義は、",{"type":38,"tag":46,"props":47,"children":49},"a",{"href":48},"\u002Farticles\u002Fyoken-teigi-hacchu-kaihatsu-yakuwari\u002F",[50],{"type":43,"value":51},"第1回",{"type":43,"value":53},"で整理した工程の中で、",{"type":38,"tag":55,"props":56,"children":57},"strong",{},[58],{"type":43,"value":59},"発注側と開発側のどちらか一方に任せられない唯一の工程",{"type":43,"value":61},"です。発注側が「何を求めているか」を持ち込み、開発側が「システムとして何を満たせばよいか」に翻訳し、すり合わせながら決めていきます。",{"type":38,"tag":39,"props":63,"children":64},{},[65,67,73],{"type":43,"value":66},"本記事はシリーズ「発注側のための要件定義」の第4回として、要件定義書に何を書くのか、そのために何をするのかを、発注側の視点で解説します。要件定義の進め方そのものは",{"type":38,"tag":46,"props":68,"children":70},{"href":69},"\u002Farticles\u002Fyoken-teigi-susumekata\u002F",[71],{"type":43,"value":72},"全体像の記事",{"type":43,"value":74},"で扱っているので、この回では「文書に何が入っていれば要件定義と言えるのか」に焦点を当てます。",{"type":38,"tag":76,"props":77,"children":79},"h2",{"id":78},"要件定義とは-何を作るかを決めること",[80],{"type":43,"value":81},"要件定義とは ――「何を作るか」を決めること",{"type":38,"tag":39,"props":83,"children":84},{},[85],{"type":43,"value":86},"要件定義は、システムやソフトウェアの開発・導入にあたって、どのような機能や性能が必要かを明確にする作業です。システムが満たすべき条件を定義し、その基準を明確にすることで、開発の進め方と、導入後に「できた」と判断する基準を確立します。",{"type":38,"tag":39,"props":88,"children":89},{},[90,92,97],{"type":43,"value":91},"要は、",{"type":38,"tag":55,"props":93,"children":94},{},[95],{"type":43,"value":96},"何を作るかを決める",{"type":43,"value":98},"ということです。",{"type":38,"tag":39,"props":100,"children":101},{},[102],{"type":43,"value":103},"システム開発の中で「何を作るか」を決めることは、最も重要な工程です。ウォーターフォール型でもアジャイル型でも、要件定義はシステム開発の出発点であり、ここがうやむやなまま進むと、後の工程がすべてぐだぐだになります。",{"type":38,"tag":105,"props":106,"children":107},"picture",{},[108,110,118,119],{"type":43,"value":109},"\n  ",{"type":38,"tag":111,"props":112,"children":117},"source",{"media":113,"srcSet":114,"width":115,"height":116},"(max-width: 768px)","\u002Fimg\u002Fcontents\u002Farticles\u002Fyoken-teigisho-kakikata-kinou-hikinou\u002Fkaihatsu-lifecycle-sp.svg",420,496,[],{"type":43,"value":109},{"type":38,"tag":120,"props":121,"children":127},"img",{"src":122,"alt":123,"width":124,"height":125,"loading":126},"\u002Fimg\u002Fcontents\u002Farticles\u002Fyoken-teigisho-kakikata-kinou-hikinou\u002Fkaihatsu-lifecycle.svg","システム開発のライフサイクル。要件定義→設計→開発→テスト→リリース→運用・保守と進み、運用で見えた課題が次の要件定義につながって回り続ける。要件定義がすべての出発点で、ここで決めたことが設計・開発・テストにそのまま引き継がれる。リリースして終わりではない。要件定義のずれは、運用に入ってから直すのが一番高くつく",800,350,"lazy",[],{"type":38,"tag":39,"props":129,"children":130},{},[131],{"type":43,"value":132},"システム開発は、要件定義→設計→開発→テスト→リリース→運用・保守と進み、運用の中で見えてきた課題が次の要件定義につながる、というサイクルで回り続けます。要件定義はこのサイクルの出発点です。ここで決めたことは設計・開発・テストにそのまま引き継がれるので、最初のずれは後の工程で直すほど高くつきます。",{"type":38,"tag":105,"props":134,"children":135},{},[136,137,142,143],{"type":43,"value":109},{"type":38,"tag":111,"props":138,"children":141},{"media":113,"srcSet":139,"width":115,"height":140},"\u002Fimg\u002Fcontents\u002Farticles\u002Fyoken-teigisho-kakikata-kinou-hikinou\u002Fkikaku-yokyu-yoken-sp.svg",568,[],{"type":43,"value":109},{"type":38,"tag":120,"props":144,"children":148},{"src":145,"alt":146,"width":124,"height":147,"loading":126},"\u002Fimg\u002Fcontents\u002Farticles\u002Fyoken-teigisho-kakikata-kinou-hikinou\u002Fkikaku-yokyu-yoken.svg","企画構想・要求定義・要件定義の関係。企画構想は発注側が主で、プロジェクト化・体制構築・計画立案を行い企画書を作る。要求定義は発注側が主で、現状把握と問題抽出・要求分析・要求の文書化を行い要求仕様書を作る。要件定義は両者で握り、要件の抽出・仕様の検討・要件の文書化を行い要件定義書を作る。左から右へ、同じ「やりたいこと」がだんだん具体的になる",250,[],{"type":38,"tag":39,"props":150,"children":151},{},[152,158,160,166],{"type":38,"tag":46,"props":153,"children":155},{"href":154},"\u002Farticles\u002Fsystem-kaihatsu-kikakusho-tsukurikata\u002F",[156],{"type":43,"value":157},"企画",{"type":43,"value":159},"で「なぜやるのか」を決め、",{"type":38,"tag":46,"props":161,"children":163},{"href":162},"\u002Farticles\u002Fyokyu-teigi-susumekata-yokyu-shiyosho\u002F",[164],{"type":43,"value":165},"要求定義",{"type":43,"value":167},"で「何を求めているのか」を言葉にし、要件定義で「システムが何を満たせばよいか」を決める。同じ「やりたいこと」が、工程を経るごとに具体的になっていきます。",{"type":38,"tag":39,"props":169,"children":170},{},[171],{"type":43,"value":172},"要件定義の目的を整理すると、次の4つになります。",{"type":38,"tag":174,"props":175,"children":176},"ul",{},[177,188,198,208],{"type":38,"tag":178,"props":179,"children":180},"li",{},[181,186],{"type":38,"tag":55,"props":182,"children":183},{},[184],{"type":43,"value":185},"プロジェクトの土台を築く",{"type":43,"value":187},"：ここで要件を正確に定義することで、方向性が定まり、後の開発作業がスムーズに進みます",{"type":38,"tag":178,"props":189,"children":190},{},[191,196],{"type":38,"tag":55,"props":192,"children":193},{},[194],{"type":43,"value":195},"範囲と目標を決める",{"type":43,"value":197},"：プロジェクトで達成すべき目標と、必要な機能・非機能要件が明確になります",{"type":38,"tag":178,"props":199,"children":200},{},[201,206],{"type":38,"tag":55,"props":202,"children":203},{},[204],{"type":43,"value":205},"関係者の期待を一致させる",{"type":43,"value":207},"：関係者の期待を集めて分析し、全員が同じ目標に向かえるようにします",{"type":38,"tag":178,"props":209,"children":210},{},[211,216],{"type":38,"tag":55,"props":212,"children":213},{},[214],{"type":43,"value":215},"後の工程での誤解を防ぐ",{"type":43,"value":217},"：要件が明確なほど、開発の各段階での誤解が減り、変更要求の数が減って、遅延とコスト増加を防げます",{"type":38,"tag":76,"props":219,"children":221},{"id":220},"要件定義書は二層でできている",[222],{"type":43,"value":220},{"type":38,"tag":39,"props":224,"children":225},{},[226,228,233],{"type":43,"value":227},"要件定義書に何を書くかを考えるとき、",{"type":38,"tag":55,"props":229,"children":230},{},[231],{"type":43,"value":232},"ビジネス要件とシステム要件の二層",{"type":43,"value":234},"で捉えると整理しやすくなります。",{"type":38,"tag":105,"props":236,"children":237},{},[238,239,244,245],{"type":43,"value":109},{"type":38,"tag":111,"props":240,"children":243},{"media":113,"srcSet":241,"width":115,"height":242},"\u002Fimg\u002Fcontents\u002Farticles\u002Fyoken-teigisho-kakikata-kinou-hikinou\u002Fbusiness-system-yoken-sp.svg",470,[],{"type":43,"value":109},{"type":38,"tag":120,"props":246,"children":250},{"src":247,"alt":248,"width":124,"height":249,"loading":126},"\u002Fimg\u002Fcontents\u002Farticles\u002Fyoken-teigisho-kakikata-kinou-hikinou\u002Fbusiness-system-yoken.svg","要件定義の二層。上の層はビジネス要件で発注側が主に決める：企画の要望、要求仕様書、現状（As-Is）、あるべき姿（To-Be）。下の層はシステム要件で開発側が主に決める：機能要件、非機能要件、外部連携、データ構造、運用設計。二層は要件定義書で一つに結ぶ",270,[],{"type":38,"tag":252,"props":253,"children":255},"h3",{"id":254},"ビジネス要件-発注側が主に決める",[256],{"type":43,"value":257},"ビジネス要件 ―― 発注側が主に決める",{"type":38,"tag":39,"props":259,"children":260},{},[261],{"type":43,"value":262},"企画の要望と要求仕様書の内容を土台に、業務の現状（As-Is）と、あるべき姿（To-Be）を書きます。「今はこう回っていて、ここに問題がある。システムが入ったあとはこう回る」という、業務の変化を描く層です。",{"type":38,"tag":39,"props":264,"children":265},{},[266],{"type":43,"value":267},"ここは発注側にしか書けません。開発側は業務の現状を知りませんし、あるべき姿を決める権限もありません。要求仕様書がしっかりしていれば、この層の多くは要求仕様書から引き継げます。",{"type":38,"tag":252,"props":269,"children":271},{"id":270},"システム要件-開発側が主に決める",[272],{"type":43,"value":273},"システム要件 ―― 開発側が主に決める",{"type":38,"tag":39,"props":275,"children":276},{},[277],{"type":43,"value":278},"ビジネス要件を受けて、システムとして何を満たすかを書きます。",{"type":38,"tag":174,"props":280,"children":281},{},[282,292,301,311,321],{"type":38,"tag":178,"props":283,"children":284},{},[285,290],{"type":38,"tag":55,"props":286,"children":287},{},[288],{"type":43,"value":289},"機能要件",{"type":43,"value":291},"：システムが提供する具体的な機能そのものです。確実に実装する必要があります",{"type":38,"tag":178,"props":293,"children":294},{},[295,299],{"type":38,"tag":55,"props":296,"children":297},{},[298],{"type":43,"value":19},{"type":43,"value":300},"：機能以外で求められる要件です。性能やセキュリティなど、後述します",{"type":38,"tag":178,"props":302,"children":303},{},[304,309],{"type":38,"tag":55,"props":305,"children":306},{},[307],{"type":43,"value":308},"外部連携",{"type":43,"value":310},"：既存のシステムや外部サービスと、何をどう受け渡すか",{"type":38,"tag":178,"props":312,"children":313},{},[314,319],{"type":38,"tag":55,"props":315,"children":316},{},[317],{"type":43,"value":318},"データ構造",{"type":43,"value":320},"：どんなデータを、どんな形で持つか",{"type":38,"tag":178,"props":322,"children":323},{},[324,329],{"type":38,"tag":55,"props":325,"children":326},{},[327],{"type":43,"value":328},"運用設計",{"type":43,"value":330},"：稼働後に、誰が、何を、どう運用するか",{"type":38,"tag":39,"props":332,"children":333},{},[334],{"type":43,"value":335},"この層は開発側が主に書きますが、発注側は「それで業務が回るか」を確認する役割を持ちます。特に運用設計は、発注側の業務に直結するので、開発側に任せきりにせず、内容を理解しておく必要があります。",{"type":38,"tag":39,"props":337,"children":338},{},[339],{"type":43,"value":340},"二層は、要件定義書という一つの文書で結ばれます。ビジネス要件のどの項目が、システム要件のどの項目で実現されるのかが追えるようになっていれば、要件定義書として機能します。",{"type":38,"tag":76,"props":342,"children":344},{"id":343},"要件定義の4ステップ",[345],{"type":43,"value":343},{"type":38,"tag":39,"props":347,"children":348},{},[349],{"type":43,"value":350},"要件定義は、次の4ステップで進みます。要求定義の4ステップと似ていますが、扱うものが「要求」から「要件」に変わり、開発側の関わりが深くなります。",{"type":38,"tag":105,"props":352,"children":353},{},[354,355,360,361],{"type":43,"value":109},{"type":38,"tag":111,"props":356,"children":359},{"media":113,"srcSet":357,"width":115,"height":358},"\u002Fimg\u002Fcontents\u002Farticles\u002Fyoken-teigisho-kakikata-kinou-hikinou\u002Fyoken-teigi-steps-sp.svg",564,[],{"type":43,"value":109},{"type":38,"tag":120,"props":362,"children":366},{"src":363,"alt":364,"width":124,"height":365,"loading":126},"\u002Fimg\u002Fcontents\u002Farticles\u002Fyoken-teigisho-kakikata-kinou-hikinou\u002Fyoken-teigi-steps.svg","要件定義の4ステップ。1 要件の収集（要求仕様書の確認、期待と得たい結果の確認）、2 要件の分析（整合性・実現性の確認、コストと期間、範囲の決定）、3 仕様の検討（優先順位と矛盾の解決、機能／非機能に分類）、4 仕様化（要件定義書の作成と合意、変更管理の取り決め）。「最終的に何が得たいのか」を両者が常に意識して進める",220,[],{"type":38,"tag":368,"props":369,"children":370},"ol",{},[371,381,391,401],{"type":38,"tag":178,"props":372,"children":373},{},[374,379],{"type":38,"tag":55,"props":375,"children":376},{},[377],{"type":43,"value":378},"要件の収集",{"type":43,"value":380},"：要求仕様書をもとに、発注側の期待と「最終的に得たい結果」を開発側が確認します。発注側は、要求の背景にある目的を伝えます。",{"type":38,"tag":178,"props":382,"children":383},{},[384,389],{"type":38,"tag":55,"props":385,"children":386},{},[387],{"type":43,"value":388},"要件の分析",{"type":43,"value":390},"：要求同士の整合性を確認し、技術的に実現できるか、費用と期間はどのくらいか、どこまでを範囲にするかを検討します。",{"type":38,"tag":178,"props":392,"children":393},{},[394,399],{"type":38,"tag":55,"props":395,"children":396},{},[397],{"type":43,"value":398},"仕様の検討",{"type":43,"value":400},"：優先順位をつけ、競合する要求の矛盾を解決し、機能要件と非機能要件に分類します。",{"type":38,"tag":178,"props":402,"children":403},{},[404,409],{"type":38,"tag":55,"props":405,"children":406},{},[407],{"type":43,"value":408},"仕様化",{"type":43,"value":410},"：要件定義書を作成し、関係者の合意を取ります。あわせて、要件が変わったときの変更管理の方法を取り決めます。",{"type":38,"tag":39,"props":412,"children":413},{},[414,416,421],{"type":43,"value":415},"このステップを通じて大切なのは、発注側と開発側が多くのコミュニケーションを取り、協力しながら進めることです。",{"type":38,"tag":55,"props":417,"children":418},{},[419],{"type":43,"value":420},"「最終的に何が得たいのか」を常に意識して、お互いの理解を深めていく",{"type":43,"value":422},"ことが成功の要です。",{"type":38,"tag":39,"props":424,"children":425},{},[426],{"type":43,"value":427},"発注側の立場で言えば、開発側から「この要件はどちらにしますか」「この機能はなくても目的は達成できますか」と聞かれたときに、目的に照らして即答できる状態を作っておくことが、この工程での役割です。",{"type":38,"tag":76,"props":429,"children":431},{"id":430},"抜けやすい非機能要件",[432],{"type":43,"value":430},{"type":38,"tag":39,"props":434,"children":435},{},[436],{"type":43,"value":437},"システム要件の中で、発注側が最も見落としやすく、しかも後から直しにくいのが非機能要件です。",{"type":38,"tag":105,"props":439,"children":440},{},[441,442,447,448],{"type":43,"value":109},{"type":38,"tag":111,"props":443,"children":446},{"media":113,"srcSet":444,"width":115,"height":445},"\u002Fimg\u002Fcontents\u002Farticles\u002Fyoken-teigisho-kakikata-kinou-hikinou\u002Fhikinou-yoken-sp.svg",490,[],{"type":43,"value":109},{"type":38,"tag":120,"props":449,"children":452},{"src":450,"alt":451,"width":124,"height":147,"loading":126},"\u002Fimg\u002Fcontents\u002Farticles\u002Fyoken-teigisho-kakikata-kinou-hikinou\u002Fhikinou-yoken.svg","機能要件は「何ができるか」、非機能要件は「どのくらいちゃんと動くか」で、抜けやすいがあとから直しにくい。非機能要件の主な観点：性能（応答速度・同時利用者数）、可用性（止まってよい時間・復旧の速さ）、セキュリティ（認証・権限・操作ログ）、運用・保守（監視・バックアップ・更新の手順）、使いやすさ（操作性・アクセシビリティ）、拡張性（利用者の増加・機能の追加）。「速く」ではなく「3秒以内」のように数字で書く",[],{"type":38,"tag":39,"props":454,"children":455},{},[456],{"type":43,"value":457},"機能要件が「何ができるか」だとすれば、非機能要件は「どのくらいちゃんと動くか」です。主な観点は次のとおりです。",{"type":38,"tag":174,"props":459,"children":460},{},[461,471,481,491,501,511],{"type":38,"tag":178,"props":462,"children":463},{},[464,469],{"type":38,"tag":55,"props":465,"children":466},{},[467],{"type":43,"value":468},"性能",{"type":43,"value":470},"：画面の応答速度、同時に使う人数、処理できるデータ量",{"type":38,"tag":178,"props":472,"children":473},{},[474,479],{"type":38,"tag":55,"props":475,"children":476},{},[477],{"type":43,"value":478},"可用性",{"type":43,"value":480},"：止まってよい時間、障害からの復旧の速さ",{"type":38,"tag":178,"props":482,"children":483},{},[484,489],{"type":38,"tag":55,"props":485,"children":486},{},[487],{"type":43,"value":488},"セキュリティ",{"type":43,"value":490},"：認証の方法、誰が何を見られるかの権限、操作の記録",{"type":38,"tag":178,"props":492,"children":493},{},[494,499],{"type":38,"tag":55,"props":495,"children":496},{},[497],{"type":43,"value":498},"運用・保守",{"type":43,"value":500},"：監視、バックアップ、更新の手順と頻度",{"type":38,"tag":178,"props":502,"children":503},{},[504,509],{"type":38,"tag":55,"props":505,"children":506},{},[507],{"type":43,"value":508},"使いやすさ",{"type":43,"value":510},"：操作性、アクセシビリティ、教育なしで使えるか",{"type":38,"tag":178,"props":512,"children":513},{},[514,519],{"type":38,"tag":55,"props":515,"children":516},{},[517],{"type":43,"value":518},"拡張性",{"type":43,"value":520},"：利用者が増えたとき、機能を足すときに耐えられるか",{"type":38,"tag":39,"props":522,"children":523},{},[524],{"type":43,"value":525},"非機能要件は、案外エンジニアも意識が抜けがちです。機能の話は具体的で盛り上がるのに対し、「何秒以内」「何人まで」といった話は地味だからです。しかし、リリース後に「遅い」「落ちる」「セキュリティ監査で指摘された」となったとき、直すのは機能の追加より大変です。",{"type":38,"tag":39,"props":527,"children":528},{},[529,531,536],{"type":43,"value":530},"発注側が意識すべきことは、",{"type":38,"tag":55,"props":532,"children":533},{},[534],{"type":43,"value":535},"非機能要件を数字で書く",{"type":43,"value":537},"ことです。「速く」ではなく「一覧画面は3秒以内に表示」、「止まらない」ではなく「計画停止は月に計2時間まで」のように書きます。数字が分からなければ、「今の業務ではどのくらいで困るか」から逆算し、開発側と相談して決めます。",{"type":38,"tag":76,"props":539,"children":541},{"id":540},"効果的な要件定義のための3つの戦略",[542],{"type":43,"value":540},{"type":38,"tag":39,"props":544,"children":545},{},[546],{"type":43,"value":547},"要件定義の質を高めるために、K.S.Rogers が重視している戦略を3つ挙げます。",{"type":38,"tag":105,"props":549,"children":550},{},[551,552,557,558],{"type":43,"value":109},{"type":38,"tag":111,"props":553,"children":556},{"media":113,"srcSet":554,"width":115,"height":555},"\u002Fimg\u002Fcontents\u002Farticles\u002Fyoken-teigisho-kakikata-kinou-hikinou\u002Fyoken-3senryaku-sp.svg",484,[],{"type":43,"value":109},{"type":38,"tag":120,"props":559,"children":563},{"src":560,"alt":561,"width":124,"height":562,"loading":126},"\u002Fimg\u002Fcontents\u002Farticles\u002Fyoken-teigisho-kakikata-kinou-hikinou\u002Fyoken-3senryaku.svg","効果的な要件定義の3つの戦略。1 コミュニケーション（定期的なミーティング、開かれた連絡経路）で誤解を早く見つける。2 明確性と一貫性（分かりやすい文書化、図表やモデルの活用）で全員が同じ理解を持つ。3 柔軟性（変更管理の仕組み、迅速な評価と反映）で変化に振り回されない",180,[],{"type":38,"tag":252,"props":565,"children":567},{"id":566},"_1-コミュニケーション-誤解を早く見つける",[568],{"type":43,"value":569},"1. コミュニケーション ―― 誤解を早く見つける",{"type":38,"tag":39,"props":571,"children":572},{},[573],{"type":43,"value":574},"関係者との定期的なコミュニケーションは、誤解を避け、要件を正確に理解し合うために欠かせません。定期的なミーティングと進捗の報告、フィードバックの場を設け、開かれた連絡経路を確保します。要件定義の誤解は、見つかるのが遅いほど高くつきます。",{"type":38,"tag":252,"props":576,"children":578},{"id":577},"_2-明確性と一貫性-全員が同じ理解を持つ",[579],{"type":43,"value":580},"2. 明確性と一貫性 ―― 全員が同じ理解を持つ",{"type":38,"tag":39,"props":582,"children":583},{},[584],{"type":43,"value":585},"要件を明確かつ一貫した形で文書化することで、全員が同じ理解を共有し、将来の混乱を防ぎます。文書化する際は、明瞭で理解しやすい言葉を使い、必要に応じて図表やモデルで説明します。発注側が読んで分からない要件定義書は、発注側が確認できないという意味で、要件定義書として不十分です。",{"type":38,"tag":252,"props":587,"children":589},{"id":588},"_3-柔軟性-変化に振り回されない",[590],{"type":43,"value":591},"3. 柔軟性 ―― 変化に振り回されない",{"type":38,"tag":39,"props":593,"children":594},{},[595,597,602],{"type":43,"value":596},"プロジェクトは動く環境の中で進むので、新しい情報や変更要求に対応できる力が求められます。ただし、柔軟に対応することと、なし崩しに変わることは違います。",{"type":38,"tag":55,"props":598,"children":599},{},[600],{"type":43,"value":601},"変更管理の仕組みを確立し、新たな要求や情報が出たときには迅速に評価して、適切に要件に反映させる",{"type":43,"value":603},"、という手続きを最初に決めておきます。",{"type":38,"tag":39,"props":605,"children":606},{},[607,609,613],{"type":43,"value":608},"変更管理の基本は、変更が出たら「影響（費用・期間・他の要件）を評価する → 採否を決める → 記録して関係者に通知する」の3つです。誰が採否を決めるのかは、",{"type":38,"tag":46,"props":610,"children":611},{"href":48},[612],{"type":43,"value":51},{"type":43,"value":614},"で決めたプロジェクトオーナーとPMの役割に従います。",{"type":38,"tag":76,"props":616,"children":618},{"id":617},"要件定義の後開発はどう進むか",[619],{"type":43,"value":620},"要件定義の後、開発はどう進むか",{"type":38,"tag":39,"props":622,"children":623},{},[624],{"type":43,"value":625},"発注側と開発側が力を合わせて要件定義をした後は、開発側が要件に基づいて設計と実装を行い、それぞれのテストを実施します。実装が終わるとシステムテストが始まり、それが進むと受入テストが始まります。",{"type":38,"tag":105,"props":627,"children":628},{},[629,630,635,636],{"type":43,"value":109},{"type":38,"tag":111,"props":631,"children":634},{"media":113,"srcSet":632,"width":115,"height":633},"\u002Fimg\u002Fcontents\u002Farticles\u002Fyoken-teigisho-kakikata-kinou-hikinou\u002Fkaihatsu-flow-test-sp.svg",486,[],{"type":43,"value":109},{"type":38,"tag":120,"props":637,"children":641},{"src":638,"alt":639,"width":124,"height":640,"loading":126},"\u002Fimg\u002Fcontents\u002Farticles\u002Fyoken-teigisho-kakikata-kinou-hikinou\u002Fkaihatsu-flow-test.svg","システム開発の基本的な流れとテストの位置づけ。要件定義（発注側と開発側で）→設計（基本設計・詳細設計）→開発（実装）→テスト→リリース→運用・保守。テストは単体テスト・結合テスト・システムテスト（開発側）の後に受入テスト（発注側が主役）。要件定義書が、そのまま受入テストの合否基準になる。設計・開発・テストは開発側が進め、受入テストで発注側が主役に戻る。ウォーターフォール型を例にした流れ",290,[],{"type":38,"tag":39,"props":643,"children":644},{},[645],{"type":43,"value":646},"要件定義書は、この後の工程すべての基準になります。設計は要件定義書に基づいて行われ、テストは「要件定義書に書かれた条件を満たしているか」で合否が決まります。だからこそ、要件定義書に書かれていないことは、作られませんし、テストもされません。発注側が「当然入っていると思っていた」ことは、書かれていなければ入りません。",{"type":38,"tag":39,"props":648,"children":649},{},[650],{"type":43,"value":651},"受入テストは、発注側が再び主役になる工程です。要件定義書に書いた条件が、業務で使える形で満たされているかを、発注側が確認します。",{"type":38,"tag":76,"props":653,"children":655},{"id":654},"要件定義でよくあるつまずき",[656],{"type":43,"value":654},{"type":38,"tag":252,"props":658,"children":660},{"id":659},"_1-要件定義書が開発側の言葉だけで書かれている",[661],{"type":43,"value":662},"1. 要件定義書が開発側の言葉だけで書かれている",{"type":38,"tag":39,"props":664,"children":665},{},[666],{"type":43,"value":667},"システム要件が専門用語で書かれ、発注側が内容を確認できないケースです。確認できないものに合意しても、あとで「そういう意味だとは思わなかった」が起きます。発注側が読んで分かる言葉と図で書いてもらうか、開発側に説明を求めて理解してから合意します。",{"type":38,"tag":252,"props":669,"children":671},{"id":670},"_2-非機能要件が一般的な水準でになっている",[672],{"type":43,"value":673},"2. 非機能要件が「一般的な水準で」になっている",{"type":38,"tag":39,"props":675,"children":676},{},[677],{"type":43,"value":678},"「性能は一般的な水準で」「セキュリティは適切に」のように、数字のない非機能要件です。何をもって満たしたと言えるのかが決まっていないので、テストのしようがなく、リリース後に揉めます。前述のとおり、数字で書きます。",{"type":38,"tag":252,"props":680,"children":682},{"id":681},"_3-変更が口頭で積み重なる",[683],{"type":43,"value":684},"3. 変更が口頭で積み重なる",{"type":38,"tag":39,"props":686,"children":687},{},[688],{"type":43,"value":689},"打ち合わせのたびに「ついでにこれも」と要件が増え、記録も影響の評価もないまま進むケースです。開発側は善意で受けますが、費用と期間が膨らみ、最後に「聞いていない」と衝突します。変更は手続きを通す、と最初に決めておきます。",{"type":38,"tag":76,"props":691,"children":693},{"id":692},"支援の現場で見た要件定義書があることの意味",[694],{"type":43,"value":695},"支援の現場で見た、要件定義書があることの意味",{"type":38,"tag":39,"props":697,"children":698},{},[699,705],{"type":38,"tag":46,"props":700,"children":702},{"href":701},"\u002Frd\u002Fcase-studies\u002Fcase-study-5\u002F",[703],{"type":43,"value":704},"オンライン診療プロダクトの開発体制を立て直した事例",{"type":43,"value":706},"では、要件定義書がなく、プロダクトを実際に触らないと要件が分からない状態から支援を始めました。要件が文書になっていないと、開発側は判断の基準を持てず、発注側は確認のしようがありません。",{"type":38,"tag":39,"props":708,"children":709},{},[710,712,717],{"type":43,"value":711},"要件定義書は、作ること自体が目的ではなく、",{"type":38,"tag":55,"props":713,"children":714},{},[715],{"type":43,"value":716},"発注側と開発側が同じものを見て判断するための共通の基準",{"type":43,"value":718},"です。それがあるかないかで、その後の開発の進み方は大きく変わります。",{"type":38,"tag":76,"props":720,"children":722},{"id":721},"参考になる公的資料",[723],{"type":43,"value":721},{"type":38,"tag":174,"props":725,"children":726},{},[727,740,752],{"type":38,"tag":178,"props":728,"children":729},{},[730,738],{"type":38,"tag":46,"props":731,"children":735},{"href":732,"rel":733},"https:\u002F\u002Fwww.ipa.go.jp\u002Farchive\u002Fpublish\u002Ftn20191220.html",[734],"nofollow",[736],{"type":43,"value":737},"IPA「ユーザのための要件定義ガイド 第2版」",{"type":43,"value":739},"：要件定義で起きやすい問題と解決策が、発注側の視点で整理されています。非機能要件の考え方についても触れられています",{"type":38,"tag":178,"props":741,"children":742},{},[743,750],{"type":38,"tag":46,"props":744,"children":747},{"href":745,"rel":746},"https:\u002F\u002Fwww.ipa.go.jp\u002Farchive\u002Fdigital\u002Fiot-en-ci\u002Fjyouryuu\u002Fhikinou\u002Fent03-b.html",[734],[748],{"type":43,"value":749},"IPA「非機能要求グレード」",{"type":43,"value":751},"：可用性・性能・セキュリティなど非機能要件の項目と水準を、体系的に整理した資料です。「何を、どのくらいで決めればよいか」の網羅性を確認するのに使えます",{"type":38,"tag":178,"props":753,"children":754},{},[755,762],{"type":38,"tag":46,"props":756,"children":759},{"href":757,"rel":758},"https:\u002F\u002Fwww.ipa.go.jp\u002Fdigital\u002Fmodel\u002Fmodel20201222.html",[734],[760],{"type":43,"value":761},"IPA「情報システム・モデル取引・契約書（第二版）」",{"type":43,"value":763},"：要件定義の成果物と、その後の工程の契約上の位置づけを確認できます",{"type":38,"tag":76,"props":765,"children":767},{"id":766},"要件定義書の作成からご一緒します-ksrogers-の要件定義支援",[768],{"type":43,"value":769},"要件定義書の作成からご一緒します ―― K.S.Rogers の要件定義支援",{"type":38,"tag":39,"props":771,"children":772},{},[773,775,782],{"type":43,"value":774},"K.S.Rogers では「決まっていないところから一緒に考える」をコンセプトに、",{"type":38,"tag":46,"props":776,"children":779},{"href":777,"rel":778},"https:\u002F\u002Fks-rogers.co.jp\u002Frd\u002F",[734],[780],{"type":43,"value":781},"要件定義支援サービス",{"type":43,"value":783},"を提供しています。開発側との間に入り、発注側の言葉と開発側の言葉を翻訳しながら、要件定義書にまとめます。",{"type":38,"tag":785,"props":786,"children":787},"table",{},[788,817],{"type":38,"tag":789,"props":790,"children":791},"thead",{},[792],{"type":38,"tag":793,"props":794,"children":795},"tr",{},[796,802,807,812],{"type":38,"tag":797,"props":798,"children":799},"th",{},[800],{"type":43,"value":801},"プラン",{"type":38,"tag":797,"props":803,"children":804},{},[805],{"type":43,"value":806},"月額（税別）",{"type":38,"tag":797,"props":808,"children":809},{},[810],{"type":43,"value":811},"稼働の目安",{"type":38,"tag":797,"props":813,"children":814},{},[815],{"type":43,"value":816},"こんなときに",{"type":38,"tag":818,"props":819,"children":820},"tbody",{},[821,845,868],{"type":38,"tag":793,"props":822,"children":823},{},[824,830,835,840],{"type":38,"tag":825,"props":826,"children":827},"td",{},[828],{"type":43,"value":829},"相談・壁打ち",{"type":38,"tag":825,"props":831,"children":832},{},[833],{"type":43,"value":834},"10万円",{"type":38,"tag":825,"props":836,"children":837},{},[838],{"type":43,"value":839},"月8時間",{"type":38,"tag":825,"props":841,"children":842},{},[843],{"type":43,"value":844},"開発会社から届いた要件定義書を、第三者の目で確認してほしい",{"type":38,"tag":793,"props":846,"children":847},{},[848,853,858,863],{"type":38,"tag":825,"props":849,"children":850},{},[851],{"type":43,"value":852},"要件定義設計",{"type":38,"tag":825,"props":854,"children":855},{},[856],{"type":43,"value":857},"27万円",{"type":38,"tag":825,"props":859,"children":860},{},[861],{"type":43,"value":862},"月25時間",{"type":38,"tag":825,"props":864,"children":865},{},[866],{"type":43,"value":867},"要求仕様書から要件定義書の作成まで任せたい",{"type":38,"tag":793,"props":869,"children":870},{},[871,876,881,886],{"type":38,"tag":825,"props":872,"children":873},{},[874],{"type":43,"value":875},"プロジェクト推進",{"type":38,"tag":825,"props":877,"children":878},{},[879],{"type":43,"value":880},"50万円",{"type":38,"tag":825,"props":882,"children":883},{},[884],{"type":43,"value":885},"月50時間",{"type":38,"tag":825,"props":887,"children":888},{},[889],{"type":43,"value":890},"開発側との要件のすり合わせを含め、プロジェクトごと推進してほしい",{"type":38,"tag":76,"props":892,"children":894},{"id":893},"まとめ",[895],{"type":43,"value":893},{"type":38,"tag":174,"props":897,"children":898},{},[899,904,923,928],{"type":38,"tag":178,"props":900,"children":901},{},[902],{"type":43,"value":903},"要件定義は「何を作るかを決める」工程で、発注側と開発側の両方が関わります。ここが曖昧だと、後の工程がすべて曖昧になります",{"type":38,"tag":178,"props":905,"children":906},{},[907,909,914,916,921],{"type":43,"value":908},"要件定義書は、発注側が主に決める",{"type":38,"tag":55,"props":910,"children":911},{},[912],{"type":43,"value":913},"ビジネス要件",{"type":43,"value":915},"（要望・要求仕様・現状・あるべき姿）と、開発側が主に決める",{"type":38,"tag":55,"props":917,"children":918},{},[919],{"type":43,"value":920},"システム要件",{"type":43,"value":922},"（機能・非機能・外部連携・データ・運用）の二層で捉えます",{"type":38,"tag":178,"props":924,"children":925},{},[926],{"type":43,"value":927},"進め方は要件の収集 → 分析 → 仕様の検討 → 仕様化の4ステップです。「最終的に何が得たいのか」を常に意識します",{"type":38,"tag":178,"props":929,"children":930},{},[931],{"type":43,"value":932},"非機能要件は抜けやすく、あとから直しにくいので、数字で書きます。変更は手続きを通す、と最初に決めておきます",{"type":38,"tag":39,"props":934,"children":935},{},[936,938,944,946,951,953,959],{"type":43,"value":937},"次回は、要件定義書を基準に発注側が主役として行う",{"type":38,"tag":46,"props":939,"children":941},{"href":940},"\u002Farticles\u002Fukeire-test-susumekata-hacchugawa\u002F",[942],{"type":43,"value":943},"受入テストの進め方",{"type":43,"value":945},"を扱います。シリーズの全体像は",{"type":38,"tag":46,"props":947,"children":948},{"href":69},[949],{"type":43,"value":950},"要件定義の進め方",{"type":43,"value":952},"を、要件定義書について相談したい方は",{"type":38,"tag":46,"props":954,"children":956},{"href":955},"\u002Fcontact\u002F",[957],{"type":43,"value":958},"お問い合わせ",{"type":43,"value":960},"からお気軽にご連絡ください。",{"title":7,"searchDepth":962,"depth":962,"links":963},2,[964,965,970,971,972,977,978,983,984,985,986],{"id":78,"depth":962,"text":81},{"id":220,"depth":962,"text":220,"children":966},[967,969],{"id":254,"depth":968,"text":257},3,{"id":270,"depth":968,"text":273},{"id":343,"depth":962,"text":343},{"id":430,"depth":962,"text":430},{"id":540,"depth":962,"text":540,"children":973},[974,975,976],{"id":566,"depth":968,"text":569},{"id":577,"depth":968,"text":580},{"id":588,"depth":968,"text":591},{"id":617,"depth":962,"text":620},{"id":654,"depth":962,"text":654,"children":979},[980,981,982],{"id":659,"depth":968,"text":662},{"id":670,"depth":968,"text":673},{"id":681,"depth":968,"text":684},{"id":692,"depth":962,"text":695},{"id":721,"depth":962,"text":721},{"id":766,"depth":962,"text":769},{"id":893,"depth":962,"text":893},"markdown","content:articles:yoken-teigisho-kakikata-kinou-hikinou.md","content","articles\u002Fyoken-teigisho-kakikata-kinou-hikinou.md","articles\u002Fyoken-teigisho-kakikata-kinou-hikinou","md",[994,999,1003,1007,1011],{"_path":995,"title":996,"seriesNo":997,"seriesLabel":998},"\u002Farticles\u002Fyoken-teigi-susumekata","要件定義の進め方・やり方｜5ステップの流れと、難しい・失敗する原因を実務目線で解説",0,"全体像",{"_path":1000,"title":1001,"seriesNo":1002,"seriesLabel":51},"\u002Farticles\u002Fyoken-teigi-hacchu-kaihatsu-yakuwari","システム開発の発注側と開発側の役割分担｜要件定義の前に「誰が何を決めるか」を明確にする方法",1,{"_path":1004,"title":1005,"seriesNo":962,"seriesLabel":1006},"\u002Farticles\u002Fsystem-kaihatsu-kikakusho-tsukurikata","システム開発の企画書の作り方｜「システムありき」にしない現状分析と課題の抽出（3C・PEST・SWOT）","第2回",{"_path":1008,"title":1009,"seriesNo":968,"seriesLabel":1010},"\u002Farticles\u002Fyokyu-teigi-susumekata-yokyu-shiyosho","要求定義の進め方と要求仕様書の書き方｜要望・要求・要件の違いと、関係者の要求を集めて優先順位をつける4ステップ","第3回",{"_path":4,"title":8,"seriesNo":15,"seriesLabel":16},1791300125105]