レガシーアプリケーションのポートフォリオをモダナイズすると、企業環境に固有の課題がいくつか生じます。このシリーズの最初のブログ 「モダナイゼーション:重要な理由」 では、モダナイゼーションプロジェクトに着手するかどうかを決定する際に、以下の 2 つのポイントについて考慮することをお勧めしました。

  • アプリケーションを未来の状態に移行する場合の利点と、アプリケーションをモダナイズするために必要な労力の比較。

  • 企業にとって、この未来の状態を長期的に運用することが可能かどうか。

モダナイゼーションプロジェクトに着手する前に考慮すべきポイントは、この 2 つだけではありません。企業は、単なるプロセスとシステムの総和ではありません。企業とは、人間が構造的に関わり、業務が遂行される大規模な社会的集合体です。企業には、複数の製品を扱う巨大市場において、長年に渡る活動により形成された複雑なルールと社内政治が存在します。これは、規制対象の業界で特に顕著となっています。

整合性は必要だが、困難である

ソフトウェアを正常にモダナイズするには、担当チームは、企業の目標、コンプライアンス、およびポリシーの整合性をとる必要があります。また、イノベーションと現在の環境における制限とのバランスをとることについても、理解している必要があります。

しかし、すばらしい成果を得るために必要な整合性をとることは、大企業にとっては困難で、膨大な時間がかかります。一番の問題は、ソフトウェアの開発履歴と、それを実稼働環境で実行することに関する詳細が、企業全体に分散されるている可能性があることです。ここで課題となるのは、チームが情報共有に対してオープンでない場合があることです。個々のチームメンバー、特に組織に加わったばかりのメンバーは、モダナイゼーション・プロジェクトの成功に必要なコンテキストを取得することに苦労する場合があります。

チームが以下の図のような状態であれば、既存アプリケーションのモダナイズを成功させる確率は高くなります。

Modernization ingredients for an effective decision

企業のナレッジとイノベーションとの整合性は、非常に重要です。

以下は、進捗が遅かったり、意図した成果が得られなかったりすることで発生する不整合の原因の一部です。

サイロへのアクセス制限

インターネットが登場する前は、大企業が最初の IT イノベーターでした。これらの企業は、1960 年代に最初にメインフレーム (「Big Iron」) を使い始めました。多くの重要なプロセスが、メインフレーム・コンピューティングに移行されました。この技術はコストがかかり、尊敬される企業のチームに属する専門家が必要でした。これらのチームや彼らが立ち上げた製品は、今日の企業文化に大きな影響を与え続けています。

多くの人間が、自分たちにとって価値あるもの (データセンターなど) の周りに集まると、排他的なグループが形成されることがあります。このようなグループは、他の人たちがリソースを利用する方法についてのルールやプラクティスを自分たちで定義することができます。これらの排他的なグループと、彼らが作成するルールやプラクティスとの組み合わせは、一般にサイロと呼ばれます。

このようなサイロは、ツールやプラットフォームの周りに形成される傾向があり、これらのテクノロジーの対象となる消費者を遠ざける可能性があります。

以下に例を示します。

  • サイロのプラットフォームへは特定の人だけが許可され、それ以外の人に対しては非友好的である。

  • テクノロジーを使いたい人にとっては意味のないチャージバックモデルを使用している。

  • ツールまたはテクノロジーをうまく使用するための、厳重に保護された手順を維持している。

企業は、既存のアプリケーションを改善するために新しいテクノロジーを導入する可能性があります (たとえば、新しいアプリケーション・パフォーマンス監視ツールやコンテナランタイムなど)。ただし、このテクノロジーの周りにサイロがあると、各チームは、プロジェクトを完了するためのテクノロジーにアクセスできるまで、長い間待つことになる可能性があります。その結果、プロジェクトの達成に必要な成果を得るまでに時間がかかり、チームにはフラストレーションがたまることになります。

Modernization - slow enterprise knowledge

無駄な仕事と多すぎる中間管理職

中間管理職層の厚い企業では、結果に対する責任者を特定することは、混乱を招く可能性があります。誰が意思決定者なのかわからない場合、または意思決定者に適切な成果を得ることが任されている場合は、整合性をとることは困難となります。

(意味のある形でソフトウェアプロジェクトに携わったことがない人もいるほど) 中間管理職層が厚い場合、エンドレスなチェックポイントや多すぎるスタンドアップミーティングのほか、必要以上にレポートを提出したりプレゼンテーションを行ったりすることが、重要かつ技術的な決定を狂わせる可能性があります。このような「無駄な仕事」という企業文化は、本来ならよりインパクトのある仕事に時間を割くことができるであろう従業員の時間を拘束してしまうことになります。

Modernization - the impact of too much management

「ロックスター」が解決策をもたらすとは限らない

満足できない結果に対する典型的な解決策として、「ロックスター」を採用して解決してもらうことがあげられます。ロックスターとは、非常に賢く、簡単に「ものごとを修正」してくれると管理職が信じている人材のことです。

しかし、ロックスターにはロックスターのエゴがあり、妥協をいとわないという考えに影響を及ぼす可能性があります。ロックスターは、企業のコンテキストを無視したり、既存のポリシーやセキュリティ標準に準じなかったりすることもあります。その結果、「なんでも修正」するために採用した人材が争いに巻き込まれ、誰もが不満を抱えることになります。

誤解のないように言うと、賢い人材を採用しないようにと言っているのではありません。採用する人材と、その人材に割り当てる仕事に対して、優れた判断力を持つようにしてください。次回のブログでは、より優れたプロダクトチームを作り出す方法について説明します。

