[{"data":1,"prerenderedAt":896},["ShallowReactive",2],{"article-\u002Farticles\u002Fyokyu-teigi-susumekata-yokyu-shiyosho":3,"article-series-yoken-teigi":881},{"_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":875,"_id":876,"_source":877,"_file":878,"_stem":879,"_extension":880},"\u002Farticles\u002Fyokyu-teigi-susumekata-yokyu-shiyosho","articles",false,"","要求定義の進め方と要求仕様書の書き方｜要望・要求・要件の違いと、関係者の要求を集めて優先順位をつける4ステップ","要求定義は、企画で決めた目的をもとに「システムに何を求めているか」を言葉にする工程で、発注側が主役です。要望・要求・要件の違い（旅行計画の例）、関係者の選定・要求の収集・要求の分析・要求仕様書の4ステップ、効果と工数で優先順位をつける方法、要求仕様書に書く項目を、図解つきで解説します。","2026-10-05","要件定義","K.S.ロジャース株式会社","\u002Fimg\u002Fcontents\u002Fnews\u002Fthumb139.jpg","yoken-teigi",3,"第3回",[11,18,19,20],"要求定義","システム開発","要求仕様書",[22,25,28,31],{"q":23,"a":24},"要望・要求・要件はどう違いますか？","抽象度の違いです。要望は「旅行に行きたい」のような漠然とした願い、要求は「リゾートでゆっくりしたい、7泊以上」のように何を求めているかを言葉にしたもの、要件は「4つ星以上でダブルベッド」のように満たすべき条件まで具体化したものです。要求定義は要望を要求に整える工程、要件定義は要求を要件に落とす工程です。",{"q":26,"a":27},"要求定義は誰がやるのですか？","発注側が主役です。何を求めているかを知っているのは、業務を行い、成果に責任を持つ発注側だからです。ただし一方的に書いて渡すものではなく、技術的に可能かどうかや、実現の難しさを開発側に確認しながら進めます。",{"q":29,"a":30},"要求を集める関係者はどう選べばよいですか？","プロジェクトに影響を与える人と、影響を受ける人の両方を洗い出します。使う部門や顧客だけでなく、情報システム部門、法務・セキュリティ、運用を担うベンダーなど、あとから条件を出しやすい関係者を最初から入れておくことが重要です。ここが抜けると、収集も分析もやり直しになります。",{"q":32,"a":33},"要求が多すぎて絞れないときはどうすればよいですか？","企画で決めた目的に照らして、効果の大きさと開発の工数の2軸で並べます。効果が大きく工数が小さいものを最優先にし、効果が小さく工数が大きいものはやらないと決めます。部門間で要求がぶつかる場合は、売上の増加やコストの削減など成果の大きいほうを優先し、その判断はプロジェクトオーナーが行います。",{"type":35,"children":36,"toc":854},"root",[37,45,59,64,71,83,96,102,107,131,136,171,176,181,193,198,203,219,263,275,280,287,292,308,313,325,331,336,359,371,376,382,387,415,430,442,447,452,458,463,479,484,489,522,527,532,537,570,575,581,586,592,597,603,608,614,625,630,635,663,669,683,790,795,825],{"type":38,"tag":39,"props":40,"children":41},"element","p",{},[42],{"type":43,"value":44},"text","企画で「なぜやるのか」が決まったら、次は「システムに何を求めているのか」を言葉にする番です。この工程が要求定義です。",{"type":38,"tag":39,"props":46,"children":47},{},[48,50,57],{"type":43,"value":49},"要求定義は、",{"type":38,"tag":51,"props":52,"children":54},"a",{"href":53},"\u002Farticles\u002Fyoken-teigi-hacchu-kaihatsu-yakuwari\u002F",[55],{"type":43,"value":56},"第1回",{"type":43,"value":58},"で整理したとおり発注側が主役の工程ですが、実際には最も省略されやすい工程でもあります。企画から要件定義に飛んでしまい、「何を求めているのか」が言葉になる前に「どう作るか」の話が始まる。その結果、開発側は発注側の頭の中を推測しながら作ることになります。",{"type":38,"tag":39,"props":60,"children":61},{},[62],{"type":43,"value":63},"本記事はシリーズ「発注側のための要件定義」の第3回として、要求定義の進め方と、その成果物である要求仕様書の書き方を扱います。",{"type":38,"tag":65,"props":66,"children":68},"h2",{"id":67},"要求定義とは-企画に基づいて何を求めているかを明確にする",[69],{"type":43,"value":70},"要求定義とは ―― 企画に基づいて「何を求めているか」を明確にする",{"type":38,"tag":39,"props":72,"children":73},{},[74,75,81],{"type":43,"value":49},{"type":38,"tag":51,"props":76,"children":78},{"href":77},"\u002Farticles\u002Fsystem-kaihatsu-kikakusho-tsukurikata\u002F",[79],{"type":43,"value":80},"企画",{"type":43,"value":82},"で決めた目的に基づいて、システムに実現してほしいことを明確にしていく作業です。自分たちの頭の中にあるシステムのイメージを、開発側に正確に伝えるための工程と言えます。",{"type":38,"tag":39,"props":84,"children":85},{},[86,88,94],{"type":43,"value":87},"ここで押さえておきたいのは、要求定義は",{"type":38,"tag":89,"props":90,"children":91},"strong",{},[92],{"type":43,"value":93},"開発側が一方的に聞き取るものではなく、双方が協力して行うもの",{"type":43,"value":95},"だということです。発注側は「何を求めているか」を言葉にする責任を持ち、開発側は「それは技術的にどう実現できるか」「どこが難しいか」を返します。このやり取りを通じて、要求は少しずつ具体的になっていきます。",{"type":38,"tag":65,"props":97,"children":99},{"id":98},"要望要求要件の違い",[100],{"type":43,"value":101},"要望・要求・要件の違い",{"type":38,"tag":39,"props":103,"children":104},{},[105],{"type":43,"value":106},"要求定義を理解するうえで欠かせないのが、要望・要求・要件の3つの違いです。3つはすべて「同じことを言っている」のですが、抽象度が違います。",{"type":38,"tag":108,"props":109,"children":110},"picture",{},[111,113,121,122],{"type":43,"value":112},"\n  ",{"type":38,"tag":114,"props":115,"children":120},"source",{"media":116,"srcSet":117,"width":118,"height":119},"(max-width: 768px)","\u002Fimg\u002Fcontents\u002Farticles\u002Fyokyu-teigi-susumekata-yokyu-shiyosho\u002Fyobo-yokyu-yoken-sp.svg",420,600,[],{"type":43,"value":112},{"type":38,"tag":123,"props":124,"children":130},"img",{"src":125,"alt":126,"width":127,"height":128,"loading":129},"\u002Fimg\u002Fcontents\u002Farticles\u002Fyokyu-teigi-susumekata-yokyu-shiyosho\u002Fyobo-yokyu-yoken.svg","要望・要求・要件の違い。旅行の例では、要望（夢）は「旅行に行きたい」、要求（理想）は「リゾートでゆっくりしたい、7泊以上」、要件（現実）は「4つ星以上・ダブルベッド・日本人が少ない・買い物ができる」。業務の例では、要望は「営業の事務作業を楽にしたい」、要求は「訪問後の報告を10分で終えたい」、要件は「スマホの音声入力で報告を作り、上長に自動通知する」。抽象的から具体的へ、下に行くほど臨場感が出る",800,300,"lazy",[],{"type":38,"tag":39,"props":132,"children":133},{},[134],{"type":43,"value":135},"旅行の計画で考えると分かりやすくなります。",{"type":38,"tag":137,"props":138,"children":139},"ul",{},[140,151,161],{"type":38,"tag":141,"props":142,"children":143},"li",{},[144,149],{"type":38,"tag":89,"props":145,"children":146},{},[147],{"type":43,"value":148},"要望",{"type":43,"value":150},"：「旅行に行きたい」。漠然とした願いです。",{"type":38,"tag":141,"props":152,"children":153},{},[154,159],{"type":38,"tag":89,"props":155,"children":156},{},[157],{"type":43,"value":158},"要求",{"type":43,"value":160},"：「リゾート地に行ってゆっくりしたい」「最低でも7泊はしたい」「日本人の少ないところがいい」。何を求めているかが、言葉になっています。",{"type":38,"tag":141,"props":162,"children":163},{},[164,169],{"type":38,"tag":89,"props":165,"children":166},{},[167],{"type":43,"value":168},"要件",{"type":43,"value":170},"：「ホテルは4つ星以上でベッドはダブル」「グルメはなくてもよいが、買い物ができる場所は必須」。満たすべき条件まで具体化されています。",{"type":38,"tag":39,"props":172,"children":173},{},[174],{"type":43,"value":175},"すべて「旅行に行きたい」という同じ願いから出ていますが、下に行くほど臨場感のある具体的な内容になり、旅行会社（開発側）が提案できる状態に近づきます。",{"type":38,"tag":39,"props":177,"children":178},{},[179],{"type":43,"value":180},"業務のシステムでも同じです。「営業の事務作業を楽にしたい」は要望、「訪問後の報告を10分で終えたい」は要求、「スマホの音声入力で報告を作り、上長に自動で通知する」は要件です。",{"type":38,"tag":39,"props":182,"children":183},{},[184,186,191],{"type":43,"value":185},"要求定義は、要望を要求に整える工程です。言い換えると、",{"type":38,"tag":89,"props":187,"children":188},{},[189],{"type":43,"value":190},"発注側の「夢」を「理想」として語れるようにする段階",{"type":43,"value":192},"です。それを「現実」の仕様に落とす要件定義は、次の工程になります。この違いを意識しておくと、要求定義の段階で細かい画面の話に入り込んでしまうことを防げます。",{"type":38,"tag":65,"props":194,"children":196},{"id":195},"要求整理の4ステップ",[197],{"type":43,"value":195},{"type":38,"tag":39,"props":199,"children":200},{},[201],{"type":43,"value":202},"要求定義は、次の4つのステップで進めます。それぞれに、次へ進むための条件があります。",{"type":38,"tag":108,"props":204,"children":205},{},[206,207,212,213],{"type":43,"value":112},{"type":38,"tag":114,"props":208,"children":211},{"media":116,"srcSet":209,"width":118,"height":210},"\u002Fimg\u002Fcontents\u002Farticles\u002Fyokyu-teigi-susumekata-yokyu-shiyosho\u002Fyokyu-4steps-sp.svg",582,[],{"type":43,"value":112},{"type":38,"tag":123,"props":214,"children":218},{"src":215,"alt":216,"width":127,"height":217,"loading":129},"\u002Fimg\u002Fcontents\u002Farticles\u002Fyokyu-teigi-susumekata-yokyu-shiyosho\u002Fyokyu-4steps.svg","要求整理の4ステップ。1 関係者の選定（影響を与える人・受ける人を洗い出す。選び終えたら次へ）、2 要求の収集（面談・アンケート・資料で集める。材料がそろったら次へ）、3 要求の分析（重複と矛盾を整理し優先順位をつける。順位がついたら次へ）、4 要求仕様書（合意を取り、数枚にまとめる。承認されたら次工程へ）。関係者が抜けていると収集も分析もやり直しになるので、1が土台",260,[],{"type":38,"tag":220,"props":221,"children":222},"ol",{},[223,233,243,253],{"type":38,"tag":141,"props":224,"children":225},{},[226,231],{"type":38,"tag":89,"props":227,"children":228},{},[229],{"type":43,"value":230},"関係者の選定",{"type":43,"value":232},"：プロジェクトに影響を与える人と、影響を受ける人を特定します。選び終えたら次へ進みます。",{"type":38,"tag":141,"props":234,"children":235},{},[236,241],{"type":38,"tag":89,"props":237,"children":238},{},[239],{"type":43,"value":240},"要求の収集",{"type":43,"value":242},"：面談、アンケート、既存資料の確認を通じて、関係者から具体的な要求を集めます。必要な材料がそろったら分析に進みます。",{"type":38,"tag":141,"props":244,"children":245},{},[246,251],{"type":38,"tag":89,"props":247,"children":248},{},[249],{"type":43,"value":250},"要求の分析",{"type":43,"value":252},"：集めた要求を整理し、重複や矛盾を解決し、実現の可能性と優先順位を評価します。順位がついたら文書化に進みます。",{"type":38,"tag":141,"props":254,"children":255},{},[256,261],{"type":38,"tag":89,"props":257,"children":258},{},[259],{"type":43,"value":260},"要求仕様書の作成",{"type":43,"value":262},"：分析した要求をもとに、明確な要求仕様書を作ります。関係者に承認されたら、次の要件定義の工程に進みます。",{"type":38,"tag":39,"props":264,"children":265},{},[266,268,273],{"type":43,"value":267},"順番が大切なのは、",{"type":38,"tag":89,"props":269,"children":270},{},[271],{"type":43,"value":272},"前のステップが不十分だと、後のステップがやり直しになる",{"type":43,"value":274},"からです。特に、関係者の選定が抜けていると、要求を集めて分析したあとに「あの部門に聞いていなかった」と分かり、収集からやり直すことになります。",{"type":38,"tag":39,"props":276,"children":277},{},[278],{"type":43,"value":279},"以下、各ステップのポイントを見ていきます。",{"type":38,"tag":281,"props":282,"children":284},"h3",{"id":283},"ステップ1関係者を選定する",[285],{"type":43,"value":286},"ステップ1：関係者を選定する",{"type":38,"tag":39,"props":288,"children":289},{},[290],{"type":43,"value":291},"要求を取りまとめるために必要な登場人物を、企画の内容に応じて洗い出します。",{"type":38,"tag":108,"props":293,"children":294},{},[295,296,301,302],{"type":43,"value":112},{"type":38,"tag":114,"props":297,"children":300},{"media":116,"srcSet":298,"width":118,"height":299},"\u002Fimg\u002Fcontents\u002Farticles\u002Fyokyu-teigi-susumekata-yokyu-shiyosho\u002Fstakeholder-map-sp.svg",350,[],{"type":43,"value":112},{"type":38,"tag":123,"props":303,"children":307},{"src":304,"alt":305,"width":127,"height":306,"loading":129},"\u002Fimg\u002Fcontents\u002Farticles\u002Fyokyu-teigi-susumekata-yokyu-shiyosho\u002Fstakeholder-map.svg","要求を集める関係者の例。中心のプロジェクトの周りに、顧客、営業、マーケティング、商品企画、バックオフィス、カスタマーサポート、情報システム、法務・セキュリティ、運用ベンダー、分析チーム。情報システム・法務・セキュリティ・運用ベンダーは、あとから条件を出しやすい関係者",290,[],{"type":38,"tag":39,"props":309,"children":310},{},[311],{"type":43,"value":312},"関係者の例を挙げると、顧客（社内向けなら使う社員）、営業、マーケティング、商品企画、バックオフィス、カスタマーサポート、情報システム部門、法務・セキュリティ、運用を担うベンダー、分析チームなどです。",{"type":38,"tag":39,"props":314,"children":315},{},[316,318,323],{"type":43,"value":317},"見落としやすいのは、",{"type":38,"tag":89,"props":319,"children":320},{},[321],{"type":43,"value":322},"「使う人」ではなく「条件を出す人」です",{"type":43,"value":324},"。情報システム部門はセキュリティや既存システムとの連携の条件を、法務は契約や個人情報の扱いの条件を、運用ベンダーは保守の条件を持っています。こうした関係者を最初に入れておかないと、要求がまとまったあとに「その方式は認められない」と条件が出て、振り出しに戻ります。",{"type":38,"tag":281,"props":326,"children":328},{"id":327},"ステップ2要求を収集する",[329],{"type":43,"value":330},"ステップ2：要求を収集する",{"type":38,"tag":39,"props":332,"children":333},{},[334],{"type":43,"value":335},"関係者から、システムに求めることを集めます。聞き方の例は次のとおりです。",{"type":38,"tag":137,"props":337,"children":338},{},[339,344,349,354],{"type":38,"tag":141,"props":340,"children":341},{},[342],{"type":43,"value":343},"どんなシステムがあれば、業務が楽になるか",{"type":38,"tag":141,"props":345,"children":346},{},[347],{"type":43,"value":348},"どんな機能があれば、売上が上がるか",{"type":38,"tag":141,"props":350,"children":351},{},[352],{"type":43,"value":353},"どんな機能があれば、顧客が喜ぶか",{"type":38,"tag":141,"props":355,"children":356},{},[357],{"type":43,"value":358},"どんな機能なら、お金を出す価値があるか",{"type":38,"tag":39,"props":360,"children":361},{},[362,364,369],{"type":43,"value":363},"集めるときのコツは、",{"type":38,"tag":89,"props":365,"children":366},{},[367],{"type":43,"value":368},"要求と一緒に「なぜ」を聞く",{"type":43,"value":370},"ことです。「〇〇の機能が欲しい」という要求の裏には、「今は△△に時間がかかっているから」という理由があります。理由が分かっていれば、次の分析で優先順位をつけるときの根拠になり、要件定義で別の手段を提案するときの材料にもなります。",{"type":38,"tag":39,"props":372,"children":373},{},[374],{"type":43,"value":375},"この段階では、要求を絞りません。矛盾する要求が出てきても構いません。整理するのは次のステップです。",{"type":38,"tag":281,"props":377,"children":379},{"id":378},"ステップ3要求を分析する",[380],{"type":43,"value":381},"ステップ3：要求を分析する",{"type":38,"tag":39,"props":383,"children":384},{},[385],{"type":43,"value":386},"集めた要求を整理し、矛盾や重複を解決して、優先順位をつけます。判断の軸は、企画で定めた目的です。",{"type":38,"tag":137,"props":388,"children":389},{},[390,395,400,405,410],{"type":38,"tag":141,"props":391,"children":392},{},[393],{"type":43,"value":394},"企画の目的に沿って、このシステムで何が必要かを見極める",{"type":38,"tag":141,"props":396,"children":397},{},[398],{"type":43,"value":399},"最終的に得たい成果を明確にし、それを実現するために要求を整理する",{"type":38,"tag":141,"props":401,"children":402},{},[403],{"type":43,"value":404},"機能に利害の衝突がある場合は、成果が大きいほう（売上の増加、コストの削減など）を優先する",{"type":38,"tag":141,"props":406,"children":407},{},[408],{"type":43,"value":409},"効果がそれほど得られない機能は、優先度を下げる",{"type":38,"tag":141,"props":411,"children":412},{},[413],{"type":43,"value":414},"スケジュールと照らし合わせて、最終的な範囲を決める",{"type":38,"tag":108,"props":416,"children":417},{},[418,419,424,425],{"type":43,"value":112},{"type":38,"tag":114,"props":420,"children":423},{"media":116,"srcSet":421,"width":118,"height":422},"\u002Fimg\u002Fcontents\u002Farticles\u002Fyokyu-teigi-susumekata-yokyu-shiyosho\u002Fyusen-matrix-sp.svg",330,[],{"type":43,"value":112},{"type":38,"tag":123,"props":426,"children":429},{"src":427,"alt":428,"width":127,"height":128,"loading":129},"\u002Fimg\u002Fcontents\u002Farticles\u002Fyokyu-teigi-susumekata-yokyu-shiyosho\u002Fyusen-matrix.svg","要求の優先順位のつけ方。効果の大小と工数の大小の2軸で4つに分ける。効果が大きく工数が小さいものは最優先、効果は大きいが工数が大きいものは計画的にやる、効果が小さく工数も小さいものは余力があれば、効果が小さく工数が大きいものはやらない。開発側とすり合わせながら、右上から順に範囲に入れていく",[],{"type":38,"tag":39,"props":431,"children":432},{},[433,435,440],{"type":43,"value":434},"優先順位をつけるときに便利なのが、",{"type":38,"tag":89,"props":436,"children":437},{},[438],{"type":43,"value":439},"効果と工数の2軸",{"type":43,"value":441},"です。効果が大きく工数の小さいものを最優先にし、効果が小さく工数の大きいものは「やらない」と決めます。効果は発注側が、工数は開発側が判断できるので、この表は自然と両者のすり合わせの場になります。",{"type":38,"tag":39,"props":443,"children":444},{},[445],{"type":43,"value":446},"「やらない」と決めたことは、消さずに記録しておきます。あとから「あの要求はどうなった」と蒸し返されたときに、いつ、なぜ落としたのかを説明できるからです。",{"type":38,"tag":39,"props":448,"children":449},{},[450],{"type":43,"value":451},"部門間で要求がぶつかり、効果の比較だけでは決まらない場合は、プロジェクトオーナーの判断を仰ぎます。第1回で「オーナーを名前で決める」と書いたのは、まさにこの場面のためです。",{"type":38,"tag":281,"props":453,"children":455},{"id":454},"ステップ4要求仕様書にまとめる",[456],{"type":43,"value":457},"ステップ4：要求仕様書にまとめる",{"type":38,"tag":39,"props":459,"children":460},{},[461],{"type":43,"value":462},"分析して優先順位をつけた要求を、関係者の合意を得て文書にします。",{"type":38,"tag":108,"props":464,"children":465},{},[466,467,472,473],{"type":43,"value":112},{"type":38,"tag":114,"props":468,"children":471},{"media":116,"srcSet":469,"width":118,"height":470},"\u002Fimg\u002Fcontents\u002Farticles\u002Fyokyu-teigi-susumekata-yokyu-shiyosho\u002Fyokyu-shiyosho-sp.svg",440,[],{"type":43,"value":112},{"type":38,"tag":123,"props":474,"children":478},{"src":475,"alt":476,"width":127,"height":477,"loading":129},"\u002Fimg\u002Fcontents\u002Farticles\u002Fyokyu-teigi-susumekata-yokyu-shiyosho\u002Fyokyu-shiyosho.svg","要求仕様書の構成。目的（何のために）、プロジェクト概要（範囲と体制）、現状分析（企画書から）、システム要求（実現してほしいこと）、システム概要（ざっくりの姿）、プロジェクト計画（期間と進め方）、収支計画（費用と回収）。数枚に収め、細部より「誰が・何のために」が伝わることを優先する。細かい仕様は次の要件定義で",250,[],{"type":38,"tag":39,"props":480,"children":481},{},[482],{"type":43,"value":483},"要求仕様書に入れる項目は、目的、プロジェクト概要、現状分析、システム要求、システム概要、プロジェクト計画、収支計画です。企画書と重なる項目が多いのは、要求仕様書が企画書を土台にしているからで、現状分析や収支計画は企画書の内容を引き継いで構いません。",{"type":38,"tag":39,"props":485,"children":486},{},[487],{"type":43,"value":488},"書くときのポイントは3つです。",{"type":38,"tag":137,"props":490,"children":491},{},[492,502,512],{"type":38,"tag":141,"props":493,"children":494},{},[495,500],{"type":38,"tag":89,"props":496,"children":497},{},[498],{"type":43,"value":499},"細かいことより、要点が伝わるように書く",{"type":43,"value":501},"：要求仕様書の段階で画面の細部まで書く必要はありません。数枚に収め、読んだ人が全体像をつかめることを優先します。",{"type":38,"tag":141,"props":503,"children":504},{},[505,510],{"type":38,"tag":89,"props":506,"children":507},{},[508],{"type":43,"value":509},"「誰が」「何のために」必要なシステムなのかをはっきりさせる",{"type":43,"value":511},"：システムが満たすべき機能や性能の要求は、必ず「誰の、どんな目的のため」とセットで書きます。",{"type":38,"tag":141,"props":513,"children":514},{},[515,520],{"type":38,"tag":89,"props":516,"children":517},{},[518],{"type":43,"value":519},"プロジェクト計画案を添える",{"type":43,"value":521},"：いつまでに、どんな体制で進めるのかを、要求と一緒に示します。",{"type":38,"tag":39,"props":523,"children":524},{},[525],{"type":43,"value":526},"要求仕様書が関係者に承認された時点で、要求定義は完了です。ここから先の、要求をシステムの条件に落とす作業は、開発側と一緒に行う要件定義になります。",{"type":38,"tag":65,"props":528,"children":530},{"id":529},"効果的な要求整理のための3つのコツ",[531],{"type":43,"value":529},{"type":38,"tag":39,"props":533,"children":534},{},[535],{"type":43,"value":536},"4ステップを進めるうえで、K.S.Rogers が支援の現場で重視しているコツを3つ挙げます。",{"type":38,"tag":137,"props":538,"children":539},{},[540,550,560],{"type":38,"tag":141,"props":541,"children":542},{},[543,548],{"type":38,"tag":89,"props":544,"children":545},{},[546],{"type":43,"value":547},"コミュニケーション",{"type":43,"value":549},"：定期的にミーティングを設け、進み具合の共有と新しい要求の議論を行います。あわせて、チャットやプロジェクト管理ツールなど、思いついたときに意見を出せる経路を用意します。要求は会議の場だけで出てくるものではありません。",{"type":38,"tag":141,"props":551,"children":552},{},[553,558],{"type":38,"tag":89,"props":554,"children":555},{},[556],{"type":43,"value":557},"文書化",{"type":43,"value":559},"：ミーティングや議論で合意したことは文書に記録し、参加者全員で共有します。要求に変更が生じたら、正式な手続きを通じて管理し、関係者に知らせます。「言った・言わない」を防ぐには、これしかありません。",{"type":38,"tag":141,"props":561,"children":562},{},[563,568],{"type":38,"tag":89,"props":564,"children":565},{},[566],{"type":43,"value":567},"検証",{"type":43,"value":569},"：要求仕様書や文書化した要求を、関係者と一緒にレビューします。全員の理解と合意が得られていることを確認する場であり、要求がプロジェクトの目的に合っているかを最後に見直す場でもあります。",{"type":38,"tag":65,"props":571,"children":573},{"id":572},"要求定義でよくあるつまずき",[574],{"type":43,"value":572},{"type":38,"tag":281,"props":576,"children":578},{"id":577},"_1-集めた要望を全部そのまま載せる",[579],{"type":43,"value":580},"1. 集めた要望を、全部そのまま載せる",{"type":38,"tag":39,"props":582,"children":583},{},[584],{"type":43,"value":585},"関係者から集めた要望を、分析せずにそのまま要求仕様書に並べてしまうケースです。矛盾した要求が同居し、優先順位もないため、開発側は何から手をつければよいか分かりません。「集める」と「決める」は別の作業です。",{"type":38,"tag":281,"props":587,"children":589},{"id":588},"_2-条件を出す関係者をあとから呼ぶ",[590],{"type":43,"value":591},"2. 条件を出す関係者を、あとから呼ぶ",{"type":38,"tag":39,"props":593,"children":594},{},[595],{"type":43,"value":596},"情報システム部門や法務、運用ベンダーを、要求がまとまってから呼ぶケースです。前述のとおり、ここで条件が出ると振り出しに戻ります。使う人だけでなく、条件を出す人を最初から入れてください。",{"type":38,"tag":281,"props":598,"children":600},{"id":599},"_3-要求が機能の羅列で目的がない",[601],{"type":43,"value":602},"3. 要求が「機能の羅列」で、目的がない",{"type":38,"tag":39,"props":604,"children":605},{},[606],{"type":43,"value":607},"「〇〇機能、△△機能、□□機能」と機能だけが並び、それぞれが誰の何のためなのかが書かれていないケースです。開発側は機能を作ることはできても、目的が分からなければ、より良い手段を提案することができません。機能には、必ず「なぜ」を添えます。",{"type":38,"tag":65,"props":609,"children":611},{"id":610},"支援の現場で見た要求整理の効果",[612],{"type":43,"value":613},"支援の現場で見た、要求整理の効果",{"type":38,"tag":39,"props":615,"children":616},{},[617,623],{"type":38,"tag":51,"props":618,"children":620},{"href":619},"\u002Frd\u002Fcase-studies\u002Fcase-study-5\u002F",[621],{"type":43,"value":622},"オンライン診療プロダクトの開発体制を立て直した事例",{"type":43,"value":624},"では、開発が進まない原因は開発そのものではなく、その手前の要求整理にありました。要件定義書がなく、プロダクトを実際に触らないと何が求められているのか分からない状態だったのです。",{"type":38,"tag":39,"props":626,"children":627},{},[628],{"type":43,"value":629},"そこで最初に行ったのは、主要な立場の人に一通り話を聞き、それぞれの視点の課題を集めて整理し、レポートとして示すことでした。まさに、関係者の選定と要求の収集・分析にあたる作業です。要求が言葉になったことで、開発側は「何を作るべきか」を判断できるようになりました。",{"type":38,"tag":65,"props":631,"children":633},{"id":632},"参考になる公的資料",[634],{"type":43,"value":632},{"type":38,"tag":137,"props":636,"children":637},{},[638,651],{"type":38,"tag":141,"props":639,"children":640},{},[641,649],{"type":38,"tag":51,"props":642,"children":646},{"href":643,"rel":644},"https:\u002F\u002Fwww.ipa.go.jp\u002Farchive\u002Fpublish\u002Ftn20191220.html",[645],"nofollow",[647],{"type":43,"value":648},"IPA「ユーザのための要件定義ガイド 第2版」",{"type":43,"value":650},"：要求の獲得や関係者の合意形成について、発注側の視点で起きやすい問題と対策が整理されています",{"type":38,"tag":141,"props":652,"children":653},{},[654,661],{"type":38,"tag":51,"props":655,"children":658},{"href":656,"rel":657},"https:\u002F\u002Fwww.ipa.go.jp\u002Fdigital\u002Fmodel\u002Fmodel20201222.html",[645],[659],{"type":43,"value":660},"IPA「情報システム・モデル取引・契約書（第二版）」",{"type":43,"value":662},"：要件定義の前段階を発注側がどう担うかを含め、ユーザ企業とITベンダの役割が整理されています",{"type":38,"tag":65,"props":664,"children":666},{"id":665},"要求の整理からご一緒します-ksrogers-の要件定義支援",[667],{"type":43,"value":668},"要求の整理からご一緒します ―― K.S.Rogers の要件定義支援",{"type":38,"tag":39,"props":670,"children":671},{},[672,674,681],{"type":43,"value":673},"K.S.Rogers では「決まっていないところから一緒に考える」をコンセプトに、",{"type":38,"tag":51,"props":675,"children":678},{"href":676,"rel":677},"https:\u002F\u002Fks-rogers.co.jp\u002Frd\u002F",[645],[679],{"type":43,"value":680},"要件定義支援サービス",{"type":43,"value":682},"を提供しています。関係者への聞き取りから、要求の分析、要求仕様書の作成まで、発注側の立場で伴走します。",{"type":38,"tag":684,"props":685,"children":686},"table",{},[687,716],{"type":38,"tag":688,"props":689,"children":690},"thead",{},[691],{"type":38,"tag":692,"props":693,"children":694},"tr",{},[695,701,706,711],{"type":38,"tag":696,"props":697,"children":698},"th",{},[699],{"type":43,"value":700},"プラン",{"type":38,"tag":696,"props":702,"children":703},{},[704],{"type":43,"value":705},"月額（税別）",{"type":38,"tag":696,"props":707,"children":708},{},[709],{"type":43,"value":710},"稼働の目安",{"type":38,"tag":696,"props":712,"children":713},{},[714],{"type":43,"value":715},"こんなときに",{"type":38,"tag":717,"props":718,"children":719},"tbody",{},[720,744,767],{"type":38,"tag":692,"props":721,"children":722},{},[723,729,734,739],{"type":38,"tag":724,"props":725,"children":726},"td",{},[727],{"type":43,"value":728},"相談・壁打ち",{"type":38,"tag":724,"props":730,"children":731},{},[732],{"type":43,"value":733},"10万円",{"type":38,"tag":724,"props":735,"children":736},{},[737],{"type":43,"value":738},"月8時間",{"type":38,"tag":724,"props":740,"children":741},{},[742],{"type":43,"value":743},"集めた要求の整理の仕方を相談したい",{"type":38,"tag":692,"props":745,"children":746},{},[747,752,757,762],{"type":38,"tag":724,"props":748,"children":749},{},[750],{"type":43,"value":751},"要件定義設計",{"type":38,"tag":724,"props":753,"children":754},{},[755],{"type":43,"value":756},"27万円",{"type":38,"tag":724,"props":758,"children":759},{},[760],{"type":43,"value":761},"月25時間",{"type":38,"tag":724,"props":763,"children":764},{},[765],{"type":43,"value":766},"関係者への聞き取りから要求仕様書まで任せたい",{"type":38,"tag":692,"props":768,"children":769},{},[770,775,780,785],{"type":38,"tag":724,"props":771,"children":772},{},[773],{"type":43,"value":774},"プロジェクト推進",{"type":38,"tag":724,"props":776,"children":777},{},[778],{"type":43,"value":779},"50万円",{"type":38,"tag":724,"props":781,"children":782},{},[783],{"type":43,"value":784},"月50時間",{"type":38,"tag":724,"props":786,"children":787},{},[788],{"type":43,"value":789},"要求の取りまとめ役がおらず、プロジェクトごと推進してほしい",{"type":38,"tag":65,"props":791,"children":793},{"id":792},"まとめ",[794],{"type":43,"value":792},{"type":38,"tag":137,"props":796,"children":797},{},[798,803,808,820],{"type":38,"tag":141,"props":799,"children":800},{},[801],{"type":43,"value":802},"要求定義は、企画の目的に基づいて「システムに何を求めているか」を言葉にする工程で、発注側が主役です。ただし開発側と協力して進めます",{"type":38,"tag":141,"props":804,"children":805},{},[806],{"type":43,"value":807},"要望（夢）・要求（理想）・要件（現実）は抽象度の違いです。要求定義は要望を要求に整える段階で、細かい仕様に入り込まないようにします",{"type":38,"tag":141,"props":809,"children":810},{},[811,813,818],{"type":43,"value":812},"進め方は",{"type":38,"tag":89,"props":814,"children":815},{},[816],{"type":43,"value":817},"関係者の選定 → 要求の収集 → 要求の分析 → 要求仕様書",{"type":43,"value":819},"の4ステップです。条件を出す関係者を最初から入れ、要求には「なぜ」を添え、効果と工数で優先順位をつけます",{"type":38,"tag":141,"props":821,"children":822},{},[823],{"type":43,"value":824},"要求仕様書は数枚に収め、「誰が・何のために」が伝わることを優先します。承認されたら要件定義に進みます",{"type":38,"tag":39,"props":826,"children":827},{},[828,830,836,838,844,846,852],{"type":43,"value":829},"次回は、要求仕様書を受けて開発側と一緒に行う",{"type":38,"tag":51,"props":831,"children":833},{"href":832},"\u002Farticles\u002Fyoken-teigisho-kakikata-kinou-hikinou\u002F",[834],{"type":43,"value":835},"要件定義書に書くこと",{"type":43,"value":837},"（ビジネス要件とシステム要件、抜けやすい非機能要件）を扱います。シリーズの全体像は",{"type":38,"tag":51,"props":839,"children":841},{"href":840},"\u002Farticles\u002Fyoken-teigi-susumekata\u002F",[842],{"type":43,"value":843},"要件定義の進め方",{"type":43,"value":845},"を、要求の整理について相談したい方は",{"type":38,"tag":51,"props":847,"children":849},{"href":848},"\u002Fcontact\u002F",[850],{"type":43,"value":851},"お問い合わせ",{"type":43,"value":853},"からお気軽にご連絡ください。",{"title":7,"searchDepth":855,"depth":855,"links":856},2,[857,858,859,865,866,871,872,873,874],{"id":67,"depth":855,"text":70},{"id":98,"depth":855,"text":101},{"id":195,"depth":855,"text":195,"children":860},[861,862,863,864],{"id":283,"depth":15,"text":286},{"id":327,"depth":15,"text":330},{"id":378,"depth":15,"text":381},{"id":454,"depth":15,"text":457},{"id":529,"depth":855,"text":529},{"id":572,"depth":855,"text":572,"children":867},[868,869,870],{"id":577,"depth":15,"text":580},{"id":588,"depth":15,"text":591},{"id":599,"depth":15,"text":602},{"id":610,"depth":855,"text":613},{"id":632,"depth":855,"text":632},{"id":665,"depth":855,"text":668},{"id":792,"depth":855,"text":792},"markdown","content:articles:yokyu-teigi-susumekata-yokyu-shiyosho.md","content","articles\u002Fyokyu-teigi-susumekata-yokyu-shiyosho.md","articles\u002Fyokyu-teigi-susumekata-yokyu-shiyosho","md",[882,887,891,895],{"_path":883,"title":884,"seriesNo":885,"seriesLabel":886},"\u002Farticles\u002Fyoken-teigi-susumekata","要件定義の進め方・やり方｜5ステップの流れと、難しい・失敗する原因を実務目線で解説",0,"全体像",{"_path":888,"title":889,"seriesNo":890,"seriesLabel":56},"\u002Farticles\u002Fyoken-teigi-hacchu-kaihatsu-yakuwari","システム開発の発注側と開発側の役割分担｜要件定義の前に「誰が何を決めるか」を明確にする方法",1,{"_path":892,"title":893,"seriesNo":855,"seriesLabel":894},"\u002Farticles\u002Fsystem-kaihatsu-kikakusho-tsukurikata","システム開発の企画書の作り方｜「システムありき」にしない現状分析と課題の抽出（3C・PEST・SWOT）","第2回",{"_path":4,"title":8,"seriesNo":15,"seriesLabel":16},1791131955410]