fbpx

シャドーITとは?セキュリティリスクを削減する方法・対策のまとめ

序章

ITの専門家として、おそらくあなたは以下の現象の1つまたはすべてを観察したことがあるでしょう。

ある部門の小さなグループが、ビジネスユーザーが感心し、恍惚としてしまうようなシステムを作り上げました。この人たちはIT部門の人間ではありませんが、デスクトップ技術を使って、ビジネス上の重要なニーズを見事に満たしたものを作ったのです。営業部門は、Salesforce.comが提供するAPIに接続するモバイルアプリケーションを作成するために外部のサービスプロバイダと契約しましたが、企画会議にはIT部門からは誰も招待されませんでした。ある企業のある部門全体が、独自の独立したIT部門としか言いようのないものを持っています。この部門は、電子メールやホスティングなどの「企業」の IT 部門が提供するサービスを使用していますが、独自のアプリケーション・サーバを維持し、認可された「企業」のソフトウェア・スタックとは全く異なる言語やツールを使用する独自のプログラマーを抱えています。

一枚岩の企業IT部門が存在する世界では、これらの個々の取り組みはしばしば「シャドーIT」と呼ばれています。これらのグループは、従来の集中管理されたIT部門の権限外で活動しており、独自のインフラ、ツール、ベンダー、プログラマーを擁していることが多いです。これらのグループが提供するソリューションは、単純なものから非常に複雑なものまで様々であり、彼らが解決するビジネス上の問題は、郵送用ラベルの作成から、財務、エンジニアリング、運用管理などの特定の領域における複雑な計算の実行に至るまで、何でもあります。

今日の一般的な企業の指揮統制IT環境にしっかりと定着している専門家の最初の反応の一つは、これらの努力を嘲笑することかもしれません。実際、企業の IT 部門が管理する広大なサーバーやネットワークインフラ、何百万行ものコードに比べれば、これらの取り組みは小さく、取るに足らないものに見えることが多いのです。もう一つの反応は、これらの取り組みに対して不安を感じることかもしれません。なぜ存在しているのか、どのような規模で存在しているのか。企業の IT 部門が提供していない、あるいは提供すべきではないサービスは何か?安全なのか?どのようなリスクがあるのか?予算はどのように組まれているのか?冗長性はあるのか?

シャドー IT の現象は明らかに、一度直面すると、いくつかの難しい問題を提起します。実際、私たちは、それが私たちが無視してきた技術の使用について、おそらく私たちの不利になるようなことを私たちに教えてくれるかもしれません。しかし、このような懸念を検討する前に、定義を整理しておきましょう。

シャドー IT を、集中 IT 機能が管理・管理していない企業内のグループが行う技術関連の活動と定義することができます。集中型 IT 機能は、これらの活動が IT 組織の権限の一部であり、通常は IT 組織の管理下にあると考えています。分散型構造の個々のIT部門は、シャドーITグループではありません。正式な中央集権型IT組織がなければ、シャドーITは存在しません。さらに、シャドウ IT グループは、独立性、生産性の向上、専門的な領域の知識、開発ライフサイクルの管理、競争力、予算の自律性など、さまざまな理由から、中央集権型 IT 機能から独立して運営されることを望んでいます。

もっと簡単に言うと、シャドー IT とは、「IT ができないこと、またはできないことを行うこと」と定義できます。シャドー IT は、集中化された IT 機能では提供されないサービスのギャップを意味するため、企業はシャドー IT を懸念する必要があります。さらに、データ損失に関連するリスクや、サービスの重複や断片化に起因するコストにも対処しなければなりません。しかし、シャドー IT の存在は、しばしば具体的なビジネスニーズを指し示しており、多くの場合、企業に大きなプラスの結果をもたらす機会となっています。

本記事では、従来の中央集権型 ITモデルに統合しようとする努力にもかかわらず、このようなシャドーITが存在し、存続している理由を見ていきます。また、これらの取り組みが最も頻繁に想定している構造を定義し、それらに関連するリスクとメリットを特定することを試みます。最終的には、シャドーIT現象に対処するための推奨事項を提示し、意外な結論が出るかもしれません。

第一節 企業におけるシャドーITのモデル

モデル1:実践主導型開発

