ITパスポート試験

= 目 次 =

第 1章 はじめに ···························································· 1

◆ストラテジ系◆

第 2章 企業と法務 ···························································· 2

2.1. 経営・組織論 ·························································· 3

2.2. OR・IE ································································ 6

2.3. 会計・財務 ·························································· 15

2.4. 知的財産権 ·························································· 21

2.5. セキュリティ関連法規 ················································· 25

2.6. 労働関連・取引関連法規 ··············································· 27

2.7. その他の法律・ガイドライン・技術者倫理 ································ 30

2.8. 標準化関連 ·························································· 32

確認問題 ······························································ 34

第 3章 経営戦略 ····························································· 45

3.1. 経営戦略手法 ························································· 46

3.2. マーケティング ······················································· 49

3.3. ビジネス戦略と目標・評価 ············································· 52

3.4. 経営管理システム ····················································· 53

3.5. 技術開発戦略の立案・技術開発計画 ······································ 54

3.6. ビジネスシステム ····················································· 55

3.7. エンジニアリングシステム ············································· 57

3.8. e-ビジネス ··························································· 58

3.9. 民生機器・産業機器 ··················································· 60

確認問題 ······························································ 61

第 4章 システム戦略·························································· 66

4.1. 情報システム戦略 ····················································· 67

4.2. 業務プロセス ························································· 68

4.3. ソリューションビジネス ··············································· 71

4.4. システム化計画 ······················································· 73

4.5. 要件定義 ···························································· 74

4.6. 調達計画・実施 ······················································· 75

確認問題 ······························································ 76

◆マネジメント系◆

第 5章 開発技術 ····························································· 81

5.1. システム開発技術 ····················································· 82

5.2. 開発プロセス・手法 ··················································· 85

確認問題 ······························································ 90

第 6章 プロジェクトマネジメント ············································· 95

6.1. プロジェクトマネジメント ·············································· 96

確認問題 ······························································ 98

第 7章 サービスマネジメント ················································ 102

7.1. サービスマネジメント ················································· 103

7.2. サービスサポート ···················································· 104

7.3. サービスデリバリ ····················································· 106

7.4. ファシリティマネジメント ············································ 108

7.5. システム監査 ························································ 109

7.6. 内部統制 ···························································· 110

確認問題 ····························································· 111

◆テクノロジ系◆

第 8章 基礎理論 ···························································· 115

8.1. 離散数学 ··························································· 116

8.2. 応用数学 ··························································· 126

8.3. 情報に関する理論 ···················································· 131

8.4. データ構造 ························································· 135

8.5. アルゴリズム ························································ 137

8.6. プログラミング・プログラム言語 ······································· 142

8.7. その他の言語 ························································ 143

確認問題 ····························································· 144

第 9章 コンピュータシステム ················································· 158

9.1. プロセッサ ························································· 159

9.2. メモリ ······························································ 160

9.3. 入出力デバイス ······················································ 163

9.4. システムの構成 ······················································ 165

9.5. システムの評価指標 ·················································· 167

9.6. オペレーティングシステム ············································ 170

9.7. ファイルシステム ···················································· 171

9.8. 開発ツール ························································· 173

9.9. オープンソースソフトウェア ·········································· 180

9.10. ハードウェア(コンピュータ・入出力装置) ····························· 181

確認問題 ···························································· 187

第 10章 技術要素 ··························································· 195

10.1. ヒューマンインタフェース技術 ······································· 196

10.2. インターフェース設計 ··············································· 198

10.3. マルチメディア技術 ・ 応用 ········································· 200

10.4. データベース方式 ・ 設計 ··········································· 205

10.5. データ操作 ・トランザクション処理 ·································· 209

10.6. ネットワーク方式 ··················································· 213

10.7. 通信プロトコル ····················································· 216

10.8. ネットワーク応用 ··················································· 218

10.9. 情報セキュリティとその管理 ········································· 224

10.10. 情報セキュリティ対策・情報セキュリティ実装技術 ····················· 227

確認問題 ·························································· 238

第 11章 おわりに ························································· 254

ITパスポート試験

通信講座

第 1 章 はじめに

1

第 1章 はじめに

「ITパスポート試験」は、平成 21年 4月に新しく創設された情報処理技術者試験であり、

スキルレベル 1 に相当します。この試験は経済産業省が認定する国家資格であり「職業人

が共通に備えておくべき情報技術に関する基礎的な知識をもち、情報技術に携わる業務に

就くか、担当業務に対して情報技術を活用していこうとする者」を対象として実施されて

います。

本書は、この IT パスポート試験の合格を目的として作成されています。この 1 冊で IT

パスポートの試験範囲を網羅でき、かつ必要な知識を得られるようになっております。ま

た、本書の内容と章末のサンプル問題とを組み合わせて学習することで、確実に実力が付

