開発技術

1. システム開発技術と設計技法

要件定義から実装までの流れとV字モデル、モジュール分割の良し悪しを測るものさし、UMLとオブジェクト指向の考え方が分かります。

システム開発は、いきなりプログラムを書き始めるのではなく、決まった順序で少しずつ具体化していきます。まずシステム全体で何を実現するかを決めるシステム要件定義、次にその機能をハードウェア・ソフトウェア・手作業のどれに割り当てるかを決めるシステム方式設計、続いてソフトウェアが何をするかを決めるソフトウェア要件定義、ソフトウェアの内部をどんなモジュールに分けてどうつなぐかを決めるソフトウェア方式設計、各モジュールの中身を決めるソフトウェア詳細設計、そして実装（プログラミング）へと進みます。「何をするか」を決めてから「どう作るか」を決める、全体から部分へ詳細化する、という二つの向きを守るのが基本です。

この流れを図にすると、左側に設計の工程が下りていき、右側にテストの工程が上がっていくV字の形になります。これがV字モデルで、左右で向かい合う工程どうしが対応関係を持ちます。ソフトウェア詳細設計に対応するのが単体テスト、ソフトウェア方式設計に対応するのが結合テスト、システム方式設計に対応するのがシステムテスト、システム要件定義（要件定義）に対応するのが運用テスト（受入テスト）です。つまり各テストは「対応する設計工程で決めたことが実現できているか」を確かめる場であり、テスト設計は対応する設計工程の成果物を根拠に作ります。この対応を意識すると、テストで見つかった不具合がどの工程の誤りかを追いやすくなります。

要件定義では、要件を機能要件と非機能要件に分けて整理します。機能要件は「受注を登録できる」「請求書を出力する」のように、システムが提供する処理そのものです。非機能要件は「検索結果を3秒以内に表示する」「24時間365日稼働する」「通信を暗号化する」のように、機能をどの程度の性能・可用性・セキュリティ・運用性・拡張性で実現するかを定めたものです。非機能要件は後から変えると全体の作り直しになりやすいため、早い段階で数値を伴った形で決めておくことが重要です。

設計技法のうち、処理の手順を中心に考えるのが構造化設計です。データの流れに着目してシステムを表すデータフロー図（DFD）では、プロセス（円または角丸四角）、データフロー（矢印）、データストア（2本の平行線）、外部実体（四角形）の四つの記号を使い、制御の流れではなくデータの流れだけを描きます。イベントによって振る舞いが変わる対象は状態遷移図で、状態と、状態を移らせるイベントの組合せとして表します。プログラム全体は、機能のまとまりごとにモジュールへ分割します。

モジュール分割の良し悪しは、モジュールの独立性で測ります。ものさしは二つあり、一つはモジュール同士のつながりの弱さを見る結合度で、弱いほど（データ結合に近いほど）よいとされます。弱い順にデータ結合、スタンプ結合、制御結合、外部結合、共通結合、内容結合です。もう一つはモジュールの中身のまとまりの良さを見るモジュール強度（凝集度）で、強いほど（機能的強度に近いほど）よいとされます。弱い順に暗号的強度、論理的強度、時間的強度、手順的強度、連絡的強度、情報的強度、機能的強度です。「結合度は弱く、強度は強く」が合言葉で、この二つの順序は試験で頻出です。

現在の主流であるオブジェクト指向では、データ（属性）とそれを操作する手続（メソッド）を一つにまとめたクラスを単位に考えます。クラスから実際に生成した実体がインスタンスです。内部のデータを外から直接触れないようにして、決められたメソッド経由でだけ操作させるのがカプセル化、上位クラスの属性や操作を下位クラスが受け継いで差分だけ書けるようにするのが継承（汎化・特化の関係）、同じメッセージでも受け手のクラスによって異なる動作をするのが多相性（ポリモーフィズム）です。全体と部分の関係を表すのが集約です。よく現れる設計の型をまとめたものがデザインパターンです。

オブジェクト指向の設計を図で表す共通の記法がUMLです。クラスの属性・操作と、汎化や集約といったクラス間の静的な関係を表すクラス図、利用者（アクター）とシステムの機能の関係を表すユースケース図、オブジェクト間のメッセージのやり取りを時間順に表すシーケンス図、処理の流れや分岐・並行処理を表すアクティビティ図、一つのオブジェクトの状態遷移を表す状態マシン図などがあり、表したいものによって使い分けます。