このモデルは、一般的にシャドーITという用語を使用するときに人々が参照するものではありません。このモデルでは、組織内の別個のプラクティスの一部であるグループが、中央の IT 組織から部分的または完全に独立して独自のテクノロジー管理を実行します。これらのグループは、ビジネスの特定の側面に精通しており、この親密さが、彼らが生産し、使用する技術ソリューションに直接影響を与えます。しかし、誰もこれらのグループを従来の意味でのIT機能とは考えていません。このような専門知識があるからこそ、これらのグループは独立した存在であり、CIOはこれらのグループを吸収するリスクを冒したくないと見て見ぬふりをしていることが多いのです。このような実務主導型の組織は、一般的に3つの異なる形態のいずれかに分類される。

  • レガシー
    • 成熟したIT組織の形成に先行して、ビジネス機能におけるこの最初のタイプのプラクティス主導型の独立したIT努力が行われます。グループは、独自のリソースと専門知識を使用して、必要に応じて技術を作成および/または採用する。これらのグループは決して技術機能と考えられなかった。彼らは伝統的に最初のコンピュータソフトウェア、典型的には会計および財務部門を使用したグループと区別される。多くの場合、これらのグループは、配送が重要な業務グループ(倉庫管理、メディア制作、販売など)です。一般的に、これらのグループは、IT組織がハンズオンの経験や運用知識を持たない技術やベンダーに対処します。
  • オーガニック
    • プラクティス主導型のITは、顧客/消費者が直面する技術に強い焦点を当てているものです。これらの疑似プロダクトチームは、しばしばB2Cのウェブプレゼンス、モバイルアプリケーション開発、およびビジネスのためのその他のパブリック・フェイシング技術資産を管理しています。これらのグループは、市場からの圧力や競争に駆られており、マーケティング部門の一部であることが多い。多くの場合、企業のIT部門は、特にモバイルデザインの分野では、これらの能力を持っておらず、以前にこのような取り組みで失敗したことがあります。したがって、ビジネスは、公式のITグループとは独立してこれらの活動を行うことを決定します。
  • 専門家
    • 従来のITから独立している理由としては、必要とされるソリューションに高度な専門知識が必要とされ、技術の開発が専門家と密接に結びついている必要がある場合が挙げられます。特定のビジネスニーズに対応した非常に複雑なソリューション、カスタマイズされたソリューションのための顧客との密接な接触、複雑なアルゴリズムの開発などは、これらのグループが独立性と開発に対する高度なコントロールを求めるようになる可能性があります。多くの場合、これらの組織は、従来の企業のITリソースでは実現できない(または実現できないと認識されている)科学的または複雑な金融アプリケーションのためのソリューションに、ハイレベルな能力を持っています。

いずれの場合も、これらの機能を企業のIT組織に移行させることは非常に困難です。多くの場合、これを実現するためにはトップレベルの企業再編が必要となります。さらに、適切な技術スキルや高度な専門知識が不足しているため、IT部門がこれらの機能を吸収できない可能性があり、これらのチームをIT部門に統合しようとすることのリスクが高まります。多くの場合、このようなリスクを認識しているために、実践的なITの取り組みが妨げられずに継続されてしまうことがあります。

モデル2:ローグライク開発

ほとんどの人が「シャドー IT」という言葉を使うとき、本当の意味はローグライク開発のことを指しています。しかし、それは驚くべきことではありません。ローグライク開発はシャドー IT の中でも最も古く、最も一般的なタイプの一つです。もしあなたがIT業界で長く働いているならば、おそらくキャリアの中でいくつかの不正プロジェクトを知っているか、あるいは参加したことがあるでしょう。では、ローグライク開発とは一体何を意味しているのでしょうか?

定義

ローグライク開発には2つのタイプがあることが判明しました。「ブラックオプス」と「スカンクワークス(Skunkworks)」です。ブラックオプスはその名の通り、日の目を見ることのない不正なプロジェクトです。一方、Skunkworksプロジェクトは、最終的には会社の合法的な一部になることを目的とした半強制的なプロジェクトです。

ブラックオプスは、通常、自分の仕事を終わらせようとしている1人か2人の従業員によって生み出されます。多くの場合、その従業員は実際に IT 部門と協力し、プロトコルに従ったり、公式のチャネルを使用したりして作業を試みましたが、何も行われませんでした。最終的には、彼らは、彼ら自身がそれを行う場合には、彼らが任意の進歩をしようとしている唯一の方法であると感じるようになります。ブラックオプスにはほとんど監視がなく、最終的な製品の品質は、関係する従業員のスキルに完全に依存しています。従業員は自分の仕事を終わらせようとしているだけなので、ブラックオプスのプロジェクトは、当面の問題を超えた有用性の制限、長期的なサポートの不足、ドキュメントのほとんどない、などの深刻な問題を抱えている可能性があります。

スカンクワークスは、中央のIT組織が満たせない(あるいは満たそうとしない)正当なニーズに対処するために作成される、やや大規模なプロジェクトである傾向があります。従業員がそのようなニーズに気づき、小規模なチームを編成してソリューションを開発します。成功した場合、skunkworksプロジェクトは大規模なIT組織に組み込まれることが多く、直接、またはIT部門が同様のサービスを提供するために使用できるテンプレートを提供します。スカンクワークスプロジェクトのチーム性と、マネージャーやビジネスユニットによる監視が相まって、より有用な最終製品が生み出されます。直ぐに問題を解決しようとしているわけではないので、skunkworksチームは文書化や最終製品が社内でどのように使用されるかなど、より多くのことを考えることができます。

ローグライク開発の推進

