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