統合されたビジネスおよびテクノロジー戦略の策定

コードベースでの製品タイプの表現は、新しいものを追加したり、新しい製品が登場したときにカテゴリを調整したりするのがどれだけ簡単かに大きな影響を与える可能性があります。製品ライン情報について、他のシステムでの仮定を探してください。製品コードは他の場所にハードコードされている可能性があり、一部のシステムは特定の種類の製品のみを想定している場合があります。サイトでのさまざまな顧客エクスペリエンスとナビゲーションを提供することから、ドメインモデルの新しいエントリやデータベースの新しいテーブル構造に至るまで、スタック全体での変更を探してください。

ビジネスプロセスは、検討中の将来の製品には適していない場合があります。支払いおよび請求システム、流通および倉庫管理システム、ビジネスレポートなどの共有サービスバックエンドシステムに対して変更を加える必要がある場合があります。

製品間で機能を共有することで、新製品の付加価値のある差別化要因に集中できます。共有機能を統合することで、市場投入までのスピードが向上します。ただし、製品提供間でプロセスが異なる場合に、機能の共有を強制すると、機能内に不必要な複雑さと負債が生じる可能性があるため、注意が必要です。

製品の差別化に貢献しない機能は、インストールまたはSaaSのいずれかによって、パッケージ化されたソフトウェアに安全に割り当てることができます。このような機能のリストを作成すると、現在のベンダー製品の検討を促進できます。製品ラインの変更は、製品の差別化に重要な機能を明確にするのに役立ちます。時間の経過による変更と、差別化要因の再評価の両方により、適切な製品を提供しているベンダーを再検討してください。

市場全体で多様化、複製、統合、または調整できる機能を特定します。多様化および複製された機能は各市場に存在できますが、グローバルプラットフォームを通じて統合された機能を提供することを目指します。

規制、コンプライアンス、またはパフォーマンス上の理由で、新しい市場でインフラストラクチャをホストする必要がある場合は、システム全体でデプロイを繰り返せるようにする必要があります。これにより、地域間の不整合が減少し、障害が発生した場合のトリアージ時間が短縮されます。組織が地域ごとにカスタマイズおよび運用する個別のチームを立ち上げ、コードとしての構成ドリフト/スノーフレークや手動メンテナンスにつながることはよくあります。メンテナンスにも同様の重点を置く必要があります。コスト、スタッフの労力、および結果（パッチが適用され、一貫性があり、古いバージョンが廃止され、あらゆる規模の修正が迅速かつ包括的に展開される）です。地理的に規模を拡大するためのランニングコストはほぼ線形になり、改善と修正が迅速または一貫して配布されません。

コンプライアンスを遵守するために新しい市場で新しいデータセンターを立ち上げるには、長い時間がかかる場合があります。プロセスに再現性がなく、立ち上げに時間がかかる場合は、クラウドへの移行を検討できます。クラウドベースのインフラストラクチャは、新しい市場でのデータ主権要件を遵守するのに役立ちますが、コンプライアンスを遵守するためにデータベースをパーティション分割する方法を検討する必要がある場合があります。

規制対象情報を国外に渡すことで、コンプライアンス違反を引き起こす可能性のあるサードパーティシステムを探します。これには、OLAおよびSLAの調査が含まれる場合があります。

デフォルトでこれを有効にするUIフレームワークを探します。UIに国際化を後付けするのは面倒なプロセスになる可能性があります。コンテンツの長さは言語によって異なる場合があります。長文または短文のテキスト要素に対応できる動的なUI要素を探します。UIフレームワークがすでに翻訳ファイル用に構成されている場合は、「XXX」のような小さなものや、ページがどのように応答するかを確認するために非常に長いものにすべての翻訳を変更する優れた実験を実行することです。

変更を分離する十分に考慮されたコードベースを探します。

ファイルを翻訳するためにエージェンシーに許可する時間を開発プロセスに追加する必要がありますか？この余分な待ち時間は、小さなフィードバックループに影響を与える可能性があります。または、設計プロセスの一部として翻訳プロセスを導入する必要がありますか？

変更が困難なフロントエンドコードは、新しい顧客エクスペリエンスを提供することを困難にします。ハードコードされたナビゲーション要素、変更が困難なフロントエンドコード、およびフロントエンドテストの欠如を探します。

テストされていないコード、特にテストされていないJavaScriptは、エクスペリエンスを変更することを危険にします。低速（および不安定な）エンドツーエンドテストでのみテストされるフロントエンドは、新しいエクスペリエンスの開発にかかる時間を増やします。

