システムアーキテクト 2016年 午後1 問02
問合せ管理システムの導入に関する次の記述を読んで、設問1~3に答えよ。
D社は、産業用機械メーカである。全国にあるグループの販売会社数社を通じて、法人顧客に対してD社製品の販売・保守を行っている。D社グループでは、製品に関する顧客からの不具合の連絡、クレームなどを含む問合せ(以下、問合せという)をグループ全体で一元的に管理する問合せ管理システム(以下、新システムという)の導入を行うことにした。
〔新システム導入の目的〕
顧客からの問合せは、販売会社で受け付け、対応しており、受付内容及び対応内容の情報(以下、問合せ情報という)については、各販売会社で記録、管理している。しかし、現在は問合せへの対応状況が適切に管理されておらず、一部の対応が滞ることがある。また、問合せ情報をD社グループ内で共有できておらず、過去の対応内容を類似の問合せへの対応に生かすことができていない。製品製造であるD社においても、問合せ情報が即時に販売会社から報告されていないので、問合せが急増している製品を早期に把握し、改善を図ることができていない。
そこで、D社グループ内で新システムを構築し、顧客サービスの向上と製品の品質改善につなげることにした。新システムは1年後に稼働する計画とした。
〔現在の問合せ対応業務の概要〕
現在の、各販売会社で行う問合せ対応業務の概要は、次のとおりである。
(1)顧客は、購入したD社製品に問題が発生した場合、販売会社へ電話又は電子メール(以下、メールという)で連絡する。
(2)連絡を受けた担当者は、顧客から問合せ内容の詳細を聞取りする。
(3)担当者は、即時に解決可能な問合せの場合、聞取りと同時に解決に必要な対応を行う。即時に解決できない問合せの場合、一旦聞取りを終了し、販売会社内の製品技術者又はD社の製品部門に連絡して、対応策を相談する。相談した対応策に基づき、再度顧客に連絡し、解決に必要な対応を行う。
(4)対応が完了した後、担当者は各販売会社所定の報告書を作成し、上司に報告する。報告書は、各販売会社の文書管理規程にのっとって管理する
なお、解決困難な問合せの場合は、問合せ内容の聞取り終了から報告までに数週間掛かる場合がある。また、安全性に関わる重大な問題の場合は、品質問題報告書を作成し、聞取り終了した日の翌営業日までに、D社品質保証部門に報告している。
〔D社グループのIT戦略〕
5年前に策定したD社グループのIT戦略では、グループ全体の経営を支える情報システムの最適化を目標として定め、社内LAN及びグループウェアを含む社内イントラネットシステムの統合を実現した。統合の際、ディレクトリサーバを用いたID管理基盤を導入し、それまで情報システムごとに個別管理していた利用者ID及びパスワードを一元管理している。また、多様な働き方に対応するために、社員に貸与するPCを利用して、自宅、外出先などから、インターネットVPN経由で社内システムへ安全にアクセスできる環境を構築した。当環境では、個人所有のPCなど、許可されていない端末からはアクセスできない対策が取られている。
現在、新システムとは別に、D社グループ全体で基幹業務システムの再構築プロジエクトが進行しており、1年半後に新たな基幹業務システムの稼働を予定している。
なお、D社では今年、IT戦略の見直しを行った。見直し後のIT戦略では、更なる経営効率向上を目指し、自社で構築・運用する情報システム(以下、自社運用システムという)を段階的に減らし、専門の事業者が提供するクラウドコンピューティングサービス(以下、クラウドサービスという)の活用を積極的に進めることにした。
〔販売会社からの新システムへの要望〕
販売会社からの新システムへの要望は次のとおりである。
・問合せ対応の参考にするために、他の販売会社で受け付け、対応が完了した問合せ情報についても、製品型番、製品名、問合せ分類、フリーワード、受付年月日の期間指定などで検索することで、問合せ件名などの基本情報、受付内容及び対応内容を閲覧できるようにしてほしい。一方で、その他の情報については、必要がない限り問合せ受付元の販売会社以外には閲覧させないことを原則としてほしい。
・自社で登録した問合せ情報は、登録後も自社で修正できるようにしてほしい。一方で、自社で登録した問合せ情報を、他の販売会社が修正できないようにしてほしい。
・誤って同一の問合せを重複して登録することが想定されるので、自社で登録した問合せ情報を削除できるようにしてほしい。一方で、自社で登録した問合せ情報を、D社及び他の販売会社が削除できないようにしてほしい。
・担当者が問合せを受けた時に聞取りした相手である顧客側の担当者(以下、問合せ顧客という)の情報については、機密性が高いので、D社及び他の販売会社へ開示しないでほしい。D社が問合せ顧客の情報を必要とする場合は、担当者に連絡をもらえれば、問合せ顧客に了解を得た上で、情報を伝えるようにする。
・新たに、利用者ID及びパスワードを覚えなくても済むようにしてほしい。
〔D社品質保証部門及び製品部門からの新システムへの要望〕
D社品質保証部門及び製品部門からの新システムへの要望は次のとおりである。
・販売会社からの要望に加えて、D社としては製品の品質改善のために、重大な問題に限らず、早期に問合せ情報を確認できるようにしてほしい。具体的には、どのような問題が発生しているのかを把握するために、問合せ件名、受付内容及び報告時点までの対応経緯だけでも直ちに確認できるようにしてほしい。問合せ内容、対応経緯などの修正が後から生じることは問題ない。
・受付内容の記入間違い時の訂正、D社が支援した内容の対応経緯への加筆などが想定されるので、販売会社が登録した受付内容及び対応内容を、販売会社が対応中でも対応が完了した後でも、D社が修正できるようにしてほしい。
・複雑な問題の場合、D社が直接顧客から問合せの詳細を聞取りしたいことがあるので、必要な情報を見られるようにしてほしい。
・製品マスタなどのマスタ情報は、基幹業務システム上で更新が発生するので、新システム上にも最新情報を反映するようにしてほしい。
〔新システムの構成〕
IT戦略に基づき、新システムは、クラウドサービスを活用して構築することを検討した。検討の中で、クラウドサービス上に構築する新システムを、社内LAN経由ではなくインターネット経由で直接利用した場合のリスクとして、外部からの不正アクセス、盗聴の他、社内システムでは認めていないシステムの利用方式で社員が新システムを利用できてしまうおそれがあるのではないかという意見が挙がった。これらのリスクに対して、クラウドサービスと自社運用システムとの間を閉域網で接続し、インターネットから論理的に遮断して社内LAN経由でしか新システムを利用できない構成とすることによって、リスクを回避することにした。検討した新システムの構成概要を図1に示す。
新システムへの要望に基づき、新システムで構築するディレクトリサーバと自社運用システム上のディレクトリサーバとの連携、及び新システムで開発する業務アプリケーションプログラムと基幹業務システムの業務アプリケーションプログラムとの連携が必要になる。しかし、基幹業務システムとの連携は、基幹業務システム側での対応作業の負荷が高いことに加え、①ある理由で新システム稼働後の改修が発生する可能性が高いので、今回はディレクトリサーバの連携だけを行うことにした。基幹業務システムとの連携は新システム稼働後に改めて検討することにし、当面は人手での情報連携で運用することにした。
〔登録画面の設計〕
新システムで管理する問合せ情報は、五つに分類し、その情報の種類ごとに画面領域を分割して問合せ情報を登録する画面(以下、登録画面という)を設計した。情報の種類ごとの主な属性を、表1に示す。
基本情報の対応ステータスは、問合せへの対応状況に応じて“受付内容確認中”、“受付完了・対応中”、“対応完了”の三つのステータスの中から選択し、新システムに登録、更新することによって、問合せ対応の進捗状況を可視化できるようにした。 新システムへの要望を踏まえて、対応ステータスを“受付完了・対応中”にすることによって、D社品質保証部門及び製品部門に必要な権限を与えるようにした。また、“対応完了”にすることによって、D社品質保証部門及び製品部門に加えて、問合せ受付元以外の販売会社にも必要な権限を与えるようにした。 なお、②新システムを利用した問合せ対応業務では、即時に解決できない問合せの場合であっても、遅くとも業務上のあるタイミングまでには、問合せ情報を新システムに登録するルールとした。 〔問合せ情報に対する権限) 問合せ受付の販売会社が登録した問合せ情報を利用するに当たっての、利用者の所属、基本情報の対応ステータス及び情報の種類に応じた、関覧、修正及び削除の権限を、表2の決定表に整理した。
基本情報の対応ステータスは、問合せへの対応状況に応じて“受付内容確認中”、“受付完了・対応中”、“対応完了”の三つのステータスの中から選択し、新システムに登録、更新することによって、問合せ対応の進捗状況を可視化できるようにした。 新システムへの要望を踏まえて、対応ステータスを“受付完了・対応中”にすることによって、D社品質保証部門及び製品部門に必要な権限を与えるようにした。また、“対応完了”にすることによって、D社品質保証部門及び製品部門に加えて、問合せ受付元以外の販売会社にも必要な権限を与えるようにした。 なお、②新システムを利用した問合せ対応業務では、即時に解決できない問合せの場合であっても、遅くとも業務上のあるタイミングまでには、問合せ情報を新システムに登録するルールとした。 〔問合せ情報に対する権限) 問合せ受付の販売会社が登録した問合せ情報を利用するに当たっての、利用者の所属、基本情報の対応ステータス及び情報の種類に応じた、関覧、修正及び削除の権限を、表2の決定表に整理した。

