はじめに

システム開発では、プログラムを書くだけでなく、さまざまなルールを守る必要があります。

例えば、はちみつ屋さんがネットショップを開発会社に依頼するとしましょう。

その際には、次のような疑問が生まれます。

どのような手順でシステムを開発するのか？
発注者と開発会社の役割はどう決めるのか？
システムの品質は何を基準に評価するのか？
誰もが使いやすい画面を作るにはどうすればよいのか？
プログラムの著作権は誰のものになるのか？
開発会社の技術者に直接指示してもよいのか？

これらの問題を解決するために、標準化・ガイドライン・契約・法律が存在します。

今回は、応用情報技術者試験で重要な次の4つを学びます。

共通フレーム
情報システムモデル取引契約書
システム開発に関連する規格・ガイドライン
関連法規

1. 標準化とは

1-1. 標準化の目的

**標準化（Standardization）**とは、製品・サービス・業務手順などについて共通の基準を定めることです。

システム開発では、企業や担当者によって作業方法が異なる場合があります。

例えば、開発会社Aでは「基本設計」と呼ぶ作業を、開発会社Bでは「外部設計」と呼ぶことがあります。

こうした違いが原因で、認識のずれが発生する可能性があります。

標準化には、次のような目的があります。

用語や手順を統一する
品質を一定水準に保つ
発注者と受注者の認識を合わせる
作業の重複や漏れを防ぐ
システム間の互換性を確保する

1-2. 標準化団体

代表的な標準化団体には、次のようなものがあります。

団体	正式名称	主な役割
ISO	International Organization for Standardization	国際標準の策定
IEC	International Electrotechnical Commission	電気・電子技術分野の国際標準
IEEE	Institute of Electrical and Electronics Engineers	電気・電子・情報通信技術などの標準化
W3C	World Wide Web Consortium	Web技術の標準化
JISC	Japanese Industrial Standards Committee	日本産業規格に関する審議など

日本では、JIS（Japanese Industrial Standards：日本産業規格）が広く利用されています。

2. 共通フレーム

2-1. 共通フレームとは

共通フレームとは、情報システムの企画・開発・運用・保守などに関する作業を体系的に整理した枠組みです。

発注者と受注者が共通の認識を持つことを目的としています。

例えば、はちみつ屋さんがネットショップを開発会社に依頼した場合を考えます。

はちみつ屋さんは、

「商品を販売できるサイトを作ってほしい」

と依頼します。

しかし、開発会社は次の点を確認する必要があります。

どのような商品を販売するのか
会員登録は必要か
決済方法は何を利用するか
在庫管理は必要か
運用開始後は誰が保守するのか

共通フレームは、このような作業を整理し、関係者の認識を合わせるために役立ちます。

2-2. 共通フレームの特徴

共通フレームには、次の特徴があります。

システムのライフサイクル全体を対象とする
必要なプロセスや活動を整理する
発注者と受注者の共通言語となる
特定の開発手法だけに限定されない

重要なのは、共通フレームは開発手順を一律に強制するものではないという点です。

プロジェクトの特性に応じて、必要なプロセスや活動を選択して利用します。

3. SLCP-JCF

3-1. SLCPとは

**SLCP（Software Life Cycle Process）**とは、ソフトウェアのライフサイクルに関するプロセスを表す用語です。

ソフトウェアのライフサイクルには、次のような活動が含まれます。

企画
 ↓
要件定義
 ↓
設計
 ↓
開発
 ↓
テスト
 ↓
運用
 ↓
保守
 ↓
廃棄

実際には、これらの活動が反復されたり、並行して実施されたりする場合があります。

3-2. SLCP-JCFとは

SLCP-JCFは、ソフトウェアライフサイクルプロセスに関する日本の共通フレームの流れを理解するうえで登場する名称です。

JCFは、Japan Common Frameの略です。

日本では、国際標準を踏まえながら、発注者と受注者が共通に利用できる枠組みとして共通フレームが整備されてきました。

3-3. SLCP-JCFと共通フレームの関係

用語	内容
SLCP	ソフトウェアライフサイクルプロセス
SLCP-JCF	日本における共通フレームの考え方に関係する名称
共通フレーム	システムのライフサイクルに関する作業を整理した枠組み
共通フレーム2013	2013年版の共通フレーム

