改正個人情報保護法を意識した要件定義工程の進め方と組織点検及びシステム監査に関する研究－企業 2 社での実務への適用を通じて－

107[® 研究論文 ]改正個人情報保護法を意識した要件定義工程の進め方と組織点検及びシステム監査に関する研究－企業 2 社での実務への適用を通じて－

A Study on the Organizational Inspection and Information Systems Audit of Requirement Definition
Process that Considers Revised Personal Information Protection Law- Survey with the Two Private Enterprises

栗山

孝祐

Takahiro Kuriyama

原善一郎

Zenichiro Hara

概 要2015 年 9 月に改正個人情報保護法が成立・公布され、2017 年 5 月に全面施行された。個人情報の保有件数の条件が撤廃され、全企業が改正個人情報保護法の適用対象になる。しかし、2017 年 3 月時点では改正個人情報保護法への対応が進んでいない状況であった。そこで、システム開発の上流工程の中心である要件定義工程で実施すべきプロセスを研究することにした。本論文では、個人情報保護要件検討シートを作り、改正法への対応漏れを防いだ。実践での使用として、企業 2 社の実際の要件定義工程の組織点検に着目し、既存のプロセスに組込みを行った。さらに、組織点検が適切に行われていることを確認するシステム監査で実施すべき 10 個のプロセスおよび主な監査項目一覧を具体的に整理した。これから改正個人情報保護法をシステム開発段階で適用される企業の参考になろう。
キーワード：個人情報保護法、要件定義工程、システム監査
1 はじめに
1.1 テーマ選定の背景
改正個人情報保護法は全企業が対象であるが、対応準備が遅れている企業が少なくない。
2015 年 9 月に改正個人情報保護法が成立・公布 さ れ、2017 年 5 月 30 日 に 全 面 施 行 さ れ た。
個人情報の保有件数の下限条件が撤廃され、5、000 件以下を保有する場合についてもこの法律が適用されることになり、全企業へ適用が拡大されるとことになった 1)。2017 年 3 月 10 日の一般財団 法 人 日 本 情 報 経 済 社 会 推 進 協 会（ 以 下、JIPDEC という）から公表された News Release（以下、News Release という）では、改正個人情報保護法対応について、2017 年春頃までに体制構築対応を予定している企業は 6 割、対応済は 1割未満であった 2)。
1.2 企業における課題
企業では、改正個人情報保護法の対応として、
投稿受理日
再投稿受理日
査読完了日

2017 年 3 月 30 日
2017 年 8 月 21 日
2017 年 9 月 26 日

自社の規程やルールの見直しの対応をする。そして、規程やルールに従い、業務の見直しを行う。
それに合わせ、関連システムの対応も取る。システムの対応をする場合、要件定義工程の役割は重要であるが、システム開発時に個人情報保護法の対応が重点管理されていないことが、改正個人情報保護法対応遅れの原因の一つとなっているケースがある。
この News Release の参加者アンケート結果で法対応の遅れの問題が提示されている。法適用の有無にかかわらず、企業が抱える情報管理実施上の問題点の上位 3 件は、次のとおりである。
・担当できる人材がいない (30.7%)
・管理ルールはあるが社内で徹底されていない(30.7%)
・規程類のルールが定まっていない (26.1%)
上記の問題点がある中、企業のシステム開発時は、改正個人情報保護法の対応以外に数多くのカテゴリー ( 例 : 品質、費用、納期、情報セキュリティ )108