職場に現れて、気まぐれでシャドウ IT プロジェクトを開始しようと決めた人はいません。そうだとしたら、なぜ私たちはあらゆる規模、あらゆる業界の企業でローグライク開発プロジェクトを見つけることができるのでしょうか?ブラックオプスとスカンクワークスのプロジェクトには違いがありますが、多くの共通点があります。例えば、ITのコンシューマライゼーション、モバイルプラットフォームの導入、BYOD、生産性向上への欲求、ITプロジェクトのバックログ、ドメインの専門知識の欠如、オフサイクルのリリース要件などです。

IT のコンシューマライゼーションは、今日の組織に大きな影響を与えています。従業員は、職場でも自宅と同じような機能や機能を期待し始めています。自宅ではApple TVでワイヤレスでできるのに、なぜプロジェクターにケーブルを接続する必要があるのでしょうか?IT 部門が技術をテストして承認するには時間がかかりますが、新しいデバイスや技術が導入される速度を考えると、これは問題です。

モバイル・プラットフォームとBYOD は、開発の観点からも、従業員のユースケースからも、今日の企業のホットな話題です。IT がすべてをサポートすることはできないので、問題は「どのプラットフォームをサポートしているか」ということになります。従業員は、生産性を高めるために必要なテクノロジーを持っていることに気づくことはほとんどありませんが、持っていないときには大きな声で不満を口にします。多くの新しい生産性向上ツールやサービスが利用可能になっているため、集中管理された IT 組織がそれらすべてに精通していることはおろか、それらをサポートしようとすることも不可能でしょう。

時には、不正な開発の原因となるのは、支援したくても、IT 部門はすでにやるべきことが多すぎるという事実です。これにより、従業員には2つの選択肢が残されます。ITが自分のプロジェクトにたどり着くのを待つか、自分で何かを実装して新しいことに移るかです。

IT部門がプロジェクトを完了させるための経験や専門知識を持っていない場合はどうなるのでしょうか?追加の人材を雇うか、請負業者に依頼する必要があるかもしれません。どちらの方法も時間がかかり、遅延の原因になります。開発者が仕事を完了させるために必要な専門知識を持っている場合、その開発者に飛び込んでもらうべきでしょうか?それとも、IT部門がリソースを確保できるまでプロジェクトを遅らせるべきでしょうか?

最後に、従来のIT組織が使用していたスケジュールとは異なるスケジュールで運用する必要がある場合はどうなるでしょうか?IT部門はあなたの要件をサポートできるかもしれませんが、他の会社にはどのような影響があるでしょうか?もしあなたがIT組織のリリーススケジュールに従うならば、あなたは俊敏性を犠牲にしなければなりません。

モデル3:目的に応じた開発

目的に応じた開発には様々な形態があり、ユーザーが特殊なマクロを使ってスプレッドシートを作成するような単純なものから、特別にコード化されたロジックを使って複雑なタスクを実行するように設計された洗練されたプラットフォームまで、様々な形態があります。また、SaaS(Software as a Service)プラットフォームの出現により、部門が外部ベンダーと契約して、企業のテクノロジー・インフラストラクチャの外で従業員が完全に利用できるプラットフォームを展開することも可能になっている。これらの事例は「実践主導型開発」に似ているが、ドメイン知識に焦点を当てたものではない。特定の機能を実行するためのニーズが発生し、IT 部門はそのニーズに対応できない、あるいは対応しようとしない。いくつかの例を見てみよう。

金融サービス会社のメインフレームベースの記録管理システムは、記録のシステムであり、主要なコンピューティング・プラットフォームである。しかし、長年にわたってビジネスユーザーの間でマイクロコンピュータが普及するにつれ、一般的なデスクトップソフトウェアを使用して手動の機能を自動化または半自動化されたものに置き換える方が生産性が高くなってきました。特殊な文書は、デスクトップデータベースにアクセスする「メールマージ」機能を使用して作成されました。データは、記録システムによって生成された紙のレポートからデスクトップ・データベースにキー入力される。これらの文書は、収益実現プロセスに必要なものなので、使用される技術や実装されるロジックがアルゴリズム的に洗練されているわけではありませんが、明らかにビジネス上の重要な機能を果たしています。ここで重要なのは、ITはこのシステムのことを何も知らないということです。実際、このシステムは、ユーザーが複数のユーザーがLAN経由でデスクトップ・データベースにアクセスすることを許可することで拡張しようとしたときに、おそらくITの注意を引くことになり、それによってその破損を誘発し、その結果、ビジネス・プロセスの混乱を引き起こします。

もう一つのシナリオは、ビジネス・グループがレポーティングのために既存のシステムからデータにアクセスする場合です。ビジネス・エリアから直接雇用された契約プログラマーには、本番用データベースへの読み取り専用のアクセス権が与えられています。最終的には、大量のデータを取得するマルチジョイン・クエリではなく、トランザクション・パフォーマンスに最適化されていた本番用データベースの速度が低下してしまいます。このようなケースでは、「影」の大きさがわからないことが多いです。どのくらいの数のレポートが存在するのでしょうか?同時に実行できるレポートの数は?その中に含まれるクエリはどれくらい最適化されているのでしょうか?