利用者が実際に触れる部分の設計も開発技術の一部です。ユーザビリティは、指定された利用者が特定の状況で目的を達成する際の有効さ・効率・満足度の度合いを指し、見た目の良し悪しだけを言うものではありません。UI設計では、操作の一貫性を保つ、押せるものと押せないものを見た目で区別する、誤操作を取り消せるようにする、エラーメッセージで次にすべきことを示す、といった配慮が求められます。年齢や障害の有無にかかわらず使えるようにする考え方がアクセシビリティです。

/* データ結合の例：必要な値だけを引数で渡している */○実数型: 税込金額(整数型: 本体価格, 実数型: 税率)  return 本体価格 × (1 + 税率) /* 制御結合の例：引数で相手の処理内容を切り替えている */○整数型: 計算(整数型: a, 整数型: b, 整数型: 種別)  if (種別 = 1)    return a + b  else    return a - b  endif

用語

V字モデル

左に設計工程、右にテスト工程を並べてV字に描き、向かい合う工程を対応付けた開発の進め方。詳細設計と単体テスト、方式設計と結合テストのように、各テストが何を検証するかを明確にする。

機能要件

システムが提供する処理そのものを定めた要件。受注を登録する、請求書を出力するなど「何をするか」を表す。

非機能要件

機能をどの程度の品質で実現するかを定めた要件。応答時間などの性能、稼働率などの可用性、セキュリティ、運用・保守性、拡張性が含まれ、数値で決めておくことが望ましい。

DFD

データフロー図。プロセス、データフロー、データストア、外部実体の四つの記号でデータの流れを表す図。制御の流れや実行順序は表さない。

結合度

モジュール同士のつながりの強さ。弱いほど独立性が高く保守しやすい。弱い順にデータ結合、スタンプ結合、制御結合、外部結合、共通結合、内容結合。

データ結合

必要なデータ項目だけを引数として受け渡す結合。結合度が最も弱く、最も望ましい形とされる。

共通結合

複数のモジュールが共通のグローバル領域に置いたデータを互いに参照・更新する結合。どこで値が変わるか追いにくく、結合度が強い。

内容結合

相手モジュールの内部を直接参照したり途中に飛び込んだりする結合。結合度が最も強く、避けるべき形とされる。

モジュール強度

凝集度ともいう。モジュール内のまとまりの良さ。強い順に機能的強度、情報的強度、連絡的強度、手順的強度、時間的強度、論理的強度、暗号的強度。

機能的強度

一つの明確な機能だけを実行するモジュールの状態。モジュール強度の中で最も強く、最も望ましい。

カプセル化

データとそれを操作する手続を一つにまとめ、内部の構造を外から隠すこと。外部は決められたメソッドを通じてだけ操作できるため、内部を変更しても影響が広がらない。

継承

上位クラスの属性や操作を下位クラスが受け継ぐ仕組み。下位クラスは差分だけを定義すればよい。クラス間の汎化・特化の関係を実装したもの。

多相性

ポリモーフィズム。同じメッセージを送っても、受け取るオブジェクトのクラスによって異なる動作をする性質。呼び出す側は相手のクラスを意識しなくてよい。

集約

複数のオブジェクトを部分としてまとめ、全体と部分の関係を表すもの。汎化（〜は〜の一種である）とは区別する。

ユーザビリティ

指定された利用者が特定の状況で目的を達成する際の、有効さ・効率・満足度の度合い。見た目の美しさだけを指す言葉ではない。

例題

/* 改善前：共通域を使う（共通結合）*/○処理A()  WORK ← 100  処理B() /* 改善後：引数で渡す（データ結合）*/○処理A()  処理B(100)

出典・根拠：IPA 基本情報技術者試験 シラバス Ver.9.2 大分類4：開発技術　中分類12：システム開発技術

2. テストと品質の確認

ホワイトボックステストの網羅基準の違い、同値分割と境界値分析、テスト工程とレビューの進め方が分かります。

