第9章　システム開発

この章のねらい ここからは「情報システムをどうやって作るか」というシステム開発の分野に入ります。プログラムそのものの書き方（前章）ではなく、プロジェクトとしてシステムを"企画→設計→作成→運用"していく段取りの話です。診断士は自分でコードを書く人ではなく、発注する側（ユーザ企業）の立場でベンダー（開発業者）とやり取りする人。だからこの章は「開発の全体の流れ」「頼み方・契約の仕方」を知っておくための地図になります。

過去問での出方：この分野は経営情報システムの得点源のひとつで、毎年ほぼ確実に2〜3問出ます。特に、①開発プロセスモデル（ウォーターフォール・アジャイル・スクラム・DevOpsなど用語の正誤）、 ②モデリング手法（DFD・E-R図・UMLの各図が「何を表すか」）は、ほぼ毎年どちらかが顔を出す超頻出テーマです。用語と「その用語が何を指すか」を一対一で覚えれば、素直に得点できます。

9-0　この章の地図

この章は、システムを作る一連の流れ「どう進めるか（開発の型）」→「何を決めるか（要件・設計）」→ 「どう表現するか（モデリング図）」→「誰が作るか（内製・外注）」の順に進みます。

9-1 開発プロセスモデル      … 開発の"進め方"の型（★超頻出）
   │  ウォーターフォール／プロトタイピング／スパイラル
   │  アジャイル・スクラム／DevOps
   │
9-2 要件定義と設計          … 上流工程で"何を作るか"を決める
   │  超上流・要求分析／外部設計・内部設計／システム化計画
   │
9-3 構造化手法とオブジェクト指向  … 設計を"図"で表す（★超頻出）
   │  DFD／E-R図／UML各種図／ユースケース
   │
9-4 調達・内製と外部委託     … "誰に頼むか"・契約・SLA
      RFP／SIer／ハウジング・ホスティング／契約形態

まず「開発には決まった工程（段取り）がある」ことをつかみ、そのうえで各節を見ていきましょう。

9-1　開発プロセスモデル ★超頻出

まず全体像：システム開発の「工程」

どんな作り方をするにせよ、システム開発は大きく次の工程（フェーズ）を通ります。「上流（じょうりゅう）」から「下流（かりゅう）」へ、川の流れのように進むイメージです。

【上流】 要件定義 → 外部設計 → 内部設計 → 【下流】プログラミング → テスト → 運用・保守
        （何を作る）（見た目・ふるまい）（内部の作り）（実装）      （検証）    （動かし続ける）

上流工程：要件定義・設計。ここで「何を作るか」を決める、いちばん大事なところ。
下流工程：プログラミング・テスト。決まったものを実際に作って確かめる。

💡 なぜ上流が大事？：上流の要件定義でのミス（決め忘れ・勘違い）は、後の工程すべてに波及します。「上流での1の手戻りは、下流では100の手戻りになる」とよく言われ、上流ほど慎重に進めます（→ 9-2で詳述）。

この工程をどんな順番・進め方でこなすかの型が「開発プロセスモデル」です。代表的な4つを見ていきます。

① ウォーターフォールモデル（滝型）

ウォーターフォール（waterfall＝滝）モデルは、上流から下流へ各工程を順番に、後戻りせずに進める、最も基本的で古典的な方法です。滝の水が上から下へ落ちて戻らないイメージから、この名前がつきました。

要件定義 ─┐
          └→ 外部設計 ─┐
                       └→ 内部設計 ─┐
                                    └→ プログラミング ─┐
                                                       └→ テスト ─┐
                                                                  └→ 運用
（各工程が完了してから次へ。後戻りしないのが理想）

長所：工程がはっきり区切られ、進捗・分担・予算の管理がしやすい。大規模開発に向く。
短所：途中の後戻りが苦手。上流で要件を確定してしまうため、後から「やっぱり変えたい」に弱い。利用者が完成品を見られるのは最後のほうなので、要求とのズレが最後まで発覚しにくい。

