クラウド屋はマルチカンパニーの夢を見ない〜マルチカンパニーを想定したクラウドサービスアーキテクチャ〜

こんにちは。コーポレートエンジニアリング部の永田です。

先日、約15年で4万キロ使用した妻の原付2種スクーターを、後継車に乗り換えました。3世代後の現行型になるわけですが、水冷式、可変バルブ、リヤディスク、液晶メーター、USB充電ソケットなど進化ぷりがすごい。とりわけガチガチの足回りと、6千回転からのVVA作動がええ感じなのです。楽しいおもちゃがひとつ増えました。年々厳しくなる規制に対応しつつ、性能向上させていくというメーカー、エンジニアの努力に脱帽です。また15年乗ります。

はじめに

さて今回は、「マルチカンパニーを想定したクラウドサービスアーキテクチャ」について記載します。（具体的にどのクラウドサービスを選択すべきかについては言及しません。）

我々コーポレートエンジニアリング部は、いわゆる「情シス」「コーポレートIT」のチームであり、以下のミッションを担っています。

お陰様でサーバーワークスは年々成長しており、今やサーバーワークス単体ではなくサーバーワークスグループとして事業を展開しています。我々は、以前のようにサーバーワークス単体でのコーポレートサービスアーキテクチャではなく、グループとしてどうあるべきか考える必要性が出てきました。
XXXをまるっとエンタープライズ向けのクラウドサービスにリプレイスする？その際、全グループ会社で相乗り統合するのか？？サービスへのロックインは許容するのか、、
むーん。正解がわからん。世の中の「マルチカンパニーを想定したクラウドサービスアーキテクチャ」の情報が圧倒的に乏しいのです。というわけで今回は、現時点で我々なりに辿り着いた構成についてご紹介していきます。

マルチカンパニーにおけるクラウドサービス・テナント構成パターン

我々のビジョンは、「クラウドで、世界を、もっと、はたらきやすく」です。クラウドサービスの利用はイチ手段です。しかし、我々はクラウドインテグレーターとして、我々自身がクラウドサービスをフル活用したはたらきかたをドッグフーディングし続ける必要があります。よって、今回のブログでは極力クラウドサービスの組み合わせで実現できる構成を前提としています。

検討の結果、自身で腹落ちできたのが、業務・機能単位での3パターンの構成分類です。例えば、アクセス管理は疎結合型、人事コアは密結合型といった形です。

※ 疎結合型、分離型においては、同一種のクラウドサービスに統一されているかはここでは問わない。個社ごとに何かしらのクラウドサービスを契約利用している状態。
※ 疎結合型の「グループ統合管理」レイヤは、各社のデータを統合的に参照、管理する役割を担うテナント。例えばOktaやkaonaviなど、「グループ統合管理」テナントを別途契約することで、当構成を実現できるサービスもある模様。
※ 疎結合型が実現できるサービスは限定的。なお、グループ統合管理部分はクラウドサービスを使わず独自開発する選択肢もある。

特徴相対比較

分類	観点	密結合型(統合型)	疎結合型	分離型
経営	会社統廃合のしやすさ(対応期間・対応コスト)	✗	△	○
経営・IT	ガバナンスの効かせやすさ	○	△	✗
経営・IT	ライセンスコスト	△ ※グループ全社のライセンスプランを、最上位プランを必要としている会社に合わせる必要あり	✗ ※グループ統合管理テナントのコストが追加で必要	○
IT	各社の管理者への権限移譲のしやすさ	✗	△	○
IT	トータル運用効率	○	△	✗
IT	サービスリプレイスのしやすさ	✗	△	○

どの構成パターン選ぶべきか

必ずしも統合することが正ではなく、どの構成パターンがベストという正解もありません。企業ごとにケースバイケースで吟味が必要です。その際、視点として考えられるものを挙げておきます。

グループ会社として何処を目指すのか

グループとして何処を目指すのか。それは何故なのか。経営層の意思であるWhy、Whatが定まっていることで、自ずと絶対に譲れない観点、優先順位が明確になります。Why、Whatが定まっていないと、アーキテクチャのHowがブレることになります。当ブログでは記載を省略していますが、サーバーワークスにおいても、経営層がグループとして目指したい姿を明確化したうえで、今回の取り組みを遂行中です。

各社個別に担う価値がある業務・機能は何か

個社ごとに担う価値が見出せない業務・機能は集約し、シナジー効果を狙えないか検討します。つまり、密結合型、もしくは疎結合型を志向します。しかしながら、個社ごとのビジョンや、ビジネスモデルの違いによっても、あえて個別最適すべきという判断もありえます。

グループ会社間のデータ共有は可能か

技術的には統合可能でも、サービス統合が実現できない制約がありえます。対象の業務・機能に関わるデータ（例：社員情報、営業データなど）が、グループ会社間で共有可能な契約・ポリシーが制定されているかどうかです。恐らくグループ統合の検討を始めたタイミングでは、共有不可な契約形態となっているケースが大半でしょう。対象となる情報によっては、グループ会社内だけでなく顧客との契約・ポリシーに影響が及ぶものもあります。また、子会社が完全子会社でないケースも、考慮が必要です。契約・ポリシーの変更が現実的ではない場合は、自ずと分離型を選択することになります。

グループ各社のサービス利用料は現実的か

こちらの観点については、構成に閉じた話ではなく、採用するクラウドサービスのライセンス体系にも依存します。仮に最強の構成、クラウドサービス、契約プランを導けたとしても、グループ各社にとってはオーバースペックなケースがあります。特に売上、利益に直結しないジャンルの業務・機能については、グループ各社にとっては廉価なサービス利用料で済むに越したことはありません。密結合型、疎結合型の方向でまとめたい場合、現時点のグループの成長フェーズも判断したうえで、グループ各社にとって現実的な構成、クラウドサービスを選定します。また、どのような配賦基準を採用するかによってもグループ各社のサービス利用料負担額が違ってくるので、検討ポイントのひとつです。

最後に

今回は、「マルチカンパニーを想定したクラウドサービスアーキテクチャ」についての見解をご紹介しました。まだまだ試行錯誤中であり、より良い視点・アーキテクチャがたくさんあるのではないかと感じています。読者の皆様の知見コメントも別途いただければ幸いです。

私としては、サービスの選定も大事ですが、「何を選ぶか」よりも「どう使うか（どう使いたいか）」のほうがより重要であると考えています。とはいえ、肝心のクラウドサービスについては具体的に何を選ぶべきか？が、やはり気になる方も多いのではないでしょうか。次回機会があれば、サーバーワークスが各種業務・機能ごとに選択した構成・クラウドサービスを具体的にご紹介していきます。

我が家の原付のように15年使い続けられる基盤など、なかなかありえませんが、変化に柔軟に対応し続けられるアーキテクチャを選びたいものですね。
それでは。