設問1:〔新システムの構成〕について、(1)~(3)に答えよ。
(1)リスクとして挙げられた、社内システムでは認めていないシステムの利用方式を、30字以内で述べよ。
模範解答
許可されていない端末を用いた社内システムの利用
解説
解答の論理構成
- 既存対策の前提
- 「個人所有のPCなど、許可されていない端末からはアクセスできない対策が取られている」
⇒ 社内システムは利用端末を厳格に制限している。
- 「個人所有のPCなど、許可されていない端末からはアクセスできない対策が取られている」
- 新システムをインターネット経由で直接利用した場合の懸念
- 「社内システムでは認めていないシステムの利用方式で社員が新システムを利用できてしまうおそれ」
⇒ インターネット経由なら端末制限を回避できる可能性がある。
- 「社内システムでは認めていないシステムの利用方式で社員が新システムを利用できてしまうおそれ」
- リスクの正体
- 社員が自宅の私物PCやスマートフォンなど「許可されていない端末」を用いて業務システムに接続する状況こそが、社内ポリシー違反となる利用方式。
- 以上から、設問が求める「社内システムでは認めていないシステムの利用方式」は
「許可されていない端末を用いた社内システムの利用」となる。
誤りやすいポイント
- 「外部からの不正アクセス」「盗聴」など他のリスクをそのまま書いてしまう。
- 「社外ネットワーク経由の利用」とだけまとめ、端末制限の観点が抜ける。
- 「VPNを使わないアクセス」と答え、端末許可に言及しない。
FAQ
Q: 端末以外の観点(場所・ネットワーク)を答えても減点ですか?
A: 設問は「社内システムでは認めていないシステムの利用方式」を聞いており、問題文が具体例として示しているのは端末制限の回避です。場所やネットワークだけでは意図がずれるため減点対象となります。
A: 設問は「社内システムでは認めていないシステムの利用方式」を聞いており、問題文が具体例として示しているのは端末制限の回避です。場所やネットワークだけでは意図がずれるため減点対象となります。
Q: 「許可されていない端末」とは具体的に何を指しますか?
A: 社員が個人的に所有するPCやスマートフォン、会社貸与でも管理外の端末など、ディレクトリサーバの認証ポリシーや資産管理台帳に登録されていない端末を指します。
A: 社員が個人的に所有するPCやスマートフォン、会社貸与でも管理外の端末など、ディレクトリサーバの認証ポリシーや資産管理台帳に登録されていない端末を指します。
Q: 回答に「私物PC」と書いてもよいですか?
A: ニュアンスは近いですが、設問は“社内システムで認めない利用方式”を求めています。「許可されていない端末」を含まない表現は不十分になる可能性があります。
A: ニュアンスは近いですが、設問は“社内システムで認めない利用方式”を求めています。「許可されていない端末」を含まない表現は不十分になる可能性があります。
関連キーワード: VPN, ディレクトリサーバ、クラウドサービス、閉域網、不正アクセス
設問1:〔新システムの構成〕について、(1)~(3)に答えよ。
(2)新システムで構築するディレクトリサーバと自社運用システム上のディレクトリサーバを連携させることによって、新システムで何が利用できるようになるか。25字以内で述べよ
模範解答
自社運用システムの利用者 ID 及びパスワード
解説
解答の論理構成
- 【問題文】では「新システムで構築するディレクトリサーバと自社運用システム上のディレクトリサーバとの連携」が必要だと明示。
- 既存ディレクトリサーバは「利用者ID及びパスワードを一元管理している」ため、連携すれば新システムでも同じ認証情報を取得可能。
- したがって利用者は新たな資格情報を覚える必要がなく、販売会社の要望「新たに、利用者ID及びパスワードを覚えなくても済むようにしてほしい」を満たす。
- 以上より、連携で使えるようになるのは「自社運用システムの利用者 ID 及びパスワード」である。
誤りやすいポイント
- 「シングルサインオン機能」そのものと答えてしまい、何が利用できるのかを具体的に示さない。
- 連携対象を「問合せ情報」や「製品マスタ」と誤解する。製品マスタ連携は後回しであり今回の範囲外。
- 「アクセス権限」や「役職情報」と書き、ID とパスワードという認証情報である点を外す。
FAQ
Q: 連携で自動付与されるのは権限も含まれますか?
A: 認証情報(利用者ID及びパスワード)の共用が主目的で、細かな業務権限は新システム側の設定ポリシにより制御します。
A: 認証情報(利用者ID及びパスワード)の共用が主目的で、細かな業務権限は新システム側の設定ポリシにより制御します。
Q: 今後、基幹業務システムと連携する際にも同じ ID を使えますか?
A: 基幹業務システムも同じ ID 管理基盤を参照しているため、連携すれば共通 ID での運用が可能です。改修時の負荷が懸念され一旦延期されたものの、認証基盤自体は統一されています。
A: 基幹業務システムも同じ ID 管理基盤を参照しているため、連携すれば共通 ID での運用が可能です。改修時の負荷が懸念され一旦延期されたものの、認証基盤自体は統一されています。
関連キーワード: ディレクトリサーバ、認証基盤、一元管理、クラウド連携、シングルサインオン
設問1:〔新システムの構成〕について、(1)~(3)に答えよ。
(3)本文中の下線①について、どのような理由で、新システム稼働後の改修が発生する可能性が高いと判断したのか。40字以内で述べよ
模範解答
新システムの構築と並行して基幹業務システムの再構築を進めているから
解説
解答の論理構成
- 事実確認
- 問題文に「現在、新システムとは別に、D社グループ全体で基幹業務システムの再構築プロジエクトが進行しており、1年半後に新たな基幹業務システムの稼働を予定している。」とある。
- 新システムは「1年後に稼働する計画」。
- 時期差の発生
- 新システム稼働時点では、基幹業務システムはまだ旧システムのまま。半年後に新基幹システムへ切替わる。
- 連携仕様の不確実性
- 「基幹業務システムとの連携は、新システム稼働後に改めて検討することにし」と明示されており、連携内容が未確定。
- 結論導出
- 半年後に基幹業務システム側の仕様が変わる=新システム側のインタフェースを改修し直す可能性が高い。
- よって「①ある理由」とは「基幹業務システム再構築の進行」が該当する。
誤りやすいポイント
- クラウド利用や閉域網構成が改修要因と早合点する。
- 「連携は人手で運用」とあるため改修不要と思い込む。
- 変更リスクの根拠をセキュリティ方針変更と誤読する。
FAQ
Q: 基幹業務システムと連携しないなら改修は不要では?
A: 稼働後に正式連携を予定しているため、新基幹システムの仕様確定後にインタフェースを追加・修正する必要が生じる可能性が高いです。
A: 稼働後に正式連携を予定しているため、新基幹システムの仕様確定後にインタフェースを追加・修正する必要が生じる可能性が高いです。
Q: 半年の時期差がなぜ重要なのですか?
A: 新システム稼働から半年以内に基幹業務システムが切替わるため、その時点で再度連携方式を整備する作業が発生しやすいからです。
A: 新システム稼働から半年以内に基幹業務システムが切替わるため、その時点で再度連携方式を整備する作業が発生しやすいからです。
Q: クラウド利用と改修リスクは無関係ですか?
A: 本問では改修リスクの直接要因は「基幹業務システムの再構築」であり、クラウド利用自体は関係しません。
A: 本問では改修リスクの直接要因は「基幹業務システムの再構築」であり、クラウド利用自体は関係しません。
関連キーワード: システム連携、インタフェース設計、仕様変更、改修リスク
設問2:
〔登録画面の設計〕について、本文中の下線②の業務上のあるタイミングとは、どのようなタイミングか。25字以内で述べよ。また、そのときに、登録画面の対応ステータスで選択すべきステータスは何か。そのステータスを答えよ。
模範解答
タイミング:問合せ内容を聞取り終了したタイミング
ステータス:受付完了・対応中
解説
解答の論理構成
- 下線②の記述
- 「②新システムを利用した問合せ対応業務では、即時に解決できない問合せの場合であっても、遅くとも業務上のあるタイミングまでには、問合せ情報を新システムに登録するルールとした。」
- 現行業務フロー
- (2)「連絡を受けた担当者は、顧客から問合せ内容の詳細を聞取りする。」
- 聞取りが完了しないと受付内容は確定しない。
- ステータスの意味づけ
- 「基本情報の対応ステータスは…“受付内容確認中”、“受付完了・対応中”、“対応完了”」。
- また「対応ステータスを“受付完了・対応中”にすることによって、D社品質保証部門及び製品部門に必要な権限を与えるようにした。」
- よって聞取り終了後にこのステータスを選ぶことで、D社が早期に閲覧・修正できる。
- 以上より
- 登録すべき最遅タイミング=聞取り終了時
- 選択すべきステータス=受付完了・対応中
誤りやすいポイント
- “受付内容確認中”と勘違いし、登録を聞取り開始時と誤認する。
- “対応完了”を選択してしまい、進捗を見誤る。
- 登録の目的が「D社への早期共有」であることを見落とす。
FAQ
Q: なぜ“受付内容確認中”では不十分なのですか?
A: このステータスではD社部門に修正権限が与えられず、早期品質改善の要望を満たせないためです。
A: このステータスではD社部門に修正権限が与えられず、早期品質改善の要望を満たせないためです。
Q: 聞取り終了前に暫定登録してはだめですか?
A: 可能ですがルール上の「遅くとも」の基準は聞取り終了時。暫定登録は必須ではありません。
A: 可能ですがルール上の「遅くとも」の基準は聞取り終了時。暫定登録は必須ではありません。
Q: “対応完了”との違いは何ですか?
A: “対応完了”は顧客対応が終わった状態で、他販売会社も閲覧・修正権限を持ちます。聞取り終了時点ではまだ対応中であり、“受付完了・対応中”を用います。
A: “対応完了”は顧客対応が終わった状態で、他販売会社も閲覧・修正権限を持ちます。聞取り終了時点ではまだ対応中であり、“受付完了・対応中”を用います。
関連キーワード: ワークフロー、アクセス権限、ステータス管理、情報共有
設問3:〔問合せ情報に対する権限〕について、(1)、(2)に答えよ。
(1)表2中の(a)(g)に入れる適切な字句を、解答群の中から選び、記号で答えよ。
なお、(a)(g)には同じ字句が入ることもある。