4. 共通フレーム2013

4-1. 共通フレーム2013とは

共通フレーム2013とは、IPAが公表した情報システムのライフサイクルに関する共通フレームです。

システムの企画から開発、運用、保守、廃棄までを対象としています。

国際規格であるISO/IEC 12207やISO/IEC 15288などの考え方を踏まえています。

4-2. 共通フレーム2013の目的

共通フレーム2013の主な目的は、次のとおりです。

発注者と受注者の認識を統一する
必要な作業の漏れを防ぐ
システム開発の責任範囲を明確にする
システムライフサイクル全体を整理する

5. 企画プロセス

5-1. 企画プロセスとは

企画プロセスとは、経営上の課題や業務上の問題を踏まえ、情報システムをどのように活用するかを検討するプロセスです。

例えば、はちみつ屋さんが次のような課題を抱えているとします。

電話注文が多く、対応に時間がかかる
在庫数を手作業で管理している
注文情報の入力ミスが発生している

これらの課題を解決するために、ネットショップや在庫管理システムの導入を検討します。

5-2. 企画プロセスで考えること

企画プロセスでは、主に次の内容を検討します。

経営課題や業務課題の把握
システム化の目的
システム化の対象範囲
投資効果
実現可能性
推進体制

6. システム化計画の立案プロセス

6-1. システム化計画とは

システム化計画とは、情報システムを導入・開発するための具体的な計画です。

企画段階で整理した目的を実現するために、必要な活動を明確にします。

6-2. システム化計画の内容

代表的な検討項目は次のとおりです。

項目	内容
システム化の目的	何を実現するか
対象業務	どの業務をシステム化するか
システム化の範囲	どこまでを開発対象とするか
スケジュール	いつまでに実施するか
予算	いくら投資するか
推進体制	誰が担当するか
投資効果	どのような効果を期待するか
リスク	どのような問題が想定されるか

6-3. はちみつ屋さんの例

項目	計画内容
目的	電話注文を減らす
対象業務	商品販売・注文受付
システム	ネットショップ
開発期間	6か月
予算	300万円
期待効果	注文受付業務の効率化

このように、システム化の目的と実施内容を明確にします。

7. 要件定義プロセス

7-1. 要件定義とは

**要件定義（Requirements Definition）**とは、システムに求められる機能や品質などを明確にする活動です。

例えば、ネットショップを開発する場合、

「商品を販売できること」

という要望だけでは不十分です。

具体的には、次のような要件を定義する必要があります。

7-2. 機能要件

**機能要件（Functional Requirements）**とは、システムが実現する機能に関する要件です。

例えば、

商品を検索できる
商品をカートに追加できる
注文を確定できる
決済できる
在庫を確認できる

などがあります。

7-3. 非機能要件

**非機能要件（Non-functional Requirements）**とは、性能・可用性・セキュリティなど、機能以外の品質や制約に関する要件です。

例えば、

商品検索結果を3秒以内に表示する
24時間利用できる
通信を暗号化する
障害発生時に復旧できる
一定数の同時アクセスに対応できる

などがあります。

7-4. 企画・計画・要件定義の違い

プロセス	主な目的
企画	なぜシステムが必要なのかを明確にする
システム化計画	どのようにシステム化を進めるか計画する
要件定義	システムに何が必要なのかを明確にする

8. 情報システムモデル取引契約書

8-1. 情報システムモデル取引契約書とは

情報システムモデル取引契約書とは、情報システムの開発や導入に関する取引で、契約条件を明確にするためのモデル契約書です。

経済産業省が公表したモデル契約書などが知られています。

システム開発では、発注者と受注者の認識が異なると、トラブルが発生することがあります。

例えば、

追加機能は無償で開発してもらえるのか
納品後の不具合は誰が修正するのか
開発が遅れた場合はどうするのか
成果物の著作権は誰に帰属するのか

といった問題です。

これらを契約で明確にすることが重要です。

8-2. モデル契約書の目的

モデル契約書には、次のような目的があります。

発注者と受注者の責任を明確にする
契約条件の認識違いを防ぐ
システム開発のトラブルを減らす
公平で適切な取引を促進する

8-3. 契約で重要な項目

