この章で学ぶこと
第10章に続き「その他知識」を扱う章です。データベースとシステム開発・運用は、PD-Sコース第4〜6章と重複する分野のため、この章では試験対応に必要な要点を精選して扱います。163語とボリュームはありますが、①データモデリングとDB運用→②トランザクション制御と分散データベース→③システム要件定義とソフトウェア要件・方式設計→④詳細設計・実装とテスト工程→⑤導入・保守運用と開発方法論→⑥ソフトウェアアーキテクチャと開発環境・Web技術、という「共通フレーム」のライフサイクル(要件定義→設計→実装→テスト→導入→保守)に沿って積み上げれば迷いません。
データモデリングとデータベース運用管理
データベース全体の構造を捉える視点として、1か所に集約する集中型アーキテクチャ、複数の拠点に分ける分散型アーキテクチャ、両者を組み合わせるハイブリッド型アーキテクチャというデータアーキテクチャ、そして利用者から見た外部スキーマ・全体設計の概念スキーマ・物理的な内部スキーマに分けるデータベースの3層スキーマアーキテクチャがあります。データの構造を表現するデータモデルには、ノードと関係で表すグラフ型のデータモデル、行と列の表で表す関係モデル、JSON等の文書単位で扱うドキュメント指向データベースがあります。
業務の視点で実体と関係を整理する概念データモデルをE-R図やUMLで表現し、実体間の対応関係の数を示すカーディナリティを明記します。これをデータベースの実装に近づけたものが論理データモデルで、一意性・参照関係・値の妥当性を保証する一貫性制約、レコードを一意に識別する主キー、他表とのつながりを表す外部キー、意味を持たない人工的な識別子サロゲートキー、データの重複や矛盾を排除する正規化を行います。
運用段階では、応答速度などを測るデータベースの性能評価、索引の再構築などで性能を改善するチューニング、断片化したデータを整理する再編成を含むデータベースの運用・保守を継続します。データを操作する理論的な基盤として、和・積・差を扱う集合演算、選択・射影・結合を行う関係演算、これらを体系化した関係代数があり、実際のデータベース操作では表の定義を行うDDL(データ定義言語)、データの検索・更新を行うDML(データ操作言語)を使います。
扱う用語(精選・25語)
- データアーキテクチャ(集中型・分散型・ハイブリッド型)/データベースの3層スキーマアーキテクチャ/データモデル/グラフ型のデータモデル/関係モデル/ドキュメント指向データベース
- 概念データモデル/E-R図/UML/カーディナリティ/論理データモデル/一貫性制約/主キー/外部キー/サロゲートキー/正規化
- データベースの性能評価/チューニング/再編成/データベースの運用・保守/集合演算/関係演算/関係代数/DDL/DML
トランザクション制御と分散データベース
複数の処理が同時にデータベースへアクセスしても矛盾が起きないよう管理する仕組みが同時実行制御(排他制御)とコミットメント制御です。データにロックをかける段階を2つに分ける2相ロッキングプロトコルを使いますが、互いにロックを待ち合って進めなくなるデッドロックには注意が必要です。複数のデータベースにまたがる更新を確実に反映させる2相コミットメント、そしてトランザクションが満たすべき原子性・一貫性・独立性・永続性というACID特性が、信頼できるデータベースの基本要件です。
障害からの復旧のために、更新履歴を記録するジャーナルファイル(ログファイル)と、復旧の起点となるチェックポイントを管理します。障害発生前の状態まで更新を再適用するフォワードリカバリ(ロールフォワード)、逆に未完了の更新を取り消すバックワードリカバリ(ロールバック)、コミットの順序関係を管理するコミットシーケンスがあります。
複数拠点にデータを複製・分散させる技術としては、同じデータを複数箇所に複製するレプリケーション、行単位でデータを分ける水平分散、列単位で分ける垂直分散という表の分散があります。分散システムでは、更新が即座に全拠点へ反映されなくても最終的に一致すればよいとする結果整合性の考え方が重要で、大量データを複数サーバーに分割して格納するシャーディングもあわせて押さえておきましょう。
扱う用語(精選・17語)
- 同時実行制御(排他制御)/コミットメント制御/2相ロッキングプロトコル/デッドロック/2相コミットメント/ACID特性
- ジャーナルファイル(ログファイル)/チェックポイント/フォワードリカバリ(ロールフォワード)/バックワードリカバリ(ロールバック)/コミットシーケンス
- レプリケーション/水平分散/垂直分散/表の分散/結果整合性/シャーディング
システム要件定義とソフトウェア要件・方式設計
システム開発の共通フレームは、要件定義から始まります。システムが実現すべき機能を定めるシステムの機能要件、処理速度などのシステムの性能要件、扱うデータの入出力情報要件・データベース要件、検証方法を定めるテスト要件、日々の運用に関する運用要件、修正・改善のための保守要件、そしてシステムが止まらない度合いを示す可用性、障害時にどう対応するかという障害対応、定期・随時といった保守の形態・保守のタイミングを定めます。予算や技術的な制約となる設計及び実装の制約条件を踏まえて、定めた要件が妥当かを確認するシステム要件の評価及びレビューを行います。
続くソフトウェア要件定義では、具体的なソフトウェアの機能仕様を固め、大きなシステムを扱いやすい単位に分けるサブシステム分割、外部に提供する機能をまとめたサービスの定義、第1〜9章で学んだ観点を反映するセキュリティ要件の識別、将来の変更のしやすさを考慮する保守性の考慮を経てソフトウェア要件の評価及びレビューを行います。人間の作業とシステムの作業を切り分けるハードウェア・ソフトウェア・サービス・手作業の機能分割により機能要件と、性能・セキュリティなど機能以外の要件である非機能要件を整理します。
方式設計の段階では、必要なハードウェア構成の決定・ソフトウェア構成の決定を行い、機能を独立したサービスに分けるマイクロサービスアーキテクチャ、サービス間通信を管理するサービスメッシュ、障害の連鎖を防ぐサーキットブレーカー、サーバー管理を意識せず実行できるサーバレスアーキテクチャといったシステム処理方式の決定を行います。
扱う用語(精選・29語)
- システムの機能要件/システムの性能要件/入出力情報要件/データベース要件/テスト要件/運用要件/保守要件/可用性/障害対応/保守の形態/保守のタイミング/設計及び実装の制約条件/システム要件の評価及びレビュー
- ソフトウェアの機能仕様/サブシステム分割/サービスの定義/セキュリティ要件の識別/保守性の考慮/ソフトウェア要件の評価及びレビュー/機能分割/機能要件/非機能要件
- ハードウェア構成の決定/ソフトウェア構成の決定/システム処理方式の決定(マイクロサービスアーキテクチャ・サービスメッシュ・サーキットブレーカー・サーバレスアーキテクチャ)
詳細設計・実装とテスト工程
方式設計を踏まえ、ソフトウェアの構造の設計を進め、実装しやすい単位に分けるソフトウェアユニット分割、その検証方法を決めるソフトウェアユニットのテストの設計・ソフトウェア統合テストの設計を行います。機能適合性・信頼性・セキュリティ・保守性・安全性などで品質を捉える品質特性モデル、ユニットのまとまり具合を示すモジュール強度・依存の強さを示すモジュール結合度というモジュール分割基準、統一したルールでコードを書くコーディング標準、goto文を避け構造的に書く構造化プログラミング、複数処理を同時に進める並列処理プログラミングを経て実装します。コードの品質を仲間内で確認するコードレビュー(メトリクス計測・コードインスペクション)、未実装部分を補う仮のモジュールドライバ・スタブもテスト実装の実務でよく使われます。
テスト工程では、テスト設計と管理手法のもと、内部構造に着目するホワイトボックステスト、外部からの入出力だけに着目するブラックボックステストを使い分けます。ユニットを段階的に組み合わせるソフトウェア統合計画・ソフトウェア統合テストには、上位モジュールから結合するトップダウンテスト、下位から結合するボトムアップテストがあり、結果を統合テスト報告書にまとめます。要件を満たすか確認するソフトウェア検証テストとその評価には、応答時間を測る性能テスト、高負荷時の挙動を確認する負荷テスト、第1〜9章で学んだ観点を検証するセキュリティテストが含まれ、ソフトウェア検証テスト報告書・システム全体を対象にしたシステム統合テスト・システム統合の評価までを経て完成します。
扱う用語(精選・28語)
- ソフトウェアの構造の設計/ソフトウェアユニット分割/ソフトウェアユニットのテストの設計/ソフトウェア統合テストの設計/品質特性モデル/モジュール分割基準(モジュール強度・モジュール結合度)/コーディング標準/構造化プログラミング/並列処理プログラミング/コードレビュー/ドライバ/スタブ
- テスト設計と管理手法/ホワイトボックステスト/ブラックボックステスト/ソフトウェア統合計画/ソフトウェア統合テスト/トップダウンテスト/ボトムアップテスト/統合テスト報告書/ソフトウェア検証テスト/ソフトウェア検証テストの評価/性能テスト/負荷テスト/セキュリティテスト/ソフトウェア検証テスト報告書/システム統合テスト/システム統合の評価
導入・保守運用と開発方法論
完成したシステムを実際に使い始める段階では、導入作業、旧システムから入れ替えるリプレース、本番移行を判断する受入れ基準、利用者への教育訓練計画を行います。本当に業務目的を達成できるかを確かめる観点として、妥当性確認される要件(要求事項)、妥当性確認テストの目的、達成すべき成功基準(期待される結果)があり、不具合が出た場合は不具合の根本原因を追求し、障害発生時の運用計画に沿って対応します。近年はAIを使って運用を自動化・効率化するAIOpsも普及しています。
保守段階では、作業員の安全や業務継続を守る運用安全及び業務安全に関する安全戦略のもと保守テストを行い、不具合を直す是正保守、機能を改善する改良保守、環境変化に対応する適応保守、予防的に手を打つ予防保守、潜在的な欠陥を先回りして直す完全化保守を使い分けます。故障のしやすさを分析するシステム信頼性のための解析技法(FTA・FMEA)も、高い信頼性が求められるシステムで使われます。
こうした開発・運用を効率的に進める方法論として、短い反復で機能を作り込むエクストリームプログラミング(XP)、優先順位をつけながら反復開発するスクラム、無駄を省くリーンソフトウェア開発、テストを先に書くテスト駆動開発(TDD)があります。運用の信頼性をエンジニアリングとして扱うSREでは、許容できる障害の余地を数値化したエラーバジェットという考え方を使います。コードの統合を頻繁に行う継続的インテグレーション(CI)、リリース準備を自動化する継続的デリバリー(CD)、本番反映まで自動化する継続的デプロイ、意図的に障害を起こして耐性を確認するカオスエンジニアリング、システムの内部状態を外部から把握できるオブザーバビリティ(可観測性)、開発・運用にセキュリティを組み込むDevSecOpsも、現代的な開発・運用の実務として重要です。
扱う用語(精選・30語)
- 導入作業/リプレース/受入れ基準/教育訓練計画/妥当性確認される要件/妥当性確認テストの目的/成功基準/不具合の根本原因/障害発生時の運用計画/AIOps
- 運用安全及び業務安全に関する安全戦略/保守テスト/是正保守/改良保守/適応保守/予防保守/完全化保守/システム信頼性のための解析技法(FTA・FMEA)
- エクストリームプログラミング(XP)/スクラム/リーンソフトウェア開発/テスト駆動開発(TDD)/SRE/エラーバジェット/継続的インテグレーション(CI)/継続的デリバリー(CD)/継続的デプロイ/カオスエンジニアリング/オブザーバビリティ(可観測性)/DevSecOps
ソフトウェアアーキテクチャ・設計原則と開発環境・Web技術
ソフトウェアの構造を整理する型として、責務ごとに層を分けるレイヤードアーキテクチャ、依存の方向を内側に向けるクリーンアーキテクチャ、画面・処理・データを分離するMVC、サービス単位に分割するマイクロサービスアーキテクチャとその源流であるSOA(Service-Oriented Architecture)があります。頻出する設計上の課題への定石をまとめたGoFのデザインパターンには、インスタンスの作り方を扱う生成に関するパターン、クラス構成を扱う構造に関するパターン、オブジェクト間のやり取りを扱う振る舞いに関するパターンがあります。良い設計の指針ソフトウェア設計原則(SOLID)のもと、データと処理をまとめるカプセル化、同じ操作で異なる型を扱える多相性(ポリモーフィズム)、共通点を抽象化する汎化とその逆の特化を活用し、クラス構造を示すクラス図、処理の流れを示すアクティビティ図、状態遷移を示すステートマシン図で設計を可視化します。
開発環境としては、変更履歴を管理するソースコード管理(SCM)、本番前の検証を行うステージング環境、設計書やモデルを管理する設計データ管理、コーディングを支援する統合開発環境(IDE)、無償で利用できるオープンソースライブラリとその利用条件を定めるオープンソースライセンシング(代表例がGPL)を活用します。Web・モバイル開発では、スマートフォン向けの設計を優先するモバイルファースト、画面サイズに応じてレイアウトを変えるレスポンシブWebデザイン、サーバー側で処理を行うサーバサイドプログラミング、ページ遷移なしで動作するSPA(Single Page Application)、ブラウザ上で高速に実行できるWebAssembly、アプリのような体験を提供するプログレッシブウェブアプリ(PWA)、機能利用時に許可を求めるパーミッション要求があります。
最後に、システムを支える施設・設備として、地震対策の免震装置や落雷対策のサージ防護デバイスなどを含む建物管理、泡・ハロゲン化物・不活性ガスなどの消火設備、無停電電源装置(UPS)や自家発電設備などの電気設備もあわせて押さえておきましょう(第5章で学んだ物理的管理策とも関連します)。
扱う用語(精選・34語)
- レイヤードアーキテクチャ/クリーンアーキテクチャ/MVC/マイクロサービスアーキテクチャ/SOA/GoF(生成・構造・振る舞いに関するパターン)/ソフトウェア設計原則(SOLID)/カプセル化/多相性(ポリモーフィズム)/汎化/特化/クラス図/アクティビティ図/ステートマシン図
- ソースコード管理(SCM)/ステージング環境/設計データ管理/統合開発環境(IDE)/オープンソースライブラリ/オープンソースライセンシング/GPL
- モバイルファースト/レスポンシブWebデザイン/サーバサイドプログラミング/SPA/WebAssembly/プログレッシブウェブアプリ(PWA)/パーミッション要求
- 建物管理/消火設備/電気設備
AIで学ぶ
ここまでの用語は、ChatGPTやClaudeなどの生成AIに以下のプロンプトを投げかけると、比較表つきでさらに深く掘り下げて学習できます。コピーして使ってみましょう。
あなたは情報処理安全確保支援士(SC)試験の講師です。「データベースとシステム開発・運用」の範囲について、以下の用語を初学者向けに**関連づけながら**説明してください(単体の丸暗記より、「共通フレーム」の一連の流れ「要件定義→設計→実装→テスト→導入→保守」のどこに位置する用語かを理解したほうが記憶に定着しやすいためです)。用語同士の違いが分かる**比較表**を最後に付けてください。
【データモデリングとDB運用】データアーキテクチャ、データベースの3層スキーマ、E-R図、UML、論理データモデル、主キー、外部キー、正規化、DDL、DML
【トランザクション制御と分散DB】同時実行制御、2相ロッキングプロトコル、デッドロック、ACID特性、ジャーナルファイル、フォワードリカバリ、バックワードリカバリ、レプリケーション、シャーディング、結果整合性
【要件定義と方式設計】システムの機能要件、非機能要件、セキュリティ要件、マイクロサービスアーキテクチャ、サーバレスアーキテクチャ
【詳細設計・実装とテスト】モジュール分割基準、コーディング標準、ホワイトボックステスト、ブラックボックステスト、トップダウンテスト、ボトムアップテスト、性能テスト、負荷テスト
【導入・保守と開発方法論】受入れ基準、是正保守、改良保守、予防保守、スクラム、テスト駆動開発(TDD)、SRE、エラーバジェット、CI、CD、DevSecOps
【アーキテクチャ・設計原則と開発環境】レイヤードアーキテクチャ、MVC、SOLID、カプセル化、多相性、IDE、SPA、WebAssembly、PWAこのプロンプトが「共通フレームの一連の流れ」を軸にした整理を指示しているのは、この章の用語が「要件定義→設計→実装→テスト→導入→保守」というシステム開発の標準的な工程に沿って並んでいるためです。今どの工程の話かを意識すると、初見の用語でも大まかに位置づけられます。試験対応としてはこの章の精選範囲で十分ですが、実務でより深く扱いたい場合はPD-Sコース第4〜6章も参考にしてください。
章末チェック
最後に、この章で学んだ知識をアウトプットして定着させましょう。全問に答えたら「答え合わせ」を押してください。
問1. 業務の視点で実体(エンティティ)と関係を整理し、E-R図で表現するデータモデルはどれか。
問2. トランザクションが満たすべき原子性・一貫性・独立性・永続性という4つの性質の総称はどれか。
問3. 分散システムにおいて、更新が即座に全拠点へ反映されなくても、最終的に一致すればよいとする考え方はどれか。
問4. システム開発の共通フレームにおいて、機能を独立したサービスに分割し、それぞれを個別にデプロイできるようにするアーキテクチャはどれか。
問5. プログラムの内部構造(ロジック)に着目してテストケースを設計する手法はどれか。
問6. 許容できる障害の余地をあらかじめ数値化しておき、その範囲内でリリース頻度を判断する、SREの考え方はどれか。
問7. 環境の変化(OSやミドルウェアのバージョンアップなど)に対応するために行う保守の種類はどれか。
この章のまとめ
この章では、データモデリングとトランザクション制御・分散データベース、システムライフサイクルプロセス(要件定義から保守まで)、そしてアジャイル・DevOps・SREといった開発方法論、ソフトウェアアーキテクチャと開発環境・Web技術を学びました。これで知識861語(専門知識9章+その他知識2章)を全てカバーしたことになります。
次章では、知識ではなく実務で求められる技能を、架空企業でのケーススタディ形式で学びます。→ 第12章 実務ケーススタディ(技能)