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