項目	内容
業務範囲	何を実施するか
成果物	何を納品するか
納期	いつまでに納品するか
対価	いくら支払うか
検収	成果物をどのように確認するか
変更管理	要件変更時にどう対応するか
知的財産権	成果物の権利をどう扱うか
責任範囲	不具合や損害にどう対応するか

9. 多段階契約と工程ごとの契約

システム開発では、最初からすべての要件が確定しているとは限りません。

そのため、工程ごとに契約を分ける方法が利用されることがあります。

例えば、

要件定義
   ↓
契約・条件の確認
   ↓
設計
   ↓
契約・条件の確認
   ↓
開発
   ↓
テスト

というように、工程の進行に合わせて契約条件を明確にします。

これにより、要件が不明確な段階で大きな契約を結ぶリスクを抑えられる場合があります。

10. システム開発に関連する規格・ガイドライン

システム開発では、品質や使いやすさを評価するために、さまざまな規格やガイドラインが利用されます。

今回学ぶ主な規格は次のとおりです。

規格・ガイドライン	主な対象
JIS X 25010:2013	システム・ソフトウェアの品質モデル
JIS X 0161:2008	ソフトウェアライフサイクルプロセスの評価
WCAG	Webコンテンツのアクセシビリティ
JIS X 8341-1:2010	高齢者・障害者等への配慮に関する共通指針
知識体系ガイド	専門分野の知識の体系化

11. JIS X 25010:2013

11-1. JIS X 25010とは

JIS X 25010:2013とは、システムやソフトウェアの品質を評価するための品質モデルを定めた規格です。

国際規格ISO/IEC 25010に対応しています。

ソフトウェアの品質を、さまざまな特性に分けて考えることができます。

11-2. 製品品質モデル

JIS X 25010:2013では、製品品質を8つの特性で整理しています。

品質特性	内容
機能適合性	必要な機能を満たしているか
性能効率性	応答時間や資源利用が適切か
互換性	他のシステムと共存・連携できるか
使用性	利用者が使いやすいか
信頼性	安定して動作するか
セキュリティ	情報やシステムを保護できるか
保守性	修正や変更を行いやすいか
移植性	別の環境へ移行しやすいか

※これはJIS X 25010:2013の品質モデルです。後年の国際規格改訂では、品質特性の構成が変更されています。

11-3. はちみつ屋さんの例

ネットショップを例に考えます。

品質特性	具体例
機能適合性	商品を購入できる
性能効率性	商品検索が速い
互換性	外部決済サービスと連携できる
使用性	初めての人でも操作しやすい
信頼性	障害が発生しにくい
セキュリティ	個人情報を適切に保護する
保守性	機能を追加・修正しやすい
移植性	別の実行環境へ移行しやすい

12. 利用時の品質モデル

JIS X 25010:2013では、製品品質だけでなく、利用時の品質も定義しています。

利用時の品質とは、実際にシステムを利用したときの品質です。

代表的な特性は次のとおりです。

特性	内容
有効性	目的を達成できるか
効率性	少ない資源や労力で目的を達成できるか
満足性	利用者が満足できるか
リスク回避性	利用によるリスクを抑えられるか
利用状況網羅性	さまざまな利用状況に対応できるか

13. JIS X 0161:2008

13-1. JIS X 0161とは

JIS X 0161:2008とは、ソフトウェアライフサイクルプロセスの評価に関する規格です。

ソフトウェア開発組織のプロセスが、どの程度適切に実施されているかを評価するために利用されます。

13-2. プロセス評価とは

**プロセス評価（Process Assessment）**とは、開発や運用などの業務プロセスが、どの程度適切に実施されているかを評価することです。

例えば、開発会社について、

開発手順が定義されているか
作業結果が記録されているか
品質を確認しているか
継続的に改善しているか

などを確認します。

13-3. プロセス能力水準

プロセス評価では、プロセスの実施状況や管理状況を段階的に評価します。

代表的な能力水準の考え方は次のとおりです。

レベル	名称	概要
0	不完全なプロセス	プロセスが十分に実施されていない
1	実施されたプロセス	プロセスの目的が達成されている
2	管理されたプロセス	計画・監視・調整されている
3	確立されたプロセス	定義された標準プロセスに基づく
4	予測可能なプロセス	定量的に管理されている
5	最適化するプロセス	継続的な改善が行われている

