必要性

　組織がクラウドを導入するには様々な組織的な対応をする必要があります。

これまで、オンプレミスシステムに適合した組織作りをしてきました。しかし、クラウドを導入するにあたってその目的を達成するために組織の変更から文化の変更まで迫られます。

たいていの場合、クラウドを導入する理由はあらゆる品質の向上にあります。

たとえば、

• クラウドならではのサービスを利用して顧客に新たな価値を導入したい
• CI/CDを導入するとともに自動テストをしていきたい
• 必要なサーバーリソースを瞬時に調達することで顧客体験を向上させたい

　目的はそれぞれかと思いますが、たいていの動機は品質の向上に資するところにあるかと思います。

そうしたときに、組織や組織文化の観点から見たとき、自組織はそれに対応できるかどうか。

やりたいことと比べて承認フローなどが重厚すぎて人がボトルネックになっていないだろうか？

そもそも、クラウド導入に関して自分事として捉えているだろうか？

　このような、課題解決していくのにあたって非常に有用なのがCloud Adoption Framework(CAF)です。

本稿では、組織論と導入戦略のみに焦点を絞って書きたいと思います。

組織と組織文化

　よくあるアンチパターンとして特定の領域のみの業務に固執することが上げられます。

また、これまでオンプレミスシステムはしばしばパートナー企業に重要なシステム設計や意思決定をアウトソーシングするということが行われてきました。

しかしながら、クラウド導入及び導入にあたってはその意思決定をアウトソーシングすることを避けてください。この導入にかかる時間を短縮したり、技術的な支援を求めるために外部パートナーを利用します。

特定の領域の業務に固執するチーム

　この問題は、特定のプロセスや責任範囲の調整を通じて自らを定義することにあります。チームは自分たちの責任範囲に外部から影響が及ぶことが問題につながるという前提のもとで活動します。企業がIT部門をコストセンターと見なしている場合、この問題が発生する可能性が高くなります。

これは、リーダーシップが不足している組織で特に一般的です。

　ここでの問題は、クラウドの特性として同じことを実現するサービスはいくつかありそれぞれ目的や特性が異なっています。これらのサービスの選択は本質的にはインフラチームには最適な選択は難しいということです。インフラチームはアプリケーションやビジネスの本質を理解してないことがほとんどです。ここに対して理解があるのはビジネス側、またはシステム開発チームではないでしょうか？なので、クラウドサービスのある程度の理解がプロジェクトチームに関わるすべてのメンバーに必要になってくる理由になってきています。

　この原因でクラウド導入作業が妨げられる場合、運用・職責・場合によってはその特定のチームの責任者の人員でさえ自由に変更できる必要さえあります。この必要な変更を推進するために、ビジネス関係者、ビジネス上の動機、ビジネス上の成果との調整が必要になる場合があります。必要に応じて、課題に取り組むためにエスカレーションに関与する必要があります。

重要なシステム設計をアウトソーシングする

　最も価値の高いビジネスの中核機能をアウトソーシングして、パートナー企業に過度に依存しないようにします。

ビジネス機能をパートナー企業に依存することでクラウドの利点の一つである高速にリリースできるという点がなくなってしまいます。一般的になにか新しい機能を実装しようとした場合、これまでと同様に、見積もりやら発注などの人手を介したウォーターフォール的なプロセスにならざるを得なくクラウドのメリットが著しく損なわれます。

しかしながら、クラウドの導入作業を加速するためにパートナー企業を利用することはとてもよいことです。

また、実装フェーズに能力あるエンジニアを雇ったり、パートナー企業を利用することも有用です。

導入戦略

　クラウドを導入するには理由があります。

これらを文書化してクラウド技術者が理解でき、なおかつビジネスの関係者に受け入れられるビジネス戦略を文書化してください。

そして、関係者の共通認識としてください。

この、クラウドを導入する目的が明らかになることで自ずと特定のクラウド機能にマップできます。そして、最終到達点を定義できます。

動機

　クラウドに移行する理由はビジネス関係者、技術的な関係者共通の課題です。

答えが「会社のトップからクラウドに移行するように指示された」みたいな場合、なにを目的にクラウドに移行するのか？クラウド移行のゴールは何か不明確になるので成果を得ることが非常に難しいです。

より具体的な理由を示す必要があります。

例

• DevOpsによる運用の最適化
• AIの導入のため
• 市場の需要に合わせたスケーリングを可能にするため
• ビジネスの機敏性の向上

これら目的によっても最適なクラウドソリューションは異なります。

たとえば、社内向けの業務アプリケーションをクラウドサービスにしたいとして目的はDevOpsによる運用の最適化だったとして、これは果たして動的にスケールする必要まではあるだろうかということです。

ビジネス上の成果

　クラウド導入にはコストと時間がかかります。成功を収めるにはビジネスエリアから一定のサポートが得られることが重要です。

このためにクラウド化することでどのようなビジネス成果を収めることができるかということを合意できてなくてはいけません。

• 財務成果
• 機敏性成果
• 到達性成果
• 顧客エンゲージメントの成果
• パフォーマンス成果
• 持続可能性の成果

　これらの成果について検討してクラウド導入の成果が十分にあることを確認しクラウド導入する動機に結び付ける必要があります。

さらに、クラウド導入の目的に即した組織を作る必要があります。

コンウェイの法則

　システムを生み出す組織はそのコミュニケーション構造そっくりの設計を生み出してしまうという原則があります。

たとえば、従来型のシステム開発においてバックエンド・フロントエンド・インフラなどの職能型のチーム構成があります。この場合、チーム内で完結する変更はとてもスムーズにいきますが、チームをまたがる変更はとても工数がかかったりコミュニケーションコストがとても高いことでチーム内は密結合に、チーム外は疎結合になりがちです。

これを逆手に取り、バックエンド・フロントエンド・インフラなどを含むプロジェクトチームを結成しコミュニケーションを密にとることでコンウェイの法則を逆手に取りコミュニケーションコストの削減が見込めます。

スキル文化

　従来のオンプレミスの時代であれば、システム開発だけとかインフラだけ。インフラもサーバーだけ、ネットワークだけみたいな限られた範囲内で仕事をすることも可能でした。

しかしながら、クラウド文化は違います。

　プログラム開発者が積極的にインフラに関与し、それによっても書くコードが変わってくるということが言えます。

例えば、オンプレミスの時代であればインフラが用意されたサーバーの中で動かすしか選択肢がなかったのですが、クラウド時代は様々な便利なサービスがあります。バッチを動かすのにも単純にAzure VMで動かすのか？WebJobsとして動かすのか？Azure Functionsで動かすのか？など要件によってさまざまな可能性があります。

このため、開発者だからプログラムだけ書けばよいとかインフラ要員だからプログラムのことは知らなくてよいとかそういうことはなく先に書いたようなプロジェクトチームとしてそれぞれの専門領域がありながら横断的な知識を身につけていくということが必要になってきます。

まとめ

　クラウドを導入するには目的があります。

その目的を達成するためにはまずは組織をクラウドに対応した組織に改める必要があります。

なぜなら、コンウェイの法則によって作られるシステム構造は組織を反映したものにしかならないからです。

ならば、組織構造をクラウドに適したものに改めることでよりよいシステムを作ることができます。

そして、よりよいクラウド文化を醸成することができます。

それは、品質に反映されます。