機密情報とは、ここでは 社外に出せない情報全般 を指します。従業員の個人情報や顧客の個人情報といったセンシティブなものもありますし、インサイダーに繋がるような未公開の重要情報もあれば、単に社内で決めただけのルールやプロセスもあったりします。
クラウドにば置けないとか、生成 AI サービスは使えないといった文句は、エンジニアなら一度は聞いたことがあるでしょう。
なぜでしょうか。本当に置けないのでしょうか？
実は、単に過保護なだけだったりします。辛辣に言えば、大したことがない情報なのに、なぜか頑なに外に出すことを拒む。まるで箱入り娘のように。
もちろん本当に出せない重要な情報やセンシティブな情報も多いですが、そうではないものも多いはず。にもかかわらず、社内で扱う情報＝センシティブ＝外に出さない、と決めつけているのです。.gitignore を知らないようなものです。過保護は非常に古典的かつ融通が利かない、悪しき文化ですらあります。だってそのせいでクラウドが使えないのですから。Webサービスが使えないのですから。
機密情報の過保護はやめましょう、と提案したいです。また私がナレッジ・アーキテクトとしてお客様の課題に取り組む際も、高確率でこの提言を言います。
では、過保護を減らすにはどうすればいいか。かんたんな話で、次の二点です。
.gitignore と同じです。外に出したくないものを特定して、指定するだけです。この拒否リストを 保護ポリシー と呼ぶことにします。
保護ポリシーは二段構えにします。
つまり最低限全社レベルのポリシーは存在しており、これは守らねばなりません。言い換えると、全社レベルのポリシーさえ守っているのなら、他は外に出してもいい（クラウドに置いたり生成 AI に入れたりしてもいい）わけです。
ただし、これだけだと現実的な運用ができません（チームや PJ ごとに扱う機密情報は違います）ので、個別のポリシーもつくれるようにします。それが 2: です。
ちなみに、保護ポリシーをちゃんと機能させるには、1: の全社レベルをどれだけ緩和できるかにかかっています。そもそも全社レベルのポリシーが厳しいものを過保護と呼んでいます。
このような過保護と保護ポリシーの話は、顧客にも提案できます。というより、まともにエンジニアリングするために、ぜひとも積極的に提案して、一緒にポリシーをつくりこんでいくのが良いとさえ言えます。専門的にはナレジャーが担うこともあります。あるいは、ソフトウェアエンジニアが担えるようにトレーニングもできます。
顧客の過保護を軽減できない場合、その先に待つのは地獄です。過保護前提でエンジニアリングをしなければならないからです。無駄に大きな開発が発生したり、別に守らなくてもいいものに過剰なセキュリティを構築したりします。無論、コストや期間の形で膨らみますから、顧客としても印象がよろしくない。それをセキュリティだから、機密情報だから、の言い分で正当化する――。
地獄はもうコリゴリだというのなら、ぜひ過保護を軽減することを考えてみてください。