外部の人間が企業のシステム構築に関わると，好むと好まざるにかかわらずその企業の機密に触れることになる。NDA（Non-Disclosure Agreement：機密保持契約）を交わすのは当然のことであるが。悩ましいのは現場の運用ではないだろうか。

　ある通販会社の基幹系システム再構築で，既存システムの全画面のレイアウトや機能に関する調査がはじまった。調査対象画面数は300近くになったが，そのすべてについて実画面を使った説明資料が用意され，提供されることになった。ユーザー側の担当者は，画面資料の扱いに細心の注意を払い，表示項目中のテキストをチェックして，不適切を判断された場合はすべてダミー情報に書き換えられた。

　ユーザー側としては，顧客情報を含む機密に関する情報はすべて削除あるいは書き換えたものを提供する，という姿勢で臨んでいたが，資料の引渡しの段階になってちょっとした問題になった。

　この資料は持ち出してもらっても構わないが，他の資料については確認していないので持ち出しは許可できないという。ところが，どの資料は大丈夫で，どれは駄目なのかを特定するのは事実上困難である。ユーザー側にしてみれば，調査がスムーズに進むためにできるだけ便宜をはかりたい，という思いがあり，一方で機密情報の管理の手は抜けないという事情もある。担当者がその板ばさみになっている様子がうかがい知れた。

　私はユーザーにちょっと意地悪な質問をしてみた。「大丈夫と言われる画面資料中に顧客情報が残っていたらどうされますか」ユーザーの答えはこうだった。「十分チェックしたのですべて削除したので大丈夫です。しかし，今後作成する分についてはなんともいえません。こういう場合，きちんと分けるのがいいんでしょうか？」私はこう申し上げた。「すべての資料に，顧客情報を含む機密情報が含まれていると言いきってしまえばいいんですよ。ベンダー側としても，そう言い切ってもらった方が体制をつくりやすいと思いますよ。見落としがあった時のフェイルセーフにもなります」

　このプロジェクトでは以下のようなルールと運用方法を決めた。


・ユーザー側は提供資料に機密情報が紛れ込まないようにする。
・ベンダー側はすべての提供資料に機密情報が含まれるとして扱う。
・顧客側にオフィス内に設置したプロジェクト・ルームに資料ライブラリを用意した。
・提供資料はすべて資料ライブラリに保管し，全ドキュメントの台帳を作成した。
・ドキュメント台帳には，資料のタイトル，出典，サイズ，ページ数，内容の概要を記述した。
・資料の閲覧はプロジェクト・ルーム内で行うようにした。

　このプロジェクトではこのやり方が最適かどうかはまだ最終的な答えが出ていないが，いくつか副次的な効果が出てきた。まず，台帳を見たユーザーが，漏れている資料があることに気づいて追加してくれた。情報管理がしっかりなされている様子を見たユーザーが，情報開示に難色を示さなくなった。資料が一元管理されるようになったことと見やすい台帳ができたおかげで，詳細設計段階にはいってからも確認作業がしやすくなり，いちいちユーザーに問い合わせて資料を出してもらうという手間が減った。ライブラリが整備されて使いやすくなってきたため，ベンダー側がこれまで預かっていた資料をすべてライブラリに移動させたので，社外に出ている資料がなくなった。

　情報セキュリティの管理は仕事を進める上ではオーバーヘッドになる。かといって手を抜いてリスクを増やすわけにはゆかない。今後も，リスク管理と仕事の効率性・効果性の両方に役立つアイデアがあったら，どんどん学んで実践したみたいと思っている。

●編集部からのお知らせ

木村哲氏による書籍「本当に使える要求定義」を発売しました。このブログの1回目を執筆中にゲラのチェックをしていると紹介されたものです。要求定義にまつわるエピソードはもちろん，成果物のサンプルやプロセスマップなど実践的なノウハウが満載です。要求定義に苦労している人や自分のやり方が正しいかどうか知りたい人は，是非こちらをご覧ください。