Webサイトをネイティブモバイルアプリに拡張するなど、新しいUIエクスペリエンスを組み込む場合は、さまざまなフロントエンドインタラクションに柔軟性を提供しながら、デジタルプラットフォームがコアビジネス機能をどのように調整および統合するかを検討します。マイクロサービスまたはマイクロフロントエンドWebサイトを導入している場合、BFF（Backend For Frontend）モバイルアダプターなどのどのようなアーキテクチャ調整が必要ですか。

買収されたビジネスが独立して運営を継続する場合でも、一部のビジネス機能（財務など）を統合する必要があるが、すべてではない可能性があるという前提があります。ビジネス機能マップは、APIにドロップする前に、ビジネスレベルでのクロスオーバーを示すための最初の簡単なステップです。API戦略は、規模に合わせてイノベーションを可能にするAPIエコシステムを構築することにより、既存のビジネス機能のロックを解除する方法です。操作、統合、および消費が容易なAPIのエコシステムを作成することにより、市場投入までの時間を短縮できます。APIは、システム統合に焦点を当てた従来のアプローチとは異なります。明確に定義されたAPIを通じてビジネスの統合に焦点を当てることにより、将来にわたってイノベーションを起こす能力が向上します。

API戦略の調査は、このケースと同様に独立して実行されるケースにも当てはまりますが、利用できるその他のレバーがいくつかあります。たとえば、イベントストリームを共有したり、共有ストレージを利用したりできます。

買収したビジネスと緊密に連携しようとする場合は、ドメインモデル全体を統合する必要があります。ドメインモデルでこの整合性を得ることに焦点を当てると、データマッチングとシステムの統合が構成しやすくなります。

2つの製品で統一された顧客体験を提供することで、顧客満足度を高め、リテンションを向上させることができます。また、顧客が2つの分断されたシステムをまたいで作業する負担をなくすことで、両社が協力して顧客に提供する価値を増幅させることができます。

「エンタープライズアーキテクチャ・アズ・ストラテジー」のオペレーティングモデルクアドラントは、グループ企業全体で能力を統合したい組織や、非有機的な成長の統合に取り組む際に役立ちます。

買収を成功させるには、事業統合のためにリソースと人材を投入する必要があります。技術リーダーとして、システムの統合方法を理解するための統合努力を支援するために、あなたのインプットが必要になる場合があります。ランタイム環境を統合する必要があるかもしれませんし、データを新しいシステムに移行するか、コンプライアンス上の理由でアーカイブする必要があるかもしれません。システムのセキュリティレビューでは、移行前にシステム内で必要なセキュリティ対策が明らかになる可能性があります。また、製品間で移動する開発者のエクスペリエンスを向上させるために、テクノロジースタック全体でライブラリやフレームワークが統合されるため、システム自体を統合する必要があるかもしれません。

システムの運用面を合理化し統合することで、複数の異種システムを管理する運用コストと時間を削減できます。ログ情報、頻度、またはログの重大度レベルの変更など、実行中のシステムを監視する方法を変更する必要がある場合があります。

ドメインを反映していますか？クラスまたはファイル内から、コンポーネントの境界まで、複数のレベルでこれを検討してください。それらはどのように相互作用しますか？（ドメインモデリングを検討）。コードを評価する際の側面は、サイズ、複雑さ、結合度、凝集度です。

テストカバレッジは測定しやすいですが、常にテストの品質を適切に示すとは限りません。他に確認すべき事項としては、テストの数、不安定さ、実行時間、テストの一貫性/構造、命名、およびコードへの結合度などがあります。

プリプロダクションまたはプロダクションで発見された欠陥は、修正コストが指数関数的に高く、付加価値のある作業の流れを妨げます

長いビルド時間や、部門横断的な要件が維持されているかの検証など、長いフィードバックループを探してください

どのようなドキュメントが存在し、最新であるか、関連性があり/うまく整理されているか/見つけやすいか、各リポジトリにコードの目的とテストおよび実行方法に関する明確なドキュメントがあるか。

賢明なデフォルト、設定よりも規約、安全なガードレール、適切なオンボーディングドキュメントにより、新しいチームメンバーの生産性向上までの速度が向上します。

認知的負担は品質問題を引き起こし、デリバリーを大幅に遅らせます。

チームは、ビジネス価値に不可欠ではない多くのものを構築することに夢中になりがちです。デリバリープロセス内の無駄の例としては、認知負荷/コンテキストスイッチング、適切な情報を適切なタイミングで見つける能力、開発エクスペリエンスの摩擦、遅い品質フィードバックループなどがあります。ジョブを完了するために複数の場所やシステムに移動する必要がある、断片化された開発者エコシステムを探してください。ワークフローの段階間の作業キューのサイズを測定することは、ボトルネックを定量化するのに適した方法です。フローメトリクス、サイクルタイム、リードタイムを調べてください。