テストは、作ったものが仕様どおりに動くことを確かめる作業です。大きく二つの立場があります。プログラムの内部構造を見て、どの経路を通るかを根拠にテストケースを作るのがホワイトボックステスト、内部構造は見ずに仕様上の入力と出力の関係だけからテストケースを作るのがブラックボックステストです。前者は主に単体テストで、後者は主に結合テスト以降で使われます。両方を組み合わせないと、通っていない経路や、仕様に対する考え違いを見落とします。

ホワイトボックステストでは、どこまで網羅すれば十分と考えるかの基準（網羅基準、カバレッジ）を決めます。命令網羅は、すべての命令を少なくとも1回実行すればよいという最も弱い基準です。判定条件網羅（分岐網羅）は、それぞれの判定の結果が真と偽の両方になるようにします。条件網羅は、判定の中に複数の条件があるとき、個々の条件がそれぞれ真と偽の両方になるようにします。判定条件／条件網羅は、判定条件網羅と条件網羅の両方を同時に満たします。複数条件網羅は、判定に含まれる個々の条件の真偽の全組合せを実行する最も強い基準です。

ここで注意したいのは、条件網羅を満たしても判定条件網羅を満たすとは限らない、という点です。たとえば if (A or B) に対して（A＝真, B＝偽）と（A＝偽, B＝真）の2件を実行すると、AもBも真と偽の両方を取るので条件網羅は満たしますが、判定の結果はどちらも真のままなので判定条件網羅は満たしません。逆に if (A and B) に対して（真,真）と（偽,真）の2件では、判定は真と偽の両方になりますが、Bが真のままなので条件網羅を満たしません。一方、複数条件網羅を満たせば、個々の条件も判定全体も必ず真と偽の両方を取るので、条件網羅と判定条件網羅の両方を含みます。条件の数がn個なら組合せは2のn乗通りで、条件が増えると急に件数が増えるのが弱点です。

ブラックボックステストの代表がまず同値分割です。同じ結果になる入力の範囲を同値クラスに分け、各クラスから代表値を一つずつ選びます。「1以上100以下なら有効」という仕様なら、有効クラス（1〜100）、無効クラス（1未満）、無効クラス（100より大きい）の三つに分かれ、たとえば50、-5、150の3個を選びます。次に境界値分析は、誤りは境目で起きやすいという経験に基づき、同値クラスの境目とその隣の値を選びます。同じ仕様なら0、1、100、101の4個です。判定式の不等号や等号の付け間違いは、まさにこの4個で見つかります。入力と出力の論理関係を図にして決定表に直し、組合せのテストケースを作るのが原因結果グラフです。

テストは工程としても段階を踏みます。単体テストはモジュール一つずつの内部を確認し、結合テストはモジュールをつないだときのインタフェースを確認します。結合の進め方には、上位から順につないでいくトップダウンテストと、下位から順につないでいくボトムアップテストがあります。トップダウンでは、まだできていない下位モジュールの代わりに決められた値を返すスタブを用意し、ボトムアップでは、上位モジュールの代わりにテスト対象を呼び出すドライバを用意します。その後、システム全体を確認するシステムテスト、利用者が実際の業務の流れで確認する運用テスト（受入テスト）へと進みます。

そのほか、修正した箇所以外に悪影響が出ていないかを、過去のテストケースを再実行して確認するのが回帰テスト（リグレッションテスト）です。想定した応答時間やスループットが出るかを見るのが性能テスト、想定を超える負荷をかけて限界や挙動を見るのが負荷テスト（ストレステスト）です。テストの進み具合と品質は、テスト項目の消化件数と検出バグ件数を時間の経過に沿って描いたバグ管理図（信頼度成長曲線）で管理します。検出バグの累積件数はふつうS字を描き、終盤で増加が鈍って水平に近づくと収束したと判断します。

プログラムを動かさずに人の目や道具で確認する方法もあります。関係者が集まって成果物の誤りを見つけるのがレビューで、作成者が主催して非公式に行うウォークスルー、モデレーター（進行役）が主催し役割と手順を定めて公式に行うインスペクション、参加者が持ち回りで司会や説明を担当するラウンドロビンなどがあります。ソースコードを実行せずに構文や規約違反、危険な記述を機械的に調べるのが静的解析です。加えて、回帰テストのように何度も繰り返すテストはツールで自動化しておくと、修正のたびに安心して確認できます。

