企業ITの6大要素について、今回はIT法務・認証取得・セキュリティを説明します。法務部門とIT部門のコミュニケーションが悪い事案を多く見てきました。多くは、法務部門がこれから導入するITの技術的な中身を理解していないために起こっている事案で、その反対側では、IT部門の法務部門への丁寧な説明が足りていないという、いずれもコミュニケーション不足による事象が多いように思います。知財の帰属IT法務において、私たちが一番重視視しているのが契約上の知財の帰属です。実はここが曖昧であったために、事業会社とITベンダーが後々になって揉めるケースが多くなっています。IPOプロセスにおけるIT内部統制の中で問題になります。ITシステムをオーダーメイドでフルスクラッチ開発する場合と、クラウドサービス(SaaS)を利用する場合で考え方が異なります。前者の場合、事業会社で発注をし費用を支払った部分においては、基本的には当該知財(開発したソフトウェア)が発注側、つまり事業会社に帰属するように基本契約書のルールを社内で明確に確定させておく必要があります。ところが、事はそう簡単ではありません。開発会社は、工期を短縮したり、効率化をするために、自社独自のコンポーネントやサブルーチンなどを材料として利用する場合があります。それが埋め込まれた上で、システム全体が納品物として完成しますが、この材料としてのコンポーネントやサブルーチンについての権利もしっかりと発注の時点で処理をしておかないといけません。将来ベンダースイッチが発生した時などに、システムリソースが引き継げず、結局ゼロから開発し直す必要が出たりと、IPOプロセスを大きく遅延する問題になります。IPOの予定がなければこの問題が発生しないわけではなく、どの企業においても、将来のどこかの時点でこの問題は発生します。開発会社の立場に立てば、当該材料の権利を手放し、それが将来ベンダースイッチの際に競合たる別のベンダーに渡ってしまうのはどうしても避けたいものです。したがって、開発会社の知財を使わずに開発するように求める必要が出てくる可能性もあります。当然ですが、その場合工期や開発費が余分にかかるので、投資対効果を検討しなくてはなりません。してもコンポーネントやサブルーチンなどを利用したい場合は、将来起こり得るベンダースイッチを想定した開発ベンダーとの議論が必要です。すると当該材料を事業会社が他社に販売しないことを約束したり、次のベンダーがこれを外販しない約束を事業会社に取り付けたりと、将来の約束をペーパーワークする必要が出てきます。SaaS利用の場合は、約款を個別にカスタマイズすることは不可能です。Agreement)を個別に変える交渉ができるはずもありません。これまでも、皆さんが、Microsoft製品を使う際に、個別に約款の変更をMicrosoftの法務部門に求めないのと同じ構造です。そもそも、以前ポストした通り、自社の知財を含めた、顧客のビックデータまでもを自分の資産とすることで、ビジネスが成り立っているのがクラウドサービスのビジネスモデルです。そのためSaaSを使う際は、これらの約款やSLAをしっかりと検討し、自社の業務へのリスクと支障をIT部門だけではなく、経営を巻き込んで議論する必要があります。昨今、どんな企業でも顧客情報などの個人情報を扱うことが多くなりました。IT前提経営の6大要素の中にも「AI*BigData*IoT」がありますが、個別にAIやビックデータを使った分析をせずとも、CRMのクラウドサービスを月々数万円支払って利用し、顧客データを管理する企業は沢山あると思います。なれば、これらの顧客データの管理をしっかりと行っていることを対外的に証明する必要が出てきます。個人情報で言えば、個人情報保護法に連動するプライバシーマークの取得はその一つの手段だったりします。IPOを目指す会社の情報システム部門が、セキュリティーを含めたITシステムの健全性を対外的に証明するためにISMSを取得することも一般化しました。これらはIPOしない企業にとって無意味だと指摘する人や、印籠のようなものであるという批判も多いことは知っています。一方で、顧客のプライバシー管理が重要なことは事実であり、情報システムの健全性が一定以上であることは、顧客のみならず、事業会社のステークホルダーにとっても重要な要素です。複雑怪奇になった業務フローの効率化に、何度もチャレンジしたが頓挫してしまった経験がある会社は、ISMSなどの認証の取得・維持を目的として、認証取得のコンサルティング会社に手伝ってもらい、その結果として業務フローが明文化されることを目指すようお勧めすることがあります。この場合重要なのは、ITシステム部門だけでこれらの認証の取得をやらないことです。いうのが、私がIT前提経営と言っている通り、現代の企業の業務フローのほとんどはITシステムによって処理されています。認証を保持するのは法人です。名刺にも認証ロゴが印刷されるかもしれません。あれば、全社をあげて、それぞれの業務部門長が我が事として、参加できるバーチャルオフィスを立ち上げ、ここで認証取得を目指すのが理想系なのは言うまでもありません。その際、業務システムに詳しいIT部門もそこに参加することは重要です。Standardの考え方を推奨してきました。これは、私たちが勝手に主張している訳ではなく、経済産業省などの役所も「クラウド・バイ・デフォルト宣言」や「2025年の崖」を発表するまでになっています。Standardであるべきだと考えています。SaaSを利用すれば、当該SaaSのSLAに準拠せざるを得ません。APIエコノミーのポストで説明した通り、SaaS同士をAPI連携するのであれば、SaaSそのもののセキュリティーについてはSLA通りですが、個別に開発したAPI連携の部分は、セキュリティーの視点で開発ベンダーと保守体制を議論する対象になります。それでも、フルスクラッチ開発をするより断然注意すべき点が減り、日頃の精神的安定に繋がりますし、会社の外のステークホルダーから見ても安心です。Standardするのが理想です。したがって、情報システム部門の限られた人員で個別にセキュリティー対応するのではなく、専業ベンダーが提供するセキュリティーサービスをしっかり理解した上で、そのまま使うことが肝要です。ところで、ITセキュリティーの諸問題の多くがヒューマンエラーによることは前にポストした通りであり、皆さんも周知の事実だと思います。したがって、企業として、その社員に対して、ITセキュリティーやSNSの使い方、ネットリテラシーの基礎の習得に一定の投資をすることはとても重要になります。これまでも、これらの文脈で多くの事件、事故が起こってマスコミを騒がせています。一方で、企業がこういった投資をした上での事件なのか、全くそうでないのかでは、その後の民事訴訟の流れが大きく変わるのも事実です。企業ITの中でセキュリティーを「育てる」ためには、その組織文化にあった中長期の方針をITグランドデザインで構築することが重要になります。----高柳の著書はこちらよりご参照ください。