2018.02.02Mendixで課題解決 , Mendixとは? , デジタルトランスフォーメーション

デジタルトランスフォーメーションの進め方:Start・Structure・Scale

  • このエントリーをはてなブックマークに追加

Roald Kruit
2017年9月7日

「実に逆説的なことなのです。私たちは可能な限り大きくしたい、と考えてしまうものなのですが、まずは小さなものから始めるのです。そして、それを急速に拡大するのです。Facebookは、今のFacebookから次のFacebookを構築する方法を考え続け、あっという間に世界的な存在となりました。」 – Eric Ries

デジタルトランスフォーメーションのために組織を変革する必要があることは疑いの余地がありません。
IDCによれば、組織におけるITリーダーシップの最大の課題は、デジタルトランスフォーメーションに関連するビジネスニーズ、能力、および可用性を中心とした組織にできるのかどうか、ということです。
しかしながらEric Ries氏が述べたように、デジタルトランスフォーメーションを実現させようとしたときに、はじめから海を沸騰させようなんて無謀なことは考えるべきではありません。
はじめから全てのことに対して大きく始めようとすると、次の2つの理由で失敗します。

1. 組織は、一度に多くのことを変えようとすると、そのすべてを推進・管理することは非常に困難になります。イニシアチブを持ったチームが大きければ、混乱を招き、必然的に行き詰ることになります。

2. 「変化」は、その効果を実感できなければ破たんしてしまいます。人々は仮説を立てて検証しながら変化をすすめようとするものです。大きな変化をコミットする前に、自分の目で見て効果を確認する必要があります。

私たちのデジタルトランスフォーメーションフレームワークは、何百ものお客様との経験から、組織が適切なタイミングで適切なサイズに成長できるように設計されています。

フレームワークはStart、Structure、Scaleの3つのフェーズに分かれています。

この記事では、3つのフェーズのそれぞれを簡単に説明し、導入する理由を説明します。

 

Start
Startフェーズは、小さなプロジェクトからスモールスタートし、デジタルトランスフォーメーションに向かっていく新しいアプローチ方法の価値を証明する必要があります。
社内に対してPRをして、最初の変化に対する成功をアピールします。

最初の小さなプロジェクトに含まれたさまざまな要素を拾い出して、次のプロジェクトに適用します。
これを繰り返すことによって次第に大きな影響を生むようになり、社内全体に変化を広げることができるようになります。

Plautusは言いました。「1人の人間の目撃は10人の伝聞より重い – 百聞は一見にしかず。」
これは、最初のプロジェクトを慎重に選ぶことがとても重要だということも意味しています。
またプロジェクトを始めるにあたっては、事業部門やステークホルダーとの合意、インフラシステムの準備を含め、必要な条件が確実にそろっている状態でスタートする必要があります。
最初のプロジェクトからのチーム成長戦略によるデジタルトランスフォーメーション機能の構築について詳しくは、こちらをご覧ください。

 

Structure

Structureフェーズに移行すると、プロジェクトチームから専任組織へと移行し、全社の戦略もデジタル実行を加速する方針を明確に打ち出すことになります。
このフェーズでは、組織の編成、メンバーの教育、人的リソースの活用方法を決定することが主な課題になってきます。
成功を再現できるようにするために、最初のプロジェクトで使用された方法論を形式化することも重要です。
アプリケーションの数が増えるにつれて、迅速かつ継続的なリリースを可能にするDevOpsの実装、全体の統制(ガバナンス)と構成(アーキテクチャ)に焦点を当ててアプリケーションの保守性と互換性を確保するなどのトピックも重要になります。

 

Scale

Scaleフェーズは、デジタルエンタープライズを支える数百のアプリケーションを管理し、快適に利用するための効率的な運用を実現する為に大規模に自動化を適用するフェーズです。
「自動化」には、企業の幅広いポートフォリオを実現する数百のアプリケーションをサポートするために、デプロイと運用の自動化、プロジェクトの保守性を積極的に監視するための品質保証の自動化、企業内で共通に利用可能なアプリケーションストアの構築による再利用性の向上などが含まれます。
こうした自動化を実現することにより、複数のチームが同時に開発しながら、企業全体に分散しているイノベーション要素を統合して価値と生産性を最大限に高めるアプリケーションを構築することができます。

 

Scaleの実践

私たちの顧客のうち、ある1社がScaleのコンセプトを適用しました。
この企業は、社内にMendixを活用してアプリケーションを構築することができる複数の分散チーム「工場ライン」と呼ばれるものを確立しました。

工場ラインでは、Mendixをどんな場面で使用するのかという明確なガイドラインを定義しました。
また、アプリケーションのコンポーネントをすべて把握し、コンポーネントを再利用のために組織内のリポジトリで共有する必要があるかどうかを決めることも工場ラインの重要な役割でした。

このチームの方針に基づいて、2017-2018年までに200件のアプリケーションを提供するビジョンを持ち、毎週のようにアプリケーションをリリースできるようになりました。
また、ロードマップとガイダンスを策定して社内で共有したことによってDevOps、QA、継続的な統合といったトピックにもうまく取り組めるようになりました。

 

タイミングが極めて重要です

私たちのデジタルトランスフォーメーションへの変換フレームワークは、すべてを一度に行うのではなく、それほど重要なポイントでなかったとしても、必要なことが後から見つかったりしないように、適切なタイミングで作業をチェックすることが極めて重要です。
たとえば、Structureフェーズでガバナンスに対処するのを忘れた場合、完成後に処理するのは一見コストがかかるのですが、もっと後のフェーズになってやり直すとなれば、よりいっそうコストが増大しさらに広い範囲で開発を妨げることになります。

私たちは何百ものお客様にデジタルトランスフォーメーションの導入をご支援してきました。
今では、組織が適切なタイミングで作業をチェックするためのベストプラクティスを数多く持っています。

各段階の具体的なトピックについて詳しくは、Digital Transformationのページをご覧ください。

 

翻訳元:

A Digital Transformation Framework: Start-Structure-Scale

  • このエントリーをはてなブックマークに追加