標準化と関連法規

このページでは、共通フレームの企画・要件定義、請負と準委任などの契約、JIS X 25010の品質特性と保守の分類、著作権や製造物責任法などの法律がわかります。

一言で言うと：
- システム開発の「共通ルール」の話。関係者が同じ言葉で話すための物差し（規格・ガイドライン）と、守らなければいけない法律が出てくる。暗記中心の節。

作業の共通言語（共通フレーム）→ 契約のルール（モデル取引・契約書）→ 品質などの規格（規格・ガイドライン）→ 法律（関連法規）

覚え方の軸
共通フレーム：開発作業の「共通の物差し」
情報システム・モデル取引・契約書：工程ごとに契約を分ける
システム開発に関連する規格、ガイドライン
関連法規：何を守る法律か
混同しやすいペア

覚え方の軸

規格は「何の物差しか」で分ける：
- 作業（共通フレーム）、品質（JIS X 25010）、保守（JIS X 0161）、使いやすさ（WCAG、JIS X 8341-1）、知識（〜BOK）、データ（文字コード、画像）
契約は「誰が指示を出せるか」「完成させる義務があるか」の2つで分ける：
- 派遣（派遣先が指示）、請負（完成義務あり）、準委任（完成義務なし）
法律は「何を守る法律か」で覚える：
- 競争、被害者、下請、著作者、派遣労働者、ネットの安全
著作権の帰属は「誰の指示で作ったか」：
- 委託なら作った会社、社員なら会社、派遣社員なら派遣先
段階のある規格は、上から順に覚える：
- 共通フレームの4階層（プロセス → アクティビティ → タスク → 注記）、企画 → 要件定義

共通フレーム：開発作業の「共通の物差し」

共通フレーム（SLCP-JCF）：
- ソフトウェア、システム、サービスに関わる人が同じ言葉で話すための共通の枠組み。構想から開発、運用、保守、廃棄までの作業を一つひとつ定義したガイドライン。最新版は共通フレーム2013
- ISO/IEC 12207:2008（JIS X 0160:2012）に基づく。JIS X 0160は2021年に改訂されたが、共通フレームの改訂は見送られている
4階層の構造：
- プロセス（役割の観点でまとめたもの）→ アクティビティ（関連の強いタスクのまとまり）→ タスク → 注記
- プロセスはモジュール化されていて、プロジェクトの特性に合わせて必要なものを選べる
8つの大きなプロセス（合意プロセス、テクニカルプロセス、運用・サービスプロセス、支援プロセスなど）。試験に出るのはテクニカルプロセス
- 企画・要件定義の視点：
  - 企画プロセス、要件定義プロセス
- 開発・保守の視点：
  - システム開発プロセス、ソフトウェア実装プロセス、ハードウェア実装プロセス、保守プロセス
企画プロセス：
- 経営・事業の目的を達成するために、システムへの要求、システム化の方針、実施計画を得る
- システム化構想の立案プロセス：
  - 経営上のニーズや課題を解決するために、新しい業務の全体像と、システム化構想・推進体制を立案する
  - 7つのタスク：
    - ①経営上のニーズ・課題の確認 ②事業環境・業務環境の調査分析 ③現行業務・システムの調査分析 ④情報技術動向の調査分析 ⑤対象となる業務の明確化 ⑥業務の新全体像の作成 ⑦対象の選定と投資目標の策定
- システム化計画の立案プロセス：
  - 構想を具体化し、運用や効果などの実現性を考えたシステム化計画とプロジェクト計画を作り、利害関係者の合意を得る（16のタスク）
  - 主な内容：
    - システムで解決する課題の定義 → 業務モデルの作成（業務機能と組織のモデル化）→ システム方式やDB・サーバ・ネットワークの構成概要の明確化 → 費用と効果の比較（投資効果の明確化）→ QCD（品質・コスト・納期）の目標値と優先順位の設定、実現可能性の検討、開発スケジュールの大枠の作成
- どちらのプロセスも、「プロセス開始準備 → 立案 → 承認」のアクティビティで構成される
要件定義プロセス：
- 利害関係者が必要とするサービスを提供できるシステムの要件を定義する
- アクティビティ：
  - プロセス開始準備 → 利害関係者の識別 → 要件の識別 → 要件の評価 → 要件の合意 → 要件の記録