14. WCAG

14-1. WCAGとは

**WCAG（Web Content Accessibility Guidelines）**とは、Webコンテンツのアクセシビリティに関するガイドラインです。

W3Cによって策定されています。

14-2. Webアクセシビリティとは

**Webアクセシビリティ（Web Accessibility）**とは、障害の有無や年齢、利用環境などにかかわらず、Webコンテンツを利用できるようにする考え方です。

例えば、

画像に代替テキストを設定する
キーボードだけで操作できるようにする
文字と背景のコントラストを確保する
動画に字幕を付ける

などの対応があります。

14-3. WCAGの4原則

WCAGでは、アクセシビリティの基本原則として次の4つを定めています。

原則	英語	内容
知覚可能	Perceivable	情報を認識できる
操作可能	Operable	インターフェースを操作できる
理解可能	Understandable	情報や操作方法を理解できる
堅ろう	Robust	支援技術などでも適切に解釈できる

14-4. 適合レベル

WCAGには、次の3つの適合レベルがあります。

一般に、AAAが最も厳しい達成基準を含みます。

ただし、すべてのWebサイトでAAAを達成することが現実的とは限りません。

15. JIS X 8341-1:2010

15-1. JIS X 8341-1とは

JIS X 8341-1:2010とは、高齢者や障害のある人などに配慮した製品・サービスの設計に関する共通指針を定めた規格です。

アクセシビリティを考慮した設計の基本的な考え方を扱います。

15-2. JIS X 8341シリーズ

JIS X 8341シリーズには、情報通信に関するアクセシビリティの規格が含まれます。

特に、WebコンテンツについてはJIS X 8341-3が重要です。

規格	主な対象
JIS X 8341-1	共通指針
JIS X 8341-3	Webコンテンツ

WCAGと直接関係が深いのはJIS X 8341-3です。

16. ユーザビリティ評価手法

16-1. ユーザビリティとは

**ユーザビリティ（Usability）**とは、利用者が特定の利用状況において、目的を有効・効率的・満足して達成できる度合いです。

例えば、はちみつ屋さんのネットショップで、

商品を簡単に探せる
注文方法が分かりやすい
操作ミスが起こりにくい
購入完了まで迷わない

といった点が重要になります。

17. ユーザビリティテスト

17-1. ユーザビリティテストとは

**ユーザビリティテスト（Usability Testing）**とは、実際の利用者などにシステムを操作してもらい、使いやすさや問題点を確認する手法です。

例えば、

「ネットショップで商品を検索し、購入手続きまで進んでください」

という課題を与えます。

その際に、

操作完了までの時間
操作ミスの回数
途中で迷った箇所
利用者の満足度

などを確認します。

18. ヒューリスティック評価

18-1. ヒューリスティック評価とは

**ヒューリスティック評価（Heuristic Evaluation）**とは、ユーザビリティの専門家などが、経験則や評価原則に基づいてインターフェースを評価する手法です。

例えば、

操作結果が分かりやすいか
用語が統一されているか
エラーから回復しやすいか
不要な情報が多すぎないか

などを確認します。

19. 認知的ウォークスルー

19-1. 認知的ウォークスルーとは

**認知的ウォークスルー（Cognitive Walkthrough）**とは、利用者が操作手順を理解できるかを、利用者の視点で順番に確認する評価手法です。

例えば、初めてネットショップを利用する人が、

商品を検索する
商品を選択する
カートに入れる
注文を確定する

という操作を迷わず実施できるかを検討します。

20. ユーザビリティ評価手法の比較

手法	評価方法
ユーザビリティテスト	利用者に実際に操作してもらう
ヒューリスティック評価	専門家が評価原則に基づいて確認する
認知的ウォークスルー	利用者の操作手順を追って確認する
アンケート	利用者の主観的な評価を収集する
インタビュー	利用者の意見や問題点を詳しく聞く

21. 知識体系ガイド

21-1. 知識体系とは

**知識体系（Body of Knowledge：BOK）**とは、特定の専門分野に必要な知識や技術を体系的に整理したものです。