シ ス テ ム 監 査の対応が必要となる。個人情報を取扱うシステムの開発でも同様となる。実際のシステム開発時は、
Quality: 品質、Cost: コスト、Delivery: 納期 ( 以下、QCD という）の 3 つの視点が要件定義工程で重要視される。個人情報保護のみの視点で、組織内による点検及び社内の専門部門 ( 品質管理やシステム管理 ) による点検 ( 以下、両方合わせて組織点検と記述 ) や専用の要件定義プロセス追加を実施することは現実的ではない。なぜならば、個人情報保護の視点の点検を独立させると、これにより、専用規定やルールの作成、人材確保とコスト増になるからである。
肝要なのは、既存の規程やルールの見直しにとどめ、既存の人材を活用し、コストを抑えながら法対応することである。また、システム開発時に、プライバシー・バイ・デザイン (PbD) の基本原則を組み込むタイミングは、要件定義工程である 3)。
つまり、「システムを個人情報保護対応済みとすること」は、そのシステム開発の要件定義工程で実施すべきであり、システム開発後に要件実現を組み込むことよりも、コストが低減できる。
1.3 本論文での研究概要
各企業は、従来から要件定義工程のプロセスがあり、組織点検を多様なカテゴリーに関して実施してきた。また、そのことによる内部統制の整備と運用状況を確認する作業をシステム監査として実施してきた。
本論文は、各企業が既に持っている既存のプロセスに、改正個人情報保護法対応に必要な要件定義、組織点検、システム監査を組込むことを提言するものである。
また、改正個人情報保護法対応に必要な要件定義では、3.3.1 で述べる「個人情報保護要件検討シート」を活用して、システムで実現する要件の抽出と要件定義を提言する。
次の章では、従来の個人情報保護法の下での 2つの企業の状況を示す。
2

従来の要件定義工程 ( 進め方、組織点検、システム監査 )SI ベンダー注 1)A 社及び、製造業 B 社での事例を調査し、これらを比較した。

2.1 SI ベンダー A 社の事例
当事例は、A 社が顧客と契約する作業の事例である。
A 社は顧客のシステム開発を行う標準的な手順の中で、手順の項目について顧客と共同で数多くの点検を行っている。この内容は、QCD が重要視される。特に従来は、開発するシステムで取扱う個人情報の件数が少ないため法適用外であるケースが多く、「個人情報保護法対応は重要な点検ポイントであるという認識」が低いケースが多かった。
2.1.1 開発の手順と点検項目
開発の手順は、国際標準に準じて作成され、これに沿って以下に述べるような点検をしている。
独立行政法人情報処理推進機構の「共通フレーム2013」に於いては、システム開発での要件定義は顧客責任としている 4) が、A 社における実態は、要件定義を顧客と共同作業として進めていることが多い。
A 社は、要件定義工程を、「商談」工程から「要件定義終了」工程までの 5 つとしている。個人情報の取扱いの確認に着目すると、次の通りとなる。
（1）「商談」工程
・SI ベンターとして、顧客システムの構築に向けた商談対応の工程で、組織としての商談審査、顧客への見積提示がある。その中で図表－１の①商談審査で、個人情報の取扱いをするシステム商談かどうかの確認をする。
（2）「受注」工程
・顧客と開発システムの契約に関することを進める工程であり、図表－１の②契約前確認にて、個人情報取扱いシステムであるかの確認、及び、個人情報取扱いシステムの場合、A 社は顧客の持つ個人情報を取扱わないように指導する。
（3）「要件定義開始～途中～終了」の 3 工程・要件定義を進める工程であり、開発システムの全体がわかる「システム概要図」も含めた要件定義書の作成を行う。その中で組織として 3 つの点検を実施している。図表－１の③にて要件定義工程のプロジェクト計画点検を行い、個人情報を取扱うかどうかを再確認する。そして、システム機能として取扱う場合、要件定義の途中では図表－１の④途中工程のプロジェクト点検、要件定義終了時には図表－１の⑤工程終了のプロジェクト点検で、システム機能での対応範囲の確認を行っている。

改正個人情報保護法を意識した要件定義工程の進め方と組織点検及びシステム監査に関する研究－企業 2 社での実務への適用を通じて－

A 社のシステム開発の場合、5、000 人以上の個人情報を取扱うシステムは、社員情報を管理する人事・給与システムや消費者情報を取扱うシステムであり、これら以外のシステムは法適用外プ
図表－１