さらに別のシナリオとしては、あるビジネス・エリアがニーズがあると判断し、IT部門の知識なしに(少なくとも計画段階では)そのニーズを満たすためにSaaSベンダーを利用するというものがある。これはクライアント・サービス分野では一般的なシナリオとなっており、以前は営業部隊の自動化の分野であったソーシャルメディア・ツールの普及につながっている。従来、IT は金融サービス分野では記録管理システム商業分野では在庫管理や調達システムなど、ビジネスのコア・コンピテンシーに焦点を当てたシステムを構築してきた。テリトリー管理、リード配布、アクティビティログなどの販売プロセスの自動化を求められたとき、従来の IT 組織は選択を迫られました。そのようなシステムを構築するか、拒否するかの選択を迫られました。そのようなシステムを構築した企業もありましたが、営業組織との取引は、財務グループや製造グループとの取引とは大きく異なることがわかりました。要件管理は、90年代初頭にノートパソコンを持って現れることを楽しみにしていたが、技術的なプロジェクトを管理するために必要な厳しさを何も知らない営業の専門家とのやりとりでは、より困難なものでした。このことと、ほとんどの営業組織が同じ活動(リード管理、テリトリー管理、コンタクトトラッキング、アクティビティログ)を行っているという事実が、営業自動化のための市販製品につながり、最終的には完全にパブリックなクラウドベースのソリューションになりました。今日では、独自の営業部隊自動化システムを構築したり、IT部門に構築を依頼することを検討する営業組織はほとんどありません。このようなシステムは、データと処理がすべてベンダーのインフラ上で実行され、ほとんどが従来のITの領域から外れています。

セクションII – モデルの評価

モデル1の評価:実践主導型開発

プラクティスドリブン開発とは、組織の内部または外部の顧客に非常に特殊なサービスを提供するなど、組織の目的に応じて展開される主題専門知識を必要とする開発のことである。そのため、その技術的要件は、組織の他の分野とは異なることがある。

メリット

  • 独自の価値:このような取り組みに固有の専門知識を持つことで、組織は確実に利益を得ることができます。多くの場合、これらの取り組みはクライアントに直接影響を与え、全体的な収益を生み出すイベントの一部となる。
  • アライメント:プラクティス主導の取り組みでは、ビジネススタッフと技術スタッフが緊密に連携しているため、「一般的な」開発環境では不可能な、要件定義、開発、およびテストの作業が緊密に連携している。この調整は、提供されるサービスの効率性と品質に不可欠であり、多くの場合、アジャイルプラクティスのベストプラクティスと同様のソフトウェア開発ライフサイクルを示す。

デメリット

  • インフラの重複:プラクティス主導型の取り組みでは、独自の要件に焦点を当てているため、独自のインフラが発生することが多 い。また、プラクティス・ドリブンの実践者は、環境の管理を維持し、従来の IT 組織からの干渉を避けるために、環境を「レーダーの下」に置いておきたいと考えることがある。このように見えなくなると、IT 組織がデータベース管理、ツール開発、ライセンス管理などの機能を統合して コスト削減を実現することができなくなる可能性がある。プラクティス・ドリブンの実践者がこのことに気づけば、実際にはインフラ管理よりも価値のある活動に多くの労力を割くことができるだろう。
  • コンプライアンス・リスク:ITインフラストラクチャの外で行われているすべての作業は、コンプライアンス・リスクにつながる可能性がある。シャドーITプロジェクトに従事するグループは、データの保持と削除ポリシーに関するセキュリティ、プライバシー、およびデータガバナンスの要件を実施していない可能性がある。

モデル2の評価:ローグライク開発

ここまでで、さまざまなタイプの不正な開発とその原動力となるものを理解しました。

ブラックオペレーションズ(ブラックオプス)

ブラック企業がブラック企業であり続けるためには、小さな足跡を残さなければなりません。プロジェクトが大きな影響力を持っていたり、多くの従業員を巻き込んでいたりする場合、そのプロジェクトが長く隠れていることはありません。このようなプロジェクトの規模の小ささは、祝福であると同時に呪いでもあります。

長所
  • ブラックオペレーションの利点は、これらのプロジェクトは小規模で集中度が高いため、よりシンプルになり、正しく実装しやすくなる傾向があることです。シンプルなプロジェクトは、たとえそれが理想的ではないとしても、事実の後に文書化することができます。
  • 小規模チームは信じられないほど機敏に活動することができます。多くの人や他のチームと調整する必要がないため、変化する状況や新しい問題にも素早く対応することができます。
  • これらのプロジェクトのフットプリントが小さいということは、通常、会社のリスクが小さいということでもあります。小規模なプロジェクトでは、建築上のミスを元に戻したり、セキュリティ上の問題を修正したりすることは、大規模なプロジェクトよりも容易である。ミスが発見されなかったとしても、企業への影響は問題のプロジェクトに限定される可能性が高い(これには明らかに例外がある)。
  • 優秀な従業員がいる場合、ブラック・オペレーションを行うことで、企業にとってのメリットは非常に大きくなります。ビジネスは望む結果をより早く得ることができ、IT部門はそのために貴重なリソースを縛る必要がありません。