けられるよう構成されております。

本書が、皆様が ITパスポート試験を受験される際の最初の一歩となりますことを願って

おります。

平成 24年○月

株式会社ルート

第 4 章 システム戦略

66

第 4 章

システム戦略

第 4 章 システム戦略

67

第 4 章 システム戦略

4.1. 情報システム戦略

1．情報システム戦略

情報システム戦略とは、企業が経営戦略・経営目標を達成するために、IT を活用して業

務の効率化を図ることを指します。そのために、社内の現状分析を実施し、システム導入

に関しての有効性・投資効果の分析などを行っていく必要があります。

情報システムの導入には、以下のようなリスク・効果があると考えられます。

・一般的にシステムの導入・運用には大きなコストがかかる

・自社のビジネスモデルや業務プロセスに大きな影響を与える

・ネットワークを介した顧客・取引先とのやり取りに、既存の状態からの変化がある

・導入後には生産性・効率の向上、意思決定の支援、コストの低減などが可能になる

このように、大きなコストこそかかるもののその影響はとても大きいため、企業の現状

に合わせ、全社的な経営戦略に沿って戦略を立案しなければなりません。

2．図解を利用しての現状分析

情報システムを立案するためには、経営環境の分析を通じて、具体的な目標を立てるこ

とが必要になります。そのためには、まず企業の業務を分析していきます。

業務プロセスを視覚的に表したものをビジネスプロセスモデルといいます。これを作成

する際には、現状の業務を分かりやすく整理するための図解技法(ワークフロー図やフロー

チャートなど) を、目的に応じて使い分けます。

第 4 章 システム戦略

68

4.2. 業務プロセス

1．ITによる業務改善

(1)業務プロセスの把握・分析

現在の業務の効率性・生産性を上げるためには、現状の組織体制や業務プロセスを詳細

に分析し、現状における問題点を把握する必要があります。このために、業務プロセスを

視覚的に表すモデリングという考え方を使います。

①E-R図

実体(Entity)と関係(Relationship)を使い、データの関連を図解する手法です。データ

の構造とデータ間の結びつきを表現し、データ同士の関連性を分かりやすく図示します。

これにより、システム化に必要な業務ルールやデータ構造を把握できます。

②DFD(Data Flow Diagram：データフローダイヤグラム)

「データフロー」「プロセス」「データストア」「外部」の 4つの要素を使用し、業務やデ

ータの流れを表現する手法です。図解にあたり、4つの要素を以下のように定義します。

記号 名称 意味

データフロー データや情報の流れを表現する

プロセス データの処理(プロセス)を表現する

データストア データの蓄積(ファイル)を表現する

外部 データの発生源や行き先を表現する

例)取引先からの注文を請けた際の業務プロセスを DFDで示した場合

第 4 章 システム戦略

69

(2)業務プロセスの改善

業務プロセスの分析が出来たら、次はそれを改善する方法を探ります。

業務プロセスの改善に用いられる手法には次のようなものがあります。

①BPR(Business Process Reengineering：ビジネスプロセス再構築)

既存の組織や業務プロセスをすべて見直し、基礎から再構築する手法です。

業務プロセスを分析して機能別に分解し、抜本的な再設計と再構築を行うことで、企業

業績を飛躍的かつ継続的に向上させることを目的とします。

②BPM(Business Process Management：ビジネスプロセス管理)

業務プロセスの改善を継続的に進めていく経営手法です。

PDCA サイクルなどを使用してプロセスを改善していきます。これには業務プロセスの分

析ツールや自動化ツール、運用管理ツールなどが含まれます。

③ワークフローシステム

ネットワーク上で効率的に業務が流れるようにする仕組みを指します。

業務を企業全体の動きから分析し、業務の流れを図示したり、ルールを整備したりする

ことによって業務効率の改善を図ります。シームレス化1、書類の流れの電子化、文書・デ

ータの共有化などの機能があります。

2．ITの有効活用

(1)ITを有効に使いこなすために

業務改善・効率化を図るうえで、多くの企業が ITの導入を推進しています。

IT を有効活用することでその目的は達成できますが、そのためには利用者一人ひとりの

コンピュータに対する理解・能力(リテラシー)が必要になってきます。

情報リテラシーとは、情報システムを使いこなす能力を指します。

IT を導入して効果を出すためには、利用者となる社員に十分な情報リテラシーが無けれ

ばならず、そのための教育は欠かせない事項となります。

また、コンピュータを使えない高齢者層や貧困層等は、情報を活用できないために不利

な立場に置かれます。これにより、社会的な格差が拡大するディジタルディバイドが問題

となっています。

1 シームレス化：業務同士がスムーズに連携することを指す。「シーム」とはつなぎ目のこと。

第 4 章 システム戦略

70