例えば、プロジェクトマネジメントには多くの知識が必要です。

スケジュール管理
コスト管理
品質管理
リスク管理
コミュニケーション管理

これらを体系的に整理することで、学習や実務に活用できます。

21-2. 代表的な知識体系ガイド

名称	正式名称	対象分野
PMBOK	Project Management Body of Knowledge	プロジェクトマネジメント
BABOK	Business Analysis Body of Knowledge	ビジネスアナリシス
SWEBOK	Software Engineering Body of Knowledge	ソフトウェア工学
SEBoK	Systems Engineering Body of Knowledge	システムズエンジニアリング

21-3. PMBOKとは

PMBOKとは、プロジェクトマネジメントに関する知識体系です。

プロジェクトの計画・実行・監視・管理などに必要な知識を整理しています。

21-4. BABOKとは

BABOKとは、ビジネスアナリシスに関する知識体系です。

業務課題の分析や要求の整理などに活用されます。

21-5. SWEBOKとは

SWEBOKとは、ソフトウェア工学に関する知識体系です。

ソフトウェアの要求・設計・構築・テスト・保守などに関する知識を整理しています。

22. データの標準化

22-1. データ標準化とは

**データ標準化（Data Standardization）**とは、データの形式・名称・構造・意味などを統一することです。

例えば、顧客の生年月日を管理する場合、

2026/10/14

2026-10-14

令和8年10月14日

のように表記が異なると、システム間でデータを連携する際に問題が発生することがあります。

そのため、共通の形式を定めることが重要です。

23. XML

23-1. XMLとは

**XML（Extensible Markup Language）**とは、データの構造や意味をタグで表現するマークアップ言語です。

例えば、はちみつ屋さんの商品情報を表現します。

<product>
  <name>高級はちみつ</name>
  <price>1500</price>
</product>

XMLは、異なるシステム間で構造化データを交換するために利用されます。

24. JSON

24-1. JSONとは

**JSON（JavaScript Object Notation）**とは、データをキーと値の組み合わせなどで表現する軽量なデータ形式です。

{
  "name": "高級はちみつ",
  "price": 1500
}

Web APIなどで広く利用されています。

25. CSV

25-1. CSVとは

**CSV（Comma-Separated Values）**とは、データをカンマなどの区切り文字で表現するテキスト形式です。

商品名,価格
高級はちみつ,1500
通常はちみつ,800

表形式のデータを交換する際によく利用されます。

26. データ標準化に関係する技術

技術・形式	主な用途
XML	構造化データの表現
JSON	Web APIなどでのデータ交換
CSV	表形式データの交換
Unicode	文字の符号化に関する標準
ISO 8601	日付・時刻の表記
EDI	企業間の電子データ交換

27. 関連法規

システム開発では、技術的な知識だけでなく、法律に関する理解も必要です。

例えば、

他社の営業秘密を不正に取得してはいけない
他人のプログラムを無断で複製してはいけない
個人情報を適切に取り扱う必要がある
契約形態に応じて指揮命令関係が異なる

といったルールがあります。

28. 不正競争防止法

28-1. 不正競争防止法とは

不正競争防止法とは、公正な競争を確保するため、不正な競争行為を規制する法律です。

代表的な規制対象には、

営業秘密の不正取得・使用・開示
商品等表示の混同を生じさせる行為
著名な商品等表示の不正使用
商品形態の模倣
技術的制限手段の効果を妨げる一定の行為

などがあります。

29. 営業秘密

29-1. 営業秘密とは

不正競争防止法で保護される営業秘密には、主に次の3つの要件があります。

秘密管理性
有用性
非公知性

29-2. 秘密管理性

秘密管理性とは、情報が秘密として管理されていることです。

例えば、

アクセス権限を制限する
秘密情報であることを明示する
閲覧できる従業員を限定する

などの管理が考えられます。

29-3. 有用性

有用性とは、事業活動に役立つ情報であることです。

例えば、

顧客リスト
製造ノウハウ
研究開発情報

などが該当する可能性があります。

29-4. 非公知性

非公知性とは、一般に知られておらず、容易に入手できない情報であることです。

29-5. 営業秘密の3要件

要件	内容
秘密管理性	秘密として管理されている
有用性	事業活動に役立つ
非公知性	一般に知られていない