⚠️ 工程の順番がひっかけになる 正しい順は「要件定義 → 外部設計 → 内部設計 → プログラミング → テスト → 運用」。「内部設計 → 外部設計」と逆にした選択肢や、「運用 → テスト」と逆にした選択肢はバツです（H29 第17問）。 外部（ユーザから見える所）を先に、内部（中身）を後に決める、と覚えましょう。

📝 過去問はこう出る（H29 第17問） ウォーターフォール型の説明として正しいものを選ぶ問題。正解は「要件定義→外部設計→内部設計→開発（プログラミング）→テスト→運用の順に行い、後戻りしないことが理想」。「内部設計→外部設計」の順に入れ替えた選択肢や、「テスト工程のノウハウ蓄積のためにプロトタイプが提案された」という プロトタイプの目的を取り違えた選択肢はバツ（プロトタイプは要求を早期に確認するためのもの）。 → H29 第17問

② プロトタイピング（プロトタイプモデル）

プロトタイピングは、開発の早い段階で試作品（プロトタイプ）を作ってユーザに見せ、「これで合っていますか？」と確認しながら進める方法です。

ねらい：ウォーターフォールの弱点（要求とのズレが最後まで見えない）を克服する。ユーザは動くものを早く見られるので、要求のあいまいさ・認識のズレを早期に発見できる。
短所：試作と確認を繰り返すため、比較的小規模なシステムに向く。大規模には不向きとされる。

⚠️ 混同注意：プロトタイプは「テスト工程のノウハウを貯めるため」ではなく、 要件定義段階で利用者の要求を早期に確認・確定するための手法です（H29 第17問の誤り選択肢）。

③ スパイラルモデル（らせん型）

スパイラルモデルは、システムを複数のサブシステムに分割し、基本部分から順に「設計→開発→評価」をらせん状に繰り返しながら、少しずつ完成度を高めていく方法です。

   ┌──→ 設計 → 開発 → 評価 ──┐
   │  （サブシステム1）        │
   └───←──── 繰り返し ←──────┘ → 次のサブシステム2へ…
   （回るたびに機能が増え、システムが育っていく）

ウォーターフォール（工程の確実さ）とプロトタイピング（試作・確認）の良いとこ取りをした反復型。
基本となるサブシステムをまずウォーターフォール的に作ってユーザに試用してもらい、その結果を反映して次のサブシステムを作る、を繰り返します（H19 第15問の説明どおり）。

📝 過去問はこう出る（H19 第15問） 開発モデルの用語を空欄補充する問題。「各工程を後戻りなく行う最も基本的な方法」＝ウォーターフォールモデル、「試作品をユーザに見せて確認しながら行う」＝プロトタイプモデル、「サブシステムに分け、基本部分をまず開発・試用し結果を反映して次を開発」＝スパイラルモデル。あわせて「企画・開発・保守・運用を一括して請け負う業者」＝システムインテグレータ（SIer）も問われました（→ 9-4）。 → H19 第15問

④ アジャイル開発とスクラム ★超頻出

アジャイル（agile＝俊敏）開発は、最初に全部を作り込まず、 短い期間の反復（イテレーション）で「動くソフトウェア」を少しずつ作り、 環境変化や要求の変更に柔軟に対応していく開発の考え方の総称です。

アジャイルには、いくつかの具体的な方法論（フレームワーク）があります。試験頻出の4つを押さえましょう。

方法論	ひとことで	覚えどころ
スクラム	スプリントという短い期間を区切って反復開発する代表的フレームワーク	用語（下記）がそのまま問われる
XP（エクストリーム・プログラミング）	少人数向けのアジャイル手法。ペアプログラミングが代表的な実践	2人1組で協力して書く
FDD（フィーチャ駆動開発）	全体をモデル化し、機能（フィーチャ）単位で反復して計画・設計・構築	「機能のまとまり」が単位
かんばん	トヨタ生産方式由来。作業の流れ（ワークフロー）を可視化しWIP（仕掛かり）を管理	「見える化」で流れを管理

スクラムの用語は、正誤問題で頻繁に問われます。混同しないように整理します。