(2)データを活用するための促進・啓発

情報システムに蓄積されたデータは、それを分析・加工し、個々の業務の改善や問題解

決に活用されて初めて価値があるものになります。

しかし、利用者一人ひとりの情報リテラシーは様々です。

そのため、利用者が誰でもデータを活用できるようにするためには、インターフェース

を使いやすくする、テンプレート2を用意する、サポート体制を整備するなど、利用しやす

さや利便性の向上に対する工夫が重要になります。

(3)コミュニケーションのためのシステム

企業が ITを導入するにあたり、業務効率の改善以外にも、関係者間の情報交換の場を設

けたり、コミュニケーションに役立つシステムを導入したりする事も出来ます。

以下にいくつか例を示します。

①グループウェア

関係者間の情報共有や連絡をスムーズに行うための支援システムです。電子メール機

能・電子掲示板機能・スケジュール管理機能・会議室予約機能等があります。

②テレビ会議

離れた場所にいる関係者同士をネットワークを介して繋ぎ、リアルタイムに会議を行う

ことができる機能です。

③電子メール

個人同士、もしくは複数人に向けてメッセージのやり取りをする機能です。ファイル添

付などの機能により電子データをやり取りすることも出来ます。

④電子掲示板

関係者間で 1 つのネットワーク上の空間を共有し、そこに各自が記載したメッセージを

使用してやり取りを行う機能です。

⑤チャット

関係者同士が 1 つのネットワーク上の空間を共有し、短いメッセージをリアルタイムに

やり取りできるサービスです。

2 テンプレート：雛形のこと。入力作業の効率化のため、あらかじめ入力項目を定めた書式を準備する。

第 4 章 システム戦略

71

4.3. ソリューションビジネス

1．ソリューションとは

ソリューションビジネスとは、情報技術を利用して業務における課題を把握し、解決の

糸口を提示するビジネスです。業務改善を行うには、現状の課題の把握とその解決法を示

すことが重要になりますが、ソリューションビジネスはそれらの手助けを行うビジネスに

なります。

ソリューションビジネスでは、主にシステムインテグレータ(SI)3などの専門の業者が、

このような顧客の要望に応じた情報システムを設計・構築を行って進めていきます。

以下にその形態の一例を示します。

(1)SOA(Service Oriented Architecture)

大規模なシステムを構築する際の手法のひとつです。業務上の処理を担当するソフトウ

ェアの機能をサービスと見立て、そのサービス同士を連携させてシステムを構築していく

ことを指します。サービスの組み合わせを利用してシステムを構築するため、柔軟性が高

いシステムを作成することができます。

(2)ASP(Application Service Provider)

業者のサーバにインストールされているアプリケーションソフトの機能一式を、インタ

ーネット経由でユーザに貸し出すサービスを展開する業者、及びそのサービスそのものを

指します。ユーザ毎に環境を用意するシングルテナント方式が採用されています。

(3)SaaS(Software as a Service)

業者がネットワーク経由で提供するアプリケーションソフトについて、ユーザにとって

必要なものだけを選択・利用できるようにしたサービスを指します。ASPとは違い、複数の

ユーザで 1つのシステムを利用するマルチテナント方式が採用されています。

(4)クラウドコンピューティング

インターネットを主とした、ネットワーク上をベースとしたコンピュータ資源の利用形

態のことを指します。ASP や SaaS の考え方を発展させたものであり、ソフトウェアに限ら

ず、データの格納や処理を含めてネットワークを経由し、サービスとして利用します。

3 システムインテグレータ：システムの企画立案・開発・運用に至るまでを提供する業者のこと。

第 4 章 システム戦略

72

(5)ハウジングサービス

ユーザが所有するサーバ等の設備を業者が所有する施設に預け、その運用管理を委託す

るサービスのことです。設備をユーザ側で準備するため、サーバの機種・OS・セキュリテ

ィの構成などをユーザ側で決めることが出来ます。また、業者が提供する高速で安定した

通信環境を利用できるようになります。

(6)ホスティングサービス

業者が所有するサーバ等の設備をレンタルし、設備の運用を委託するサービスのことで

す。業者の設備をレンタルするため、環境や構成、またシステム権限などの自由度はハウ

ジングサービスと比べ低くなります。

第 4 章 システム戦略

73

4.4. システム化計画

1．システム化計画

(1)システム化構想とシステム化計画

システム化構想とは、業務をシステム化する際の目的やスケジュール・費用などをまと

めたものです。経営戦略や事業戦略に基づき、経営目標を達成するうえで効果が期待でき

る分野を見極め、システム化構想をまとめ、システム化する案件を検討します。

システム化計画とは、システム化構想を含めた一連のシステム化の基本方針を立案して

まとめた開発計画の事を指します。

一般にシステム化計画は次のような手順でまとめていきます。