短所
  • 小規模なプロジェクトであれば、才能ある人材の数が少なく、ミスを見抜く目が少ないことを意味します。活用できる知識や経験が少なく、チームは特定の技術に精通していない可能性があります。見落としがなければ、深刻なアーキテクチャや実装のミスを最終製品に落とし込むことは容易です。
  • セキュリティは、おそらく関係する従業員にとっては優先順位が高くないだろうし、そもそもセキュリティの意味合いを理解していないかもしれないので、ブラックな運用には大きな懸念があります。
  • また、小規模なチームでは、自由に使える時間も少なくなります。つまり、大規模なIT組織を念頭に置いてソリューションを設計したり、ドキュメントを作成したりすることが少なくなります。結局のところ、それを使用するのは自分たちだけなのです。
  • 特定の問題を解決したいという欲求は、ブラックオペレーションの一環として開発されたものは、より大きな組織への適用可能性が限られている可能性が高いことを意味します。これらのプロジェクトに費やされた時間と労力は、より多くの組織のニーズを満たすであろうやや大規模なプロジェクトに費やされた方が良かったかもしれない。
  • また、ライセンスの問題もあります。従業員の監督が行き届かない場合、会社が適切または十分なライセンスを持っていないソフトウェアを導入することになるかもしれません。会社が監査を受けた場合、ライセンスの問題を解決するために多額の費用を支払うことになりかねません。
  • 最後に、何かが壊れたらどうなるか?オペレーションチームはブラックオペレーションについて何も知らない可能性が高く、トラブルシューティングや問題への対応能力に深刻な影響を与えます。

スカンクワークスプロジェクト

スカンクワークスのプロジェクトは不正なものかもしれませんが、チームの規模やプロジェクトの規模が大きいため、完全に隠蔽されたままではいられません。これは、管理者の関与と相まって、組織にとって異なる意味合いを持つことを意味します。ブラック・オペレーションと同じように、長所と短所があります。

メリット
  • プロジェクトの規模が大きくなり、チームの規模が大きくなればなるほど、より多くの人材と経験を積むことができます。そのため、アーキテクチャーやプランニング、ドキュメント作成、さらにはセキュリティレビューにも適切なリソースを割り当てることができます。また、プロジェクトをより多くの目で見ることで、問題を迅速に発見し、影響を小さくすることが可能になります。
  • 限られた管理監督は、必要とされる俊敏性を維持するだけでなく、プロジェクトの目標が組織全体のより大きな目標と一致していることを保証します。ライセンシングのようなものは事前に対処することで、後になってからのサプライズを少なくすることができます。優れた管理者は、最終的なソリューションの運用化にも配慮することができます。
  • 優れたSkunk Worksプロジェクトは、適切に実行することで、組織に完全なソリューションを迅速かつ最小限のリスクで提供することができます。最終的な結果は、より大きなIT組織にとって有用であり、簡単に統合することができます。これにより、ITリソースを他の問題に取り組むために解放することができ、どの企業にとってもwin-winの状況となります。
デメリット
  • スカンクワークスのプロジェクトではアジリティを維持することが目的ですが、リスクを減らし、組織の有用性を高めるためには、アジリティを犠牲にすることもあります。重要なのは合理的なバランスをとることです。
  • スカンクワークスのプロジェクトは少しオープンになったとはいえ、努力の重複の可能性は非常に現実的です。あるチームが問題を発見した場合、別のチームも問題を発見している可能性が高いのです。一番避けたいのは、2つのチームが影で作業して同じソリューションを構築することです(もっと悪いことに、IT部門がすでに取り組んでいる問題のソリューションを構築することです)。
  • スカンクワークスのプロジェクトは、手に負えなくなりがちです。最初の問題の解決に成功したチームは自信過剰になり、多くのことに取り組もうとすることがあります。優れたマネージャーは、プロジェクトの集中力を維持し、目標を達成することができます。
  • 最後に、スカンクワークスのプロジェクトは、より大きなIT組織から挑戦や侮辱として見られる可能性があります。スコープを小さくし、特定の問題を解決することで、このような認識を和らげることができます。良いコミュニケーションと経営陣の協力があれば、後はスムーズに進むでしょう。

モデル3の評価:目的駆動型開発

目的主導型シャドーITの取り組みは、プラクティス主導型の取り組みと似ていると言いたくなるかもしれないが、実際には異なるものである。目的主導型シャドーITと実践主導型シャドーITの違いの鍵は、実践者の専門知識にある。プラクティス主導型シャドー IT の取り組みでは、実務者の専門知識が必要とされるが、これは目的主導型の取り組みの特徴ではない。多くのPurpose Drivenな取り組みは、特定の分野の専門知識がないにもかかわらず、ニーズがあるために存在していることが多い。