○整数型: 判定(整数型: a, 整数型: b)  整数型: x  if (a > 0 and b > 0)    x ← 1  else    x ← 2  endif  return x /* (a,b)=(1,1) と (-1,-1) の2件 : 判定条件網羅も条件網羅も満たす *//* (a,b)=(1,1) と (-1,1)  の2件 : 判定条件網羅のみ（bが真のまま）*//* (a,b)=(1,-1) と (-1,1) の2件 : 条件網羅のみ（判定はどちらも偽）*//* 上記4組合せすべてを実行して初めて複数条件網羅（4件）*/

用語

ホワイトボックステスト

プログラムの内部構造（分岐や経路）を見て、どこを通るかを根拠にテストケースを作る技法。網羅基準を決めて、どこまで確認したかを測る。主に単体テストで使う。

ブラックボックステスト

内部構造を見ずに、仕様上の入力と出力の関係だけからテストケースを作る技法。同値分割、境界値分析、原因結果グラフが代表例。

命令網羅

すべての命令を少なくとも1回実行することを求める、最も弱い網羅基準。else側に命令がなければ判定を偽にしなくても満たせてしまう。

判定条件網羅

分岐網羅ともいう。それぞれの判定の結果が真と偽の両方になるようテストケースを作る基準。個々の条件の真偽までは問わない。

条件網羅

判定に含まれる個々の条件が、それぞれ真と偽の両方の値を取るようにする基準。判定全体の結果が真と偽の両方になるとは限らない点に注意する。

判定条件／条件網羅

判定条件網羅と条件網羅の両方を同時に満たす基準。個々の条件も判定全体も真と偽の両方を取る。

複数条件網羅

判定に含まれる個々の条件の真偽の全組合せを実行する、最も強い網羅基準。条件がn個なら2のn乗通りが必要で、条件網羅と判定条件網羅を包含する。

同値分割

同じ結果になる入力の範囲（同値クラス）に分け、有効クラスと無効クラスのそれぞれから代表値を一つずつ選ぶブラックボックステストの技法。

境界値分析

同値クラスの境目とその隣の値をテストデータに選ぶ技法。1以上100以下が有効なら0・1・100・101を選ぶ。不等号や等号の付け間違いを見つけやすい。

原因結果グラフ

入力（原因）と出力（結果）の論理的な関係を図に表し、決定表に変換して組合せのテストケースを作る技法。

スタブ

トップダウンテストで、まだできていない下位モジュールの代わりに用意する仮のモジュール。呼び出されると決められた値を返す。

ドライバ

ボトムアップテストで、まだできていない上位モジュールの代わりに用意する仮のモジュール。テスト対象を呼び出して結果を受け取る。

回帰テスト

リグレッションテスト。修正した箇所以外に悪影響が出ていないかを、過去のテストケースを再実行して確認するテスト。自動化の効果が大きい。

バグ管理図

テスト項目の消化件数と検出バグ件数を時間の経過に沿って描いた図。検出バグの累積件数がS字を描いて水平に近づいたとき収束と判断する（信頼度成長曲線）。

インスペクション

モデレーター（進行役）が主催し、参加者の役割と手順をあらかじめ定めて公式に行うレビュー。事前準備と指摘の記録、是正の確認までを手順化する。

ウォークスルー

作成者が主催し、参加者と一緒に成果物を追いながら誤りを指摘し合う非公式なレビュー。管理者は原則参加せず、評価の場にしないのが原則。

静的解析

プログラムを実行せずに、ソースコードの構文・コーディング規約違反・危険な記述などを機械的に検査すること。

例題

出典・根拠：IPA 基本情報技術者試験 シラバス Ver.9.2 大分類4：開発技術　中分類12：システム開発技術（ソフトウェア構築・ソフトウェア結合・ソフトウェア導入）

3. 開発モデルと開発管理

ウォーターフォールからアジャイルまでの進め方の違い、スクラムの役割・イベント・成果物、CI/CDや構成管理の考え方が分かります。

