[{"data":1,"prerenderedAt":1656},["ShallowReactive",2],{"article-\u002Farticles\u002Fyoken-teigi-shippai-genin":3,"article-series-none":1655},{"_path":4,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"title":8,"description":9,"date":10,"category":11,"author":12,"thumbnail":13,"tags":14,"faq":18,"body":34,"_type":1649,"_id":1650,"_source":1651,"_file":1652,"_stem":1653,"_extension":1654},"\u002Farticles\u002Fyoken-teigi-shippai-genin","articles",false,"","要件定義が失敗する原因と防ぎ方｜よくある失敗事例6パターンと「危ない兆候」チェックリスト","要件定義の失敗は、担当者の力量より「進め方の構造」から起きます。よくある失敗事例を6パターンに分け、こうなっていたら危ないという兆候、システム開発を外注に丸投げしないための発注側の役割、見積もり時点で必要な要件の粒度、失敗した要件定義の立て直し方までを、K.S.Rogers の支援事例とあわせて解説します。","2026-10-12","要件定義","K.S.ロジャース株式会社","\u002Fimg\u002Fcontents\u002Fnews\u002Fthumb124.jpg",[11,15,16,17],"システム開発","外注","プロジェクト管理",[19,22,25,28,31],{"q":20,"a":21},"要件定義が失敗する一番の原因は何ですか？","最も多いのは、要件を決める役割が置かれていないことです。発注側と開発側のどちらが何を決めるのかが曖昧なまま進むと、利用者の調査も関係者の合意も抜け落ち、開発が始まってから「想定と違う」が噴き出します。まず「誰が決めるのか」をはっきりさせることが出発点です。",{"q":23,"a":24},"システム開発を外注に丸投げすると、なぜ失敗するのですか？","開発会社はシステムを作る専門家ですが、発注側の業務の事情や、社内で何を優先したいかは知りません。業務の目的・利用者・やらないことを決めるのは発注側の役割で、ここを任せきりにすると「言われた通りに作ったのに使われない」システムになりやすくなります。要件定義を外部に頼む場合も、決める権限と最終判断は発注側に残します。",{"q":26,"a":27},"要件定義が失敗しているかどうかは、どうすれば分かりますか？","会議のたびに前提が変わる、仕様の質問に誰も即答できない、「なぜこの機能が必要か」を1文で言えない、利用者に一度も話を聞いていない、といった兆候が出ていれば危険信号です。本記事のチェックリストで2つ以上当てはまる場合は、開発に進む前に要件定義を見直すことをおすすめします。",{"q":29,"a":30},"要件定義に失敗したプロジェクトは立て直せますか？","立て直せます。いったん走りながら作るのを止め、関係者へのヒアリングで現状を棚卸しし、目的と利用者に立ち返って優先順位とやらないことを決め直します。そのうえで承認の流れやロードマップなど、合意と進め方の型をつくると、プロジェクトは再び前に進み始めます。",{"q":32,"a":33},"要件定義の立て直しを外部に頼むと費用はいくらですか？","依頼する範囲で変わります。K.S.Rogers の要件定義支援では、「相談・壁打ち」は月10万円（税別・月8時間）、要件定義とドキュメント作成まで任せる「要件定義設計」は月27万円（税別・月25時間）、開発中の推進まで任せる「プロジェクト推進」は月50万円（税別・月50時間）です。",{"type":35,"children":36,"toc":1613},"root",[37,45,61,82,114,121,133,138,231,236,242,247,271,278,290,304,310,322,327,333,338,350,356,368,374,395,400,406,411,423,429,441,447,492,497,546,551,591,596,601,619,624,636,641,776,781,794,800,812,833,847,852,864,883,888,894,906,922,1003,1024,1029,1034,1039,1174,1179,1187,1198,1204,1209,1225,1231,1236,1253,1259,1264,1275,1281,1293,1299,1304,1322,1333,1338,1343,1386,1391,1403,1408,1433,1439,1453,1554,1559,1564,1594],{"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,59],{"type":43,"value":49},"IPA（情報処理推進機構）が発注者向けに公開している",{"type":38,"tag":51,"props":52,"children":56},"a",{"href":53,"rel":54},"https:\u002F\u002Fwww.ipa.go.jp\u002Farchive\u002Fpublish\u002Ftn20191220.html",[55],"nofollow",[57],{"type":43,"value":58},"「ユーザのための要件定義ガイド 第2版」",{"type":43,"value":60},"でも、「システム開発の遅延の過半は要件定義の失敗にある」と言われる、という課題認識から解説が始まっています。",{"type":38,"tag":39,"props":62,"children":63},{},[64,66,72,74,80],{"type":43,"value":65},"ただし、要件定義の失敗は担当者の力量不足だけで起きるわけではありません。",{"type":38,"tag":67,"props":68,"children":69},"strong",{},[70],{"type":43,"value":71},"失敗には典型的なパターンがあり、事前に兆候が出ます",{"type":43,"value":73},"。本記事では、",{"type":38,"tag":51,"props":75,"children":77},{"href":76},"\u002Farticles\u002Fyoken-teigi-susumekata\u002F",[78],{"type":43,"value":79},"要件定義の進め方",{"type":43,"value":81},"の関連記事として「失敗する側」から掘り下げ、よくある失敗の型、こうなっていたら危ないという兆候、防ぎ方、そして失敗してしまったときの立て直し方を整理します。",{"type":38,"tag":83,"props":84,"children":85},"blockquote",{},[86,94],{"type":38,"tag":39,"props":87,"children":88},{},[89],{"type":38,"tag":67,"props":90,"children":91},{},[92],{"type":43,"value":93},"この記事の要点",{"type":38,"tag":95,"props":96,"children":97},"ul",{},[98,104,109],{"type":38,"tag":99,"props":100,"children":101},"li",{},[102],{"type":43,"value":103},"要件定義の失敗は、①役割が置かれていない、②利用者を調べていない、③合意ができていない、④外注先に丸投げ、⑤作ること自体が目的、⑥粗い要件で金額を確定、の6パターンにほぼ集約できます",{"type":38,"tag":99,"props":105,"children":106},{},[107],{"type":43,"value":108},"防ぐ鍵は発注側にあります。業務の目的・利用者・やらないことを決めるのは発注側の役割で、開発会社に任せきりにしないことが最大の予防策です",{"type":38,"tag":99,"props":110,"children":111},{},[112],{"type":43,"value":113},"失敗しても立て直せます。いったん止めて現状を棚卸しし、目的と利用者に立ち返り、優先順位を決め直し、合意と進め方の型をつくる、の4ステップで進めます",{"type":38,"tag":115,"props":116,"children":118},"h2",{"id":117},"要件定義の失敗とは-作ったのに使われないいつまでも終わらない",[119],{"type":43,"value":120},"要件定義の失敗とは ―― 「作ったのに使われない」「いつまでも終わらない」",{"type":38,"tag":39,"props":122,"children":123},{},[124,126,131],{"type":43,"value":125},"要件定義の失敗とは、",{"type":38,"tag":67,"props":127,"children":128},{},[129],{"type":43,"value":130},"作るべきものについて関係者の合意がないまま開発に進み、後工程で大きな手戻りや「使われないシステム」を生むこと",{"type":43,"value":132},"です。要件定義書が完成していても、中身が現場の実態とずれていれば失敗です。",{"type":38,"tag":39,"props":134,"children":135},{},[136],{"type":43,"value":137},"失敗は、たいてい次のような形で表面化します。",{"type":38,"tag":139,"props":140,"children":141},"table",{},[142,161],{"type":38,"tag":143,"props":144,"children":145},"thead",{},[146],{"type":38,"tag":147,"props":148,"children":149},"tr",{},[150,156],{"type":38,"tag":151,"props":152,"children":153},"th",{},[154],{"type":43,"value":155},"表面化する症状",{"type":38,"tag":151,"props":157,"children":158},{},[159],{"type":43,"value":160},"実際に起きていること",{"type":38,"tag":162,"props":163,"children":164},"tbody",{},[165,179,192,205,218],{"type":38,"tag":147,"props":166,"children":167},{},[168,174],{"type":38,"tag":169,"props":170,"children":171},"td",{},[172],{"type":43,"value":173},"できあがったシステムが現場で使われない",{"type":38,"tag":169,"props":175,"children":176},{},[177],{"type":43,"value":178},"利用者の業務や困りごとを確かめないまま機能を決めた",{"type":38,"tag":147,"props":180,"children":181},{},[182,187],{"type":38,"tag":169,"props":183,"children":184},{},[185],{"type":43,"value":186},"開発中に仕様変更が止まらない",{"type":38,"tag":169,"props":188,"children":189},{},[190],{"type":43,"value":191},"関係者の合意がないまま「決まったこと」にしていた",{"type":38,"tag":147,"props":193,"children":194},{},[195,200],{"type":38,"tag":169,"props":196,"children":197},{},[198],{"type":43,"value":199},"見積もりから費用・期間が大きく膨らむ",{"type":38,"tag":169,"props":201,"children":202},{},[203],{"type":43,"value":204},"要件が粗い段階の金額が、そのまま予算として固定された",{"type":38,"tag":147,"props":206,"children":207},{},[208,213],{"type":38,"tag":169,"props":209,"children":210},{},[211],{"type":43,"value":212},"リリースが遅れ、理由も分からない",{"type":38,"tag":169,"props":214,"children":215},{},[216],{"type":43,"value":217},"何を優先するかの判断基準がなく、要望が都度流れ込んでいる",{"type":38,"tag":147,"props":219,"children":220},{},[221,226],{"type":38,"tag":169,"props":222,"children":223},{},[224],{"type":43,"value":225},"「言われた通りに作った」「頼んだものと違う」の言い合い",{"type":38,"tag":169,"props":227,"children":228},{},[229],{"type":43,"value":230},"何を決めるのが誰の役割か、発注側と開発側で認識がずれていた",{"type":38,"tag":39,"props":232,"children":233},{},[234],{"type":43,"value":235},"症状は開発やリリースの段階で出ますが、原因はその手前にあります。だからこそ、症状が出てから開発会社を責めても解決しません。",{"type":38,"tag":115,"props":237,"children":239},{"id":238},"要件定義が失敗する6つの典型パターンよくある失敗事例",[240],{"type":43,"value":241},"要件定義が失敗する6つの典型パターン（よくある失敗事例）",{"type":38,"tag":39,"props":243,"children":244},{},[245],{"type":43,"value":246},"K.S.Rogers が要件定義の相談を受ける中で見てきた失敗は、おおむね次の6パターンに分けられます。複数が同時に起きていることも珍しくありません。",{"type":38,"tag":248,"props":249,"children":250},"picture",{},[251,253,261,262],{"type":43,"value":252},"\n  ",{"type":38,"tag":254,"props":255,"children":260},"source",{"media":256,"srcSet":257,"width":258,"height":259},"(max-width: 768px)","\u002Fimg\u002Fcontents\u002Farticles\u002Fyoken-teigi-shippai-genin\u002Fshippai-patterns-sp.svg",420,716,[],{"type":43,"value":252},{"type":38,"tag":263,"props":264,"children":270},"img",{"src":265,"alt":266,"width":267,"height":268,"loading":269},"\u002Fimg\u002Fcontents\u002Farticles\u002Fyoken-teigi-shippai-genin\u002Fshippai-patterns.svg","要件定義が失敗する6つの典型パターン：役割が置かれていない、利用者を調べていない、合意ができていない、外注先に丸投げ、作ること自体が目的、粗い要件で金額を確定。それぞれの危ない兆候つき",800,380,"lazy",[],{"type":38,"tag":272,"props":273,"children":275},"h3",{"id":274},"パターン1要件定義の役割が置かれていない",[276],{"type":43,"value":277},"パターン1：要件定義の役割が置かれていない",{"type":38,"tag":39,"props":279,"children":280},{},[281,283,288],{"type":43,"value":282},"最も根本的な失敗です。発注側には「ビジネスは分かるがシステムは分からない」人しかおらず、開発側には「作れるが業務は分からない」人しかいない。その間で、",{"type":38,"tag":67,"props":284,"children":285},{},[286],{"type":43,"value":287},"要求を要件に翻訳し、決める人",{"type":43,"value":289},"がいない状態です。",{"type":38,"tag":39,"props":291,"children":292},{},[293,295,302],{"type":43,"value":294},"すると要望は整理されないまま開発に流れ込み、エンジニアが「たぶんこういうことだろう」と都度判断して作ることになります。K.S.Rogers が支援した",{"type":38,"tag":51,"props":296,"children":299},{"href":297,"rel":298},"https:\u002F\u002Fks-rogers.co.jp\u002Frd\u002Fcase-studies\u002Fcase-study-5\u002F",[55],[300],{"type":43,"value":301},"オンライン診療プロダクトの事例",{"type":43,"value":303},"でも、参画時には要件定義を担うPdM（プロダクトマネージャー）が不在で、CS・医療従事者・経営それぞれの要求が同じ土俵で整理されないまま開発に流れ込んでいました。その結果、優先順位が「説明できる基準」ではなく、その場の状況や声の大きさに引っ張られていたといいます。",{"type":38,"tag":272,"props":305,"children":307},{"id":306},"パターン2利用者を調べていない",[308],{"type":43,"value":309},"パターン2：利用者を調べていない",{"type":38,"tag":39,"props":311,"children":312},{},[313,315,320],{"type":43,"value":314},"経営層や企画担当が頭の中で描いた業務を前提に機能を決め、",{"type":38,"tag":67,"props":316,"children":317},{},[318],{"type":43,"value":319},"実際に使う人の業務を確かめていない",{"type":43,"value":321},"パターンです。現場には、会議室では見えない例外処理や、別部署が裏で抱えている手作業があります。",{"type":38,"tag":39,"props":323,"children":324},{},[325],{"type":43,"value":326},"ここを見落とすと、システムは完成しても「今のやり方のほうが早い」と使われなくなります。要件定義の段階で利用予定者に話を聞き、現状の業務フローを一度描いてみるだけでも、ずれの多くは事前に見つかります。",{"type":38,"tag":272,"props":328,"children":330},{"id":329},"パターン3合意ができていないやらないことが決まっていない",[331],{"type":43,"value":332},"パターン3：合意ができていない（やらないことが決まっていない）",{"type":38,"tag":39,"props":334,"children":335},{},[336],{"type":43,"value":337},"関係者が多いプロジェクトほど起きやすいのが、合意形成の不足です。会議で話したことが「決まったこと」として扱われていても、影響を受ける部署が呼ばれていなかったり、決裁者が内容を理解していなかったりすると、開発が進んでから「聞いていない」「思っていたのと違う」が出てきます。",{"type":38,"tag":39,"props":339,"children":340},{},[341,343,348],{"type":43,"value":342},"特に抜けやすいのが「",{"type":38,"tag":67,"props":344,"children":345},{},[346],{"type":43,"value":347},"今回はやらないこと",{"type":43,"value":349},"」の合意です。やることだけを並べた要件定義書は、読む人によって範囲の解釈が変わります。対象外にしたものと、その理由を残しておかないと、開発中に要望が膨らみ続けます。",{"type":38,"tag":272,"props":351,"children":353},{"id":352},"パターン4システム開発を外注先に丸投げする",[354],{"type":43,"value":355},"パターン4：システム開発を外注先に丸投げする",{"type":38,"tag":39,"props":357,"children":358},{},[359,361,366],{"type":43,"value":360},"「餅は餅屋」と開発会社にすべてを任せ、発注側は完成を待つだけ、というパターンです。後の章で詳しく扱いますが、開発会社は発注側の業務の優先順位や社内事情を知りません。",{"type":38,"tag":67,"props":362,"children":363},{},[364],{"type":43,"value":365},"決めるべきことを決めないまま任せる",{"type":43,"value":367},"と、開発会社は仕様書に書かれた範囲で作るしかなく、結果として「言われた通りに作ったのに使われない」システムになります。",{"type":38,"tag":272,"props":369,"children":371},{"id":370},"パターン5作ること自体が目的になる",[372],{"type":43,"value":373},"パターン5：作ること自体が目的になる",{"type":38,"tag":39,"props":375,"children":376},{},[377,379,384,386,393],{"type":43,"value":378},"「AIで何かしたい」「アプリを作りたい」という手段が先に立ち、",{"type":38,"tag":67,"props":380,"children":381},{},[382],{"type":43,"value":383},"なぜ作るのか、誰の何が良くなるのか",{"type":43,"value":385},"が言葉になっていないパターンです。K.S.Rogers のメンバーへのインタビューでも、よくある苦労として「作ること自体が目的化」するケースが挙がっています。そうしたときは、既存のツールで足りないかを例に出して「なぜ今あえて作るのか」を問い直すといいます（",{"type":38,"tag":51,"props":387,"children":390},{"href":388,"rel":389},"https:\u002F\u002Fks-rogers.co.jp\u002Frd\u002Finterviews\u002F",[55],[391],{"type":43,"value":392},"要件定義インタビュー一覧",{"type":43,"value":394},"）。",{"type":38,"tag":39,"props":396,"children":397},{},[398],{"type":43,"value":399},"目的が1文で言えないまま進むと、機能の優先順位を判断する基準がないため、要件はいつまでも固まりません。",{"type":38,"tag":272,"props":401,"children":403},{"id":402},"パターン6粗い要件の段階で金額を確定させる",[404],{"type":43,"value":405},"パターン6：粗い要件の段階で金額を確定させる",{"type":38,"tag":39,"props":407,"children":408},{},[409],{"type":43,"value":410},"構想段階でもらった概算見積もりが、そのまま社内の予算として固定されてしまうパターンです。要件が決まっていない段階の見積もりは、どうしても幅が大きくなります。それを確定額として扱うと、要件が具体化するにつれて「予算に収めるために必要な機能を削る」「追加費用で揉める」のどちらかに陥ります。",{"type":38,"tag":39,"props":412,"children":413},{},[414,416,421],{"type":43,"value":415},"このパターンは要件定義そのものの失敗というより、",{"type":38,"tag":67,"props":417,"children":418},{},[419],{"type":43,"value":420},"要件定義と見積もり・発注の順番の失敗",{"type":43,"value":422},"です。防ぎ方は後の章で整理します。",{"type":38,"tag":115,"props":424,"children":426},{"id":425},"こうなっていたら危ない-要件定義の失敗の兆候チェックリスト",[427],{"type":43,"value":428},"こうなっていたら危ない ―― 要件定義の失敗の兆候チェックリスト",{"type":38,"tag":39,"props":430,"children":431},{},[432,434,439],{"type":43,"value":433},"失敗は、開発が終わってから突然明らかになるわけではありません。途中で兆候が出ています。プロジェクトの段階ごとに、次の項目を確認してみてください。",{"type":38,"tag":67,"props":435,"children":436},{},[437],{"type":43,"value":438},"2つ以上当てはまる場合は、開発に進む前に（または開発を続ける前に）要件定義を見直す",{"type":43,"value":440},"ことをおすすめします。",{"type":38,"tag":272,"props":442,"children":444},{"id":443},"見積もり発注の前",[445],{"type":43,"value":446},"見積もり・発注の前",{"type":38,"tag":95,"props":448,"children":451},{"className":449},[450],"contains-task-list",[452,465,474,483],{"type":38,"tag":99,"props":453,"children":456},{"className":454},[455],"task-list-item",[457,463],{"type":38,"tag":458,"props":459,"children":462},"input",{"disabled":460,"type":461},true,"checkbox",[],{"type":43,"value":464}," 「なぜこのシステムが必要か」を、関係者の誰もが同じ1文で言えない",{"type":38,"tag":99,"props":466,"children":468},{"className":467},[455],[469,472],{"type":38,"tag":458,"props":470,"children":471},{"disabled":460,"type":461},[],{"type":43,"value":473}," 発注側で、要件を決める担当者と最終判断する人が決まっていない",{"type":38,"tag":99,"props":475,"children":477},{"className":476},[455],[478,481],{"type":38,"tag":458,"props":479,"children":480},{"disabled":460,"type":461},[],{"type":43,"value":482}," 実際に使う人に、まだ一度も話を聞いていない",{"type":38,"tag":99,"props":484,"children":486},{"className":485},[455],[487,490],{"type":38,"tag":458,"props":488,"children":489},{"disabled":460,"type":461},[],{"type":43,"value":491}," 構想段階の概算見積もりが、すでに確定予算として社内で通っている",{"type":38,"tag":272,"props":493,"children":495},{"id":494},"要件定義の最中",[496],{"type":43,"value":494},{"type":38,"tag":95,"props":498,"children":500},{"className":499},[450],[501,510,519,528,537],{"type":38,"tag":99,"props":502,"children":504},{"className":503},[455],[505,508],{"type":38,"tag":458,"props":506,"children":507},{"disabled":460,"type":461},[],{"type":43,"value":509}," 会議のたびに前提や優先順位が変わる",{"type":38,"tag":99,"props":511,"children":513},{"className":512},[455],[514,517],{"type":38,"tag":458,"props":515,"children":516},{"disabled":460,"type":461},[],{"type":43,"value":518}," 要件定義書に「今回やらないこと」が書かれていない",{"type":38,"tag":99,"props":520,"children":522},{"className":521},[455],[523,526],{"type":38,"tag":458,"props":524,"children":525},{"disabled":460,"type":461},[],{"type":43,"value":527}," 開発会社からの質問に、発注側の誰も即答できず、回答が1週間以上止まる",{"type":38,"tag":99,"props":529,"children":531},{"className":530},[455],[532,535],{"type":38,"tag":458,"props":533,"children":534},{"disabled":460,"type":461},[],{"type":43,"value":536}," 画面イメージやモックアップを、利用者の代表が見ていない",{"type":38,"tag":99,"props":538,"children":540},{"className":539},[455],[541,544],{"type":38,"tag":458,"props":542,"children":543},{"disabled":460,"type":461},[],{"type":43,"value":545}," 「とりあえず全部入れておいて」という発言が出る",{"type":38,"tag":272,"props":547,"children":549},{"id":548},"開発が始まってから",[550],{"type":43,"value":548},{"type":38,"tag":95,"props":552,"children":554},{"className":553},[450],[555,564,573,582],{"type":38,"tag":99,"props":556,"children":558},{"className":557},[455],[559,562],{"type":38,"tag":458,"props":560,"children":561},{"disabled":460,"type":461},[],{"type":43,"value":563}," 「それは聞いていない」「前に話したはず」のやりとりが続く",{"type":38,"tag":99,"props":565,"children":567},{"className":566},[455],[568,571],{"type":38,"tag":458,"props":569,"children":570},{"disabled":460,"type":461},[],{"type":43,"value":572}," 新しい要望と不具合対応が区別されず、開発の優先順位が毎週変わる",{"type":38,"tag":99,"props":574,"children":576},{"className":575},[455],[577,580],{"type":38,"tag":458,"props":578,"children":579},{"disabled":460,"type":461},[],{"type":43,"value":581}," リリースが遅れているが、何がボトルネックか誰も説明できない",{"type":38,"tag":99,"props":583,"children":585},{"className":584},[455],[586,589],{"type":38,"tag":458,"props":587,"children":588},{"disabled":460,"type":461},[],{"type":43,"value":590}," エンジニアが仕様を推測しながら実装している",{"type":38,"tag":39,"props":592,"children":593},{},[594],{"type":43,"value":595},"兆候の多くは「決める人がいない」「決めたことが共有されていない」の2つに行き着きます。逆に言えば、この2つを押さえるだけで、失敗の確率は大きく下げられます。",{"type":38,"tag":115,"props":597,"children":599},{"id":598},"システム開発を外注に丸投げすると失敗する理由",[600],{"type":43,"value":598},{"type":38,"tag":39,"props":602,"children":603},{},[604,606,610,612,617],{"type":43,"value":605},"システム開発を外部に頼むこと自体は、まったく悪いことではありません。問題は「",{"type":38,"tag":67,"props":607,"children":608},{},[609],{"type":43,"value":16},{"type":43,"value":611},"」と「",{"type":38,"tag":67,"props":613,"children":614},{},[615],{"type":43,"value":616},"丸投げ",{"type":43,"value":618},"」を混同することです。",{"type":38,"tag":272,"props":620,"children":622},{"id":621},"発注側にしか決められないことがある",[623],{"type":43,"value":621},{"type":38,"tag":39,"props":625,"children":626},{},[627,629,635],{"type":43,"value":628},"IPA の要件定義ガイドでは、システムの要件を定義する責任は、構築されたシステムを使ってビジネスに貢献する役目を負うユーザ（発注側）にあると言われている、と述べられています。そのうえで、ITベンダやシステム部門が中心になって要件定義を進めるスタイルから、業務部門のユーザが主体的に関与するスタイルへの変革の必要性が増している、としています（",{"type":38,"tag":51,"props":630,"children":632},{"href":53,"rel":631},[55],[633],{"type":43,"value":634},"IPA「ユーザのための要件定義ガイド 第2版」",{"type":43,"value":394},{"type":38,"tag":39,"props":637,"children":638},{},[639],{"type":43,"value":640},"発注側と開発側の役割を分けると、次のようになります。",{"type":38,"tag":139,"props":642,"children":643},{},[644,665],{"type":38,"tag":143,"props":645,"children":646},{},[647],{"type":38,"tag":147,"props":648,"children":649},{},[650,655,660],{"type":38,"tag":151,"props":651,"children":652},{},[653],{"type":43,"value":654},"項目",{"type":38,"tag":151,"props":656,"children":657},{},[658],{"type":43,"value":659},"発注側が決めること",{"type":38,"tag":151,"props":661,"children":662},{},[663],{"type":43,"value":664},"開発側が担うこと",{"type":38,"tag":162,"props":666,"children":667},{},[668,686,704,722,740,758],{"type":38,"tag":147,"props":669,"children":670},{},[671,676,681],{"type":38,"tag":169,"props":672,"children":673},{},[674],{"type":43,"value":675},"目的",{"type":38,"tag":169,"props":677,"children":678},{},[679],{"type":43,"value":680},"なぜ作るのか、何が良くなれば成功か",{"type":38,"tag":169,"props":682,"children":683},{},[684],{"type":43,"value":685},"目的に合う実現方法の提案",{"type":38,"tag":147,"props":687,"children":688},{},[689,694,699],{"type":38,"tag":169,"props":690,"children":691},{},[692],{"type":43,"value":693},"利用者・業務",{"type":38,"tag":169,"props":695,"children":696},{},[697],{"type":43,"value":698},"誰が、どの業務で、どう使うか",{"type":38,"tag":169,"props":700,"children":701},{},[702],{"type":43,"value":703},"業務に合う画面・操作の設計",{"type":38,"tag":147,"props":705,"children":706},{},[707,712,717],{"type":38,"tag":169,"props":708,"children":709},{},[710],{"type":43,"value":711},"優先順位",{"type":38,"tag":169,"props":713,"children":714},{},[715],{"type":43,"value":716},"何を先に作り、何をやらないか",{"type":38,"tag":169,"props":718,"children":719},{},[720],{"type":43,"value":721},"優先順位ごとの工数・期間の見積もり",{"type":38,"tag":147,"props":723,"children":724},{},[725,730,735],{"type":38,"tag":169,"props":726,"children":727},{},[728],{"type":43,"value":729},"例外・ルール",{"type":38,"tag":169,"props":731,"children":732},{},[733],{"type":43,"value":734},"例外時の扱い、社内ルール",{"type":38,"tag":169,"props":736,"children":737},{},[738],{"type":43,"value":739},"ルールを実装できる形に落とす",{"type":38,"tag":147,"props":741,"children":742},{},[743,748,753],{"type":38,"tag":169,"props":744,"children":745},{},[746],{"type":43,"value":747},"判断・承認",{"type":38,"tag":169,"props":749,"children":750},{},[751],{"type":43,"value":752},"要件の最終承認、変更の可否",{"type":38,"tag":169,"props":754,"children":755},{},[756],{"type":43,"value":757},"変更による影響範囲の説明",{"type":38,"tag":147,"props":759,"children":760},{},[761,766,771],{"type":38,"tag":169,"props":762,"children":763},{},[764],{"type":43,"value":765},"受け入れ",{"type":38,"tag":169,"props":767,"children":768},{},[769],{"type":43,"value":770},"業務で使えるかの確認",{"type":38,"tag":169,"props":772,"children":773},{},[774],{"type":43,"value":775},"仕様どおり動くかのテスト",{"type":38,"tag":39,"props":777,"children":778},{},[779],{"type":43,"value":780},"左の列を開発会社に任せることはできません。開発会社が善意で推測して作っても、それは発注側の意図と一致する保証がないからです。",{"type":38,"tag":39,"props":782,"children":783},{},[784,786,792],{"type":43,"value":785},"発注側と開発側がそれぞれ何を担うかは、",{"type":38,"tag":51,"props":787,"children":789},{"href":788},"\u002Farticles\u002Fyoken-teigi-hacchu-kaihatsu-yakuwari\u002F",[790],{"type":43,"value":791},"要件定義シリーズ 第1回：システム開発の発注側と開発側の役割分担",{"type":43,"value":793},"で、工程ごとに詳しく整理しています。",{"type":38,"tag":272,"props":795,"children":797},{"id":796},"丸投げと伴走の違い",[798],{"type":43,"value":799},"「丸投げ」と「伴走」の違い",{"type":38,"tag":39,"props":801,"children":802},{},[803,805,810],{"type":43,"value":804},"社内に要件定義の経験者がいない場合、要件定義そのものを外部の専門家に頼むのは有効な選択肢です。ただし、それは丸投げではなく",{"type":38,"tag":67,"props":806,"children":807},{},[808],{"type":43,"value":809},"伴走",{"type":43,"value":811},"でなければいけません。",{"type":38,"tag":95,"props":813,"children":814},{},[815,824],{"type":38,"tag":99,"props":816,"children":817},{},[818,822],{"type":38,"tag":67,"props":819,"children":820},{},[821],{"type":43,"value":616},{"type":43,"value":823},"：決める作業も判断も外部に任せ、発注側は完成物を受け取るだけ",{"type":38,"tag":99,"props":825,"children":826},{},[827,831],{"type":38,"tag":67,"props":828,"children":829},{},[830],{"type":43,"value":809},{"type":43,"value":832},"：ヒアリング・整理・ドキュメント化は外部が担い、発注側はレビュー・承認・意思決定を担う",{"type":38,"tag":39,"props":834,"children":835},{},[836,838,845],{"type":43,"value":837},"K.S.Rogers が支援した",{"type":38,"tag":51,"props":839,"children":842},{"href":840,"rel":841},"https:\u002F\u002Fks-rogers.co.jp\u002Frd\u002Fcase-studies\u002Fcase-study-6\u002F",[55],[843],{"type":43,"value":844},"HRスカウト業務のAI効率化の事例",{"type":43,"value":846},"でも、ヒアリングとアウトプットの取りまとめは支援側が担い、クライアントは提示案のレビュー・承認・意思決定を行う、という役割分担で進めています。作業を外に出しても、決める権限は発注側に残す。これが丸投げとの違いです。",{"type":38,"tag":272,"props":848,"children":850},{"id":849},"外部に頼む前に整理しておく3つのこと",[851],{"type":43,"value":849},{"type":38,"tag":39,"props":853,"children":854},{},[855,862],{"type":38,"tag":51,"props":856,"children":859},{"href":857,"rel":858},"https:\u002F\u002Fks-rogers.co.jp\u002Frd\u002Fcase-studies\u002Fcase-study-7\u002F",[55],[860],{"type":43,"value":861},"音声ライブ配信アプリの開発体制を整えた事例",{"type":43,"value":863},"では、初めて外部支援者を使う発注者に向けて、事前に次の3つを整理しておくとよい、とアドバイスしています。",{"type":38,"tag":865,"props":866,"children":867},"ol",{},[868,873,878],{"type":38,"tag":99,"props":869,"children":870},{},[871],{"type":43,"value":872},"自社の課題を、できるだけ明確に言葉にしておく",{"type":38,"tag":99,"props":874,"children":875},{},[876],{"type":43,"value":877},"それをいつまでに、どう解決したいか、ざっくりしたイメージを持っておく",{"type":38,"tag":99,"props":879,"children":880},{},[881],{"type":43,"value":882},"自社にどの程度の知見があるかを把握しておく",{"type":38,"tag":39,"props":884,"children":885},{},[886],{"type":43,"value":887},"完璧に整理できていなくても構いません。この3点が共有されているほど、外部の支援者は的確に入り込めます。",{"type":38,"tag":115,"props":889,"children":891},{"id":890},"見積もり時点の要件の粒度-金額はいつ確定させるべきか",[892],{"type":43,"value":893},"見積もり時点の要件の粒度 ―― 金額はいつ確定させるべきか",{"type":38,"tag":39,"props":895,"children":896},{},[897,899,904],{"type":43,"value":898},"パターン6の「粗い要件で金額を確定」を防ぐには、",{"type":38,"tag":67,"props":900,"children":901},{},[902],{"type":43,"value":903},"要件がどこまで決まっているかによって、見積もりの確かさが変わる",{"type":43,"value":905},"ことを発注側が理解しておく必要があります。",{"type":38,"tag":248,"props":907,"children":908},{},[909,910,915,916],{"type":43,"value":252},{"type":38,"tag":254,"props":911,"children":914},{"media":256,"srcSet":912,"width":258,"height":913},"\u002Fimg\u002Fcontents\u002Farticles\u002Fyoken-teigi-shippai-genin\u002Fmitsumori-ryudo-sp.svg",702,[],{"type":43,"value":252},{"type":38,"tag":263,"props":917,"children":921},{"src":918,"alt":919,"width":267,"height":920,"loading":269},"\u002Fimg\u002Fcontents\u002Farticles\u002Fyoken-teigi-shippai-genin\u002Fmitsumori-ryudo.svg","見積もり時点の要件の粒度：構想だけの段階は見積もりの幅が大きく要件定義を先に依頼、要求を言語化した段階は範囲つきの概算で予算枠を確保、要件定義済みの段階で確度の高い見積もりにより開発を発注",376,[],{"type":38,"tag":139,"props":923,"children":924},{},[925,946],{"type":38,"tag":143,"props":926,"children":927},{},[928],{"type":38,"tag":147,"props":929,"children":930},{},[931,936,941],{"type":38,"tag":151,"props":932,"children":933},{},[934],{"type":43,"value":935},"要件の粒度",{"type":38,"tag":151,"props":937,"children":938},{},[939],{"type":43,"value":940},"決まっていること",{"type":38,"tag":151,"props":942,"children":943},{},[944],{"type":43,"value":945},"見積もりの扱い方",{"type":38,"tag":162,"props":947,"children":948},{},[949,967,985],{"type":38,"tag":147,"props":950,"children":951},{},[952,957,962],{"type":38,"tag":169,"props":953,"children":954},{},[955],{"type":43,"value":956},"構想だけ",{"type":38,"tag":169,"props":958,"children":959},{},[960],{"type":43,"value":961},"やりたいことのイメージ",{"type":38,"tag":169,"props":963,"children":964},{},[965],{"type":43,"value":966},"金額は参考程度。要件定義を切り出して先に依頼する",{"type":38,"tag":147,"props":968,"children":969},{},[970,975,980],{"type":38,"tag":169,"props":971,"children":972},{},[973],{"type":43,"value":974},"要求を言語化",{"type":38,"tag":169,"props":976,"children":977},{},[978],{"type":43,"value":979},"目的、利用者、ゴール、やらないこと",{"type":38,"tag":169,"props":981,"children":982},{},[983],{"type":43,"value":984},"範囲つきの概算で予算の枠を確保する",{"type":38,"tag":147,"props":986,"children":987},{},[988,993,998],{"type":38,"tag":169,"props":989,"children":990},{},[991],{"type":43,"value":992},"要件定義済み",{"type":38,"tag":169,"props":994,"children":995},{},[996],{"type":43,"value":997},"機能、画面、データ、例外の扱い、優先順位",{"type":38,"tag":169,"props":999,"children":1000},{},[1001],{"type":43,"value":1002},"開発の見積もりを取り、比較して発注する",{"type":38,"tag":39,"props":1004,"children":1005},{},[1006,1008,1013,1015,1022],{"type":43,"value":1007},"ポイントは、",{"type":38,"tag":67,"props":1009,"children":1010},{},[1011],{"type":43,"value":1012},"要件定義と開発を分けて考える",{"type":43,"value":1014},"ことです。構想段階でいきなり「開発一式」の見積もりを取るのではなく、まず要件定義を進め、決まった要件をもとに開発を見積もる。IPA が公開している",{"type":38,"tag":51,"props":1016,"children":1019},{"href":1017,"rel":1018},"https:\u002F\u002Fwww.ipa.go.jp\u002Fdigital\u002Fmodel\u002Fmodel20201222.html",[55],[1020],{"type":43,"value":1021},"「情報システム・モデル取引・契約書」",{"type":43,"value":1023},"でも、システム開発における複数契約の関係が見直しのポイントとして整理されており、工程ごとの契約の考え方を確認する資料として参考になります。",{"type":38,"tag":39,"props":1025,"children":1026},{},[1027],{"type":43,"value":1028},"社内稟議の都合でどうしても早い段階に金額が必要な場合は、「この金額は構想段階の概算で、要件定義後に見直す」ことを稟議書に明記しておくだけでも、後の揉めごとを減らせます。",{"type":38,"tag":115,"props":1030,"children":1032},{"id":1031},"要件定義の失敗を防ぐ方法",[1033],{"type":43,"value":1031},{"type":38,"tag":39,"props":1035,"children":1036},{},[1037],{"type":43,"value":1038},"6つのパターンそれぞれに、打ち手があります。",{"type":38,"tag":139,"props":1040,"children":1041},{},[1042,1063],{"type":38,"tag":143,"props":1043,"children":1044},{},[1045],{"type":38,"tag":147,"props":1046,"children":1047},{},[1048,1053,1058],{"type":38,"tag":151,"props":1049,"children":1050},{},[1051],{"type":43,"value":1052},"失敗パターン",{"type":38,"tag":151,"props":1054,"children":1055},{},[1056],{"type":43,"value":1057},"防ぎ方",{"type":38,"tag":151,"props":1059,"children":1060},{},[1061],{"type":43,"value":1062},"最初にやること",{"type":38,"tag":162,"props":1064,"children":1065},{},[1066,1084,1102,1120,1138,1156],{"type":38,"tag":147,"props":1067,"children":1068},{},[1069,1074,1079],{"type":38,"tag":169,"props":1070,"children":1071},{},[1072],{"type":43,"value":1073},"1. 役割が置かれていない",{"type":38,"tag":169,"props":1075,"children":1076},{},[1077],{"type":43,"value":1078},"ビジネスとシステムの両方が分かる人を1人置く（社内でも外部でも可）",{"type":38,"tag":169,"props":1080,"children":1081},{},[1082],{"type":43,"value":1083},"要件を決める担当者と最終承認者を決める",{"type":38,"tag":147,"props":1085,"children":1086},{},[1087,1092,1097],{"type":38,"tag":169,"props":1088,"children":1089},{},[1090],{"type":43,"value":1091},"2. 利用者を調べていない",{"type":38,"tag":169,"props":1093,"children":1094},{},[1095],{"type":43,"value":1096},"利用予定者へのヒアリングと現状の業務フローの可視化",{"type":38,"tag":169,"props":1098,"children":1099},{},[1100],{"type":43,"value":1101},"代表的な利用者3〜5人に話を聞く",{"type":38,"tag":147,"props":1103,"children":1104},{},[1105,1110,1115],{"type":38,"tag":169,"props":1106,"children":1107},{},[1108],{"type":43,"value":1109},"3. 合意ができていない",{"type":38,"tag":169,"props":1111,"children":1112},{},[1113],{"type":43,"value":1114},"関係者の一覧化、やらないことの明文化、承認の記録",{"type":38,"tag":169,"props":1116,"children":1117},{},[1118],{"type":43,"value":1119},"影響を受ける部署を洗い出す",{"type":38,"tag":147,"props":1121,"children":1122},{},[1123,1128,1133],{"type":38,"tag":169,"props":1124,"children":1125},{},[1126],{"type":43,"value":1127},"4. 外注先に丸投げ",{"type":38,"tag":169,"props":1129,"children":1130},{},[1131],{"type":43,"value":1132},"発注側が決めることを決め、外部には作業と整理を任せる",{"type":38,"tag":169,"props":1134,"children":1135},{},[1136],{"type":43,"value":1137},"前章の役割分担表で自社の担当を埋める",{"type":38,"tag":147,"props":1139,"children":1140},{},[1141,1146,1151],{"type":38,"tag":169,"props":1142,"children":1143},{},[1144],{"type":43,"value":1145},"5. 作ること自体が目的",{"type":38,"tag":169,"props":1147,"children":1148},{},[1149],{"type":43,"value":1150},"目的と成功の判断基準を1〜2文で書く",{"type":38,"tag":169,"props":1152,"children":1153},{},[1154],{"type":43,"value":1155},"「何が、どうなれば成功か」を書き出す",{"type":38,"tag":147,"props":1157,"children":1158},{},[1159,1164,1169],{"type":38,"tag":169,"props":1160,"children":1161},{},[1162],{"type":43,"value":1163},"6. 粗い要件で金額を確定",{"type":38,"tag":169,"props":1165,"children":1166},{},[1167],{"type":43,"value":1168},"要件定義と開発を分けて発注する",{"type":38,"tag":169,"props":1170,"children":1171},{},[1172],{"type":43,"value":1173},"概算を「参考値」として社内に伝える",{"type":38,"tag":39,"props":1175,"children":1176},{},[1177],{"type":43,"value":1178},"表の中でも特に効果が大きいのが、パターン1への打ち手です。K.S.Rogers のメンバーは、要件定義で悩む企業へのアドバイスをこう話します。",{"type":38,"tag":83,"props":1180,"children":1181},{},[1182],{"type":38,"tag":39,"props":1183,"children":1184},{},[1185],{"type":43,"value":1186},"まずは、ビジネスとテクノロジーの両方が分かる人を一人置くことです。やりたいことが曖昧なままPMを採用しても、会話がかみ合いません。",{"type":38,"tag":39,"props":1188,"children":1189},{},[1190,1192,1196],{"type":43,"value":1191},"その人がいれば、利用者の調査も合意形成も「誰かがやるだろう」ではなく、担当として進みます。要件定義の具体的な進め方（5ステップ、ヒアリングの質問例、チェックリスト）は、",{"type":38,"tag":51,"props":1193,"children":1194},{"href":76},[1195],{"type":43,"value":79},{"type":43,"value":1197},"で詳しく解説しています。",{"type":38,"tag":115,"props":1199,"children":1201},{"id":1200},"失敗した要件定義の立て直し方4ステップ",[1202],{"type":43,"value":1203},"失敗した要件定義の立て直し方（4ステップ）",{"type":38,"tag":39,"props":1205,"children":1206},{},[1207],{"type":43,"value":1208},"すでに開発が始まっていて、上の兆候がいくつも出ている。そんな場合でも、プロジェクトは立て直せます。K.S.Rogers の支援では、次の4ステップで進めることが多くあります。",{"type":38,"tag":248,"props":1210,"children":1211},{},[1212,1213,1218,1219],{"type":43,"value":252},{"type":38,"tag":254,"props":1214,"children":1217},{"media":256,"srcSet":1215,"width":258,"height":1216},"\u002Fimg\u002Fcontents\u002Farticles\u002Fyoken-teigi-shippai-genin\u002Ftatenaoshi-4steps-sp.svg",474,[],{"type":43,"value":252},{"type":38,"tag":263,"props":1220,"children":1224},{"src":1221,"alt":1222,"width":267,"height":1223,"loading":269},"\u002Fimg\u002Fcontents\u002Farticles\u002Fyoken-teigi-shippai-genin\u002Ftatenaoshi-4steps.svg","失敗した要件定義の立て直し方4ステップ：いったん止めて現状を棚卸しする、目的と利用者に立ち返る、優先順位とやらないことを決め直す、合意と進め方の型をつくる",260,[],{"type":38,"tag":272,"props":1226,"children":1228},{"id":1227},"_1-いったん止めて現状を棚卸しする",[1229],{"type":43,"value":1230},"1. いったん止めて、現状を棚卸しする",{"type":38,"tag":39,"props":1232,"children":1233},{},[1234],{"type":43,"value":1235},"走りながら直そうとすると、手戻りが手戻りを呼びます。新しい機能の追加をいったん止め、主要な関係者に一通り話を聞いて、それぞれが何に困っているかを集めます。",{"type":38,"tag":39,"props":1237,"children":1238},{},[1239,1244,1246,1251],{"type":38,"tag":51,"props":1240,"children":1242},{"href":297,"rel":1241},[55],[1243],{"type":43,"value":301},{"type":43,"value":1245},"では、最初に主要ポジションの人たちへのヒアリングで課題を集め、レポートとして示して共通認識をつくりました。いきなり「要件定義プロセスを入れます」と言うと、「今まで回っていたのになぜ？」と反発されやすいため、",{"type":38,"tag":67,"props":1247,"children":1248},{},[1249],{"type":43,"value":1250},"みんなが困っている点を先に言葉にする",{"type":43,"value":1252},"ことから入っています。",{"type":38,"tag":272,"props":1254,"children":1256},{"id":1255},"_2-目的と利用者に立ち返る",[1257],{"type":43,"value":1258},"2. 目的と利用者に立ち返る",{"type":38,"tag":39,"props":1260,"children":1261},{},[1262],{"type":43,"value":1263},"次に「そもそも誰の、どんな課題を解決するシステムか」に戻ります。現状の業務フロー（As-Is）を描き、利用者のどこで時間がかかっているか、どの判断が重いかを確かめます。",{"type":38,"tag":39,"props":1265,"children":1266},{},[1267,1273],{"type":38,"tag":51,"props":1268,"children":1270},{"href":840,"rel":1269},[55],[1271],{"type":43,"value":1272},"HRスカウト業務の事例",{"type":43,"value":1274},"では、「AIで効率化したい」というアイデアが先行し、目的や利用者の困りごとがはっきりしない状態から、まず利用者と現状の業務フローの整理に着手しました。現状が明確でなければ、あるべき姿は設計できないという考え方です。",{"type":38,"tag":272,"props":1276,"children":1278},{"id":1277},"_3-優先順位とやらないことを決め直す",[1279],{"type":43,"value":1280},"3. 優先順位とやらないことを決め直す",{"type":38,"tag":39,"props":1282,"children":1283},{},[1284,1286,1291],{"type":43,"value":1285},"目的と利用者が見えたら、優先順位を決め直します。このとき、感覚ではなく",{"type":38,"tag":67,"props":1287,"children":1288},{},[1289],{"type":43,"value":1290},"効果の試算",{"type":43,"value":1292},"を材料にすると、議論が前に進みます。HRスカウト業務の事例では、作業にかかっている時間や月の件数をヒアリングして投資対効果を試算し、予算と期間の中で効果の高い範囲に絞り込みました。その結果、2か月でプロトタイプと、開発に引き渡せる定義ドキュメント一式まで仕上げています。数字を厳密に当てることよりも、「投資対効果を議論できる土俵」をつくることが重要だったといいます。",{"type":38,"tag":272,"props":1294,"children":1296},{"id":1295},"_4-合意と進め方の型をつくる",[1297],{"type":43,"value":1298},"4. 合意と進め方の型をつくる",{"type":38,"tag":39,"props":1300,"children":1301},{},[1302],{"type":43,"value":1303},"最後に、同じ失敗を繰り返さない仕組みを残します。",{"type":38,"tag":95,"props":1305,"children":1306},{},[1307,1312,1317],{"type":38,"tag":99,"props":1308,"children":1309},{},[1310],{"type":43,"value":1311},"要件を決める人・確認する人・実装する人の流れを決める",{"type":38,"tag":99,"props":1313,"children":1314},{},[1315],{"type":43,"value":1316},"要件定義書の承認の流れをつくり、誰がいつ合意したかを記録する",{"type":38,"tag":99,"props":1318,"children":1319},{},[1320],{"type":43,"value":1321},"半年〜1年のロードマップや WBS（作業と期限の一覧）で、何をいつまでに決めるかを見えるようにする",{"type":38,"tag":39,"props":1323,"children":1324},{},[1325,1331],{"type":38,"tag":51,"props":1326,"children":1328},{"href":857,"rel":1327},[55],[1329],{"type":43,"value":1330},"音声ライブ配信アプリの事例",{"type":43,"value":1332},"では、WBS で開発工程を見えるようにし、要望をそのまま開発に流さず開発要件に変換する流れをつくったことで、緊急対応に追われる状態から、1〜2か月に一度リリースを回せる体制へ変わりました。オンライン診療プロダクトの事例でも、ロードマップと要求定義書をセットで出すことで「思っていたのと違う」が減り、3〜6か月ほどで変化が見え始めたといいます。",{"type":38,"tag":272,"props":1334,"children":1336},{"id":1335},"立て直しのときに避けたいこと",[1337],{"type":43,"value":1335},{"type":38,"tag":39,"props":1339,"children":1340},{},[1341],{"type":43,"value":1342},"立て直しの場面では、焦りから次のような動きが出がちです。どれも問題を先送りにするだけなので注意します。",{"type":38,"tag":95,"props":1344,"children":1345},{},[1346,1356,1366,1376],{"type":38,"tag":99,"props":1347,"children":1348},{},[1349,1354],{"type":38,"tag":67,"props":1350,"children":1351},{},[1352],{"type":43,"value":1353},"開発会社を替えて、同じ要件で作り直す",{"type":43,"value":1355},"：原因が要件定義にある場合、作り手を替えても同じずれが再現します",{"type":38,"tag":99,"props":1357,"children":1358},{},[1359,1364],{"type":38,"tag":67,"props":1360,"children":1361},{},[1362],{"type":43,"value":1363},"全機能を作り切ってから見直す",{"type":43,"value":1365},"：作り込むほど手戻りの費用は大きくなります。止める判断は早いほど安く済みます",{"type":38,"tag":99,"props":1367,"children":1368},{},[1369,1374],{"type":38,"tag":67,"props":1370,"children":1371},{},[1372],{"type":43,"value":1373},"担当者を責めて終わる",{"type":43,"value":1375},"：多くの失敗は個人ではなく、役割と進め方の構造から起きています。仕組みを変えなければ、担当者が替わっても繰り返します",{"type":38,"tag":99,"props":1377,"children":1378},{},[1379,1384],{"type":38,"tag":67,"props":1380,"children":1381},{},[1382],{"type":43,"value":1383},"プロセスを一気に増やす",{"type":43,"value":1385},"：会議や書類を急に増やすと、現場は「仕事が増えただけ」と受け止めます。困りごとの共有から入り、効果が見える小さな型から始めます",{"type":38,"tag":272,"props":1387,"children":1389},{"id":1388},"立て直しで生まれた成果",[1390],{"type":43,"value":1388},{"type":38,"tag":39,"props":1392,"children":1393},{},[1394,1396,1401],{"type":43,"value":1395},"要件定義を立て直すと、成果は数字にも表れます。K.S.Rogers の支援では、目的や要件が曖昧なまま開発され使われなくなっていたシステムを、利用予定者への調査とモックアップでの合意形成によって立て直し、",{"type":38,"tag":67,"props":1397,"children":1398},{},[1399],{"type":43,"value":1400},"利用率を20%から65%に改善",{"type":43,"value":1402},"した例があります。そのほか、要求をエンジニアがすぐ実装できる粒度まで整えて開発ベロシティ（一定期間に開発を進められる量）を43%向上させた例、進捗の可視化と要件定義の承認フロー化で遅延ゼロの開発体制に整えた例もあります。",{"type":38,"tag":115,"props":1404,"children":1406},{"id":1405},"参考になる公的資料",[1407],{"type":43,"value":1405},{"type":38,"tag":95,"props":1409,"children":1410},{},[1411,1422],{"type":38,"tag":99,"props":1412,"children":1413},{},[1414,1420],{"type":38,"tag":51,"props":1415,"children":1417},{"href":53,"rel":1416},[55],[1418],{"type":43,"value":1419},"IPA「ユーザのための要件定義ガイド 第2版 要件定義を成功に導く128の勘どころ」",{"type":43,"value":1421},"（2019年12月公開）：発注側の企業向けに、ビジネス要求定義、システム化要求定義、要件定義マネジメント、主要ドキュメントの作成で起きる問題と、その対応方法を対にして整理しています。失敗の兆候に気づいたとき、該当する問題を引く辞書として使えます",{"type":38,"tag":99,"props":1423,"children":1424},{},[1425,1431],{"type":38,"tag":51,"props":1426,"children":1428},{"href":1017,"rel":1427},[55],[1429],{"type":43,"value":1430},"IPA「情報システム・モデル取引・契約書（第二版）」",{"type":43,"value":1432},"（2020年12月公開）：ユーザ企業とITベンダの役割の変化を踏まえたモデル契約です。開発を外注する際の契約の考え方を確認できます",{"type":38,"tag":115,"props":1434,"children":1436},{"id":1435},"要件定義の失敗を繰り返さないために-ksrogers-の要件定義支援",[1437],{"type":43,"value":1438},"要件定義の失敗を繰り返さないために ―― K.S.Rogers の要件定義支援",{"type":38,"tag":39,"props":1440,"children":1441},{},[1442,1444,1451],{"type":43,"value":1443},"K.S.Rogers では「決まっていないところから一緒に考える」をコンセプトに、",{"type":38,"tag":51,"props":1445,"children":1448},{"href":1446,"rel":1447},"https:\u002F\u002Fks-rogers.co.jp\u002Frd\u002F",[55],[1449],{"type":43,"value":1450},"要件定義支援サービス",{"type":43,"value":1452},"を提供しています。これから始めるプロジェクトの予防にも、すでに兆候が出ているプロジェクトの立て直しにも対応します。",{"type":38,"tag":139,"props":1454,"children":1455},{},[1456,1482],{"type":38,"tag":143,"props":1457,"children":1458},{},[1459],{"type":38,"tag":147,"props":1460,"children":1461},{},[1462,1467,1472,1477],{"type":38,"tag":151,"props":1463,"children":1464},{},[1465],{"type":43,"value":1466},"プラン",{"type":38,"tag":151,"props":1468,"children":1469},{},[1470],{"type":43,"value":1471},"月額（税別）",{"type":38,"tag":151,"props":1473,"children":1474},{},[1475],{"type":43,"value":1476},"稼働の目安",{"type":38,"tag":151,"props":1478,"children":1479},{},[1480],{"type":43,"value":1481},"こんなときに",{"type":38,"tag":162,"props":1483,"children":1484},{},[1485,1508,1531],{"type":38,"tag":147,"props":1486,"children":1487},{},[1488,1493,1498,1503],{"type":38,"tag":169,"props":1489,"children":1490},{},[1491],{"type":43,"value":1492},"相談・壁打ち",{"type":38,"tag":169,"props":1494,"children":1495},{},[1496],{"type":43,"value":1497},"10万円",{"type":38,"tag":169,"props":1499,"children":1500},{},[1501],{"type":43,"value":1502},"月8時間",{"type":38,"tag":169,"props":1504,"children":1505},{},[1506],{"type":43,"value":1507},"「なんかうまくいっていない」、セカンドオピニオンが欲しい",{"type":38,"tag":147,"props":1509,"children":1510},{},[1511,1516,1521,1526],{"type":38,"tag":169,"props":1512,"children":1513},{},[1514],{"type":43,"value":1515},"要件定義設計",{"type":38,"tag":169,"props":1517,"children":1518},{},[1519],{"type":43,"value":1520},"27万円",{"type":38,"tag":169,"props":1522,"children":1523},{},[1524],{"type":43,"value":1525},"月25時間",{"type":38,"tag":169,"props":1527,"children":1528},{},[1529],{"type":43,"value":1530},"開発会社にうまく伝わらない、手戻りをなくしたい",{"type":38,"tag":147,"props":1532,"children":1533},{},[1534,1539,1544,1549],{"type":38,"tag":169,"props":1535,"children":1536},{},[1537],{"type":43,"value":1538},"プロジェクト推進",{"type":38,"tag":169,"props":1540,"children":1541},{},[1542],{"type":43,"value":1543},"50万円",{"type":38,"tag":169,"props":1545,"children":1546},{},[1547],{"type":43,"value":1548},"月50時間",{"type":38,"tag":169,"props":1550,"children":1551},{},[1552],{"type":43,"value":1553},"社内にPMがおらず進まない、企画からリリースまで任せたい",{"type":38,"tag":39,"props":1555,"children":1556},{},[1557],{"type":43,"value":1558},"本記事のチェックリストで気になる項目があった段階なら、まずは相談・壁打ちから始めるのがおすすめです。決める権限は御社に残したまま、整理と言語化を伴走します。",{"type":38,"tag":115,"props":1560,"children":1562},{"id":1561},"まとめ",[1563],{"type":43,"value":1561},{"type":38,"tag":95,"props":1565,"children":1566},{},[1567,1579,1584,1589],{"type":38,"tag":99,"props":1568,"children":1569},{},[1570,1572,1577],{"type":43,"value":1571},"要件定義の失敗は、",{"type":38,"tag":67,"props":1573,"children":1574},{},[1575],{"type":43,"value":1576},"役割不在・利用者の調査不足・合意不足・丸投げ・目的化・粗い要件での金額確定",{"type":43,"value":1578},"の6パターンにほぼ集約できます",{"type":38,"tag":99,"props":1580,"children":1581},{},[1582],{"type":43,"value":1583},"失敗には兆候があります。「決める人がいない」「決めたことが共有されていない」サインが2つ以上出ていたら、開発を進める前に見直します",{"type":38,"tag":99,"props":1585,"children":1586},{},[1587],{"type":43,"value":1588},"外注は悪くありませんが、目的・利用者・優先順位・やらないことを決めるのは発注側です。見積もりは要件の粒度に合わせて扱い、要件定義と開発を分けて発注します",{"type":38,"tag":99,"props":1590,"children":1591},{},[1592],{"type":43,"value":1593},"失敗しても、現状の棚卸し → 目的と利用者への立ち返り → 優先順位の決め直し → 合意と進め方の型づくり、の4ステップで立て直せます",{"type":38,"tag":39,"props":1595,"children":1596},{},[1597,1599,1603,1605,1611],{"type":43,"value":1598},"要件定義の進め方そのものを知りたい方は",{"type":38,"tag":51,"props":1600,"children":1601},{"href":76},[1602],{"type":43,"value":79},{"type":43,"value":1604},"を、プロジェクトの状況について相談したい方は",{"type":38,"tag":51,"props":1606,"children":1608},{"href":1607},"\u002Fcontact\u002F",[1609],{"type":43,"value":1610},"お問い合わせ",{"type":43,"value":1612},"からお気軽にご連絡ください。",{"title":7,"searchDepth":1614,"depth":1614,"links":1615},2,[1616,1617,1626,1631,1636,1637,1638,1646,1647,1648],{"id":117,"depth":1614,"text":120},{"id":238,"depth":1614,"text":241,"children":1618},[1619,1621,1622,1623,1624,1625],{"id":274,"depth":1620,"text":277},3,{"id":306,"depth":1620,"text":309},{"id":329,"depth":1620,"text":332},{"id":352,"depth":1620,"text":355},{"id":370,"depth":1620,"text":373},{"id":402,"depth":1620,"text":405},{"id":425,"depth":1614,"text":428,"children":1627},[1628,1629,1630],{"id":443,"depth":1620,"text":446},{"id":494,"depth":1620,"text":494},{"id":548,"depth":1620,"text":548},{"id":598,"depth":1614,"text":598,"children":1632},[1633,1634,1635],{"id":621,"depth":1620,"text":621},{"id":796,"depth":1620,"text":799},{"id":849,"depth":1620,"text":849},{"id":890,"depth":1614,"text":893},{"id":1031,"depth":1614,"text":1031},{"id":1200,"depth":1614,"text":1203,"children":1639},[1640,1641,1642,1643,1644,1645],{"id":1227,"depth":1620,"text":1230},{"id":1255,"depth":1620,"text":1258},{"id":1277,"depth":1620,"text":1280},{"id":1295,"depth":1620,"text":1298},{"id":1335,"depth":1620,"text":1335},{"id":1388,"depth":1620,"text":1388},{"id":1405,"depth":1614,"text":1405},{"id":1435,"depth":1614,"text":1438},{"id":1561,"depth":1614,"text":1561},"markdown","content:articles:yoken-teigi-shippai-genin.md","content","articles\u002Fyoken-teigi-shippai-genin.md","articles\u002Fyoken-teigi-shippai-genin","md",[],1791732040055]