長所
  • 効率性と生産性:目的に沿った取り組みは、自動化が効率性と生産性に大きな影響を与えることができる領域を強調することがよくあります。セールスフォースの自動化への要求は、80/20、ACT!、そして最終的にはSalesforce.comのような、社内のプライベートソリューションと成功した市販のソリューションの創造を推進した。クライアントサービスやセルフサービスのシナリオで活用される場合、ソーシャルメディアの領域でも同じことが言える。多くのクラウドベースのソリューションが提供されている中で、ほとんどの企業は自分たちでこれらのツールを構築することはないだろう。多くの場合、これらのデプロイメントは従来の IT 部門とは全く関係がないかもしれない。そのような場合は、通常、シングルサインオン(SSO)が必要とされる認証レベルで行われます。
  • 統合:モバイル・コンピューティングの普及と IT の「コンシューマ化」により、さまざまなソースからのデータの統合の必要性が高まっています。これにより、IT が従来の境界線内に留まることが難しくなり、最終的にはビジネスエリアが IT を完全に無視することになります。モバイルアプリで営業部門と財務部門の間でデータを統合することは、従来のプラットフォームとクラウドベースのプラットフォームをまたいだデータの統合、認証、消費に関する新たな要件を確実に促進することになります。このような問題は、必然的に IT 部門を巻き込むことになります。
短所
  • 努力の重複:残念ながら、複数のクライアントサービスエリアや営業チームが存在するような大規模な組織では、複数のソリューションが存在する可能性があります(可能性があるかもしれません)が、管理、運用、財務の非効率につながります。
  • コンプライアンスリスク:開発が「不正な」チームによって行われている場合や、非ITグループによって直接保護されているベンダーによって行われている場合、この開発は企業の設計、セキュリティデータガバナンスプライバシー基準に準拠していない可能性があります。
  • 驚きの要件:デスクトップ技術の熱狂的な応用から、影の「生産性プロジェクト」がしばしば発生します。これらの関連するインフラストラクチャは、問題が発生したときに IT 部門によって「発見」されることがよくあります。マルチユーザ・データベースとして展開されたデスクトップ・ファイル・システムは、最も必要とされる時、つまり同時使用が多い時に故障することが予測されます。システムが十分に重要であれば、IT 部門は信頼できる RDBMS を含む適切な技術スタックを使用してシステムを作成することになるかもしれません。このような自動化は、異なる技術上ではあるが、伝統的な記録システムの拡張とみなすことができるので、これらのケースでは、ITはしばしばそうすることに同意するだろう。これにより、以前は隠されていたシステムが効果的に影から姿を消すことになるが、リソースには大きなコストがかかる。より信頼性の高い技術への書き換えが実現不可能な場合、IT部門は、標準外のシステムが故障したときに、バックアップを復元することで、標準外のシステムを復活させるように求められることがよくありますが、これは、少なくともいくつかのデータ損失とビジネスエリアへの運用上の影響を避けられません。

セクションIII – シャドーITサービスプロバイダモデル

図 1 は、従来の IT とさまざまなシャドー IT の取り組みが交差している様子を示しています。従来の IT 部門は、ローグライクな取り組みに対しても、少なくともいくつかのサービスを提供していることがよくあります。ローグライク企業が、少なくとも従来の IT 組織が提供する電子メールと電話サービスを利用しないことは考えにくい。実践と目的に基づいた取り組みは、ローグライクな取り組みよりも大きな交差点領域を持っています。このようなタイプのシャドー IT は、多くの場合、IT 組織が提供する一定のインフラストラクチャの分派閥であったり、それに依存しています。しかし、伝統的な IT 組織は、これらの取り組みを主に管理しているわけではないことに注意することが重要である。図 2 は、先に定義したタイプのシャドー IT が動作するさまざまなサービスモデルをさらに説明しようとしたものである。赤枠のサービス・プロバイダーは、非 IT プロバイダーです。これらは、企業内の要素、または契約に基づいて独立して運営されている SaaS、PaaS、またはコンサルティングの要素を表している可能性があります。緑の網掛けの要素は、従来のITサービス・プロバイダーを表しています。シャドーITの形態がPurpose DrivenからSkunk Worksへと移行するにつれ、明らかになるのは「レッドシフト」である。言い換えれば、取り組みが従来のIT組織からより独立したものになるにつれて、図中の赤の量が劇的に増加しているということです。

図の左端では、伝統的な IT セクションはほぼ完全に緑色になっており、サービスの調達はほぼ完全に企業内の IT 組織からのものであることを示しています。唯一の例外は、ユーザー・アクセプタンス・テスト(UAT)を実施するサブジェクト・マター・エキスパート(SME)の関与である。図の極端な右端にあるのがスカンク・ワークスで、これはほとんどが赤字で、ITグループからの重要なサービスをほとんど消費していません。これは極端なケースであり、実際にはBlack OpsやSkunk Worksのチームが電子ファイル・ストレージや電子メールなどの腐りやすいサービスに伝統的なITを利用していることは想像に難くありませんが、開発努力のためには、Black OpsやSkunk Worksのローグ的な要素が伝統的なIT組織から最も独立していることは明らかです。