開発の進め方（開発モデル）にはいくつかの型があります。ウォーターフォールモデルは、要件定義から順に工程を下流へ一度だけ流し、原則として前の工程には戻りません。工程ごとに成果物を確定させるため管理しやすい反面、後の工程で要件の誤りが見つかると手戻りが大きくなります。プロトタイピングモデルは、早い段階で試作品を作って利用者に触ってもらい、その評価をもとに要求を固めます。スパイラルモデルは、システムを独立性の高い部分に分け、設計・実装・評価という流れを部分ごとに繰り返して渦を描くように全体を完成させます。RADは、少人数のチームと開発支援ツールを使い、期間を区切って短期間で開発を終えることを重視します。

アジャイル開発は、1〜4週間程度の短い反復（イテレーション）を繰り返し、反復ごとに動くソフトウェアを作りながら進める考え方の総称です。アジャイルソフトウェア開発宣言では、プロセスやツールよりも個人と対話を、包括的なドキュメントよりも動くソフトウェアを、契約交渉よりも顧客との協調を、計画に従うことよりも変化への対応を重視するとしています。ただし右側に書かれたことに価値がないという意味ではなく、より価値を置くという相対的な表明です。代表的な手法にスクラム、XP（エクストリームプログラミング）、かんばん（作業を見える化し、仕掛かり中の作業量を制限して流れを良くする）があります。

スクラムは、役割・イベント・成果物を定めた枠組みです。役割は三つで、何を作るかを決めてプロダクトバックログの内容と優先順位に責任を持つプロダクトオーナー、スクラムが正しく実践されるよう支援し妨げを取り除くスクラムマスター、実際に作るとともに誰が何をするかを自分たちで決める開発者です。スクラムマスターは指示を出す管理者ではありません。

イベントは、固定長の期間であるスプリント（1か月以内）と、その中で行う四つです。スプリントプランニングで今回何を作るかを決めてスプリントバックログを作り、デイリースクラムで開発者が毎日15分程度、進捗と妨げを確認してその日の計画を調整し、スプリントレビューで完成したインクリメントを関係者に見せてフィードバックを得て、スプリントレトロスペクティブでチームの進め方そのものを振り返って次の改善策を決めます。レビューが「作ったもの」を見るのに対し、レトロスペクティブは「作り方」を見る点が違いです。成果物は、プロダクトに必要なものを優先順位付きで並べたプロダクトバックログ、そのスプリントで実現する項目と作業をまとめたスプリントバックログ、そのスプリントで完成し積み上がった動くインクリメントの三つです。

XPは、開発者側の具体的な実践（プラクティス）を重視します。2人が1台の端末を共有し、書き手と確認役を交代しながら進めるペアプログラミング、実装より先にテストコードを書いてそれが通るようにコードを書くテスト駆動開発、外部から見た振る舞いを変えずに内部構造を分かりやすく作り直すリファクタリング、変更をこまめに共有リポジトリへ反映してその都度自動でビルドとテストを行う継続的インテグレーションなどが代表です。ほかに、コードは全員のものとする共同所有、シンプルな設計、小まめなリリースといった実践もあります。

開発を組織として管理するための共通の物差しが共通フレーム（SLCP）です。取得者と供給者が同じ用語と作業の枠組みで話せるように、企画から開発、運用、保守、廃棄までのプロセスを定義したもので、そのまま使う手順書ではなく、必要な作業を選んで修正（テーラリング）して使います。開発コストを下げる工夫としてはソフトウェアの再利用があり、部品化したモジュールやライブラリ、フレームワークを活用します。既存のプログラムを解析して仕様や設計情報を導き出すのがリバースエンジニアリング、そこから得た情報をもとに新しいシステムを作るのがフォワードエンジニアリング、両者を合わせて既存システムを作り直すのがリエンジニアリングです。公開された複数のサービス（API）を組み合わせて新しいサービスを作るのがマッシュアップです。なお、再利用や解析にあたっては、著作権やライセンス条件、OSSの利用条件など知的財産の適用範囲を必ず確認します。