用語	意味
スプリント	開発を区切る短い一定期間（例：1〜4週間）。この単位で反復する
スプリントレビュー	スプリントの成果物をステークホルダー（利害関係者）に提示しフィードバックを得る場
デイリースクラム	開発チームが毎日行う短時間のミーティング（進捗・課題の共有）

⚠️ スクラムのド定番ひっかけ 「成果をステークホルダーに提示しフィードバックを得る」のは スプリントレビュー です。これを「デイリースクラム」と書いた選択肢はバツ（デイリースクラムは毎日の進捗共有）。この入れ替えが頻出です（R07 第13問）。

⚠️ XPのペアプログラミング 2人のプログラマがペアを組み、相談・レビューしながら"協力して"1つのプログラムを書く実践です。「複数のオブジェクトを複数人で分担して作る」という説明はバツ（分担ではなく協働）（H27 第18問）。

📝 過去問はこう出る（H27 第18問） アジャイルの方法論（FDD・スクラム・かんばん・XP）を問う問題。公式正解はスクラムに関する記述（イ）。誤り選択肢では、FDDを「逐次的に確実に行う（＝ウォーターフォールの説明）」、 XPのペアプログラミングを「複数人で分担」と誤って説明していました。 → H27 第18問

⑤ DevOps（デブオプス）

DevOpsは、開発（Development）と運用（Operations）が密接に連携・協力し、システムの導入や更新を柔軟かつ迅速に行おうとする考え方・文化です。

従来は「作る人（開発）」と「動かし続ける人（運用）」が壁で分かれ、対立しがちでした。 DevOpsはこの壁を取り払い、両者を一体化させて、素早いリリースを目指します。

⚠️ DevOpsのド定番ひっかけ DevOpsは開発と運用を「分離せず連携・統合」するのが本質。「開発と運用のフェーズを明確に分離して」と書いた選択肢はバツです（R07 第13問の誤り選択肢）。「Development ＋ Operations」という名前が「両者をくっつける」ことを表している、と覚えましょう。

📝 過去問はこう出る（R07 第13問／R04 第13問） R07は用語の正誤の組み合わせ問題。正しかったのはXPのペアプログラミング（dの記述）だけで、デイリースクラム（正しくはスプリントレビュー）、ローコード開発（正しくは反復型の説明）、 DevOps（「分離」が誤り）はすべてバツでした。 R04も同系統で、正解は「DevOpsは開発側と運用側が密接に連携し、導入・更新を柔軟かつ迅速に行う」（正しい記述）。 → R07 第13問 ／ R04 第13問

💡 用語の"すり替え"に注意（この節の総まとめ） この分野の正誤問題は、ある手法の説明に別の手法の中身を紛れ込ませるのが定番です。 - 「機能単位で反復」＝反復型／FDD → これをローコードやウォーターフォールの説明にすり替える - 「上流から下流へ後戻りなし」＝ウォーターフォール → これをFDDやスクラムの説明にすり替える「その説明は本当はどの手法のものか」を言い当てられれば正解できます。

9-2　要件定義と設計（上流工程）

開発の型がわかったところで、上流工程で"何を・どう作るか"を決めていく段取りを見ます。ここは中小企業がベンダーに発注するときの実務にも直結する、診断士的に大事な節です。

工程の全体像（もう一度、上流を細かく）

【超上流】経営戦略・情報化構想 → システム化計画
   ↓
【要件定義】業務要件・機能要件・非機能要件を決める（要求分析）
   ↓
【外部設計】ユーザから見える部分（画面・帳票・操作・データ）を設計
   ↓
【内部設計】システム内部の作り（プログラム構造・データ処理）を設計
   ↓
（以降、プログラミング・テストへ）

超上流とシステム化計画

「超上流（ちょうじょうりゅう）」とは、要件定義よりさらに前段階のこと。経営戦略やIT戦略を踏まえて「そもそもどんなシステムを作るべきか」という構想・計画を立てる段階です。

システム化計画：業務のどこをシステム化するか、費用対効果、開発スケジュール、体制などの計画を立てる。
ここが経営戦略とズレていると、「作ったけれど経営に役立たないシステム」になってしまいます。