109ロジェクトであった。したがって、「個人情報保護対応」は従来も点検項目としてはあったが、余り意識されていなかった。

A 社での要件定義工程と役割

2.1.2 点検項目の評価の重点
組織点検の中心は、QCD と要員やそのスキル等の人的資源である。
（1）「要件定義開始」時のプロジェクト計画点検 ( 図表－１の③ )プロジェクト開始時の点検である図表－１の③
プロジェクト計画点検では、プロジェクト計画書が出来ていて内容的に問題ないか ( 一定規模以上のプロジェクトでは、品質管理部門が③の一部として点検する )、作業項目、作業ボリューム、スケジュールの各妥当性、顧客、社内の各体制・要員スキル、品質管理・評価方法の確認、要件定義支援作業のコスト見積の妥当性等が点検され、リスク共有と対策検討が行われる。
（2）「要件定義工程途中」のプロジェクト点検（図表－１の④）
QCD を重視し、プロジェクトを点検している。
(1) と同様に、一定の規模以上のプロジェクトにおいては、Q（Quality: 品質）の客観的な品質評価として、品質管理部門が要件定義ドキュメントの検査を図表－１の④途中工程のプロジェクト点検の一部として行う。
（3）「要件定義工程終了」のプロジェクト点検（図表－ 1 の⑤）
要件定義工程を終了して良いか点検する。この点検で指摘されたことは、プロジェクト内で検討し、必要に応じ顧客とともに協議し、要件定義で対応をとる。「共通フレーム 2013 の概説」も要件定義の重要性を記載している 5)。A 社も要件定
義の充実度 ( システム化業務要件の明確度、システム設計着手の社内基準への適合度 ) に重点を置いて点検をしている。
2.1.3 システム監査
システム監査は、システム開発を中心にプロジェクトと組織に対し、社内の監査部門が内部監査として、半年ごとに上記 2.1.2 の (1) ～ (3) の実施確認、エビデンス確認を実施している。
2.1.4 個人情報保護対応に対する認識
従来、個人情報を取扱うシステムおよびプロジェクトは、全体システムの一部であり、多くのプロジェクトが非該当であったため、個人情報保護法対応の必要性の認識が薄かった。また、プロジェクトに対し QCD を中心とする多様なカテゴリーで点検しているため、点検時点での項目数は必要最小限に抑えてあった。そして、重要事項は、事前にプロジェクト内の自己チェックや、品質管理部門等の評価を受けていることで、確実な点検となるようにしている。
2.2 製造業 B 社での事例
製造業 B 社の利用部門が改善のためのシステム検討を行い、SI ベンダー C 社に提案依頼を行い、発注する事例である。
2.2.1 開発の手順と点検項目
B 社のシステム開発上流工程は「システム化構想」工程から「要件定義・発注」工程までの４つに分けられる ( 図表―２参照 )。
この 4 つを今回の研究対象で呼ぶ要件定義工程と位置付ける。

110

シ ス テ ム 監 査（1）「システム化構想」工程
・システムの利用部門が、システム化構想案を「システム化検討書」（業務の現状と問題点、改善後の業務の状態、改善方法のアイディア、業務改善による改善金額、改善活動の時期を記載）という文書で、作成する。
・これを、システム管理部門が図表－ 2 中の「①システム化審査」で、システム化の方向性、計画、システム化検討書の実現可否について審査する。この時、情報担当役員も参加する。
（2）「要件検討」工程・利用部門が提案依頼書を作成する。但し、利用部門だけで作成できない場合は、社内で関係者会議を立ち上げて作成する。さらに必要に応じ、C 社も作成に参画することもある。
・システム管理部門は、図表－ 2 中の「②提案依頼書評価」として、提案依頼書の内容について評価する。
この評価の特徴は、検討するシステムとこれに伴う業務改善が実現した場合、一部門の個別改善事項にとどまるのか、会社全体の新たな仕組みとなり全社の標準と位置付けられ全社の改善につながるものか、これに加えて全社の業務標準自体の継続的な改善を促す仕組みが組込まれた形になるのか、というレベルを評価していることである。これは、後述の金額で評価する投資対効果による評価の仕組みにも反映されている。
・C 社に提案依頼書を送付することで、提案依頼と見積依頼を行う。
（3）「提案検討・見積」工程
図表－ 2

