企業ITの6大要素とは？25年の経験から辿り着いた答え〜IT法務・認証取得・セキュリティ編〜

企業ITの6大要素について、今回はIT法務・認証取得・セキュリティを説明します。

4.IT法務

法務部門とIT部門のコミュニケーションが悪い事案を多く見てきました。多くは、法務部門がこれから導入するITの技術的な中身を理解していないために起こっている事案で、その反対側では、IT部門の法務部門への丁寧な説明が足りていないという、いずれもコミュニケーション不足による事象が多いように思います。


知財の帰属

IT法務において、私たちが一番重視視しているのが契約上の知財の帰属です。実はここが曖昧であったために、事業会社とITベンダーが後々になって揉めるケースが多くなっています。特にIPOプロセスにおけるIT内部統制の中で問題になります。

ITシステムをオーダーメイドでフルスクラッチ開発する場合と、クラウドサービス（SaaS）を利用する場合で考え方が異なります。


フルスクラッチ開発の場合

前者の場合、事業会社で発注をし費用を支払った部分においては、基本的には当該知財（開発したソフトウェア）が発注側、つまり事業会社に帰属するように基本契約書のルールを社内で明確に確定させておく必要があります。

ところが、事はそう簡単ではありません。開発会社は、工期を短縮したり、効率化をするために、自社独自のコンポーネントやサブルーチンなどを材料として利用する場合があります。それが埋め込まれた上で、システム全体が納品物として完成しますが、この材料としてのコンポーネントやサブルーチンについての権利もしっかりと発注の時点で処理をしておかないといけません。将来ベンダースイッチが発生した時などに、システムリソースが引き継げず、結局ゼロから開発し直す必要が出たりと、IPOプロセスを大きく遅延する問題になります。無論IPOの予定がなければこの問題が発生しないわけではなく、どの企業においても、将来のどこかの時点でこの問題は発生します。

開発会社の立場に立てば、当該材料の権利を手放し、それが将来ベンダースイッチの際に競合たる別のベンダーに渡ってしまうのはどうしても避けたいものです。したがって、開発会社の知財を使わずに開発するように求める必要が出てくる可能性もあります。当然ですが、その場合工期や開発費が余分にかかるので、投資対効果を検討しなくてはなりません。

また、どうしてもコンポーネントやサブルーチンなどを利用したい場合は、将来起こり得るベンダースイッチを想定した開発ベンダーとの議論が必要です。すると当該材料を事業会社が他社に販売しないことを約束したり、次のベンダーがこれを外販しない約束を事業会社に取り付けたりと、将来の約束をペーパーワークする必要が出てきます。


SaaSを利用する場合

一方SaaS利用の場合は、約款を個別にカスタマイズすることは不可能です。考えてみれば、GoogleやAmazonの約款やSLA（Service Level Agreement）を個別に変える交渉ができるはずもありません。これまでも、皆さんが、Microsoft製品を使う際に、個別に約款の変更をMicrosoftの法務部門に求めないのと同じ構造です。

そもそも、以前ポストした通り、自社の知財を含めた、顧客のビックデータまでもを自分の資産とすることで、ビジネスが成り立っているのがクラウドサービスのビジネスモデルです。そのためSaaSを使う際は、これらの約款やSLAをしっかりと検討し、自社の業務へのリスクと支障をIT部門だけではなく、経営を巻き込んで議論する必要があります。


5.認証取得　

昨今、どんな企業でも顧客情報などの個人情報を扱うことが多くなりました。IT前提経営の6大要素の中にも「AI*BigData*IoT」がありますが、個別にAIやビックデータを使った分析をせずとも、CRMのクラウドサービスを月々数万円支払って利用し、顧客データを管理する企業は沢山あると思います。となれば、これらの顧客データの管理をしっかりと行っていることを対外的に証明する必要が出てきます。個人情報で言えば、個人情報保護法に連動するプライバシーマークの取得はその一つの手段だったりします。また、IPOを目指す会社の情報システム部門が、セキュリティーを含めたITシステムの健全性を対外的に証明するためにISMSを取得することも一般化しました。これらはIPOしない企業にとって無意味だと指摘する人や、印籠のようなものであるという批判も多いことは知っています。しかし、一方で、顧客のプライバシー管理が重要なことは事実であり、情報システムの健全性が一定以上であることは、顧客のみならず、事業会社のステークホルダーにとっても重要な要素です。

あるいは、複雑怪奇になった業務フローの効率化に、何度もチャレンジしたが頓挫してしまった経験がある会社は、ISMSなどの認証の取得・維持を目的として、認証取得のコンサルティング会社に手伝ってもらい、その結果として業務フローが明文化されることを目指すようお勧めすることがあります。この場合重要なのは、ITシステム部門だけでこれらの認証の取得をやらないことです。というのが、私がIT前提経営と言っている通り、現代の企業の業務フローのほとんどはITシステムによって処理されています。しかし、認証を保持するのは法人です。名刺にも認証ロゴが印刷されるかもしれません。であれば、全社をあげて、それぞれの業務部門長が我が事として、参加できるバーチャルオフィスを立ち上げ、ここで認証取得を目指すのが理想系なのは言うまでもありません。無論その際、業務システムに詳しいIT部門もそこに参加することは重要です。


6.セキュリティ

これまでこのブログではNo Making, Just Usingや、Fit to Standardの考え方を推奨してきました。これは、私たちが勝手に主張している訳ではなく、経済産業省などの役所も「クラウド・バイ・デフォルト宣言」や「2025年の崖」を発表するまでになっています。となれば、セキュリティーについても、No Making, Just Usingであり、Fit to Standardであるべきだと考えています。SaaSを利用すれば、当該SaaSのSLAに準拠せざるを得ません。APIエコノミーのポストで説明した通り、SaaS同士をAPI連携するのであれば、SaaSそのもののセキュリティーについてはSLA通りですが、個別に開発したAPI連携の部分は、セキュリティーの視点で開発ベンダーと保守体制を議論する対象になります。それでも、フルスクラッチ開発をするより断然注意すべき点が減り、日頃の精神的安定に繋がりますし、会社の外のステークホルダーから見ても安心です。また、オフィスのインターネットやWiFiルーターの設定、保守管理、テレワークデバイスの利用方法なども、各セキュリティー専門企業が提供する、SaaS（Security as a Service）にFit to Standardするのが理想です。したがって、情報システム部門の限られた人員で個別にセキュリティー対応するのではなく、専業ベンダーが提供するセキュリティーサービスをしっかり理解した上で、そのまま使うことが肝要です。

ところで、ITセキュリティーの諸問題の多くがヒューマンエラーによることは前にポストした通りであり、皆さんも周知の事実だと思います。したがって、企業として、その社員に対して、ITセキュリティーやSNSの使い方、ネットリテラシーの基礎の習得に一定の投資をすることはとても重要になります。これまでも、これらの文脈で多くの事件、事故が起こってマスコミを騒がせています。ただ一方で、企業がこういった投資をした上での事件なのか、全くそうでないのかでは、その後の民事訴訟の流れが大きく変わるのも事実です。

企業ITの中でセキュリティーを「育てる」ためには、その組織文化にあった中長期の方針をITグランドデザインで構築することが重要になります。



ガーディアン・アドバイザーズ株式会社　パートナー　兼　IT前提経営®アーキテクト
立教大学大学院　特任准教授
高柳寛樹
----
高柳の著書はこちらよりご参照ください。
「IT前提経営」が組織を変える デジタルネイティブと共に働く （近代科学社digital）2020
まったく新しい働き方の実践:「IT前提経営」による「地方創生」 （ハーベスト社）2017
----