要求分析・要件定義

要件定義は、「システムに何を求めるか（要求）」を明確にし、要件定義書にまとめる工程です。要件は大きく次のように分けられます。

種類	内容	例
機能要件	システムが何をするか（機能）	受注登録できる／在庫を自動計算する
非機能要件	機能以外の品質・性能の要求	3秒以内に応答する／24時間止まらない／セキュリティ

⚠️ 上流工程で守るべき"原理原則"（頻出） 情報システム開発の上流工程には、押さえるべき原則がいくつかあります（H22 第18問より）。 - 要件は可能なかぎり数値化（定量化）する：「速く」「使いやすく」では判定基準が人によって違う。「3秒以内」など数値化すれば、満たしたか否かを客観的に判定できる。◯ - 未確定な要件の決定を安易に先送りしない：後工程での手戻り・漏れにつながる。早期の合意・確定が望ましい。 - 多段階の見積り（反復して精緻化）はリスクを減らす：進むほど不確実性が下がるため。「リスクを増大させる」は誤り。 - 要件定義（要件を決めること）の主たる責任は発注者（ユーザ）側にある（「発注者と開発者の共同責任」とまでは言えない、とされた）。

📝 過去問はこう出る（H22 第18問） 上流工程で留意すべき事項として最も適切なものを選ぶ問題。正解は「数値化していない要件は、判定基準が人によって異なるので、数値化すべきである」。「多段階の見積りはリスクを増大させる」「決定を先送りすべき」などは、いずれも原則の逆でバツでした。 → H22 第18問

外部設計と内部設計

要件が固まったら、それを「設計」に落とします。外部が先、内部が後です。

設計	何を決めるか	誰の視点
外部設計	画面・帳票・操作手順・データ項目など、ユーザから見える部分	利用者の視点
内部設計	プログラムの分割、内部のデータ処理など、システムの中身	開発者の視点

💡 覚え方：外＝ユーザから見える所（先に決める）／内＝中身（後で決める）。ウォーターフォールの工程順「外部設計→内部設計」もこれで思い出せます（9-1のひっかけ対策）。

「要求と結果のギャップ」はどこで生まれるか

発注した中小企業の「こうしてほしい」が、完成品に正しく反映されないことがあります。このズレ（ギャップ）がどの工程で生じたかを切り分けるのが、H28 第17問のテーマでした。

①要件定義書を作る段階で漏れる：発注者の要求が、そもそも要件定義書に書かれなかった（要求の取りこぼし）。
②要件定義書から外部設計へ移す段階で漏れる／歪む：開発者が要件定義書を誤認・拡大解釈した。

📝 過去問はこう出る（H28 第17問） 要求と結果のギャップが、開発の①〜③どの段階で生じるかを対応づける問題。「要件定義すべき内容が抜けて発注者が説明していない」＝①要件定義書作成段階。「要件定義書の内容が設計者の誤認で開発から漏れた」「開発者が誤認・拡大解釈して盛り込んだ」＝いずれも②外部設計へ移す段階。＝ギャップは「要求→定義書」「定義書→設計」という工程の"受け渡し"のたびに生じ得る、というのが学びどころです。 → H28 第17問

9-3　構造化手法とオブジェクト指向 ― モデリング図 ★超頻出

設計の内容は、言葉だけでなく図（モデル）で表現します。この「どの図が何を表すか」はほぼ毎年出る超頻出テーマ。用語と意味を一対一で暗記すれば確実に得点できます。

モデリング手法は大きく2つの系統があります。

構造化手法：業務やデータを「処理の流れ」「データの構造」でとらえる古典的手法 … DFD・E-R図
オブジェクト指向：システムを「オブジェクト（もの）」の集まりでとらえる手法 … UML

DFD（データフローダイアグラム／データフロー図）

DFDは、データの流れに着目して、業務の中でデータがどう流れ、どう処理されるかを表す図です。構造化手法の代表格。次の4つの記号（要素）を使います。