図の真ん中のPurpose DrivenとPractice Drivenの領域は、開発努力に対するITの関与が少なくなっていることを表しています。これらの領域の半分が緑、半分が赤のサービスになっているのは、多くの場合、開発努力がIT組織の過去の努力や現在の努力を活用している可能性があるからです。一つの例では、IT DBAが保守・修正したリレーショナルデータベース内の既存のテーブルや新しく作成したテーブルを利用する目的駆動型プログラム。もう一つは、ケーブル配線、スイッチ、ルーターなどの実際のネットワークインフラは従来の IT I&O 組織の管理下にあるかもしれないが、このインフラに接続されたデバイスやその上で実行されるプログラムは、目的、実践、ブラックオプス、さらにはスカンクワークスの開発プロジェクトの結果であるかもしれないということである。ハイブリッド・サービスの赤半分は、インフラの一部が実際にはSaaS/PaaSベンダーに部分的または完全にアウトソースされている可能性があることを示している。完全にアウトソースされたモデルでも、従来のITインフラからのネットワークVPN接続が必要な場合があるため、I&Oサポート・ブロックの緑半分はすべてのセクションを通じて残っている。

赤緑のハイブリッドブロックに代表される危険性がある。セキュリティ、データガバナンス、設計、およびアーキテクチャ標準に関する企業ポリシーへのコンプライアンスの問題は、従来のIT組織内で実施するのは十分に困難である。しかし、部分的または完全にシャドーの取り組みを意図的に運用している組織内での実施は、はるかに困難です。

シャドーITサービスプロバイダモデルは、シャドーITの現象を説明し、組織への影響とリスクを分析するのに役立つツールとして、ここで提供されています。

セクションIV – 提言

結局のところ、シャドーITの普及は、IT組織がビジネスに必要なソリューションを提供できないことに起因しています。残念ながら、好むと好まざるとにかかわらず、IT 組織のリソースは限られています。企業に最大の利益をもたらすプロジェクトに人員と資材を割り当てる必要があります。したがって、シャドー IT を完全に排除する唯一の方法は、無限のリソースを持つ IT 組織を持つことであることが明らかになりました。それは不可能なので、次の最良の選択肢は、シャドー IT をどのように活用するかを考えることです。実際には、2 つの方法があります。

新しい携帯電話にアプリケーションを移植したり、新しいオペレーティングシステムを組織内にこっそり導入したりするために時間と労力を費やしている人がいる場合、そのような技術は、IT 部門が広く展開するために評価を開始すべき技術である可能性があります。言い換えれば、シャドー IT 開発プロジェクトは、IT 部門がリソースをどこに割り当てるべきかを示す指標となります。

シャドー IT 開発は、他のプロジェクトのために IT リソースを解放したり、ソリューションを直接生産したりすることで、企業に直接的な価値を提供することができます。課題は、シャドー IT の実践者が行っている作業が、会社にとって純利益となるようにすることです。全体的なビジネス戦略に適合した、よく設計され、文書化されたプロジェクトは、確実に勝利となります。文書化されていないプロジェクトで、サポートが難しく、コストがかかるものは、そうではありません。

多くの場合、シャドー IT の存在を受け入れ、それを受け入れることが最善の方法です。私たちの目標は、これらのプロジェクトを影から救い出し、透明性を高めることです。私たちは、不正な開発者に技術革新の自由を与えると同時に、可能な限りのガイダンスやリソースを提供する必要があります。このプロセスがよりオープンであればあるほど、問題の発見が早くなり、最終的にはより良い結果が得られるでしょう。実際、”不正な “努力を適切に奨励することは、”不正者 “の否定的な意味合いよりもむしろ “市民開発者 “や “主題開発者 “を生み出すことになるでしょう。

しかし、シャドーITにはコストとリスクがあることを指摘しないのは間違いで、これらの慣行から学ぶことはできますが、アプローチを調整する必要がありそうです。

  • ダークサイドから学ぶ :シャドー IT のあらゆる形態は、提供されるサービスと非 IT 専門家が望むサービスとの間にデルタがあることを示しています。特にリソースが不足しているときには、指揮統制の観点から、このデルタを無視することは魅力的です。しかし、非 IT 組織内の IT 機能に資金を提供するのに十分な量の資金が提供されているという事実は、そうでないことを示唆しています。大きな成果を上げるためには、組織の再編成や組織の変革が必要かもしれません。何年も前から、雑誌やブログでは、ビジネスと IT の分裂について語られてきましたが、ビジネス側は IT が遅すぎる、反応が悪すぎると不満を漏らし、IT 側は戦略のテーブルに座ることができないが、ビジネスの継続的な運営には不可欠であると不満を漏らしていました。
  • 統合するか、それとも共謀するか?:IT 部門以外の複数のグループが重複した作業に従事しており、さまざまなソフトウェア・スタックやインフラを生み出している場合、これらのグループの統合を試みることは理にかなっているかもしれません。しかし、システムが共通のプラットフォームに移行することでコストが削減されるという明らかなメリットがあるにもかかわらず、これは複雑で危険な作業であることが多い。リスクを過小評価することが、ここでの第一の危険性です。しかし、「シャドウ」の要素が目的よりもむしろ実践を重視したものである場合は、同情し、すべてのシャドウグループが活用できるようなサービスを IT 部門が提供できるかどうかを判断する方が理にかなっているかもしれません。さらに、プライバシー、セキュリティ、データガバナンスのポリシーが一様に適用されていることを確認することが、IT がこのシナリオに付加できる真の価値となるかもしれません。