この3つは、応用情報技術者試験でも重要です。

30. PL法

30-1. PL法とは

**PL法（Product Liability Act）**とは、製造物責任法のことです。

製造物の欠陥によって生命・身体・財産に損害が発生した場合の、製造業者等の損害賠償責任について定めています。

30-2. 製造物責任とは

例えば、はちみつ屋さんが販売した電動はちみつ攪拌機に欠陥があり、利用者がけがをした場合を考えます。

一定の要件を満たすと、製造業者等が損害賠償責任を負う可能性があります。

30-3. PL法の特徴

PL法では、製造物の欠陥と損害などの要件が重要です。

被害者は、製造業者等の過失そのものを立証しなくても、一定の要件を満たせば責任を追及できます。

30-4. ソフトウェアとPL法

ソフトウェア単体は、通常、PL法上の「製造物」には該当しません。

一方、ソフトウェアが組み込まれた機器に欠陥がある場合、その機器がPL法の対象となる可能性があります。

例えば、制御プログラムの不具合によって機械が危険な動作をした場合などです。

31. 下請法・中小受託取引適正化法

31-1. 下請法とは

従来の**下請代金支払遅延等防止法（下請法）**は、発注者と受注者の取引を適正化するための法律です。

2026年1月1日からは、改正に伴い**中小受託取引適正化法（取適法）**という名称になっています。

試験教材では旧名称が登場する場合もあるため、両方を理解しておきましょう。

31-2. 取引適正化の目的

発注者と受注者の間には、交渉力の差が存在する場合があります。

例えば、大企業が小規模な開発会社にシステム開発を依頼する場合です。

発注者が一方的に不利な条件を押し付けると、受注者の経営に悪影響を与える可能性があります。

こうした問題を防ぐために、取引の適正化を図ります。

31-3. 禁止される行為の例

法律の適用対象となる取引では、次のような行為が問題になります。

受領拒否
支払遅延
不当な代金減額
不当な返品
買いたたき
不当なやり直しの要求

また、改正後の取適法では、価格協議への対応や支払手段などに関する規制も強化されています。

31-4. IT業界との関係

システム開発では、元請企業が別の開発会社へ業務を委託することがあります。

その際、適用要件を満たす取引では、取適法の規制を守る必要があります。

すべての企業間取引に一律に適用されるわけではなく、取引内容や事業者の規模などの要件によって適用関係が決まります。

32. 著作権法

32-1. 著作権法とは

著作権法とは、著作物を創作した人などの権利を保護する法律です。

IT分野では、次のようなものが著作物に該当する可能性があります。

プログラム
Webサイトの文章
画像
動画
データベースの構成

33. プログラムの著作権

33-1. プログラムは著作物になる

プログラムは、著作権法による保護の対象です。

ただし、保護されるのはプログラムの創作的な表現です。

アイデアやアルゴリズムそのものが、著作権によって独占されるわけではありません。

33-2. 著作権の発生

著作権は、原則として著作物を創作した時点で発生します。

登録手続きが必須というわけではありません。

34. 職務著作

34-1. 職務著作とは

職務著作とは、一定の要件を満たす場合に、法人などが著作者となる仕組みです。

プログラムの著作物については、法人等の発意に基づき、従業員が職務上作成した場合などに、原則として法人等が著作者となることがあります。

ただし、契約や勤務規則などに別段の定めがある場合は、その内容も確認する必要があります。

35. 著作者人格権と著作財産権

35-1. 著作者人格権

著作者人格権とは、著作者の人格的利益を保護する権利です。

代表的なものは次のとおりです。

公表権
氏名表示権
同一性保持権

著作者人格権は、原則として譲渡できません。

35-2. 著作財産権

著作財産権とは、著作物の利用に関する財産的な権利です。

代表的なものには、

複製権
公衆送信権
翻案権

などがあります。

著作財産権は、契約によって譲渡することができます。

36. オープンソースソフトウェアと著作権

36-1. OSSとは

**OSS（Open Source Software）**とは、一定の条件のもとでソースコードの利用・改変・再配布などが認められるソフトウェアです。

OSSであっても、著作権がなくなるわけではありません。

利用する際には、ライセンス条件を守る必要があります。