- 要件定義の4つの作業
  1. 業務要件の定義：
    - 新しい業務のあり方。業務内容（手順、入出力情報）、業務特性（ルール、制約）、業務用語、外部環境との関係
  2. 組織及び環境要件の具体化：
    - 組織の構成、要員、規模や、事務所の設備などの導入方針・計画
  3. 機能要件の定義：
    - 業務要件を実現するために必要なシステムの機能
  4. 非機能要件の定義：
    - 機能要件以外の要件。品質要件（可用性、性能、保守性、セキュリティなど。JIS X 25010の品質特性を使える）、技術要件（開発方式、開発基準・標準など）、運用・移行要件
- 利害関係者どうしの対立を避けるため、企画プロセスの経営上のニーズ・課題・投資目標を常に共有する
- 定義した要件は利害関係者にフィードバックして合意を得る。合意した成果物は、システム化のベースラインとして契約の基本になる

情報システム・モデル取引・契約書：工程ごとに契約を分ける

経済産業省がまとめた、システムの信頼性向上と取引の見える化のための契約のひな形
多段階契約：
- 工程ごとに個別に契約する。前の工程の結果で後の工程の前提が変わっても、工程の開始時に見積もり直せるので、ユーザーとベンダーの双方がリスクを避けられる
工程ごとの推奨の契約形態

工程	契約形態
システム化計画、要件定義	準委任
システム外部設計	準委任または請負
システム内部設計、ソフトウェア設計、プログラミング、ソフトウェアテスト、システム結合	請負
システムテスト	準委任または請負
受入・導入支援	準委任

覚え方：
- ユーザー主体の最初と最後は準委任、作る物がはっきりしている真ん中は請負
情報システム調達で契約するまでの流れ：
- ユーザー側：
  - 経営戦略・事業戦略を作る → IT部門がシステム化の要求事項と調達先の選定基準を作り、経営層が承認する → RFPを作る → 提案内容を比較評価して調達先を選び、経営層が承認する → 契約する
- ベンダー側：
  - RFPを受け取る → 提案書・見積書を作る → 契約する
- RFI（情報提供依頼書）：
  - RFPを作る前に、ベンダーに利用できる技術・製品、導入実績、価格などの情報を出してもらう文書
- RFP（提案依頼書）：
  - 調達するシステム、提案してほしいこと、調達条件などを示し、ベンダーに提案書と見積書を出してもらう文書
- 順番は RFI → RFP → 提案の評価 → 契約

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

JIS X 25010:2013（品質モデル）：
- システムとソフトウェアの品質の規格。JIS X 0129-1の後継
- 利用時の品質モデル：
  - 5つの特性（有効性、効率性、満足性、リスク回避性、利用状況網羅性）
- 製品品質モデル：
  - 8つの特性（★試験では規格の定義文がそのまま選択肢に出る）

品質特性	ざっくり	品質副特性
機能適合性	必要な機能を提供できるか	機能完全性、機能正確性、機能適切性
性能効率性	使う資源の量に対する性能	時間効率性、資源効率性、容量満足性
互換性	同じ環境で他と共存し、情報を交換できるか	共存性、相互運用性
使用性	利用者が目標を達成できる使いやすさ	適切度認識性、習得性、運用操作性、ユーザエラー防止性、ユーザインタフェース快美性、アクセシビリティ
信頼性	決められた条件で機能を実行し続けられるか	成熟性、可用性、障害許容性、回復性
セキュリティ	権限に応じて情報やデータを守れるか	機密性、インテグリティ、否認防止性、真正性、責任追跡性
保守性	修正のしやすさ	モジュール性、再利用性、解析性、修正性、試験性
移植性	別の環境に移しやすいか	適応性、設置性、置換性

JIS X 0129-1との違い：
- 機能性 → 機能適合性、効率性 → 性能効率性に名前が変わり、互換性とセキュリティが新しく追加された
JIS X 0161:2008（保守の4タイプ）：
- 修正依頼を「訂正」と「改良」に分け、保守を4つに分類する

分類	タイプ	中身
訂正	是正保守	引渡し後に見つかった問題を直す受け身の修正。是正保守までシステムを動かすための、計画外で一時的な緊急保守も含む
訂正	予防保守	潜在的な障害が、運用障害になる前に見つけて直す（潜在的な誤りが見つかったことで余儀なくされる修正）
改良	適応保守	変化した（変化している）環境で使い続けられるようにする修正
改良	完全化保守	問題への対応ではなく、より完全を目指す改良のための修正