①システム化構想を策定する

②システム化の基本方針を立案する

③システム化の対象業務を分析する

④開発順序・概算コスト・費用対効果4などを測定する

(2)リスク分析

リスク分析とは、現状の情報システムが抱えるリスクを洗い出し、リスクの大きさやそ

の規模を測定する作業です。リスク分析は、次のような手順で主に行われます。5

4 費用対効果：投資した費用に対して得られる効果の割合のことを指す。 5 情報資産：何らかの価値がある情報の総称。顧客情報や技術情報などが含まれる。

第 4 章 システム戦略

74

4.5. 要件定義

1．業務要件定義

要件定義とは、利用者が情報システムに求める事を定義としてまとめることを指します。

ここでは、IT 化する範囲と機能をはっきりさせ、経営者や開発者・利用者といった関係

者間の合意を得たうえで、要件定義書として文書化します。

要件定義には、大きく分けて次の 3つのフェーズが存在します。

(1)経営要件定義

経営戦略やシステム戦略に沿って、経営者の視点からシステムに求める要件のことです。

要件定義のベースになります。

(2)業務要件定義

経営要件を前提として、利用者の視点からシステムの機能や性能をまとめた要件のこと

です。具体的には以下の 2つに分けられます。

－機能要件

システム自身が持つ機能のことです。データ構造やデータ処理、インターフェース定

義など、業務においてそのシステムやソフトウェアで何ができるのかをまとめたものを

指します。

－非機能要件

システムやソフトウェアを作成する際に定義されるもののうち、上記以外の内容全般

になります。性能・信頼性・拡張性・セキュリティ等の機能を指します。

(3)システム要件定義

業務要件で示された内容を実現するために必要な要件を、具体的な内容としてまとめる

ことです。

尚、要件定義は次のような手順で行います。

①利用者の要求の調査(アンケート・ヒアリングなど)

②調査内容の分析(KJ 法など)

③現行業務の分析(PERT、ワークフロー図など)

④業務要件の定義

⑤機能要件・非機能要件の定義

第 4 章 システム戦略

75

4.6. 調達計画・実施

1．調達の流れ

・RFI(Request For information：情報提供依頼書)

システムの発注先候補の業者に対し、システム化に関する情報提供を依頼する文書です。

ユーザはこの RFIの結果を元に、構築する情報システムの内容を検討します。

・RFP(Request For Proposal：提案依頼書)

情報システム発注にあたり、発注先候補の業者に具体的な提案を依頼する文書です。

システム化に関する基本方針、概要、依頼事項などをまとめ、業者に提出します。

・提案書

RFPを元に、発注先候補の企業が発行するシステムの内容を記載した文書です。

ユーザは各発注先企業からの提案書を比較し、発注先の選定を行います。

・見積書

提案書の内容を含めた、システム開発・運用・保守にかかる費用を記載した文書です。

提案書と同じく、発注先の選定の材料となります。

提案書・見積書を比較し、ユーザ側の希望に沿った提案があった発注先候補と契約を締

結し、システム開発をスタートさせます。

第 4 章 システム戦略

76

第 4章 確認問題

問 1．

次のうち、ビジネスプロセスモデルを作成する際に有効とされる図について正しいものは

どれか。

ア 散布図

イ パレート図

ウ フローチャート

エ アローダイヤグラム

（ ）

問 2．

次のうち、DFDを用いて検討することに適している事項はどれか。

ア 業務で取り扱う顧客データと商品データとのつながり

イ 業務で取り扱う帳票とそれに付随する情報の大まかな流れ

ウ 業務工程でのクリティカルパス

エ 競合他社と自社の商品の性能差の比較や製品の各項目のバランスの図示

（ ）

問 3．

次のうち、DFDにおける 4つの要素に該当しないものはどれか。

ア データストア

イ データフロー

ウ 外部

エ 判断

（ ）

第 4 章 システム戦略

77

問 4．

次のうち、情報リテラシーを指しているものはどれか。

ア 情報システムを使いこなす能力のこと

イ インターネットなどのネットワークを利用するうえでのマナーやルールの総称のこと

ウ コンピュータを使えない層が、情報を活用できないために不利な立場に置かれること

エ 自身の個人情報を自身で管理し、他人に無断で取得・公開されないための権利のこと

（ ）

問 5．

次のコミュニケーションツールのうち、以下の要件として用いるものとして最も適切なも

のはどれか。

・「プロジェクト遂行に必要な情報を、各自空いた時間で出し合い、プロジェクトチーム内

で情報を共有するために使用する」

ア テレビ会議

イ チャット

ウ 電子掲示板

エ IP電話

（ ）

問 6．

次のソリューションビジネスにおける形態のうち、以下の状況の際に適用すべきものとし

て最も正しいものはどれか。