36-2. 代表的なOSSライセンス

ライセンス	特徴
MIT License	比較的制約が少ない
Apache License 2.0	特許に関する条項などを含む
GPL	一定の条件下で派生物のソースコード提供などを求める

OSSは「無料だから何をしてもよい」という意味ではありません。

37. セキュリティ関連法規

情報セキュリティに関係する法律には、さまざまなものがあります。

代表的なものは次のとおりです。

法律	主な対象
不正アクセス禁止法	不正アクセス行為など
個人情報保護法	個人情報の適切な取扱い
刑法	電子計算機に関する犯罪など
不正競争防止法	営業秘密の不正取得など

38. 不正アクセス禁止法

38-1. 不正アクセス禁止法とは

不正アクセス行為の禁止等に関する法律とは、他人の識別符号を不正に利用するなどの不正アクセス行為を禁止する法律です。

38-2. 不正アクセス行為の例

例えば、

他人のIDとパスワードを不正に利用してログインする
アクセス制御の仕組みを不正に回避する

などが該当する可能性があります。

38-3. パスワードの不正取得など

不正アクセス禁止法では、不正アクセス行為そのものだけでなく、不正アクセスに利用する目的で他人の識別符号を取得・保管する行為なども規制されています。

39. 個人情報保護法

39-1. 個人情報保護法とは

個人情報の保護に関する法律とは、個人情報の適正な取扱いについて定めた法律です。

企業が顧客情報を取り扱う場合にも関係します。

39-2. 個人情報とは

個人情報とは、生存する個人に関する情報で、氏名などによって特定の個人を識別できるものなどをいいます。

例えば、

氏名と住所
氏名と電話番号
特定の個人を識別できる顧客情報

などが該当します。

また、個人識別符号が含まれる情報も個人情報に該当します。

39-3. 個人情報を取り扱う際のポイント

企業には、法律に基づき、次のような対応が求められます。

利用目的の特定
利用目的の通知・公表など
安全管理措置
従業者の監督
委託先の監督
第三者提供に関するルールの遵守

40. 電子計算機使用詐欺罪

40-1. 電子計算機使用詐欺罪とは

電子計算機使用詐欺罪とは、コンピュータに虚偽の情報や不正な指令を与えるなどして、財産上不法な利益を得る行為などを対象とする犯罪です。

例えば、システムの処理を不正に操作し、実際には存在しない残高を記録させるような行為が問題になる場合があります。

41. 不正指令電磁的記録に関する罪

41-1. 不正指令電磁的記録とは

不正指令電磁的記録とは、正当な理由なく、人が意図しない動作をコンピュータにさせる不正な指令を記録したものなどです。

一般に、コンピュータウイルスなどが関係します。

一定の要件を満たす不正なプログラムの作成・提供・取得・保管などが処罰対象となります。

42. 労働者派遣法

42-1. 労働者派遣法とは

労働者派遣法とは、労働者派遣事業の適正な運営や派遣労働者の保護などについて定めた法律です。

正式名称は、

労働者派遣事業の適正な運営の確保及び派遣労働者の保護等に関する法律

です。

42-2. 労働者派遣の仕組み

労働者派遣では、派遣元企業と労働者の間に雇用関係があります。

一方、業務上の指揮命令は派遣先企業が行います。

       派遣元企業
          │
          │ 雇用契約
          ▼
        労働者
          ▲
          │ 指揮命令
          │
       派遣先企業

42-3. 労働者派遣の特徴

雇用契約は派遣元企業と結ぶ
指揮命令は派遣先企業が行う
派遣先企業の業務に従事する

43. 請負契約

43-1. 請負契約とは

請負契約とは、請負人が仕事の完成を約束し、注文者がその仕事の結果に対して報酬を支払う契約です。

例えば、はちみつ屋さんが開発会社に、

「ネットショップを完成させてください」

と依頼する場合です。

43-2. 請負契約の特徴

仕事の完成が契約の中心となる
請負人が自ら業務を管理する
注文者は請負人の従業員に直接指揮命令する立場にはない

44. 準委任契約

44-1. 準委任契約とは

準委任契約とは、法律行為ではない事務の処理を委託する契約です。

IT業界では、システム運用支援や技術調査などで利用されることがあります。