開発と運用を分断せず、協力して速く安全に価値を届けようという考え方がDevOpsです。これを支えるのが自動化で、変更を共有リポジトリへ頻繁に反映しそのたびに自動でビルドとテストを行う継続的インテグレーション（CI）と、そこからリリース可能な状態の用意や本番環境への配置までを自動化する継続的デリバリー／継続的デプロイメント（CD）が代表です。土台となるのが構成管理で、ソースコード・設計書・設定ファイル・環境の状態といった構成要素を識別し、変更を記録して、いつでも特定時点の状態を再現できるようにします。その中でソースコードの版を管理するのがバージョン管理です。開発環境・試験環境・本番環境は分けたうえで、構成管理によって同じ状態を再現できるようにしておくのが基本です。

用語

ウォーターフォールモデル

工程を上流から下流へ一度だけ順に進め、原則として前工程に戻らない開発モデル。管理しやすいが、後半で要件の誤りが判明したときの手戻りが大きい。

プロトタイピングモデル

早い段階で試作品を作って利用者に評価してもらい、その結果をもとに要求を固めていく開発モデル。認識の食い違いを早期に発見できる。

スパイラルモデル

システムを独立性の高い部分に分け、設計・実装・評価の流れを部分ごとに繰り返して、渦を描くように全体を作り上げる開発モデル。

アジャイル開発

短い反復を繰り返し、反復ごとに動くソフトウェアを作りながら要求の変化を取り込む開発の考え方の総称。スクラム、XP、かんばんなどが含まれる。

プロダクトオーナー

スクラムの役割の一つ。何を作るかを決め、プロダクトバックログの項目と優先順位に責任を持ち、プロダクトの価値を最大化する。

スクラムマスター

スクラムの役割の一つ。スクラムが正しく実践されるようチームを支援し、進行の妨げを取り除く。作業を割り当てて指示を出す管理者ではない。

スプリント

スクラムにおける1か月以内の固定長の反復期間。この中でプランニング、デイリースクラム、レビュー、レトロスペクティブが行われる。

デイリースクラム

開発者が毎日15分程度で進捗と妨げを共有し、その日の計画を調整するイベント。問題の解決そのものは別の場で行う。

スプリントレトロスペクティブ

スプリントの最後に、成果物ではなくチームの進め方（プロセス・道具・協働）を振り返り、次のスプリントで試す改善策を決めるイベント。

プロダクトバックログ

プロダクトに必要なものを優先順位を付けて並べた一覧。プロダクトオーナーが管理し、状況に応じて常に見直される。

インクリメント

そのスプリントで完成し、これまでの成果に積み上がった動作するソフトウェア。完成の定義を満たしたものだけがインクリメントになる。

テスト駆動開発

XPのプラクティスの一つ。実装するコードより先にテストコードを書き、それが通るようにコードを書いてから整理する（リファクタリングする）手法。

リファクタリング

外部から見た振る舞いを変えずに、プログラムの内部構造を分かりやすく整理し直すこと。機能追加とは分けて行うのが原則。

共通フレーム（SLCP）

取得者と供給者が共通の用語と枠組みで話せるように、企画から開発・運用・保守・廃棄までのプロセスを定義したもの。必要な作業を選んで修正（テーラリング）して使う。

リバースエンジニアリング

既存のプログラムやオブジェクトコードを解析して、仕様や設計情報を導き出すこと。得た情報から新システムを作るのがフォワードエンジニアリング。

マッシュアップ

公開された複数のサービス（API）を組み合わせ、新しい一つのサービスを作り上げる手法。地図サービスと店舗情報を組み合わせる例が典型。

継続的インテグレーション

CI。変更したソースコードを共有リポジトリへ頻繁に反映し、その都度自動でビルドとテストを実行して、統合時の問題を早期に発見する仕組み。

構成管理

ソースコード・設計書・設定・環境などの構成要素を識別し、変更を記録して、いつでも特定時点の状態を再現できるようにする管理。版を管理するバージョン管理を含む。

例題

出典・根拠：IPA 基本情報技術者試験 シラバス Ver.9.2 大分類4：開発技術　中分類13：ソフトウェア開発管理技術（システム開発技術）

演習：この章の問題を解く

ランダム出題の演習ツールです（JavaScript が有効な場合に動きます）。上の「確認問題」はそのままでもすべて読めます。