・「自社でサーバ設備を保有しているが、管理に関して技術者が自社内にいないため、機材・

設備含めて外部の専門の業者に管理・運営を任せたい」

ア ハウジングサービス

イ ホスティングサービス

ウ ASP

エ SaaS

（ ）

第 4 章 システム戦略

78

問 7．

SI に対してシステムを発注する際、ユーザ企業側で作成することになるものは次のうちど

れか。

ア RFI

イ RFP

ウ 見積書

エ 提案書

（ ）

問 8．

次のような DFDがある場合の、空欄 a b f に正しく入る組み合わせはどれか。

ア a:在庫情報 b:受注情報 f:商品

イ a:在庫情報 b:受注情報 f:配送

ウ a:受注情報 b:在庫情報 f:商品配送

エ a:受注情報 b:在庫情報 f:配送指示

（ ）

第 4 章 システム戦略

79

第 4章 確認問題 解答・解説

問 1．解答： ウ

業務プロセスを視覚的に表したものがビジネスプロセスモデルですが、ビジネスプロセ

スモデルをモデリングする為には、現在の業務の手順や工程が視覚化出来る「フローチャ

ート」や「DFD」を用います。

ア：ある 2つの要素に関する相関を探る際に利用するグラフのことです。

イ：企業内の要素とその累積比率を視覚化するグラフのことです。

エ：作業に要する時間と作業工程を図解し、日程計画を立てるのに用いる図のことです。

問 2．解答： イ

DFDは業務やデータの流れを表現する手法です。そのため、選択肢中ではイの項目が DFD

で検討することに適しています。

ア：データ同士のつながりは主に E-R図を用いて検討します。

ウ：クリティカルパスはアローダイヤグラムを用いて検討します。

エ：性能差の比較やバランスの図示はレーダーチャートを主に用いて検討します。

問 3．解答： エ

DFDには「データフロー」「プロセス」「データストア」「外部」の 4つの要素があります。

判断はフローチャートの要素であり、DFDの要素にはありません。

ア・イ・ウ：いずれも DFD中の要素になります。

問 4．解答： ア

情報リテラシーとは、情報システムを使いこなす能力のことを指します。

イ：ネチケットを説明した文章です。

ウ：ディジタルディバイドを説明した文章です。

エ：プライバシーの権利を説明した文章です。

問 5．解答： ウ

情報の集約と共有、空いた時間の活用が条件のため、各自空いた時間に確認出来る電子

掲示板が選択肢中では適切である。

ア・イ・エ：いずれもリアルタイムで実施するため、空いた時間を活用するには不向きで

ある。

第 4 章 システム戦略

80

問 6．解答： ア

自社で保有しているサーバを業者に預けて管理を任せる携帯の運用となるため、該当す

るサービスはハウジングサービスとなる。

問 7．解答： イ

RFP(Request For Proposal：提案依頼書)は、情報システム発注にあたり、発注先候補の

業者に具体的な提案を依頼する文書です。これは発注元となるユーザ企業が作成します。

ア：RFIは、システムの発注先候補の業者に情報提供を依頼する文書です。

ウ：提案書は発注先候補の企業が発行する、システムの内容を記載した文書です。

エ：見積もり書は発注先候補の企業が発行する、費用を記載した文書です。

問 8．解答： エ

問題中の DFDの正しい形は以下のものになります。

第 5 章 開発技術

81

第 5 章

開発技術

第 5 章 開発技術

82

第 5 章 開発技術

5.1. システム開発技術

1．ソフトウェア開発のプロセス

ソフトウェアは、一般的に次のようなプロセスで開発されます。

(1)要件定義

システム・ソフトウェアに要求される機能・性能・内容を整理・明確化し、どのような

システム・ソフトウェアを作成するのかを定義します。

(2)外部設計

要件定義の内容に基づき、システムの具体的な処理方式を決め、画面や帳票など、シス

テム利用者側からの視点について定義します。

(3)内部設計

外部設計の内容に基づき、開発者の視点から、ソフトウェアの構造やデータベースの物

理設計などを行い、システムの内部機能を定義します。

(4)プログラミング

内部設計の内容に基づき、内部設計で作成されるプログラム設計書の内容に従ってプロ

グラムを記述(コーディング)します。

(5)テスト

作成したソフトウェアが要求された仕様を満たしているかを検証するため、テストの計

画書を作成、その内容に従ってデータを作成し、システムの動作検証を行います。

(6)受入れ

テストが完了したシステム・ソフトウェアについて、運用時と同様の条件下で受入テス

トを実施し、ソフトウェアが正常に稼働することを確認した上で運用現場に導入します。

第 5 章 開発技術

83

2．テストの種類

(1)ソフトウェア開発に必要なテストの種類について

・単体テスト