・C 社が提案書と見積を作成し、利用部門へ送付する。
・これらの妥当性確認として、利用部門とシステム管理部門は「③提案・見積内容確認」を実施する。関係者会議を開催する場合もある。
（4）「要件定義・発注」の工程・利用部門、関係者会議でシステム実現に向けた要件定義書を作成する。この一部として「システム概要図」、「システムリスク確認シート」がある。「システムリスク確認シート」は、個人情報保護要件と関連する 5 項目 (DB（DataBase）、アクセス管理、入力ミス、影響度確認、遵法性 ) の確認が用意され実施されている。C社に直接確認がされることもある。
・システム管理部門による図表－ 2 中の「④発注書 ( 要件定義書 ) 検査」を行う。その過程で、「システムリスク確認シート」の点検も実施されている。
・利用部門が発注を行い、C 社が受注する。
2.2.2 点検項目の評価の重点
B 社は「システム開発費」、及び、その効果を評価する一定期間の「システム保守費と運用経費」の合計を、「システム投資額」としている。
B 社の計画するシステム開発・導入の評価は、投資と効果のバランスが重要視されている。個人情報保護要件が「システム投資額」の増加となった場合は、「定性効果額」に含めて評価されている。
評価は、①システム化審査、②提案依頼書評価、③提案・見積内容確認、④発注書（要件定義書）
検査に分類される。これらの評価の特徴は、投資B 社での要件定義工程と役割

改正個人情報保護法を意識した要件定義工程の進め方と組織点検及びシステム監査に関する研究－企業 2 社での実務への適用を通じて－対効果を金額で評価することである。企業であるため、システム投資により最終的には何らかの効果に結び付けなくてはならないからである。
B 社は製造業であるため、あらゆる側面で、金額による評価と原価削減がその評価の中心である。たとえ、売上増に結びつく投資であっても、売上増により原価増になるからである。このシステム投資により増加する原価は、金額で評価される効果により一定期間内に相殺され、さらに、企業としては金額的効果と金額では表現できない定性効果の実現が期待される。効果評価は、3 つに分類され、「定量効果額１」（現在の実際に支払っている費用の改善金額）、「定量効果額２」（5 年間の費用増加を想定した場合の改善金額）、「定性効果額」（金額に換算できない効果額を、投資額と同等以下で査定した金額）の合計値が、投資額以下となってはいけないとされている。すなわち、次の式が成立することがシステム開発着手の必要条件となる。
「定量効果額１」＋「定量効果額２」＋「定性効果額」≧「システム投資額」
さらに、年間に開発するシステムの全体の投資対効果も評価される。年間に開発するシステムの効果額の総合計は、「定量効果額１」と「定量効果額２」それぞれの年間合計を合算した「定量効果額」と「システム投資額」の年間合計を比較している。年間では「定性効果額」を含まないこととし、「定量効果額１」と「定量効果額２」の合計額だけで「システム投資額」を上回っていることを確認する。
「定量効果額１」の年間合計＋「定量効果額２」の年間合計≧「システム投資額」の年間合計
なぜならば、「あるシステムは、他のシステム群の前提システムとなる」という効果も定性効果として評価されるため、重複するからである。この効果評価の仕組みにより、「コンプライアンス対応」などの定性効果のみのシステムも、金額による効果評価の仕組みの中で「必要と判断」が可能となる。
2.2.3 システム監査
システム監査は、利用部門に対し、社内のシステム監査担当部門が内部監査として、半年ごとに上記 2.2.2 の (1)~(4) の実施確認、エビデンス確認、他の監査項目も含め実施している。

111