要素	表すもの	例
プロセス（処理）	データを加工・処理する働き	「希望商品情報検索」
データストア	データの保管場所（ファイル・台帳・DB）	「顧客台帳」「商品台帳」
データフロー	データの流れ（矢印）	台帳→処理への流れ
外部実体（源泉/吸収）	システムの外にいる相手	「顧客」「業者」

（外部実体）        ┌─ データストア「顧客台帳」 ─┐
  顧客 ──要求──→ ○処理「希望商品情報検索」 ──適合商品──→ 顧客
                  └─ データストア「商品台帳」 ─┘

⚠️ DFDのひっかけ：プロセス（処理）とデータストア（台帳）の位置の入れ替えが定番。「顧客台帳」「商品台帳」は保管場所＝データストア、「〜検索」は働き＝プロセス、「顧客」は外の相手＝外部実体。どの記号が何かを見分けられれば解けます（H19 第16問）。

📝 過去問はこう出る（H19 第16問） DFDの空欄A〜Dに入る用語を選ぶ問題。正解は A＝顧客台帳（データストア）、B＝希望商品情報検索（プロセス）、C＝商品台帳（データストア）、D＝顧客（外部実体）。データストアとプロセスを入れ替えた選択肢はバツでした。 → H19 第16問

E-R図（実体関連図）

E-R図（Entity-Relationship Diagram）は、実体（エンティティ）どうしの関連を表す図で、 データの構造を設計するのに使います（データベース設計の定番。→ 第7章と関連）。

エンティティ（実体）：管理したい"もの"（例：顧客、商品、注文）
リレーションシップ（関連）：実体どうしのつながり（例：顧客が商品を注文する）

⚠️ E-R図のひっかけ：E-R図はデータの構造（実体と関連）を表す図です。「システムの状態と遷移を表す」のはE-R図ではなく状態遷移図（UMLのステートマシン図）。この取り違えが頻出です（R05 第17問）。

UML（統一モデリング言語）

UML（Unified Modeling Language）は、オブジェクト指向でシステムを設計するときに使う、標準化された図（ダイアグラム）の言語です。用途の違う複数の図がセットになっています。試験では「どの図が何を表すか」がそのまま問われます。表を丸ごと暗記しましょう。

UMLの図	何を表すか	覚えどころ
ユースケース図	利用者（アクター）とシステム機能の関係。システムが提供する機能	「誰が何を使えるか」
クラス図	システムを構成する概念・事物とその関連（データ構造に近い）	「もの」と「つながり」＋多重度
シーケンス図	オブジェクト間のメッセージのやり取りを時系列に表す	「時間軸の相互作用」
アクティビティ図	活動の流れ・業務の手順（処理のフロー）	「作業の流れ図」
ステートマシン図（状態遷移図）	オブジェクトの状態とその遷移	「状態が移り変わる」

⚠️ UML頻出のすり替え（超重要） - ユースケース図＝機能と利用者の関係。「業務の実行順序」を表すのはアクティビティ図。← これを入れ替える - アクティビティ図＝処理の流れ。「システムが提供する機能」を表すのはユースケース図。← これを入れ替える - シーケンス図＝オブジェクト間の相互作用を時系列で。 - 状態と遷移＝ステートマシン図（E-R図ではない）。 R05・R02はまさにこの一対一対応を問う問題でした。

📝 過去問はこう出る（R05 第17問／R02 第17問） R05は「DFD・E-R図・UMLの説明として正しい組み合わせ」を選ぶ問題。正しかったのは「DFDはデータの流れと処理の関係を記述」と「シーケンス図はオブジェクト間の相互作用を時系列に記述」の2つ。「E-R図が状態と遷移を表す」「アクティビティ図が機能を表す」「ユースケース図が実行順序を表す」はすべて取り違えでバツ。 R02は「利用者とのやり取り＝ユースケース図」「概念・関連＝クラス図」「状態遷移＝ステートマシン図」「活動の流れ＝アクティビティ図」の対応を問う問題でした。 → R05 第17問 ／ R02 第17問

クラス図の「多重度」の読み方

