レガシーシステムをどうするか悩まないために、自社オリジナルの「羅針盤」を持つこと

「テクノロジー・アーキテクチャ（TA）」とは？

　エンタープライズ・アーキテクチャ（EA）は、「ビジネス・アーキテクチャ（BA）」「データ・アーキテクチャ（DA）」「アプリケーション・アーキテクチャ（AA）」「テクノロジー・アーキテクチャ（TA）」の4つのドメインで構成されています。

　TAでは、企業・組織のビジネス目標や要件を実現するためのインフラに焦点を当て、アーキテクチャを作成します。BA/DA/AAの実装に必要なITシステムの構成要素や要素間の接続を洗い出して可視化。最終的にはハードウェアやソフトウェア、ネットワーク、クラウドサービスなどの物理的なコンポーネントに落とし込んでいきます。

　TAでの活動には、IT標準の策定やリファレンス・アーキテクチャーの整備も含まれます。今後のインフラ設計・実装のガイドラインとなる文書を定義することで、変化していくビジネスニーズやテクノロジーの進化にも適応できる柔軟性を持たせます。

　キンドリルのアーキテクトは、EAにおける4つのドメインのうち、TAの領域を主戦場としています。しかし、インフラに対する要件とその実現に着目してアーキテクチャを策定することだけが目的ではありません。最終的にはお客様のビジネス目標達成を支援し、ステークホルダーのニーズを満たすことが重要です。特定のお客様専任で担当するチーフアーキテクトとしてビジネス課題をどう解決していくか、お客様のビジネス背景やIT環境を理解していることをベースに、BA/DA/AAに対する理解を深めて、ビジネス要件からデータ要件、アプリケーション要件を導きます。そこからインフラ要件に落とし込み、TAの決定を行うという一連の論理のつながりを意識することが大切だと考えています。

TAを策定する4つのステップ

　TA策定における一つの手法として、キンドリルでは「ロードマップアプローチ」を実践しています。お客様のITシステム全体の変革や次期システムの構想など、中長期的にITシステムのライフサイクル管理をどのようにしていくべきか、ハイレベルの計画を必要とした際に、このアプローチを適用します。ロードマップアプローチは、第1回で示された通り、以下のステップです。

1. お客様の戦略達成に向けた課題抽出
2. 課題が解決される理想の追求と現実の把握
3. 理想と現実のギャップを埋める施策の検討
4. 施策を実現するためのロードマップの策定

　まず始めに、既存IT環境や課題に関する資料収集や、ステークホルダーの方々へのヒアリングを実施し、システムの現状（As-Is）モデルおよびIT課題を可視化。そのときに、BA/DA/AAのアウトプットを入手したり、一番の命題となるお客様のビジネス方針や取り組みを把握するために、中期経営計画やDX戦略も随時参照したりします。

　TA策定の段階になると、インフラ領域を担当する方が主メンバーとして検討体制に参画するケースが多いかと思いますが、必要に応じてシステム部門の企画やアプリケーション担当者や業務部門の方も巻き込み、ディスカッションに参加してもらうことが、EA策定のポイントです。たとえば、非機能要件を見極めるために業務の重要度の確認、システムの密結合度を鑑みて配置プラットフォームを検討するために業務フローの理解、といったことを行います。