2.3 共通事項と特徴がある事項
ここまで、2 つの企業での研究対象である要件
定義工程、組織点検、システム監査の現状を見てきた。
2.3.1 共通事項
両方に共通することについて下記にまとめた。
①個人情報保護法対応の必要性の認識が低くかった。
従来は、法適用は個人情報が 5、000 件以上に限定されるとの認識があり、ほとんどのシステムが対象外とされた。
②要件定義書の一部として、開発システムの全体がわかる「システム概要図」を作成していた。
③組織点検は、効率の観点で必要最小限にしている。
組織点検は多種多様なことを要求されるため、実務的には必要事項の一覧性が重要であり、網羅的で各カテゴリー ( 例 : 品質、費用、納期 )は最小限の項目で評価・確認された。
④システム監査の位置付け
システム監査は、内部監査の位置付けで他の監査項目に含めて行っていた。
2.3.2 A 社と B 社に共通しない、各社に特徴がある事項
それぞれに特徴がある事項は次の通りである。
・組織点検は、A 社では顧客との契約履行を重視して、要件定義の品質である充実度 ( シス
テム化業務要件の明確度、システム設計着手の社内基準への適合度 ) に重点が置かれている。B 社では自社のシステムに対するコストの観点を重視して、要件定義工程全般を通じ、システムの投資対効果に重点が置かれている。
3

改正個人情報保護法の対策① ( 要件定義工程の進め方 )調査を行った企業２社の共通事項と特徴を前提に、研究を行う。
3.1 当研究の特徴
栗山 (2017)6）は、流通小売業をターゲットに改正個人情報保護法対応を意識したシステム開発における要件定義工程の進め方と要件抽出を模擬適用する研究を行った。業種枠を外し、SI ベンダー

112

シ ス テ ム 監 査

A 社と製造業 B 社へ要件定義工程の進め方、要件抽出 ( 図表－４個人情報保護要件検討シートの活用 )、組織点検、システム監査の 4 つを実際に適用する活動をおこなった研究である。具体的には、
図表－３個人情報取り扱いシステム要件定義工程
プロセス概要を 2 つの企業の既存工程 ( 図表－１、図表－２) に組み込んだ。本章では、要件定義工程の進め方、要件抽出 ( 図表－４個人情報保護要件検討シートの活用 ) を中心に説明する。
3.2 要件定義工程へのプロセス適用
個人情報を取扱うシステムの開発における要件定義工程で組込みを提唱するプロセスは、図表－３に示すように「業務要件の検討」と「個人情報保護要件の策定」の 2 つのフェーズになり、「業務要件の検討」では、システム化要件全体を検討し、「個人情報保護要件の策定」は、個別の要件定義を示す。
3.2.1 要件定義工程プロセスの詳細（１）業務要件の検討
業務要件の検討は、下記の 4 つのステップで行う。従来の要件定義工程で作成する「システム概要図」に「個人情報」に関する情報を記載することになる。
ステップ 1：目的および業務の洗い出し
情報システムの「名称」および情報システム導入の「目的」を定める。続いて、目的に合う具体的な「業務」を整理し、業務に関わる人物や情報も整理する。
ステップ 2：業務の特徴の整理
改正個人情報保護法、個別法、個人情報保護委員会からの指針、認定個人情報保護団体の情報から遵守事項を確認して対応方針を明確にする 7)。
図表－ 3