WCAG：
- Webコンテンツをアクセシブルにするためのガイドライン。WCAG 2.1では、4原則（知覚可能、操作可能、理解可能、堅牢）のもとに13のガイドラインを定めている
- アクセシビリティ：
  - 高齢者や障害者を含む誰もが利用できること、またはその度合い
- 試験に出る例
  - 色や形だけに頼らず、テキストも使う（知覚可能）
  - 仮名の入力欄の前に「フリガナ（カタカナで入力）」のように種類を書く（理解可能）
  - 必須項目は、色で強調するだけでなく「（必須）」と書く（理解可能）
  - キーボードだけでも操作できるようにする（操作可能）
  - 現在位置がわかるパンくずリスト（トップページからそのページまでの経路）を付ける（操作可能）
JIS X 8341-1:2010：
- アクセシビリティ設計の規格。ハードウェア、ソフトウェア、サービスの企画から運用までの配慮事項を定めている
- ★試験では適用する目的が問われる：
  - 「多様な人々に対して、利用の状況を理解しながら、多くの個人のアクセシビリティ水準を改善できるようにする」こと
- アクセシビリティの定義：
  - 「様々な能力をもつ最も幅広い層の人々に対する、製品・サービス・環境・施設のユーザビリティ」
- ユーザビリティの定義（JIS Z 8521）：
  - 特定の利用者が、特定の利用状況で、特定の目的を達成するときの、有効さ、効率、満足度の度合い
ユーザビリティの評価手法

誰が評価する？	手法	やり方
利用者	アンケート	選択式や記述式の質問票に答えてもらう
利用者	ユーザビリティテスト：思考発話法	考えていることを声に出しながら操作してもらい、行動と発話を観察する。モデレータは結果をゆがめない範囲で簡単な質問をする
利用者	ユーザビリティテスト：回顧法	操作してもらって観察し、その後に質問に答えてもらう
利用者	ログデータ分析法	操作ログから、利用時間や利用パターンを分析する
専門家	認知的ウォークスルー法	専門家が利用者になりきって操作する
専門家	ヒューリスティック評価	専門家が自分の経験則や、UI設計によく当てはまる経験則に照らして評価する

知識体系ガイド（成功に必要な知識やスキルを集めた「成功への道しるべ」）
- PMBOK：
  - プロジェクトマネジメント
- BABOK：
  - ビジネスアナリシス（7つの知識エリア）
- SQuBOK：
  - ソフトウェア品質（3つのカテゴリ：品質の基本概念、品質マネジメント、品質技術）
- SWEBOK：
  - ソフトウェアエンジニアリング（10の知識エリア：要求、設計、構築、テスティング、保守など）
データの標準化
- Unicode：
  - 多くの言語を一元的に表せる文字コード。UCS-2（2バイト）、UCS-4（4バイト）がある。UTF-8はASCIIと互換性があり、1〜6バイトの可変長で符号化する
- バーコード：
  - Code128（ASCII文字128種類）、ITF（数字だけ）、JANシンボル（JANコードの標準13桁、短縮8桁）。どれも最後の桁はチェックディジット
- QRコード：
  - 縦と横の2方向に情報を持つ2次元コード。最大で英数字4,296文字、漢字1,817文字
- JPEG：
  - 静止画の圧縮方式（写真などの自然な色の画像に向く）
- MPEG：
  - 動画の圧縮方式。MPEG-1（CD-ROM）、MPEG-2（高画質。DVD、放送）、MPEG-4（携帯電話）、H.264/MPEG-4 AVC（MPEG-2の2倍以上の圧縮効率）
- 可逆圧縮：
  - 元のデータに完全に戻せる
- 非可逆圧縮：
  - 圧縮率を上げるため、ある程度の情報の欠落を許す（JPEG、MPEGなど）

関連法規：何を守る法律か

法律	何を守る？	試験のポイント
不正競争防止法	公正な競争	他社商品をまねた商品の販売や、よく知られた他社の商品表示に似た表示の使用を禁止する
製造物責任法（PL法）	製品の欠陥で被害を受けた人	「製造または加工された動産」が対象。ソフトウェア単体は対象外。ただしソフトを組み込んだ機器は対象（例：電気ポットに組み込んだ制御プログラムの欠陥で、利用者がやけどをした）
下請法（下請代金支払遅延等防止法）（※）	下請事業者	親事業者による発注後の減額、支払遅延、受領拒否、返品などを禁止。支払期日は受領日から60日以内に定める（定めなければ受領日が期日になる）
著作権法	著作者	登録しなくても、創作した時点で自動的に権利が発生する
労働者派遣法	派遣労働者	二重派遣は禁止

