[{"data":1,"prerenderedAt":112},["ShallowReactive",2],{"unit:shindanshi\u002Fjoho\u002Fkaihatsu\u002Fmodel":3},{"unit":4,"drills":90,"related":95,"topicUnits":100},{"id":5,"exam":6,"subject":7,"subjectName":8,"topic":9,"title":10,"tier":11,"hindo":12,"kijunbi":13,"readingMinutes":14,"sources":15,"factcheck":20,"blocks":24,"pairs":38,"drills":50,"links":87},"shindanshi\u002Fjoho\u002Fkaihatsu\u002Fmodel","shindanshi","joho","経営情報システム","データベースと開発","開発モデル — 家を建てるか、試食を重ねるか",1,"B","2026-05-01",5,[16],{"kind":17,"label":18,"url":19},"kokai","日本中小企業診断士協会連合会「令和8年度第1次試験案内」（ウォーターフォール・アジャイル\u002Fスクラムはシステム開発の標準知識。URLは試験科目・制度の確認用）","https:\u002F\u002Fwww.jf-cmca.jp\u002Fattach\u002Ftest\u002Fr08\u002Fr08_1ji_annai.pdf",{"status":21,"date":22,"scope":23},"passed","2026-07-16","独立監査（opus・2026-07-16）: 最重要検証点＝C2（条件網羅）の定義を素材の「すべての条件の真偽の組み合わせ」から標準定義（個々の条件式の真偽をそれぞれ1回以上。全組み合わせは複数条件網羅=MCC）へ修正した当否——権威ソースで「素材が誤り・修正は正当」と確認（素材誤りの上方修正11例目）。Chen記法・正規化3段階・SQL4分類（TRUNCATE=DDL含む）・WHERE\u002FHAVING・ACID・分離レベル両端・スクラム3役と5行事・テスト4段階（UAT=発注側）・境界値分析の例（100と101）・FP法5対象（IFPUG=EI\u002FEO\u002FEQ\u002FILF\u002FEIFと一致）・COCOMO（Boehm1981・3モード）を全数照合し全点正確。ドリル20\u002F20正確・比喩の承認継承忠実・請負\u002F準委任の対応はIPA「モデル取引・契約書」の通説と一致・文字混入ゼロ（483字全て標準日本語漢字）・リンク10件全実在・hindo全一致。S\u002FA\u002FB級ゼロ・C級3点（C0⊂C1⊂C2の簡略化／TCL独立の4分類系／M:Nの層——いずれも試験深度で無害・修正不要と判定）。合格可能性約88%。PASS。",{"hook":25,"question":26,"intuition":27,"rigor":30,"pitfall":33,"jitsumu":36,"payoff":37},"\n        \u003Cp>家を建てるとき、基礎を打った後で「やっぱり間取りを変えたい」は大事故です——だから設計を固めてから一方向に進む。一方、新メニューの開発なら\u003Cb>試食を繰り返して味を調整\u003C\u002Fb>する方が確実です——完成形が最初は誰にも分からないから。\u003C\u002Fp>\n        \u003Cp>システム開発の2大モデルは、ちょうどこの対比です。どちらが優れているかではなく、\u003Cb>仕事の性質に合うのはどちらか\u003C\u002Fb>が問われます。\u003C\u002Fp>","ウォーターフォールとアジャイル（スクラム）は、それぞれどんな進め方と役割分担をするのでしょうか。",{"heading":28,"html":29},"一方向に固めて進むか、短い周期で回すかです","\n        \u003Cp>\u003Cb>ウォーターフォール\u003C\u002Fb>は要件定義→システム設計→プログラム設計→実装→テスト→運用保守と、\u003Cb>上流から下流へ一方向\u003C\u002Fb>に進みます。長所は計画と分担が明確なこと、短所は\u003Cb>手戻りが困難\u003C\u002Fb>なこと——滝は逆流しません。\u003C\u002Fp>\n        \u003Cp>\u003Cb>アジャイル\u003C\u002Fb>の代表\u003Cb>スクラム\u003C\u002Fb>は、\u003Cb>スプリント\u003C\u002Fb>（1〜4週間の固定周期）で「動くもの」を作っては見せるのを繰り返します。要求は\u003Cb>プロダクトバックログ\u003C\u002Fb>に優先順位付きで積み、スプリントごとに\u003Cb>スプリントバックログ\u003C\u002Fb>へ取り出す。毎日の\u003Cb>デイリースクラム\u003C\u002Fb>、成果を確かめる\u003Cb>スプリントレビュー\u003C\u002Fb>、進め方をふりかえる\u003Cb>レトロスペクティブ\u003C\u002Fb>で回します。\u003C\u002Fp>\n        \u003Cdiv class=\"chorus\">\u003Cspan class=\"chorus-k\">開発の合言葉\u003C\u002Fspan>\u003Cspan class=\"chorus-t\">\u003Cb>ウォーターフォール＝一方向・手戻り困難\u003C\u002Fb>／\u003Cb>スクラム＝スプリントの反復\u003C\u002Fb>——\u003Cb>PO＝何を作るか・SM＝どう進むかの支援\u003C\u002Fb>\u003C\u002Fspan>\u003C\u002Fdiv>",{"heading":31,"html":32},"スクラムの3つの役割——決める人・支える人・作る人です","\n        \u003Cp>スクラムの役割は3つで固定です。\u003Cb>プロダクトオーナー（PO）\u003C\u002Fb>＝\u003Cb>何を作るか\u003C\u002Fb>を決める——バックログの内容と優先順位に責任を持つ。\u003Cb>スクラムマスター（SM）\u003C\u002Fb>＝\u003Cb>チームがうまく回るよう支援\u003C\u002Fb>する——障害を取り除き、スクラムの進め方を守る（指示命令する管理職ではない）。\u003Cb>開発チーム\u003C\u002Fb>＝実際に作る。この3者の職務の入れ替えが試験の的です。\u003C\u002Fp>\n        \u003Cp>周辺語も1セットで——\u003Cb>DevOps\u003C\u002Fb>＝開発（Dev）と運用（Ops）が一体で回る体制、\u003Cb>CI\u002FCD\u003C\u002Fb>＝継続的インテグレーション／継続的デリバリー（変更を自動でテスト・配備し、小さく頻繁に出す）。アジャイルの思想をリリース工程まで延長した道具立てです。\u003C\u002Fp>",{"heading":34,"html":35},"POとSMの職務の入れ替えが、ほぼ毎回の的です","\n        \u003Cp>定番の誤り肢は\u003Cb>「スクラムマスターがバックログの優先順位を決める」\u003C\u002Fb>——優先順位は\u003Cb>プロダクトオーナー\u003C\u002Fb>の専権です。逆に「POがチームの障害を取り除きプロセスを支援する」もSMの職務とのすり替え。\u003Cb>決める人（PO）・支える人（SM）・作る人（チーム）\u003C\u002Fb>で固定してください。\u003C\u002Fp>\n        \u003Cp>「アジャイルでは計画を立てない」も誤り——スプリントごとに計画し、\u003Cb>短い周期で計画し直す\u003C\u002Fb>のがアジャイルです。「ウォーターフォールは各工程を並行して進める」も逆——一方向・直列が特徴です。\u003C\u002Fp>","\n        \u003Cp>顧問先がシステムを外注するとき、モデル選びは\u003Cb>契約の形\u003C\u002Fb>まで決めます——要件が固まっている基幹系の刷新はウォーターフォール＋請負契約（完成責任）が素直で、要件が動く新サービスはアジャイル＋準委任契約（伴走型）が馴染む。「アジャイルでお願いしたのに完成保証がない」というトラブルは、この対応を知らないまま契約した典型例——診断士が入口で防げる事故です。\u003C\u002Fp>","\n        冒頭の問いに答えます。ウォーターフォールは要件定義から運用保守まで一方向に進み、計画は明確だが手戻りが困難。スクラムはスプリント（1〜4週間）で反復し、PO＝何を作るかを決める・SM＝進め方を支援する・開発チーム＝作る、の3役で回します（DevOps・CI\u002FCDはその延長）。次は、作ったものをどう確かめるか——テストへ。",[39],{"label":40,"left":41,"right":45,"hinge":49},"プロダクトオーナーとスクラムマスター",{"badge":42,"name":43,"note":44},"PO","何を作るかを決める","バックログの内容と優先順位に責任",{"badge":46,"name":47,"note":48},"SM","どう進むかを支援する","障害を除去しプロセスを守る——指示する管理職ではない","「決める人」と「支える人」。優先順位の決定権のすり替えがほぼ毎回の的です。",[51,62,75,82],{"type":52,"id":53,"prompt":54,"options":55,"correct":60,"explanation":61},"quiz","joho-model-q1","スクラムに関する記述として、最も適切なものはどれか。",[56,57,58,59],"プロダクトオーナーは、プロダクトバックログの内容と優先順位に責任を持つ。","スクラムマスターは、プロダクトバックログの優先順位を決定する。","スプリントの期間は、進捗に応じて数日から半年まで柔軟に変動させる。","デイリースクラムは、スプリントの最終日に成果物を顧客へ披露する会議である。",0,"\u003Cstrong>正解：ア\u003C\u002Fstrong>　「何を作るか」の決定権はPOです。\u003Cbr>イ＝優先順位はPOの専権（SMはプロセスの支援役）、ウ＝スプリントは1〜4週間の固定周期、エ＝成果を披露するのはスプリントレビュー（デイリースクラムは毎日の短い同期）。役割と行事の入れ替えが手口です。",{"type":63,"id":64,"prompt":65,"ask":66,"choices":67,"correctKey":69,"explanation":74},"judge","joho-model-j1","「ウォーターフォールモデルは、要件定義から運用保守までを上流から下流へ一方向に進めるため、計画は明確だが後工程からの手戻りが困難である」との記述がある。","この記述は適切か。",[68,71],{"key":69,"label":70},"ok","適切",{"key":72,"label":73},"ng","不適切","\u003Cb>適切\u003C\u002Fb>です。滝は逆流しない——長所（計画・分担の明確さ）と短所（手戻り困難）は同じ性質の裏表です。要件が固まっている案件に向きます。",{"type":63,"id":76,"prompt":77,"ask":66,"choices":78,"correctKey":72,"explanation":81},"joho-model-j2","「アジャイル開発では、変化への対応を重視するため、計画そのものを立てない」との記述がある。",[79,80],{"key":69,"label":70},{"key":72,"label":73},"\u003Cb>不適切\u003C\u002Fb>です。アジャイルは計画を立てないのではなく、\u003Cb>短い周期（スプリント）で計画し直す\u003C\u002Fb>——変化のたびに小さく再計画するのが本質です。「無計画」への言い換えが定番の的です。",{"type":83,"id":84,"prompt":85,"answer":86},"blank","joho-model-b1","スクラムでスプリントの終わりに行う2つの行事——成果物を確かめる「スプリントレビュー」と、チームの進め方をふりかえる「〔?〕」。","レトロスペクティブ（ふりかえり。もの＝レビュー、進め方＝レトロと対で固定）",[88,89],"shindanshi\u002Fjoho\u002Fkaihatsu\u002Ftest","shindanshi\u002Fjoho\u002Fdodai\u002Fsystem-dx",[91,92,93,94],{"unitId":5,"unitTitle":10,"topic":9,"item":51},{"unitId":5,"unitTitle":10,"topic":9,"item":62},{"unitId":5,"unitTitle":10,"topic":9,"item":75},{"unitId":5,"unitTitle":10,"topic":9,"item":82},[96,98],{"id":88,"title":97},"テスト — 分解して見るか、ハンドルを回して見るか",{"id":89,"title":99},"ERPとDX — 台帳をつなぐ話と、商売を変える話は別物です",[101,104,107,108,109],{"id":102,"title":103},"shindanshi\u002Fjoho\u002Fkaihatsu\u002Fer-seikika","正規化 — 引っ越し1件で2行直すはめになる前に",{"id":105,"title":106},"shindanshi\u002Fjoho\u002Fkaihatsu\u002Fsql-acid","SQLとACID — 絞ってから集めるか、集めてから絞るか",{"id":5,"title":10},{"id":88,"title":97},{"id":110,"title":111},"shindanshi\u002Fjoho\u002Fkaihatsu\u002Fmitsumori","見積り3法 — 機能で測る、行数で測る、過去に聞く",1784183227533]