IT が企業内のあらゆる開発形態を可能にしたり、制御したりすることは、常に可能ではありません。実際、これは望ましいことではありません。独立した開発グループが存在することには、特に実践主導型の開発モデルにおいては、完全に正当な理由があります。多くの場合、ITは直接サービスを提供しないかもしれませんが、プライバシー、セキュリティ、および保持ポリシーの観点からデータを扱うための企業基準が守られていることを主張することができます。さらに、IT は、ドキュメント管理、電子メール、ホスティング、リレーショナル・データベース・サービスなど、企業にとってより公益性の高いサービスを提供することができます。これらのサービスを一元的に管理することは大きなメリットがあり、コストをコントロールし、サーバーのパッチ適用、アップグレード、セキュリティを管理するのに役立ちます。さらに一歩踏み込んで、ITは、別々のプラクティス・エリアで共通に保持されているサービスのみを統合することができます。例えば、各プラクティスエリアに別々のデータベース管理者(DBA)がいる場合、この機能を各プラクティスエリアが使用できるサービスに統合することができますし、統合する必要があります。これにより、プラクティス主導の取り組みを完全に支配することなく、IT 部門は冗長性とそれに伴うコストを削減することができます。

ダークサイドを有効にする – 最終的には、企業は常にITが現在提供していない何かを必要としており、既存のIT部門を拡大してあらゆるサービスを提供することは明らかに不可能である。では、合理的なCIOは何をすべきなのだろうか。その答えは、コアデータのトランザクションと関係性の完全性を保護しながら、可能性を可能にする存在になることです。トランザクションの整合性などの概念は、ビジネスを効果的に行うための鍵となります。このような概念は、複雑なトランザクションを調整し、トランザクションのいずれかのコンポーネントに障害が発生した場合にそれらをロールバックできるようにするソフトウェアやデータベースツールによってサポートされています。この種の機能は保護されなければならず、これは IT の権限の中にしっかりと含まれています。では、従来のITの支援の外にある「不正な」開発活動は、記録システムとどのように相互作用するのでしょうか?そうすべきでしょうか? イネーブラーとして、答えは「イエス」です。イネーブラーとしての鍵は、統合ハブを介して機能を安全に公開することです。統合ハブは、認証されたアプリケーションが SORのデータと機能に安全にアクセスできるようにします。ハブは一般的にウェブサービスをホストし、最近ではHTTPプロトコルの一般的なウェブメソッドを使用して呼び出すことができるAPIをホストします。このようなサービスやAPIは、インターフェイスが厳密に制御されており、SORがすべてのトランザクションロジックを維持しているため、SOR以外のユーザーが利用するのに適しています。統合ハブはセキュリティ・ポイントとしても機能し、認証されたアプリケーションのみがハブのサービスとインタラクトできるようにします。IT 部門の権限は、統合ハブの API やサービスにまで及びますが、それ以上はありません。この場合、消費者(ビジネス主導のモバイル・アプリケーションである可能性があります)と IT の間の「契約」は、サービス・ハブで公開されている Web サービスおよび/または API です。消費者がメカニズムを適切に使用する限り、有効な結果が保証されます。コンシューマが指定された通りにメカニズムを呼び出さなければ、IT からのサポートを期待せずに失敗することになります。このようにして、IT はコミュニティを制御することなく、「市民開発者」に SOR データと機能への安全でスケーラブルで信頼性の高いアクセスを提供することができます。

結論

本稿では、シャドー ITを定義し、そのような取り組みが企業内でどのような形で行われているかを特定することを試みました。また、このような取り組みの推進要因に光を当て、組織への影響を分析するためのアプローチを提供することを試みました。おそらく、「シャドー IT」についての最も重要な結論は、組織がどのようにテクノロジーを使いたいかということと、ITがどのようにテクノロジーを使うべきかということを組織に伝えているかということについて、非常に多くのことを教えてくれるからです。このようなギャップを無視すると危険です。侵略的な種のように「シャドー IT」の努力を扱うことは、実りのない根絶と制御の努力につながるだけである。この現象の原因を理解することで、IT とビジネスをこれまでにないほど協調的に結びつけることができ、最終的にはポリシーの首尾一貫した変更につながる可能性があります。

 

SNSでもご購読できます。

コメントを残す

*