※下請法は、2026年1月1日から「取適法」（中小受託取引適正化法）に名前が変わった。試験にどちらの名前で出るかは要確認

製造物責任法の免責と時効
- 引き渡したときの科学・技術の水準では欠陥を見つけられなかったと証明できれば、責任を問われない
- 完成品メーカーの設計どおりに部品メーカーが作った部品が原因なら、部品メーカーには責任が生じない
- 請求権は、引き渡しから10年、または損害と賠償義務者を知ってから3年で消える
プログラムの著作権は誰のものか（★よく出る。特に決めごとがない場合）
- 開発を外部に委託した場合 → 受託した会社（作った側）のもの
- 法人の発意で、社員が職務として作った場合 → 法人（会社）のもの
- 派遣社員が派遣先の指示で作った場合 → 派遣先企業のもの
著作権で守られるもの、守られないもの
- 守られる：
  - 原始プログラム（ソース）、目的プログラム、プログラム設計書、操作説明書
- 守られない：
  - プログラム言語、アルゴリズム
- 保護期間：
  - 個人なら死後70年、法人なら公表後70年
セキュリティ関連の法律
- 電子署名法：
  - 電子署名を、民事訴訟法での押印と同じ扱いにできるようにした。電子署名は「本人が署名したこと」と「改ざんされていないこと」を確認できるもの
- 特定電子メール法：
  - 広告・宣伝メールは、取引関係があるなどの場合を除き、あらかじめ同意した人にだけ送る（オプトイン方式）
- 不正アクセス禁止法：
  - 不正アクセスの禁止、他人のID・パスワードを不正に取得することの禁止、不正アクセスを助長する行為（正当な理由なく、他人のID・パスワードを第三者に教えること）の禁止
- サイバーセキュリティ基本法：
  - サイバーセキュリティの基本理念と、国や地方公共団体の責務を定めた法律。基本的施策は12項目。内閣にサイバーセキュリティ戦略本部、内閣官房にNISC（内閣サイバーセキュリティセンター）が置かれている
契約の種類（指揮命令を誰が出せるかがポイント）

契約	指揮命令するのは	義務
派遣	派遣先が指示を出せる（雇用関係は派遣元）	派遣契約は派遣元と派遣先の間で結ぶ
請負	発注主は指示できない（請負元が指示する）	仕事を完成させる義務。成果物が契約内容に合わなければ契約不適合責任を負う（発注主は追完、損害賠償、報酬の減額、契約解除を求められる）
準委任	発注主は指示できない	誠実に業務を行う義務（善管注意義務）だけを負う。完成させる義務も契約不適合責任もない

偽装請負：
- 請負契約なのに、発注主が作業者に直接指示を出している状態。実態は派遣と判断され、職業安定法違反になる。常駐すること自体は問題ではなく、発注主が指示を出すことが問題

混同しやすいペア

請負（完成させる義務あり）／準委任（作業を誠実に行う義務だけ）／派遣（派遣先が指示を出せる）
是正保守（後から直す）／予防保守（障害になる前に直す）／適応保守（環境の変化に合わせる）／完全化保守（より良くする）
RFI（情報をもらう）→ RFP（提案をもらう）
機能要件（何をするか）／非機能要件（品質、技術、運用・移行など、それ以外のすべて）
利用時の品質モデル（5特性）／製品品質モデル（8特性）
思考発話法（話しながら操作する）／回顧法（操作した後に質問する）
認知的ウォークスルー（専門家が利用者になりきる）／ヒューリスティック評価（専門家が経験則で評価する）
著作権の帰属：
- 委託なら作った会社、社員なら会社、派遣社員なら派遣先
可逆圧縮（完全に戻せる）／非可逆圧縮（JPEG、MPEG。少し欠ける）
システム化構想の立案（業務の全体像を描く）／システム化計画の立案（費用・効果・QCD・スケジュールを具体化する）

← 11 システム戦略・経営戦略・企業と法務の目次に戻る