テストの中では唯一プログラミングの工程中で行うもの。コーディングしたプログラム

モジュール1ごとにプログラム設計書通りに動作するかを確認し、バグ2を検出する。

・結合テスト

単体テストが完了したプログラムモジュールをいくつか連続して動作させ、想定した動

作を行うかを確認する。単体テスト含めこの 2つはホワイトボックステスト3方式で行う。

・システムテスト

全ての結合テストが完了した上で、システム全体が要件定義を満たすかを検査する。「機

能テスト」「性能テスト」「負荷テスト」等を行う開発者側で実施する最終テストとなる。

・運用テスト

実際の運用時と同様の条件下で行うもの。ユーザ側が主体で実施し、実務のデータ等を

テストデータとして使う。このテストはブラックボックステスト4形式で実施される。

・退行テスト

システムの修正が発生した際に実施するテスト。修正個所が他の部分に影響しないこと

を確認するために行う。

(2)テストの実施と結果に対する評価

システムを検収する為には、テスト結果が良好である必要があります。もしテストでバ

グが発見された場合、そのバグを修正した上で再びテストを行うという工程を繰り返し、

正しい結果が得られるまでテストを行います。テストはこのように「計画」「実施」「評価」

を繰り返しながら、結果を収束させていきます。

テスト終了の判断は、テストの結果が収束することを判断することで行います。この判

断の為に使用されるものが「バグ管理図5」と呼ばれるグラフであり、理想のグラフはゴン

ペルツ曲線を描くようになります。

1 プログラムモジュール：プログラム単位におけるひとまとまりの機能・要素のこと。

2 バグ：プログラムに存在する誤った処理のこと。 3 ホワイトボックステスト：システム内部の構造を理解した上で、それら一つ一つが意図した通りに動作しているかを

確認するテストのこと。基本的に、モジュールに記載された全ての命令を最低 1 回は実行

するようにテスト計画を組み、実行する。 4 ブラックボックステスト：システムの内部構造とは無関係に、外部から見た機能を検証するテストのこと。基本的に、

インプットデータとアウトプットデータのみを検証に用いる。 5 バグ管理図：縦軸にバグ検出累積数、横軸にテスト時間を取った、二者の関係を確認するグラフのこと。

第 5 章 開発技術

84

3.ソフトウェア開発の見積り

業務をシステム化する場合、コストを意識してシステム・ソフトウェアを設計します。

コストの見積りが甘く、工数が増加することは、そのまま費用の増加(ほぼ人件費)につな

がるため、見積りは適切に行う必要がります。

見積りの代表的な手法には以下のようなものがあります。

(1)プログラムステップ法

システム全体のステップ数6をもとにシステムの開発工数・費用を見積もる方法です。過

去の類似システムの開発実績を参考に、該当のプロジェクトの開発規模、ステップ数を想

定して見積ります。

(2)ファンクションポイント(FP：Function Point)法

開発要素の数と、その開発にかかる難易度・複雑度から、システムの開発規模や開発費

用を算出する方法です。GUIやオブジェクト指向のプログラム開発の見積りに向いています。

①入力画面やファイル数など、評価用の基準項目を決めます。

②基準項目ごとに複雑度に応じた重みを設定します。

③システムで必要となる基準項目の数を算出します。

④それぞれの基準項目の数に重みをかけ、ファンクションポイント数を計算します。

⑤全てのファンクションポイント数を合計し、システムに必要なコストを算出します。

6 ステップ数：プログラム内の行数のこと。

第 5 章 開発技術

85

5.2. 開発プロセス・手法

1．ソフトウェア開発の手法

(1)構造化手法

「順次」「選択」「繰り返し」の 3つの制御構造によって対象業務を分析する考え方です。

構造化された分析結果を基にソフトウェア開発、プログラム構築を行います。

(2)データ中心アプローチ(DOA)

データに着目して対象業務を分析する考え方です。業務で扱うデータを分析し、データ

の構造を中心にシステムの機能を決めていきます。

(3)プロセス中心アプローチ(POA)

業務の処理手続きの手順に着目して対象業務を分析する考え方です。従来からのシステ

ム開発によく使われてきた手法で、システム全体を各サブシステムの階層構造で表します。

(4)オブジェクト指向

データと操作を組み合わせた「オブジェクト」という定義を中心として対象業務を分析

する考え方です。プログラムは部品となる複数のオブジェクトからなり、オブジェクトが

互いにメッセージをやり取りしながら処理を進めます。オブジェクトに関連するデータの

「属性(プロパティ)」と「操作(メソッド)」をクラスと言う単位で纏めて管理でき、複雑

なシステムの開発に適した手法です。

オブジェクト内部のデータは外部から隠蔽され、メッセージを送ることによってのみ取

得できます。この状態をカプセル化といい、個々のオブジェクトは独立してカプセル化さ