模範解答
a:ク
b:イ
c:イ
d:ア
e:ア
f:オ
g:オ
解説
解答の論理構成
-
自社販売会社の修正・削除権
・【販売会社からの新システムへの要望】
「自社で登録した問合せ情報は、登録後も自社で修正できるようにしてほしい。」
「…自社で登録した問合せ情報を削除できるようにしてほしい。」
よって、自社販売会社は基本情報・受付内容・対応内容を常に修正可。削除も常に可。
→ 修正セルは “X‧X‧X”、削除セルは “X‧X‧X” のパターン=ク(3段すべて X)。これが (a)。 -
他販売会社は閲覧のみ
・同要望の続き
「…他の販売会社が修正できないようにしてほしい。」
したがって修正・削除は “―”。閲覧だけ許可するパターン=イ(上段 X、他段 ―)。これが (b)(c)。 -
D社品質保証部門・製品部門の修正権
・【D社品質保証部門及び製品部門からの新システムへの要望】
「…販売会社が登録した受付内容及び対応内容を…D社が修正できるようにしてほしい。」
基本情報は要修正対象に含まれていないため修正不可、受付内容・対応内容のみ修正可。
→ 上段 X(閲覧可)、中段 X(修正可)は2段、削除は ― のパターン=ア。これが (d)(e)。 -
削除権のまとめ
・削除は「自社で登録した問合せ情報」のみ可。D社も他社も不可。
→ 自社セルは “X‧X‧―”=オ、他販売会社・D社セルは “―‧―‧―”=イ/ア。
これより (f)(g) はオ。
誤りやすいポイント
- “閲覧範囲が広がる” と “修正・削除権が広がる” を混同する。要望文では段階的公開は閲覧に関する記述のみ。
- D社が修正できるのは「受付内容・対応内容」限定で「基本情報」は対象外である点を見落とす。
- 選択肢の3段表示が何を示すか(上段=閲覧、中段=修正、下段=削除)を読み取れず、選択肢を逆に当てはめてしまう。
FAQ
Q: “対応ステータス” が “受付完了・対応中” になると何が変わるのですか?
A: 「新システムへの要望を踏まえて、対応ステータスを“受付完了・対応中”にすることによって、D社品質保証部門及び製品部門に必要な権限を与える」とあります。ここでの“権限”は閲覧権を指し、修正・削除の権限までは広げていません。
A: 「新システムへの要望を踏まえて、対応ステータスを“受付完了・対応中”にすることによって、D社品質保証部門及び製品部門に必要な権限を与える」とあります。ここでの“権限”は閲覧権を指し、修正・削除の権限までは広げていません。
Q: 基本情報をD社が修正してはいけない理由は?
A: 要望文に「受付内容…対応内容を…D社が修正できるように」と限定的に書かれているためです。基本情報は対象外であり、仕様として修正不可と整理します。
A: 要望文に「受付内容…対応内容を…D社が修正できるように」と限定的に書かれているためです。基本情報は対象外であり、仕様として修正不可と整理します。
Q: 自社販売会社の削除権はステータスに関係ありますか?
A: ありません。「…自社で登録した問合せ情報を削除できるようにしてほしい」とのみ規定され、ステータス条件は付いていません。
A: ありません。「…自社で登録した問合せ情報を削除できるようにしてほしい」とのみ規定され、ステータス条件は付いていません。
関連キーワード: アクセス制御、ディレクトリ連携、クラウドサービス、決定表、ステータス管理
設問3:〔問合せ情報に対する権限〕について、(1)、(2)に答えよ。
(2)D社品質保証部門及び製品部門から、問合せ情報の担当者を閲覧可能とした理由を、40字以内で述べよ。
模範解答
D社が問合せ顧客に直接聞取りするために、担当者に連絡する必要があるから
解説
解答の論理構成
- 顧客情報の非開示要求
販売会社側は「問合せ顧客」の情報について「機密性が高いので、D社及び他の販売会社へ開示しないでほしい」と要望しています。 - D社側の業務要件
一方で、D社品質保証部門及び製品部門は「複雑な問題の場合、D社が直接顧客から問合せの詳細を聞取りしたい」と要望しています。 - 仲介者としての担当者
顧客情報を開示しない方針を守りつつ D社が顧客へアプローチするためには、まず販売会社の「担当者」へ連絡し、顧客の同意取得や日程調整を依頼する必要があります。 - 権限設定の帰結
以上より、D社が担当者情報を閲覧できなければ直接ヒアリングを開始できません。そこで決定表では D社品質保証部門及び製品部門に「担当者」情報の閲覧権限を付与しています。 - したがって模範解答どおり「D社が問合せ顧客に直接聞取りするために、担当者に連絡する必要があるから」となります。
誤りやすいポイント
- 顧客情報と担当者情報を混同し、「顧客連絡先を見るため」と答えてしまう
- 「品質保証部門が原因分析を行うため」とだけ書き、担当者連絡の必然性を示さない
- 問合せ顧客の情報を“開示する”方向で理由を作ってしまい、要望と矛盾する
FAQ
Q: なぜ D社は直接顧客に聞取りしたいのですか?
A: 重大・複雑な不具合の場合、一次情報を迅速に収集して原因究明や設計改善につなげるためです。
A: 重大・複雑な不具合の場合、一次情報を迅速に収集して原因究明や設計改善につなげるためです。
Q: 担当者情報に閲覧権限を付けると個人情報リスクはありませんか?
A: 閲覧できるのは D社品質保証部門及び製品部門に限定され、アクセスログや閉域網での通信により不正利用を抑止します。
A: 閲覧できるのは D社品質保証部門及び製品部門に限定され、アクセスログや閉域網での通信により不正利用を抑止します。
関連キーワード: アクセス権管理、個人情報保護、業務要件定義、利用者権限、情報共有