ステップ 3：システム概要図の作成
システム概要図は、他の要件と合わせて作成するため、ここでは「個人情報」に関する情報を記載する。( 例 : 個人情報 DB、個人情報の流れ、利用者を表現 )ステップ 4：定型設問による業務要件の詳細化
個人情報保護要件の導入に必要なレベルにまで業務要件を詳細化する。「主体」「情報」「利用環境・手段」の 3 つの視点と、個人情報影響評
価 (Personal information ImpactAssessment)、( 以下、PIA という）注 2) の予備評価等で用いられる項目にて業務要件の詳細化を行う。これが「PIA の予備評価情報」となる。
PIA の予備評価項目は、個人情報を新規か機能追加として扱うことになったのか、情報に機微情報を含むか、アウトソーシングか、情報取得にあたり利用目的の開示や本人との合意を適切に取って取得しているか等の項目確認である 8)。
（２）個人情報保護要件の策定
個人情報保護要件の策定に関しては、下記の 4
つのステップで行う。ステップ 7 を除き、従来の要件策定でも実施されることである。ステップ 7
は、組織点検の一部として行う詳細の個別確認を改正個人情報保護法対応用にしたものである。
ステップ 5：システム対応方針の決定とシステ
ム対応範囲の検討システムで対応すべき範囲である対応方針を決め、その後、PIA の評価項目単位にシステム対応可否を決める。ステップ 2 で行った法関連対応の確認も行う。
ステップ６：対策要件の決定
ステップ 5 の結果に従い、「個人情報保護要件検討シート」にて、システムで対応するとした項目単位に、システム機能概要要件を決定する。

個人情報取扱いシステム要件定義工程プロセス概要

業務要件の検討フェーズ
ステップ 1ステップ 2ステップ 3

目的及び業務の洗い出し（関連法、指針、方針、ガイドライ システム概要図の作成
ン等の遵守事項の対応整理も含む）

業務の特徴の整理ステップ 4
定型設問による業務要件の詳細化

個人情報保護要件の策定フェーズ
ステップ 5ステップ 6

システム対応方針の決定と対策要件の決定
対応範囲の検討（ステップ 2 の法関連対応の確認含む）

ステップ 7ステップ 8

個人情報影響評価（PIA）の要件定義書への反映
実施とその評価の反映

改正個人情報保護法を意識した要件定義工程の進め方と組織点検及びシステム監査に関する研究－企業 2 社での実務への適用を通じて－ステップ 7：PIA の実施とその評価の反映
改正個人情報保護法の普及段階では、有識者による評価を行い、指摘事項を機能要件の見直しに活用する。具体的な評価対象としては、業務要件の検討で作成した「システム概要図」、ス
テップ 4 で実施した「PIA の予備評価情報」、
および、ステップ 6 で作成した「個人情報保護要件シート」である。
ステップ 8：要件定義書への反映
ステップ 7 で決定したことを要件定義書に反映させる。
3.3 要件抽出に個人情報保護要件検討シートを活用
栗山 (2017)6）掲載の個人情報保護要件検討シートを他業種で適用できるように拡張している。

3.3.1 「個人情報保護要件検討シート」の A 社、B 社への適用
本論文では、栗山 (2017)6）掲載の個人情報保護要件検討シートに凡例を追記した。
図表－４では、評価の大項目を提示し、a) で評
価項目単位にシステム化要件にて対応 / 非対応 ( システム以外で対応 ) を、b) でシステムにて実現する場合の検討すべき補足説明等を、c) でシステム機能要件例を記載した。例えば、大項目①目的明確化は、目的を明確化すること自体はシステムでは実現できないため、a) は非対応とした。b) は①の目的外利用の防止をシステムで実現する場合、検討が必要であること、及び、機微情報について、システムで区別して管理する場合、検討が必要であることを記載した。A 社及び B 社は、当シートを活用し、改正個人情報保護法に関する要件を数プロジェクトにて抽出した。その結果、活用したシステムでは、改正個人情報保護法の要求事項のシステム要件漏れを防ぐことができている。
4

改正個人情報保護法の対策② ( 要件定義工程での組織点検とシステム監査 )改正個人情報保護法がシステム開発の要件定義工程から意識されていることを、組織点検で確認することと、組織点検の妥当性を確認するシステ
ム監査で確認することが望まれる。4 章では、2企業の組織点検の組込みと、今後予定されるシステム監査について説明する。

113