れていると見ることが出来ます。この状態は、ソフトウェアの保守性や再利用性に優れて

います。

2．ソフトウェアの開発モデル

(1)ウォーターフォールモデル

要件定義から運用保守までを段階的に進めていく開発モデルです。各工程が完了してか

ら次の工程へと進むという特徴があり、基本的に後戻りをしないことを前提とします。見

積計算や要員管理が比較的行いやすい為、大規模な開発において使用されていますが、シ

ステムの仕様変更や修正が発生した場合は以前の工程にも影響が及ぶことがあり、この場

合は工数が非常に多く加算されることがあります。

第 5 章 開発技術

86

(2)プロトタイピングモデル

開発の早い段階(主に要件定義)で試作品(プロトタイプ)を作成し、利用者に確認しても

らいながら開発を進めていく手法です。利用者・受注者が試作品を見ながら仕様を決めて

いくため完成品のイメージがしやすいという利点があるものの、要件定義に時間がかかる、

試作品から本製品を作成する際にイメージを変えづらいという欠点もあります。

(3)スパイラルモデル

あらかじめシステム全体を機能別に分割し、コアとなる機能から順番に作成していく手

法です。コア部分の開発を行った後、別機能の要求分析を行って開発、との工程を繰り返

し、段階的に開発規模を大きくしていきます。

1つの開発工程自体はウォーターフォールモデル形式になるものの、機能別に開発を行う

ため、出来上がったコア機能を見ながら次の開発内容を決めるという、プロトタイプ的な

側面も持ち合わせています。

3．共通フレーム

(1)共通フレーム

共通フレームとはソフトウェア開発の作業内容を標準化し、用語などを統一した共通の

枠組みのことです。ユーザと開発者との間で齟齬が起こることを防ぐために、ガイドライ

ンとして準備されます。

共通フレームとして代表的なものとしては、ソフトウェアライフサイクルプロセス(SLCP)

があります。これはソフトウェアが必要とされてから廃棄されるまでの一連の作業の流れ

の事を指し、ソフトウェアを中心とした開発と取引のための共通フレームとして使用され

ます。

(2)システム開発のプロセス

SLCPでは、システム開発に関するプロセスを以下のようにまとめています。

①企画プロセス

業務のシステム化に関する構想と計画を立案するプロセスです。業務をシステム化する

にあたり、企業の経営上のニーズと課題の確認したうえで、システム開発の対象業務や費

用、スケジュール、開発体制、投資効果などを明らかにします。

②要件定義プロセス

作成するシステムの仕様や要件、またシステム化する範囲を決定するプロセスです。企

画プロセスをもとに、利用者がシステムに求める内容を整理し、システム化の対象とする

業務手順やデータ構造などをまとめて、定義していきます。

第 5 章 開発技術

87

③開発プロセス

ⅰ．システム要件定義

システムで実現する機能や要件をより具体的に定義するプロセスです。要件定義プロ

セスをもとに機能要件と非機能要件7を決定し、「システム要件定義書」にまとめます。

ⅱ．システム方式決定プロセス(外部設計)

システムで使用する構成品目や実装方針を決定するプロセスです。システム要件定義

をもとに、ハードウェアで実現するもの、ソフトウェアで実現するもの、手動で行うも

の等に要件を振り分け、振り分けの内容に従ってシステムの構成品目を決めていきます。

ⅲ．ソフトウェア要件定義プロセス(外部設計)

システムの構成品目のうち、ソフトウェアによって実現する機能について、機能概要

や処理性能を決定するプロセスです。システム方式決定プロセスをもとに、主に利用者

側の視点から見たものを定義していき、「ソフトウェア要件定義書」にまとめます。

ⅳ．ソフトウェア方式決定プロセス(内部設計)

ソフトウェアの構造と、ソフトウェアコンポーネントの性能などの内部機能を決定す

るプロセスです。ソフトウェア要求定義書をもとに、ソフトウェア開発者の視点からソ

フトウェアコンポーネント8別に各機能を割り振り、個々のコンポーネントの機能やコン

ポーネント間のやり取りの方式を定義します。

ⅴ．ソフトウェア詳細設計プロセス(プログラム詳細設計)

各プログラムの具体的な処理内容を決定するプロセスです。ソフトウェアに実装する

各コンポーネントを機能単位のモジュール9に細分化し、それぞれの具体的な処理を決定

したうえで「ソフトウェア詳細設計書」にまとめます。

ⅵ．ソフトウェアコード作成(プログラミング・コーディング)

ソフトウェア詳細設計書をもとに、実際にコードを記載(コーディング)し、プログラ

ムを作成します。

ⅶ．単体テスト

作成したプログラムが、想定通りの動作を行うかをテストします。このテストは主に

ホワイトボックステスト形式で行われます。