人員削減によるナレッジの喪失

あまりにも多くの技術的人材が組織を離れてしまうと、整合性をとったり、質の高い成果を得たりするために必要な企業固有の貴重なナレッジが失われてしまいます。

たとえば、大手コンサルティング会社と企業が関係を解消する場合、担当者はプロジェクトからはずされることになります。これは、費用対効果の観点からは理にかなっているかもしれませんが、テクノロジーに関する貴重なナレッジを持つ人材が去ってしまうことになります。

また、優れた技術専門職の人材がいなくなると、最も優秀な人材がチームを見捨てたように感じられるため、チームの士気が下がります。

企業環境での働き方に特化した適切なオンボーディング・トレーニングがない場合、人材の寄せ集めのような新しいチームは、企業の仕組みに関して十分な洞察力を持ち合わせていないかもしれません。このようなチームは、正しい判断を下すために必要な整合性をとることに苦労する場合があります。その結果、チームの始動が遅れたり、アプリケーションを実稼働環境に移行するために必要な重要な側面が失われたりする可能性があります。このトレーニングに必要な内容については、モダナイゼーション・プロジェクトに向けたチームの準備に関する次回のブログで説明します。このトレーニングは、プロジェクトにおける人員削減やコンサルティング会社の乗り換えに対応する際にも非常に役に立ちます。

Modernization - attrition leading to lost knowledge

コスト削減の企業文化

優秀な人材を見つけることは難しいですが、コスト削減の企業文化がこれをさらに難しくしています。このポリシーは通常、企業内でソフトウェアの開発と運用を真に効果的に行うために必要な専門知識を理解していない調達部門によって推進されます。

多数の安価でスキルの低い人材と、少数の高価でスキルの高い人材のどちらかを選択する場合、多くの企業は、より少ない費用でより多くの人材を求める傾向にあります。

多くの場合、調達チームまたは財務チームは、ベンダー、ソリューションプロバイダー、および技術系人材派遣会社に対して値引きを求めることを奨励されています。人材の調達後、その人材が業務に従事した後の働きぶりについてフィードバックを提供したり、受けたりすることがあります。

仕事ができない人材がいることは、大きな課題となります。しかし、人材が多すぎる場合は、さらに大きな問題となる可能性があります。人材をめぐるコスト削減の判断は、結果としてこの両方の問題を同時に発生させることになります。

イノベーションのナレッジや企業のナレッジに関係なく、チームの人数が多ければ多いほど、質の高い成果が得られる可能性は低くなります。

Modernization - cost-cutting culture

不明確な基準とポリシー

「企業のナレッジ」を習得してチームに加わった人材が、その企業特有の運用ワークロードを管理する特定のポリシーと手順を把握していることが非常に重要となります。他所で得たナレッジだけでは十分とは言えません。

これは、困難な状況を招く重大な問題 (たとえば、公共の安全に関わる出来事や資金の損出など) が発生した場合は、被害が最小限に抑えられるか修復された後、誰かが再発防止の任務を負うことになるからです。この任務は、独自のセキュリティ基準や運用ポリシーとして組織内に定着していきます。これらの独自の基準は、新しいものをゼロから構築する場合よりも、既存のアプリケーションを変更する際に適用されることが多いです。

標準とポリシーについては、このブログシリーズの後半で詳しく説明します。

過密状態の市場

今日の企業環境では、クラウドプロバイダー、クラウドコンサルティング企業、およびツールプロバイダーが、あらゆるチャンスを狙っています。彼らは、企業のソフトウェア開発と運用プラクティスに関する問題を解決できるとして、企業の管理職を説得しようとしています。

表面的には、最も注目されている新しい技術をプロバイダーから購入することは、戦略的に理にかなっています。結局のところ、あなたの企業が、業界内の次の Google になることを目指している場合、Google からサポートを受けることが最適だと言えるのではないでしょうか。しかし、レガシー企業の既存のプロセスや企業文化に、(パブリッククラウドのような) 新しいものを追加することは、決して簡単なことではありません。

Modernization - fix-and-fail cycle

ベンダーによる失敗や、製品に障害が発生すると、これをきっかけに、「すべてを修正する」別のベンダーへの扉が開きます。 これは、整合性プロセスによって変化していく環境について何も理解していない人々が原因で、企業のシステム的な修正と失敗のサイクルにつながる可能性があります。チームが計画時に環境による制約を考慮しなかったことが原因となり、混乱が生じると、実装コストが高くなったり、未来の状態を達成できなくなったりする可能性が出てきます。

これまでに議論されたすべての課題を考慮しながら、モダナイゼーション作業を行うための理想的なチームを構築することについては、またのちほど説明することにします。

次に議論が必要なトピックは、資金調達についてです。資金調達を行わなければ、チームは存在することができません。次のトピックでは、モダナイゼーションプロジェクトに投資する価値があることを上級管理職に納得してもらう方法について説明します。

詳細情報


About the author

Luke Shannon has 20+ years of experience of getting software running in enterprise environments. He started his IT career creating virtual agents for companies such as Ford Motor Company and Coca-Cola. He has also worked in a variety of software environments - particularly financial enterprises - and has experience that ranges from creating ETL jobs for custom reports with Jaspersoft to advancing PCF and Spring Framework adoption in Pivotal. In 2018, Shannon co-founded Phlyt, a cloud-native software consulting company with the goal of helping enterprises better use cloud platforms. In 2021, Shannon and team Phlyt joined Red Hat.

Read full bioIcon-Red_Hat-Directional-A-Black-RGB