これまで7回にわたり、「公益業界のプラットフォーム動向と展望」を詳細に解説してきました。特に「第6回」と「第7回」では、公益業界におけるクラウドサービスの導入状況に焦点を当てました。今回の最終回では、適材適所のコンピューティングに関して深堀します。プラットフォームに限定せず、幅広い視点から適材適所のコンセプトについて考察します。
アプリケーションはその性質が多様です。一部の社員のみが使用する内部アプリケーションから、地域住民全体に公開されるアプリケーションまで存在します。以下の図は、採用技術と利用者を軸にアプリケーションの特性を分析したものです（あくまでイメージ図であり、配置は正確ではないことにご注意ください）。
「採用技術」は次のように分類できます
（1）利用者体験を重視する技術
（2）安定稼働を重視する技術
開発手法では、（1）は「人間中心デザイン」「デザインシンキング」、（2）は「業務プロセス中心デザイン」と表現できます。アプリケーションの特性に応じたモダナイゼーションへのアプローチが重要となります。
地域住民向けアプリケーションで期待される利用者体験は、エネルギー供給企業ではなく、Amazonや楽天のようなプラットフォーマーによって設定されます。利用者は、日常使うプラットフォームでの体験をすべてのアプリケーションに無意識に期待する傾向があります。
「開発スピード」と「変更頻度」を評価の軸として考えてみます。「利用者体験重視」領域では、迅速な新規アプリケーションの提供と頻繁な変更が必要です。デジタルデバイスの進化に対応するために、敏速性が重要視されます。対照的に、「安定稼働重視」領域では新技術への追従はあまり求められず、数年間変更なしで運用されるアプリケーションも存在します。この領域では安定と確実な処理実行が求められます。アプリケーションの特性に応じて適切な開発手法を選定し、要求される品質も考慮する必要があります。
「開発スピード」の軸を「独自性」に置き換えます。高い独自性と頻繁な変更が必要なエリアでは柔軟性と迅速性が重要です。この領域では、オンプレミスやパブリッククラウドに関わらず、クラウドネイティブ技術を積極的に採用します。クラウドネイティブ技術の採用は、ロケーションとは無関係です。Gartner社の提唱するNewオンプレミス（IBM外のWebサイトへ）は、従来のオンプレミスとは異なり、クラウドネイティブ技術を活用できます。
独自性が低い領域では、パッケージまたはSaaSの採用がモダナイゼーション・アプローチの一つです。これにより、定期的なバージョンアップで新機能を提供し、技術変革に追従できます。この領域では、パッケージやSaaSが最有力の選択肢となります。
下図はシステム・コンポーネントの概念に置き換えたものです。異なる特性を持つ大小のコンポーネントが組み合わさり、システム全体を形成します。理想的には、ビジネス・コンポーネントがITコンポーネント（サブシステム）に対応することが望ましいです。また、サービス（機能）とデータを漏れなく、重複なく扱うことが重要です。図の左下エリアは、データの効率的な読み書きと大量処理を行うアプリケーションに特化しています。このようなアプリケーションには、OS間通信やプロセス間通信を避け、処理効率を優先するモノリシック・アーキテクチャーが適している可能性があります（2023年現在）。
対照的に、図の右上エリアは機動性を重視しています。サービス（機能）単位でOSやデータを含むコンポーネントが形成され、これらは疎結合で関連付けられています。複数のコンポーネントを使用して業務サービスを提供し、コンポーザブルな構成により、機能の追加や不要機能の廃止が容易に行えます。このアプローチは、マイクロサービス・アーキテクチャーの採用を意味し、安全かつ迅速なシステムの見直しを可能にし、変化に強いシステムを実現します。この領域は海外に比べて日本が遅れている分野ですが、今後のIT技術と開発手法の採用が加速することが期待されます。そのため、企業のITチームは今から十分な対策を講じておくべきです。
さまざまな視点からアプリケーションの特性を考察しましたが、これを以前（第4回）紹介した「公益業界アーキテクチャー」にマッピングします。図の右上で変化が激しい領域は、フロント・サービス（フィールド・サービス）に対応します。この領域は新技術の継続的な導入により、利用者体験と業務効率化が図られます。マイクロサービス・アーキテクチャーが最適であり、DevSecOpsやコンテナ技術がこのエリアを支えます。一方、左下の効率性と安定稼働を重視するエリアはビジネス・サービスに対応し、モノリシック・アーキテクチャーが主流ですが、API化などの手法を用いてサービスとデータをフロントに提供することが必要です。
「公益業界アーキテクチャー（簡略版）」のデジタル・サービス層は、フロント・サービス（フィールド・サービス）とビジネス・サービスの間の調整層として機能します。この層はフロントに多様なビジネス・サービス（サービス・コンポーネント）を提供し、ビジネス・サービス層が持つサービスとデータをカタログ化（標準化）して提供します。これにより、フロント・サービスはビジネス・サービスについて深く考慮することなく、企業のサービスを利用できます。さらに、企業外を含むエコシステム全体のサービスも必要に応じて利用可能です。
ビジネス・サービス層も変化が見込まれます。主な変化として、規制料金システムのパッケージ化などが挙げられます。デジタル・サービス層の存在により、フロント・サービスはビジネス・サービス層の大きな変化に影響されずに、サービスを継続して活用できます。
フロント・サービス（フィールド・サービス）層
デジタル・サービス層
ビジネス・サービス層
モダナイゼーションのアプローチについて説明しましたが、実際にはアプリケーションはさらに複雑です。第6回で紹介したアプリケーション別のクラウド対応状況（下図の右側）と、今回説明した「安定領域」と「変化領域」のアプローチを組み合わせる必要があります。さらに、次の要因も考慮する必要があります。
モダナイゼーションの手法と実施時期を決定するために考慮すべき多くの要因について説明しました。IBMでは、公益業界版のモダナイゼーション簡易診断シートを用いて、現行アプリケーションの整理を支援しています。モダナイゼーションのアプローチを検討しているお客様は、ぜひ弊社の担当営業にお問い合わせください。
これまでの8回にわたる連載で、公益業界のプラットフォームについて詳細に整理しました。この情報が、モダナイゼーションに直面している担当者の方々にとって有益であれば幸いです。
最近、生成AIの台頭にともない、公益業界のアプリケーションにおけるAIの活用が再び注目されています。他業界での活用、特にコールセンター業務へのAIの採用の状況をみると、公益業界においてもさまざまな業務エリアにおいて採用されるでしょう。加えて、今回紹介したモダナイゼーションの領域においても「AI for Code」の活用が拡大すると予測されます。モダナイゼーションのロードマップにおいては、特にAIを含む最新技術の情報収集と、採用技術の定期的な見直しが重要です。機会があれば、これらのトピックについてもさらに詳しく解説したいと思いますが、プラットフォームの現状と方向性に関する説明は、今回で終了します。