44-2. 準委任契約の特徴

事務の遂行が契約の中心となる
原則として仕事の完成そのものを約束する契約ではない
受託者には善管注意義務などが求められる

なお、準委任契約でも、契約内容によって成果に対する報酬を定めることがあります。

45. 派遣・請負・準委任の違い

項目	労働者派遣	請負	準委任
契約の中心	労働者の派遣	仕事の完成	事務の遂行
指揮命令	派遣先	請負人側	受託者側
完成義務	派遣契約自体にはない	原則あり	原則なし
IT業界での例	派遣技術者による業務	システム開発の完成	運用支援・技術調査

46. 偽装請負

46-1. 偽装請負とは

偽装請負とは、契約書上は請負や準委任などの形式を取っていても、実態が労働者派遣に該当するような状態をいいます。

例えば、はちみつ屋さんが開発会社と請負契約を結んだとします。

しかし、はちみつ屋さんの担当者が、開発会社の従業員に対して、

今日の作業内容を直接指示する
作業順序を直接指示する
勤務時間や作業方法を直接管理する

といった指揮命令を行っている場合、偽装請負が問題になる可能性があります。

46-2. 契約名より実態が重要

重要なのは、契約書に書かれた名称だけではなく、実際の指揮命令関係です。

請負契約と書かれていても、実態が労働者派遣に該当する場合があります。

47. 応用情報技術者試験で重要な比較

共通フレーム

用語	覚えるポイント
共通フレーム	発注者と受注者の共通言語
SLCP	ソフトウェアライフサイクルプロセス
共通フレーム2013	システムライフサイクルの作業を整理
企画プロセス	システム化の目的を検討
システム化計画	システム化の進め方を計画
要件定義	必要な機能・品質を明確化

規格・ガイドライン

名称	覚えるポイント
JIS X 25010	システム・ソフトウェアの品質モデル
JIS X 0161	プロセス評価
WCAG	Webアクセシビリティ
JIS X 8341-1	アクセシビリティの共通指針
JIS X 8341-3	Webコンテンツのアクセシビリティ
PMBOK	プロジェクトマネジメント
BABOK	ビジネスアナリシス
SWEBOK	ソフトウェア工学

法律	覚えるポイント
不正競争防止法	営業秘密の保護など
PL法	製造物の欠陥による損害
取適法（旧下請法）	受託取引の適正化
著作権法	著作物の保護
不正アクセス禁止法	不正アクセス行為の禁止
個人情報保護法	個人情報の適切な取扱い
労働者派遣法	労働者派遣のルール

特に重要なのは、それぞれの規格や法律が何を目的としているのかを理解することです。

共通フレーム：システム開発に関する共通の枠組み
共通フレーム2013：システムライフサイクル全体の作業を整理
情報システムモデル取引契約書：発注者と受注者の契約条件を明確化
JIS X 25010：システム・ソフトウェアの品質モデル
JIS X 0161：ソフトウェアプロセスの評価
WCAG：Webアクセシビリティのガイドライン
JIS X 8341-1：アクセシビリティの共通指針
ユーザビリティ評価：システムの使いやすさを確認
知識体系ガイド：専門分野の知識を体系化
データ標準化：データ形式や意味を統一
不正競争防止法：営業秘密などを保護
PL法：製造物の欠陥による損害への責任
取適法：受託取引の適正化
著作権法：プログラムなどの著作物を保護
セキュリティ関連法規：不正アクセスや個人情報などを規制
労働者派遣法：労働者派遣のルールを定める
請負契約：仕事の完成を目的とする契約

🍯 はちみつメモ

標準化と関連法規は「システム開発を安全・公平・円滑に進めるためのルール」！

はちみつ屋さんがネットショップを作るなら、

開発の進め方を整理する → 共通フレーム

開発会社との約束を決める → モデル契約書

システムの品質を確認する → JIS X 25010

誰でも使いやすくする → WCAG

プログラムの権利を守る → 著作権法

顧客情報を守る → 個人情報保護法

開発会社との働き方を適切にする → 労働者派遣法・請負契約

という関係なんだ。

応用情報技術者試験では、特に規格の名称と目的、営業秘密の3要件、派遣と請負の違いを押さえておこう！