単一行のコード変更を本番環境に移行するまでの時間を測定します。小さな変更でラグタイムが長いと、頻繁な更新が妨げられ、より大きくリスクの高い更新につながり、ビジネスチャンスへの対応力が低下します。

コンポーネントの欠陥率のヒートマップは、最初に改善すべき最も重要な領域を示すことができます。

危険な部分で将来の機能開発が計画されている場合は、この領域を適切に修正する方が効果的な場合があります。通常、これらの領域の根本原因に対処するには、アーキテクチャの変更が必要です。

キャパシティに達している期間を探し、時間の経過に伴うパターンに注目してください。成長後の予想される負荷でキャパシティに近づいている場合は、今すぐシステムパフォーマンスに対処を開始する必要があります。

コールセンターのデータでパターンを探してください。このデータのパターンを製品の欠陥リスト全体のマッピングと照合してください。

頻繁に一緒に変更されるコンポーネントを探してください。これは、それらが密結合していることを意味します。変更のホットスポットは、高いチャーンレートを示しています。

クラウドへの移行に伴い、一部の財務管理者とテクノロジーリーダーは、かつてデータセンターで購入および運営していたインフラストラクチャに対する財務的な可視性を失っています。インフラストラクチャの購入センターは、調達オフィスからエンジニアのキーボードに移行し、クレジットカードはクラウドベンダーアカウントにファイルに保存されています。あまりにも多くの場合、財務オフィスは、請求書が月末に届いた後にのみクラウド支出を確認しています。新しいインフラストラクチャを立ち上げるエンジニアと予算の管理者の間に断絶があります。

クラウドコンポーネントのインスタンス化を担当するエンジニアへのクラウド支出に関する財務的意思決定の民主化は、適切な財務管理とアラートが導入された状態で行う必要があります。組織の文化をクラウド上で運用するように影響を与えることは、ガバナンスとコラボレーションを規律としてクラウドコストを最適化するのに役立つため重要です。インフラストラクチャにタグを付け、稼働時間と使用状況のメトリクスおよびアラートとともに運用ダッシュボードに支出を表示すると、財務管理とガバナンスの適切なバランスが提供されます。

もはや使用していないシステムの廃止またはサンセットは、クラウド請求額を削減する最も速い方法です。請求書に表示されるすべてを批判的に見て、まだ価値を得ていることを確認してください。

データガバナンスとは、組織のデータ資産の全体的な管理、制御、および保護を指します。これには、データのライフサイクル全体を通じて、データの品質、整合性、可用性、およびセキュリティを確保するプロセス、ポリシー、および標準が含まれます。データガバナンスは、組織全体でデータが収集、保存、使用、共有される方法を管理するフレームワークを確立することを目的としています。

サポート終了（EOL）ソフトウェアバージョンは、ソフトウェアベンダーによってサポートされなくなりました。これは、ベンダーがソフトウェアのセキュリティアップデート、バグ修正、または新機能を提供しなくなることを意味します。その結果、EOLソフトウェアを使用すると、セキュリティの脆弱性、パフォーマンスの問題、コンプライアンスの問題、データ損失など、ビジネスに多くのリスクをもたらす可能性があります。EOLバージョンは、次の成長段階を可能にする新しいテクノロジーに移行するための現在の市場スキャンの機会を提供します。

混乱が発生した場合に備えてバックアッププランを用意することで、企業は事業運営への混乱の影響を軽減できます。テクノロジーを使用してサプライチェーンの可視性を向上させます。商品や材料の場所に関するリアルタイムデータを入手することで、企業はより迅速に混乱を特定して対応できます。

分析ユースケースに対応するためのデータアーキテクチャを定義します。データエンジニアリング、ソフトウェアエンジニアリング、継続的デリバリーのベストプラクティスに基づいてデータプラットフォームを設計および実行します。さまざまなデータソースとユーザーに対応して容易に拡張できるようにし、より豊富なインサイトにつながる分析ユースケースを可能にする必要があります。

データへの容易なアクセスは、データがばらばらの事実の集まりである場合、組織にとってそれほど有用ではない可能性があります。分析、機械学習、サービス、アプリケーションなどのために、さまざまなソースからのデータを使用して、厳選されたビューと管理されたデータセットを構築します。