7 機能要件、非機能要件：4.5 要件定義 を参照。 8 ソフトウェアコンポーネント：特定の機能を持った、ソフトウェアを構成するプログラム(の部品)のこと。 9 モジュール：プログラム中のひとまとまりの機能単位。

第 5 章 開発技術

88

ⅷ．ソフトウェア結合

プログラムを複数動かした際の動作を確認するプロセスです。単体テストを完了した

複数のプログラムモジュールを決められた手順に沿って動作し、結果が想定通りとなる

かをテストします。このテストも主にホワイトボックステスト形式で行われます。

ⅸ．ソフトウェア適格性確認テスト

作成したソフトウェア全体の動作テストを行うプロセスです。ソフトウェア結合テス

トを通過した各モジュールをソフトウェアとなるように全体を組み立てた上で動作させ、

ソフトウェアがソフトウェア要件定義の内容に従って動作しているかをテストします。

このテストは主にブラックボックステスト形式で行われます。

ⅹ．システム結合テスト・適格性確認テスト

作成したソフトウェアと、動作させる環境との動作テストを行うプロセスです。ソフ

トウェア適正確認テストを通過したソフトウェアを、ハードウェア構成やソフトウェア

構成に従って環境を構築したうえで動作させ、結果がシステム要件定義の内容に従って

動作しているかをテストします。このテストも主にブラックボックステスト形式で行わ

れます。

ⅺ．ソフトウェア導入・受け入れ支援

実際に業務環境にソフトウェアを導入し、動作させるプロセスです。業務の現場にシ

ステムを設置し、利用者を中心に受け入れテストを実施します。その結果が良好であれ

ば、実際の業務データを投入して運用を開始します。

④運用プロセス

システムの稼働監視、評価、運用担当者の教育などを行います。

⑤保守プロセス

稼働しているシステムの維持、管理、変更等を行います。

(3) システム開発プロセスとテストの関係

要件定義や各設計工程、プログラミングまでのプロセスと、単体テスト以降のテスト工

程については、それぞれ相互に関わりを持っています。

一般に、開発プロセスと各テストの関係は次のような V字型モデルとなります。

第 5 章 開発技術

89

(4) CMMI (Capability Maturity Model Integration)

CMMI10とは、組織がプロセスをより適切に管理できるようになることを目的として、遵守

するべき指針をガイドライン化したものです。ソフトウェアの開発工程の評価手法として

も用いられています。

CMMI では、開発工程の成熟度を 5 段階に分け、それぞれの段階で実施すべきプロセスを

定めて、成熟度をレベルアップさせることで、評価を上げていきます。

・成熟度 1（初期段階）：プロセスに秩序が無く、担当者の力量などに左右される

・成熟度 2（管理された段階）：基本的なプロジェクト管理ができるようになっている

・成熟度 3（定義された段階）：組織の標準プロセスがあり、継続して改善されている

・成熟度 4（定量的管理の段階）：プロセスを定量的に評価し、目標を立てて継続的に改善

している

・成熟度 5（最適化した段階）：問題の分析と防止ができる。定量的な評価と改善に加え、

新しい施策にも取り組める

4．ソフトウェアの品質特性

品質を適切に管理するために、ソフトウェアは以下の 6 つの特性から管理を行うことが

良いとされています。

①機能性：目的のために必要となる機能が揃っているか

②信頼性：故障せずに正しく動作し続けるか

③使用性：利用者にとって理解しやすく使いやすいか

④効率性：使う資源に見合う性能を発揮するか

⑤保守性：機能変更や修正がしやすいか

⑥移植性：他の環境に移しやすいか

10 CMMI(Capability Maturity Model Integration)：能力成熟度モデル統合。システム開発プロセスの成熟度モデル。

第 5 章 開発技術

90

第 5章 確認問題

問 1．

次のうち、内部設計を説明する文章として正しいものはどれか。

ア システムの処理方式を決定し、利用者の視点で仕様を決定していくこと

イ 開発者の視点からソフトウェアの構造を決め、処理内容などを明確にしていくこと

ウ プログラム設計書に従って、プログラムを記述していくこと

エ 作成されたプログラムが仕様を満たしているかをチェックすること

（ ）

問 2．

システム開発におけるテスト工程で、記述されたプログラムについて、内部構造や論理を

チェックするために実施するものは次のうちどれか。

ア ホワイトボックステスト

イ ブラックボックステスト

ウ ファンクションポイント法

エ 結合テスト

（ ）

問 3．

ソフトウェア開発において、ユーザと開発者との間で齟齬が起こることを防ぐ為に用いら

れる、ガイドラインの役割を果たすものは次のうちどれか。

ア フレームワーク

イ スパイラルモデル

ウ 共通フレーム

エ システム適格性確認テスト

（ ）