4.1 要件定義工程での組織点検
2.3 の共通事項にあるように、それぞれの企業において既に確立された組織点検プロセスがあり、効率的に実施されている。そのため、各企業が既に持っている点検に改正個人情報保護法の視点を組込む。具体的には、図表―１の①②③④⑤、図表―２の①②③④の活動に組込んだ。
改正個人情報保護法対応として、組織点検の段階では、法適用が必要なシステムであるかの確認や、該当する場合、有識者や専門部門の事前確認が実施済であるかの確認が重要である。
そのため、組織点検の前に、有識者や専門部門で、改正個人情報保護法について熟知し、かつ、自社での影響を把握できる要員の判定や確認が必須である。対応者の候補としては、社内のシステム監査スキル保有者やプライバシーマーク制度推進者、同制度の審査員の知識を有する者などの活用が有効である。さらに、特定個人情報 ( マイナンバー ) 対応経験者の活用も有効であると考える。
点検時の組込みカテゴリーとしては、現実的には品質管理の項目として組込むのが良く、事例の 2つの企業も品質のカテゴリーとして組込んだ。
ISO（国際標準機構 International Organizationfor Standardization の略。ここでは、国際標準機構が出版した国際規格を示す）では QMS（品質 管 理 シ ス テ ム の 国 際 規 格 Quality
Management System ISO9001）と ISMS（情報セキュリティマネジメントシステムの国際規格
Information Security Management System）
で一部共通化の動きはあるが 10)、実際の現場では両方合わせて対応・点検する意識が強い。そのため、情報セキュリティ対策も品質のカテゴリーに加えて考えた方が良く、今回の個人情報保護対応も含めるのが良いと判断する。
発生するコストについては、要件定義工程で定義して設計時に対策をする場合と比較して、開発時の対策は 6.5 倍、運用時に至っては 100 倍と評価している調査結果がある 8)。
そのため、このような情報をシステム開発にかかわる者に浸透させ、組織点検は、要件定義工程ですることが大切である。
4.2 個人情報保護要件検討シートの活用に対する組織点検
図表―４の「個人情報保護要件検討シート」の114

シ ス テ ム 監 査
図表－ 4

個人情報保護要件検討シート

活用方法とプロセスについて下記に示す。概要は、有識者や専門部門のチェックを受け、組織点検で実施の有無を確認する。
①抽出した要件一覧を社内の改正個人情報保護法の有識者や専門部門がチェックする。
改正個人情報保護法について熟知し、自社での影響を把握できる要員が実施する。
②上記の①を実施したことを、確認項目の一覧に含め、組織点検する。
具体的には、図表―１の「A 社での要件定義工程と役割」では⑤終了工程のプロジェクト点検、図表―２の「B 社での要件定義工程と役割」では「④発注書（要件定義書）検査」で実施する。
要件定義工程での「組織点検」についてまとめると、要件定義工程での組織点検概要図となる（図表－５）。
4.3 要件定義工程でのシステム監査
図表－５は、見方を変えると、改正個人情報保護法を意識したシステム監査対象を表す表となる。すなわち、図表－５に示す①～⑩がシステム監査の対象を表すことになる。
さらに、この概要表にもとづきプロセス①～⑩に対する主な監査項目は、図表―６に示した。監査項目として特徴的なところは、④要件検討と⑤最終確認である。つまり④要件検討では、図表－３のステップ 2、4、5、6 の実施確認、図表－４の「個人情報保護要件検討シート」の実施と内容確認である。⑤最終確認では、図表－３のステッ改正個人情報保護法を意識した要件定義工程の進め方と組織点検及びシステム監査に関する研究－企業 2 社での実務への適用を通じて－
図表－ 5
時点

役割

組織の審査
有識者
/ 専門部門利用部門、プロジェクト115

要件定義工程での組織点検概要 ( システム監査対象 )

要件定義開始要件定義途中要件定義終了③開始審査（必要時）途中審査⑦終了審査②法対応有無判定（必要時）支援、途中確認⑤最終確認①法対応有無検討④要件検討⑥要件定義書完成⑧関係者の底上げ教育

教育⑨専門部門の育成教育⑩全体プロセス作成・実施・改善

