| 設問ア | あなたが携わったシステム開発プロジェクトの概要と、その中で機密として管理した情報を、理由や機密度とともに800字以内で述べよ。 |
|---|---|
| 設問イ | 設問アで述べたプロジェクトにおける機密管理のルール、及びルールに従って運用するための日常管理について、あなたが特に工夫した点を中心に、具体的に述べよ。また、漏えい時の影響を少なくする対策は何か。簡潔に述べよ。 |
| 設問ウ | 設問イで述べたルール及び日常管理について、あなたはどのように評価しているか。また、今後どのような改善を考えているか。それぞれ簡潔に述べよ。 |
１．プロジェクト概要と機密情報
１．１．プロジェクト概要
私が関与した情報システム開発プロジェクトはオンラインショップA社のマーケティングシステムである。A社は顧客の購買履歴やアンケート回答を元に適切な商品を推奨するオプトインメールを配信することにより、広告効果を上げることを計画していた。顧客データベース及び販売データベースから得られたデータをもとに、優良顧客情報デーベースを作成し販売促進対象となる顧客を抽出し、オプトインメールを配信する。
本システムはルータ、Webサーバ、アプリケーション（AP）サーバ、データベース（DB）サーバによって構成されている。AP開発はサービス指向アーキテクチャ（SOA）に基づき実施する。開発期間は10ヶ月と短い。
本システムの開発は、私の勤務先であるシステムインテーグレータが受託し、私がプロジェクトマネージャとしてアサインされた。開発メンバは私を含め、10人である。AP開発者、DB技術者、ネットワーク技術者から構成され、半数が協力会社要員であった。今回、協力会社とは請負にて契約を締結しているが、機密情報を取り扱うため、作業場所をＡ社内とした。
１．２．機密情報
本プロジェクトで機密として管理した情報はシステム構成情報、顧客情報、配信ルールである。顧客情報と配信ルールはシステムの開発・テストを行う上で必要になる情報である。依頼主であるA社とは受託契約において機密保持契約及び損害賠償責任を定めた特約を締結している。このため、開発プロジェクトから機密が漏洩した場合、損害賠償請求を受けることになる。
顧客情報は個人情報であり、最重要の機密情報として関係者外秘とする。個人情報に対する関心が社会的に高まり、個人情報保護法施行が迫っている時期であることを受けてのものである。
配信ルールはその次に重要な機密情報とし、同じく関係者外秘とした。これはA社顧客の購買履歴等に基づくもので、A社の企業秘密であるためである。
これら関係社外秘のアクセスに必要なパスワード等も関係者外秘情報と同等の扱いとした。もしパスワードが関係者外にもに共有されたら、メンバーの誰もが該情報にアクセスしうることになり、該情報を少数限定者のみ開示と規制した意味が乏しくなるためである。
最後にシステム構成情報や各種ドキュメント（WBS、要件定義書、設計書、仕様書）はプロジェクト外秘とし、プロジェクト内で共有した。システム構成情報を記述するドキュメントには弊社のノウハウが含まれており、その流出は弊社の競争力低下要因となるためである。
２．機密管理のルールと日常管理
２．１．機密管理ルール
機密情報については極秘・厳秘等の名称によりランク分けして扱いを定める方法がある。しかし区分の細分化や用語の微妙な違いでの区分は不明確になりやすく、官僚的形式主義に陥りかねない。また、細かくわけたとしても、全ての情報を最重要の機密にしてしまいがちで、結果として適切な機密管理にならないことも多い。このため、本プロジェクトでは公開情報、社外秘、部外秘、プロジェクト外秘、関係者外秘と開示対象で区分けすることを顧客に提案し、採用された。
本プロジェクトで特に注意を要するのは関係者外秘の情報である。これはプロジェクト内でも限られたメンバにのみ開示される情報である。顧客情報はデータクレンジング（名寄せ）機能のテストのように実データでなければ効果的でない場合にのみテストデータとして使用する。それ以外の場合には開示せず、自作データやマスク処理をかけたものを使う。
配信ルールはシステム開発の必要上、開示対象となる関係者の範囲は顧客情報よりも広くなる。同じ関係者外秘情報であるが、この点で扱いを異にする。但し開示する場合も、機能毎に必要な分だけ開示し、全体を開示しないようにする。
２．１．１．アクセスコントロール
機密情報を格納した電子ファイルについては、OSのアクセスコントロール及び暗号化ソフトの複号化パスワードにより、二重のパスワードで保護する。これにより、容易にアクセスできないようにする。
①機密情報を格納するディレクトリはアクセス規制をかける。パスワードは定期的に変更する。OSのパスワード機能を利用するだけでなく、DBMSのGRANT文などによるアクセス管理も実施した。
②暗号化ソフトを使用してファイルを暗号化する。
２．１．２．作業管理
最重要機密である顧客情報を扱う場合のルールを下記のように定めた。
①事前にプロジェクトマネージャ宛てに使用許可申請を行う。この際、オペレーションレベルの作業手順書を予め用意させる。
②一人での作業は禁止する。必ず複数人で実施する。
③作業終了後、ローカルマシン等に機密ファイルが残っていないか、別人が確認した作業報告書を提出する。
許可申請と立会は一般的なルールであるが、これだけでは形骸化してしまう恐れがある。そのため、作業書を用意させた。牽制を目的とした立会者の立場上、実作業者が今何をやっているのか、機密情報を詐取するための作業を行っていないか、などを確認する上で有効であるためである。
２．２．ルールの周知徹底
本プロジェクトではルールを周知徹底させるため、教育などを通してプロジェクトメンバーの機密管理意識向上を企図した。
①本プロジェクトでは個人情報を扱うため、全メンバに社内で実施している個人情報保護に関する研修を受講させた。
②メンバ一人一人から機密保持に関する誓約書を提出させた。誓約書は一月毎に更新する形にし、一度出したら終わりではなく、継続的に意識させるようにした。
③協力会社との請負契約にはNDA条項を含める。また、協力会社要員が上記①②に従うことも契約に定める。
④請負契約では委託者が受託者の作業状況を直接管理しないのが原則であるため、委託者が監査権限をもつことを特約として定める。
２．３．日常管理
ルールは定めるだけでは意味がない。プロジェクト実行時にはルールに従って運用されているか、ルール逸脱や漏えいが発生していないかを定期的に確認する必要がある。以下の活動を実施した。
①申請書提出のない作業は認めない。
②各人の日報を定期的に精査し、機密情報を扱う作業を単独で行っていないか確認する。
③時には機密情報を使う作業にリーダークラスのメンバが立ち会い、作業終了後に機密情報を残していないことを実際に確認する。
④機密情報ファイルのあるディレクトリへのアクセスログを定期的に監視し、異常・不正なアクセスな存在しないか確認する。ツールの利用により、ログの取得だけでなく、収集・分析・管理までを完全システム化し、管理者の負担を軽減した。
２．４．漏えい時の影響を少なくする対策
情報セキュリティの世界では、基本的に100％効果のある対策はない。そのため、漏えい時の影響を少なくする対策も検討する必要がある。情報を格納した媒体が流出したとしても、情報の内容自体は。漏えいを回避軽減する対策として以下を採用した。
・機密情報を格納したファイルを暗号化することで、漏えいした場合でも悪用される危険性を低減させた。
・複号化パスワードは機密情報毎に設定し、一つのパスワードが漏えいしても他の機密情報には影響を与えないようにする。
・USBメモリの利用は指紋認証機能付きのもののみを許可した。これにより、万が一、USBメモリの紛失、盗難が起きても情報の漏洩には直結しない。当初は、開発要員のPC端末のUSBポートを無効化し、USBメモリへの格納による持ち出し防止を考慮したが、利便性を著しく損ねるため、前述の方策に改めた。
一方、機密情報が漏えいしてしまった場合の対策として損害の転嫁策がある。協力会社との請負契約中に受託側の過失により、機密情報が漏えいした場合の損害賠償条項を盛り込んだ。また、個人情報保護保険にも加入し、リスクファイナンスを図った。
３．評価と改善
３．１．評価
本プロジェクトでは情報漏えい事件が起きることなく、スケジュール通りに無事完了した。上述のルール及び日常管理が機密管理上、有効かつ実現可能なものであったと考えている。また、本プロジェクトでの機密管理ルールは社内でも評価され、社内プロジェクトにおける標準ルールに取り込まれる予定である。
３．２．改善
本プロジェクトでは全メンバ（含協力会社要員）に個人情報保護に関する研修の受講を義務付けたが、個人情報保護法施行前であったこともあり、研修実施部署の体制が十分ではなく、多少の混乱が生じ、実施が遅れてしまった。法施行により個人情報保護の重要性は益々重要になっている。個人情報を扱うプロジェクトにおいては必須とすることで、この問題は改善されていくものと考える。
加えて今回の機密管理ルールは協力会社にも多くの協力、負担を求めるものであったため、当初は戸惑いもあった。機密管理ルールに協力的かという観点からの協力会社の再評価・再格付けの手続きも有効であると考える。
２ 請負契約における品質確認
2.1 品質目標の設定
2.1.1 システム特性
本システム開発は、WWWサーバベースの開発であること。また、弊社の得意なデータベース技術を利用できることなどから、バグの多さなどの品質よりも、むしろ依頼主であるＡ社の業務要件を満たすことのできるかどうかが品質管理が主目的となる。
2.1.2 品質計画
そこで、私は品質計画書で次のような、品質目標を立案した。①Ａ社の業務ノウハウをすべてグループウェア機能として実装すること、②Ａ社の要求する基本機能はすべて実現すること、③要件品質の確認方法としてスパイラルアプローチを採用すること、④Ａ社とのスパイラルによる品質確認は2回を限度とすることとした。また、これらの要件品質の向上には協力会社の協力も必須と考えた。そこで、B社との契約作業の期間中に設計書レビューを含めた打ち合わせが必須と考えた。
2.2 品質の確認事項
以下の手続きは当社の品質保証マネジメントシステムに沿って実施される。
(1)ユーザとの打ち合わせ会議への参加
ユーザニーズのヒアリングと、品質に大きな影響を与えるであろう、ユーザ要件と技術的な課題についてA社、弊社、B社とのメンバを交えてA社のヒアリングを行う。品質やコストは上流工程から意識したほうが効果的であるからである。
(2)弊社とB社との打ち合わせ会議
A社システム開発の課題についての認識の共通化を目的として、打ち合わせ会議を開催。ユーザ要件に合わせて私はプロジェクト開発計画書と、品質計画書をB社に提示、その方針を徹底し、B社への請負範囲の確定と検収手続き及び検収基準を定める。
(3)契約面での配慮
契約書中に、①サブシステムの設計結果の2週間間隔での中間成果物提出、②中間成果物に対する当社スタッフとのミーティング（ウォークスルー、質疑応答など）の実施、③事前のB社の品質保証体制の提出、④それに基づく、依頼1ヶ月を経た時点での品質保証体制の監査権限を定めた。
2.2.1 確認事項の詳細
要件品質の確認事項については、B社リーダC氏と以下の点で合意した。
(1)確認時期：概要設計書作成終了後と詳細設計書終了後の2回、また、上記の品質確認状況に応じて追加確認時期を設定できるとした。
(2)中間成果物：概要設計段階で提出をうける成果物は、DFD,E-R図、機能要件階層図等の文書と画面・帳票プロトタイプである。また、詳細設計段階の提出成果物は物理データベース構造やDDL関連等の文書である。
(3)確認方法：中間成果物の確認方法は以下の通りである。
①文書レビュー：ユーザＡ社を含めた設計書レビューを実施する。
②プロトタイプ：ユーザＡ社の業務担当者の操作確認を得てプロトタイプレビューを実施する。
(4)検収基準の明示：プロジェクト計画書に定義した品質要件、標準化要件、機能要件を成果物の検収基準とする。
(5)業務ノウハウ理解：業務ノウハウに乏しい弊社スタッフに対して、理解可能な概要設計書を提出する。また、当社からの会議における質問には誠意を持って回答する。
(6)開発体制の監査：事前にB社の品質保証体系図とプロジェクト組織図及び、顧客窓口と連絡先及びC氏が管理者となっている権限分掌規定の提示を求めた。そして工程の内部監査の実施をB社の努力義務とした。B社の開発1ヵ月後に、その品質保証体制について、弊社プロジェクト計画書に対する準拠性を監査目標としたシステム監査の実施とその受け入れ態勢を確認した。
2.2.2 私の実施した品質確認上の工夫
今回のプロジェクトの品質確認上重要なポイントは下記である。
①Ａ社要件を網羅的に実現している。プロジェクト計画書の要求事項を満たしている。RFPに定義された機能要件、性能要件をすべて満たしている。
②業務特有な複雑な処理系について正確に定義している。
③設計書に基づいてソフトウェア開発を実施した場合、技術的問題解決は可能である。
そのために私は次の点に留意しつつ、品質確認作業を進めていった。
(1)可視化技法の適用による理解の正確性確保
画面や帳票と業務プロセスとの関連性を状態遷移図やDFD等を使って明示することにより、A社、B社相互の要件定義に対する設計の準拠性、関連性を確認することができる。
実際問題として、テキスト情報だけでは意思疎通は難しいことがある。これはコミュニケーションの重要なポイントであり、図表など、様々な表現手段を使って初めて意思疎通を実現できる。
(2)チェックリスト利用
Ａ社要件を階層的チェックリスト化し、業務要件の漏れ、例外事項の漏れがないように配慮する必要がある。
(3)上位ドキュメントへの準拠と活用
業務要件のチェックリスト作成にあたっては、要件定義書、ユーザとの打ち合わせドキュメントを活用した。
(4)用語の標準化の徹底と合意の形成
例えば、「手順」「作業」などのように一般名詞化された用語の意味を取り違え、ユーザの意図しないシステムを構築してしまうことが良くある。このため、要件定義書の段階であらかじめ用語を定義するようにした。さらに、A,B,弊社の3者レビューで顕在化した疑問点は解決し、合意する必要がある。
(5)会議時間の有効活用
レビュー時は品質課題の抽出に力点を置き、その修正案、対策案の考察は配慮外とする。また、レビュー対象ドキュメントを事前に資料として配布して、技術上の課題を質問できるようにする。
3 評価と改善
3.1 評価
3.1.1 品質目標の達成
当初、A社が弊社と打ち合わせ時に計画していた機能はすべて網羅的にグループウェアの中に盛り込まれた。システム監査やレビューの実施によって、品質は検収基準を満たすことができた。
また、プロトタイプ実施によって、①潜在的にニーズも吸収できた。②さらに、操作性、画面遷移の適合性の検証も行うことができた。
3.1.2 請負先B社のコントロール
契約前に設計レビューを合意事項として盛り込むことができたので、協力会社統制が円滑に行うことができた。
3.2 改善
3.2.1 ユーザ錯誤による誤った業務定義
３者レビュー時に、弊社作成のDFDに誤りがあることがA,B社相互から指摘がなされた。これは、DFD定義を行う際に、A社が例外業務を定義し忘れたことが原因だった。
ユーザ定義が誤っていても、複雑な業務系列の場合、弊社では正誤の判断がつかない。このような課題の解決方法として、ユーザ定義再確認プロセスが必要だろう。
3.2 フォローアップ監査の必要性
プロジェクト期間が長く、協力会社への依頼期間が長い場合、一度の監査と改善勧告 だけだけは不十分で、当社が指摘したことが開発工程に十分、反映されているのかを再度、フォローアップして確認する必要がある。
プロジェクトの遂行時には、これらの問題の解決が遅れたり、不十分であったりすることがある。また、利用部門、プロジェクトメンバーおよび関係者の各々にそれぞれの都合や思惑がある場合、これらをうまく調整しなければならないため、プロジェクト運営は厳しくなる。その結果、例えば、要件定義が確定しなかったり、設計品質が低下したり、進捗が遅れたりするなどのプロジェクト全体に波及する問題になることがある。
プロジェクトマネージャは、プロジェクトの立上げ時に抱えていた問題から波及するおそれがあるプロジェクト全体の問題を事前に想定し、その兆候を早期に発見することが重要である。そのためには、プロジェクトの立上げ時に抱えていた問題に応じて、例えば次のような項目の傾向を分析することが重要である。
・要件に対する質問への回答の遅れ日数
・要件定義の変更回数
・仕様確定予定日との相違日数。監視項目としては、それぞれの仕様項目毎の確定時期マイルストーンを定め、これからの遅延日数を監視する。管理目標は現時点から全項目最終確定予定日までの余裕日数に応じた係数をかけ影響度を加味して目標値を定め、これからのしきい値を超えた場合に対応計画として準備した対応策を講じるよう考慮した。
・仕様変更処理に要した日数。仕様変更が発生してから設計書に反映されるまでの日数を監視する。管理目標は前項と同じ設計完了予定日までの余裕日数に応じた係数に加え、変更による波及程度の影響も加味した値を定め、これからのしきい値を超えた場合に準備した対応策を講じるよう考慮する。
・設計書と仕様書との間の相違割合と確認網羅率。仕様と設計書との項目毎の確認回数と相違個数を監視項目として定めた。管理目標としては各仕様項目ごとに確認の網羅具合や相違数のしきい値として定めた。
・設計レビューの指摘件数
・兼任している要員の作業負荷
進捗管理においては、プロジェクトの各作業やイベントの進捗を正確に把握して、状況に応じて適切な対策をとる必要がある。一般的には進捗報告によって進捗度を把握し、遅れが見られる場合には遅れの原因を分析し、遅れを回復するための対策を講じるという手順で行われる。
進捗の遅れに対して適切な時期に有効な対策を講じるには、正確な進捗度の把握が前提となる。プロジェクトの作業やイベントの進捗状況を正確に把握することで、適切な対応策を講じ、対応策に優先順位を付けることが可能になる。
プロジェクトの進捗度を把握する技法には以下がある。
定期的に進捗会議を開催し、プロジェクトメンバから作業実績を報告させる。比較的少人数で小規模なプロジェクトの場合、進捗会議で十分に進捗を把握できる場合が多い。但し実際に問題があっても、報告では「大丈夫です」と回答してしまう開発者も少なくない。それで安心してフォローをしないと、結果的に低水準の製品を期限遅れで提供することになってしまう危険がある。メンバーに進捗を聞く際の聞き方には注意する必要がある。自分の進捗がプロジェクトにおいて非常に重要であるということを上手に伝えながら、曖昧な部分が残らないように聞くとよい。
残件リスト、問題リストを作成する。
差異分析によって計画と実績の差を分析し、計画に対する実績のズレを正確に把握する。
アーンドバリュー分析を用いて、スケジュールとコストの二つの観点からの目標達成の見込みを把握する。コストとスケジュールを厳密に管理しなければならない状況に適している。
仕様確定作業において、仕様確定時点で初めてマイルストーンからの相違を見るだけではなく、それまでの進捗から予測される確定予定時期との相違についても適時監視し、その傾向を分析することで遅延が表面化する前に兆候の早期発見と対応を行う。
仕様打合せや、レビュー時の記録は主催側が作成するだけでなく、それぞれの関係者がそれぞれで作成しPMに提出する。これらの記録で各関係者間での相違を分析し、それぞれの考え方、捉え方の相違によるリスクを早期発見する。関係者間での立場や体質の相違による共通認識すべき項目の独自解釈や思い込みの解消に有益である。
PMは個別プロジェクトの特徴（対象プロジェクトの規模、ステークホルダーの要望等）を鑑み、プロジェクトの計画段階で進捗度を把握する適切な技法を選択する。進捗報告のルールや頻度を設定し、プロジェクト内で周知徹底を図って、選択された技法に沿って適切に進捗度を把握する。
進捗度の把握によって遅れの発生を認識した場合は、その原因を究明し、予め設定した余裕期間で吸収できるかどうか判断する。必要に応じて遅れを回復するための対策を講じなければならない。その際に進捗度の把握が迅速で有効な対策に結び付けられるよう工夫する必要がある。
特に，システム全体の稼動開始前に一部のサブシステムの稼働開始時期が決められている場合や，利用部門から開発期間の短縮を要求されているような場合などは，プロジェクト全体のスケジュール作成に様々な調整が必要となる。このような場合，システム開発標準で定められたタスクや，類似プロジェクトで実績のあるタスクとそれらの実施順序を参考にしながら，タスクの内容や構成，タスクの実施順序を調整して，スケジュールを作成 しなければならない。
その際，全体レビューや利用部門の承認などのように，日程を変更できないイベントやタスクに注目するとともに，次のような観点でスケジュールを作成することが重要である。
・タスクを並行させて実施することが可能な場合には，タスク間の整合性をとるための新しいタスクを定義する。
・長期間かかるタスクの場合は，サブタスクに分割し，並行させて実施したり，実施順序を調整したりする。
・高い応答性が求められるような業務の場合、最も要求の厳しい処理について開発を行い、求められている機能や性能を実現できるか評価する。
・開発環境に制約があったり、新しい開発ツールを使用したりするような場合、準備した開発環境や開発ツールが本開発に耐えられるか評価する。
・全社で使用するシステムを開発する場合、最初に一部の部門にシステムを導入し、運用面で問題がないか評価する。
パイロット開発では、このような評価を確実に行うために、システムや業務の特徴を踏まえて、パイロット開発の対象となる処理の切出し、応答時間の目標値の設定、確保すべき品質要件、開発環境の準備、部門の選定などについて、様々な工夫を行う必要がある。
全てのリスクに対してパイロット開発を行い、リスクを低減することは、コスト・スケジュールの観点から現実的では無い。パイロット開発で取り組むべき対象を絞り込むため、リスクを再評価する必要もある。
パイロット開発の必要性は、システムアナリストや上級シスアド・プロジェクトマネージャが判断するが、実際に開発を行うのは、アプリケーションエンジニアやソフトウェア開発技術者の役割である。従って、アプリケーションエンジニアとしては、パイロット開発が必要と判断された背景・目的を正確に理解して、効率的に実装・結果の収集を行わなければならない。
業務プロセスの「あるべき姿」は、一般に他社の先進事例や成功事例、ベストプラクティスなどを参考にして、新しい業務プロセスとして設計される。国内外で同様の改革を行っ た会社について調査し、参考にした。この時、他社の事例がそのまま自社に適用できるとは限らないため、自社の強みを意識し、この強みが生きるようにする。
改革の立案に当たって、システムアナリストは、新しい業務プロセスと現状の業務プロセスとのギャップを整理し、次のような点を重視して、ギャップの克服や解消のための対策を講じる必要がある。
・ギャップの原因になっている現行のビジネス慣習や組織などを調査・分析し、問題点の本質と対策のポイントをつかむ。現場のキーパーソンにヒアリングを行い、現状の業務プロセスをまとめ図にする。ヒアリングは、ヒアリングの意味と結果が今後にどのように反映するのかを説明し、理解を得てから実施した。
・新しい業務プロセスを実現するために、情報技術の最適な活用を検討する。
・経営者やマネジメント層と業務プロセスの改革の狙いやリスクを共有し、トップダウンで進めるべき事項を明確にし、その進め方を検討する。社長をはじめとする経営層へのインタビューを行い、理想像を固めていく。
具体的には、組織や管理レベルごとの活動目標に関するKPI(Key Perfomance Indicator) などの業績評価指標を設定し、達成度の把握に必要なデータを収集し、加工・編集するシステムが考えられる。業績評価指標としては、事業単位別・顧客別の売上高や利益率、生産リードダイムや納期遵守率、製品の不良率や顧客からのクレーム数などがある。このような業績評価指標を総合的に取り扱うシステムを立案する場合、システムアナリストは、業績評価指標の使用目的や用途を理解し、必要となるデータやその特性を確認した上で、タイミング良く提供するために、次のような工夫を行わなければならない。
・豊富なデータソースからデータを収集，連携するための仕組み
・必要なデータが既存のシステムにない場合の代替案や新たなデータ収集の仕組み
・データの収集を早めるためのデータ発生・入力部門との調整や業務処理の変更
・データの加工を速めるための二次データベースの構築
・必要な人に，分かりやすい形でタイミング良く提供する仕組み
・システムが経営環境の変化に追従し，効果的に利用される仕組み
SOAを実現するWebサービスなどのテクノロジーも重要であるが、サービス指向設計などの開発プロセスや、企業内・外の標準化とそれを遵守するための組織的な運用も重要になる。全社的なコンポーネント、サービス、ネーミング、ディレクトリーなどの管理や運用なども考えていく必要がある。
新規アプリケーションだけではなく、既存のアプリケーション資産もビジネス統合の重要な要素になる。できるだけ変更を伴なわずに既存のアプリケーションを統合するためには、アダプタによってサービス化する等の方法がある。各サービスをビジネスの流れに沿って実行させるには、ワークフローのようなビジネスプロセスを制御する仕掛けが必要になる。