強力なリーダーは、明確なビジョンと目的を持ち、それを効果的に伝えて他の人を鼓舞する必要があります。感情的知性は不可欠であり、誠実さと倫理観を持って行動することも重要です。決断力、エンパワーメント、適応力、協調性、チーム構築は、ポジティブな職場環境を育成するために不可欠な特性です。責任感、回復力、結果への集中も、効果的なリーダーシップを示すものです。さらに、優れたリーダーは、チームメンバーの成長を確実にするためにメンターシップと能力開発を優先し、組織の長期的な成功に貢献します。インクルージョンを促進する多様で公平な文化を推進するリーダーを探してください。

知識共有行動を奨励するインセンティブ、表彰、または昇進を検討してください。

アクセス、ナビゲート、および貢献が容易なシステムを探してください。

離職データと退職インタビューを見て、繰り返しのパターンがあるかどうかを確認します。

従業員が付加価値の高いタスクに戻ることができるように、システムアクセス要求のターンアラウンドタイムを短縮します。

ワークフローの段階間の作業キュー（在庫）のサイズを測定することは、ボトルネックを定量化するのに適した方法です。多くのコミュニケーションチャネルをサポートするとコストが増加し、多くのチャネルは人々がどれを使用すべきかわからないため混乱を引き起こします。引き渡しポイントは通常、摩擦を引き起こします。

一部のシステムは、国固有の規制や文化の違いにより、違いが必要です。しかし、多くのシステムは、世界の他の地域と実質的に同じ動作をしながら、ローカルで開発されています。ローカルビジネスユニットは、グローバルに機能が優先されるのを待つことができないことがよくありますが、これにより、維持するのに非効率的な多くの同様のシステムが発生します。

チャットコメントは、システムとプロセスに対する従業員の満足度の指標となる可能性があります。センチメント分析ツールは、顧客のコメントによく使用されますが、社内システムの評価にも使用できます。

過度に多くのサポートチケットを受け取るシステムは、拡張または交換を検討する必要があります。

スタッフが外部システムに賛成するなら、社内システムが価値があるかどうかを検討する必要があります。

古く、時代遅れのシステムは、従業員の組織に対する感情を低下させるだけでなく、生産性にも悪影響を及ぼす可能性があります。魅力的な顧客体験に注力したいのと同じように、従業員を社内製品の顧客として扱い、目標達成に必要な最新のツールを提供する必要があります。これらのシステムを、顧客向け製品と同じように注意深く扱うことが重要です。つまり、社内ユーザーをこれらのシステムの顧客として扱い、製品思考のアプローチ、顧客調査、顧客サービスを、自社製品と同様に適用する必要があります。

ThoughtworksのLooking Glassレポートとテクノロジーレーダーは、GartnerやForresterなどのアナリストレポートと並んで、テクノロジーリーダーが現在および新興のテクノロジーについて知るのに役立つ2つの出版物です。ただし、新しいテクノロジーには注意が必要です。新しくきらびやかなテクノロジーは、テクノロジーのためだけに選択すべきではありません。顧客または従業員のいずれかに対する明確な価値創造が必要です。一部の組織では、イノベーショントークンを採用しています。イノベーショントークンの概念は非常にシンプルです。3つのイノベーショントークンが付与されます。イノベーション（つまり、標準以外のことを行う）を行うたびに、それらのトークンの1つを消費します。すべて使い切ったら、あなたは終わりで、それ以上イノベーションを行うことはできません。

信頼できるデータソースと過去のデータを確実に使用し、ビジネス目標に沿った関連性の高い指標に焦点を当てます。市場をセグメント化し、経済状況や技術の進歩などの外部要因を考慮します。業界のベンチマークや競合他社との比較分析を行い、業界の専門家からの意見を求め、前提を検証します。トレンドを継続的に監視し、データを視覚化し、将来の開発を予測し、それに応じてビジネス戦略を調整するために、将来を見据えたアプローチを採用します。

これらのより広範な問題を考慮することで、急速に発展する状況に迅速に適応できます。たとえば、最近、旅行業界のクライアントのテクノロジー戦略を完了しました。旅行インサイトデータと独自の顧客調査を使用して、COVID-19によるロックダウン後に旅行の形がどのように変化したかを調査しました。人々が不確かな時代に旅行に戻ってきたため、キャンセルと再予約の容易さが重要な要素になっています。したがって、テクノロジー戦略には、キャンセル、通知、バックオフィス統合の機能を改善することに焦点を当てることが含まれていました。また、MLがキャンセルの可能性を予測するのに役立つ良い例も特定したため、顧客が旅行に戻り、カスタマーサポートチームへの負荷を軽減するために、テクノロジー戦略にMLとデータエンジニアリングの導入を含めました。実際の問題を解決するきらびやかなテクノロジーであり、きらびやかなテクノロジーを使用するためのものではありません。