クラス図では、関連の両端に「多重度（たじゅうど／multiplicity）」という数字を書き、「一方から見て相手が何個あるか」を表します。読み方が試験で問われます（R04 第11問）。

表記	意味
1	ちょうど1個（必ず1つ）
0..*	0個以上（1つもないことも、たくさんあることもOK）
1..*	1個以上（少なくとも1つ）

読み方のコツ：多重度は「関連線の相手側の端に書かれた数」を、対象から見た相手の個数として読みます。

 修理 ──────────── 従業員
0..*    「担当」      1

「修理」側の端に 0..* … 1人の従業員から見た修理は「0件以上」＝担当ゼロの従業員もあり得る。
「従業員」側の端に 1 … 1つの修理から見た従業員は「必ず1人」。

📝 過去問はこう出る（R04 第11問） 上のクラス図（修理 0..* ── 1 従業員）の解釈を選ぶ問題。正解は「各修理に対して、担当する従業員は必ず1人である」（従業員側の多重度が1）。「従業員は少なくとも1つ以上の修理を担当する」（修理側は0..*なので担当ゼロもあり得る）はバツ。 H30・R04では、このクラス図の多重度の読み取りが繰り返し出題されています。 → R04 第11問

9-4　調達・内製と外部委託

最後は、システムを「誰が作るか・どう頼むか」の話。中小企業の多くは自社に開発部隊を持たないため、 外部委託（アウトソーシング）が現実的な選択肢になります。診断士として押さえておきたい実務論点です。

内製か外部委託か

	内製（自社で開発）	外部委託（ベンダーに依頼）
ノウハウ	社内に蓄積される	社内に蓄積されにくい
コスト・人材	開発人材の確保が必要	専門業者の力を使える
柔軟性	自社都合で改訂しやすい	契約・調整が必要

企画・開発・保守・運用を一括して請け負う業者をシステムインテグレータ（SIer／エスアイヤー）と呼びます（H19 第15問）。

RFPと調達の流れ

外部に頼むときは、「こういうシステムを作ってほしい」という要求を文書で示して見積り・提案を募るのが基本です。

【ユーザ企業】情報化構想 → RFI（情報提供依頼）→ RFP（提案依頼書）を複数ベンダーに提示
                                                    ↓
【ベンダー】提案書・見積りを提出 → ユーザが比較・選定 → 契約 → 開発

RFP（Request For Proposal／提案依頼書）：ユーザ企業がベンダーに対し、「実現したいこと・要件・予算・納期」などを示して提案を依頼する文書。ベンダー選定の出発点。
RFI（Request For Information／情報提供依頼書）：RFPの前段階で、ベンダーの技術情報や実績などの情報提供を求める文書。

💡 覚え方：RFI＝Information（情報ください）→ RFP＝Proposal（提案ください）の順。まず情報、次に提案。

外部委託の"度合い"（ハウジング・ホスティング・フルアウトソーシング）

サーバなどをどこまで外部に委ねるかで、呼び方と長所・短所が変わります（H23 第23問）。

方式	何を借りるか	開発・運用	特徴
ハウジング（コロケーション）	設置場所だけ借り、サーバは自社のもの	自社	自社で管理、ノウハウは残る
ホスティング	サーバも場所も借りる	自社	サーバ調達不要
フルアウトソーシング	サーバ・場所を借り、開発・運用も委託	外部	手間は最小だが社内にノウハウが残らない

⚠️ 委託が進むほどノウハウは残らない 開発・運用まで外部に委ねる（フルアウトソーシング）方式ほど、 情報システムの運用・管理・保守のスキルが社内に蓄積されにくい、という短所があります。逆に、責任がすべて自社に残るとも、外部業者が必ず保守するとも一律には言えません（契約・方式による）。

📝 過去問はこう出る（H23 第23問） サーバ外部委託の3方式（設置場所だけ借りる／サーバも借りる／運用も委託）の長所・短所を問う問題。正解は「開発・運用を外部に委ねる方式では、運用・管理・保守のスキルが社内に蓄積できない」（正しい短所の指摘）。「障害時の責任はすべて自社」「保守は一般に外部業者が行う」などの断定しすぎの選択肢はバツでした。 → H23 第23問