プ 7 の実施確認、図表－４の「個人情報保護要件検討シート」の利用網羅性の確認である。
5

おわりに
本論文では、栗山 (2017)6）での提言を基に、要件定義工程で実施すべきプロセスと個人情報保護要件検討シートを作り、必要要件候補を一覧にした。さらに、企業 2 社の実際の要件定義工程の組織点検に着目し、既存のプロセスにこれらの組込みを行った。加えて、システム監査項目一覧を具体的に整理した。これから適用される企業の参考になろう。
なお、本研究は、改正個人情報保護法の全面施行前という時期による実践であったので、この研図表－ 6

究をさらに発展させるには、研究実践後の評価と反映があると認識する。
特に、現実のシステム開発プロセスでは、他の管理項目と合わせて適用するため、全体での位置づけ、実施タイミングなどの評価とブラシュアップが必要である。
今後、上記の課題について少しずつではあるが、実際のシステム開発の現場や特定非営利活動法人日本システム監査人協会での活動、システム監査学会での活動を通じ、継続してシステム監査に関する研究を進めていきたい。
注
注 1）顧客の業務内容を分析し、問題に合わせた要件定義工程での主なシステム監査項目一覧

116

シ ス テ ム 監 査

情報システムの企画、構築、運用などの業務を一 括 し て 請 け 負 う 企 業 の こ と。IT 用 語 辞 典
e-Words より
注 2）瀬戸洋一著「実践的プライバシーリスク評
価技法」近代科学社 2014 年を参考にして本論文では「PIA」を次のように捉えることとする。
日本における民間利用の PIA は、「個人情報影響評価」、法律で規定されたマイナンバーに関する PIA は、「特定個人情報保護評価」とする。
上 記 の 両 方 の 英 文 表 記 は、「Personalinformation Impact Assessment」とする。
注 3）サーバ等へログインしない方法で監視機により監視する方法の実現性は、実証実験が実施されている。「IoT を利用した遠隔監視機」により、サーバにログインしない方法で、「サーバ等の異常検出と短いサイクルの分析」を実現している 9)。
参考文献
1）個人情報保護委員会「個人情報保護法について」
https://www.ppc.go.jp/personalinfo/ 参照
日：2017.07.19
2） 一 般 財 団 法 人 日 本 情 報 経 済 社 会 推 進 協 会(JIPDEC)「News Release」2017 年 3 月 10 日
https://www.jipdec.or.jp/topics/news/
u71kba00000075b5-att/20170310.pdf3）堀部政男 / 一般財団法人日本情報経済社会推進協会 (JIPDEC) 編
Privacy by Design: ア ン・ カ ブ キ ア ン 著、JIPDEC 訳「プライバシー・バイ・デザイン プライバシー
情報を守るための世界的新潮流」
日経 BP 社 2012 年
4）独立行政法人情報処理推進機構 (IPA) 技術本
部 ソフトウェア・高信頼化センター (SEC)「共通フレーム 2013」 2013 年 12 月
5）室谷隆著「共通フレーム 2013 の概説」
独立行政法人情報処理推進機構 (IPA) 技術本部
ソフトウェア・エンジニアリング・センター(SEC) 2013 年
6）栗山孝祐著 「個人情報取扱いシステムにおける要件定義工程の提言－流通小売業システムでの模擬適用を通じて－」
大阪市立大学大学院 創造都市研究科 修士学
位論文 2017 年 3 月

7）岡村久道著「個人情報保護法の知識 < 第 3 版 >」日本経済新聞出版社 2016 年
8）瀬戸洋一著「実践的プライバシーリスク評価技法」 近代科学社 2014 年
9）原善一郎、石井成美 :"IoT 時代における光信号の遠隔監視の実証研究 "、日本生産管理学会
第 45 回全国大会講演論文集、pp.47-5010）NPO 法人日本システム監査人協会監修『6 ヶ月で構築する個人情報保護マネジメントシステ
ム 実施ハンドブック』同文舘版 2014 年