契約形態とSLA

外部委託では契約の形も論点になります。基本の2つを押さえましょう。

契約形態	仕事の完成	指揮命令	イメージ
請負契約	完成の義務あり（成果物に責任）	受託者（ベンダー）が自分で指揮	「作り上げて納品する」
（準）委任契約	完成義務なし（業務の遂行に責任）	―	「作業をやってもらう」

SLA（Service Level Agreement／サービスレベル合意）：提供するサービスの品質水準（稼働率・応答時間・障害対応など）を数値で取り決めた合意。「稼働率99.9％以上」のように定め、達成できなければ料金減額などのルールも決めます。委託先まかせにせず、サービスの質を約束させる仕組みです（9-2の「要件は数値化」の考え方とも通じます）。

この章のまとめ（試験直前チェック）

☐ 開発工程の順：要件定義→外部設計→内部設計→プログラミング→テスト→運用（外が先・内が後）
☐ ウォーターフォール＝各工程を後戻りなく順に進む基本形（管理しやすいが変更に弱い）
☐ プロトタイピング＝試作品でユーザに早期確認（要求のズレ対策／小規模向き）
☐ スパイラル＝サブシステムに分け反復して育てる（ウォーターフォール＋プロトタイプ）
☐ アジャイル＝短い反復で柔軟に。方法論にスクラム・XP・FDD・かんばん
☐ スクラム：成果提示＝スプリントレビュー（≠デイリースクラム）／期間の単位＝スプリント
☐ XPのペアプログラミング＝2人で"協力して"書く（≠分担）
☐ DevOps＝開発と運用を連携・統合（≠分離）で迅速リリース
☐ 上流の原則：要件は数値化する／決定を先送りしない／多段階見積りはリスクを減らす
☐ 要求と結果のギャップは工程の受け渡し（要求→定義書→設計）のたびに生じ得る
☐ DFD＝データの流れと処理（プロセス／データストア／データフロー／外部実体）
☐ E-R図＝実体と関連（データ構造）。状態遷移はステートマシン図
☐ UML：ユースケース図＝機能と利用者／クラス図＝概念と関連＋多重度／シーケンス図＝時系列の相互作用／アクティビティ図＝業務手順
☐ クラス図の多重度：1＝必ず1個、0..*＝0個以上、1..*＝1個以上（相手側の端を読む）
☐ SIer＝一括請負業者／RFP＝提案依頼書（RFI→RFPの順）
☐ 外部委託：ハウジング＜ホスティング＜フルアウトソーシング（委託が進むほどノウハウは残らない）
☐ 請負＝完成義務あり／SLA＝サービス品質を数値で合意

この章に対応する主な過去問

年度・問	論点	リンク
H19 第15問	開発モデルとSIer（用語の空欄補充）	問題
H19 第16問	DFDの構成要素	問題
H22 第18問	上流工程の原理原則（要件の数値化）	問題
H23 第23問	サーバ外部委託の方式と長所・短所	問題
H27 第18問	アジャイル開発の方法論	問題
H28 第17問	要求と結果のギャップの工程	問題
H29 第17問	ウォーターフォール型の工程順	問題
R02 第17問	UMLダイアグラムの対応	問題
R04 第11問	UMLクラス図の多重度の解釈	問題
R04 第13問	システム開発の方法論（DevOps）	問題
R05 第17問	モデリング手法（DFD・E-R図・UML）	問題
R07 第13問	開発手法（スクラム・DevOps・XP）	問題

次章予告 ▶ 第10章「プロジェクトマネジメントとシステムの評価・監査」 本章で「システムをどう作るか」を学びました。次章は、その開発をプロジェクトとして管理する技法（進捗・品質・コストの管理、PERT/CPM、テスト技法）と、できあがったシステムを評価・監査する仕組みを扱います。

← 第8章システム性能と信頼性第10章テスト品質とプロジェクト管理 →

第9章 システム開発

9-0 この章の地図

9-1 開発プロセスモデル ★超頻出