第8回適材適所コンピューティングへのアプローチ｜公益業界におけるプラットフォームの現状と方向性

連載「公益業界におけるプラットフォームの現状と方向性」

第8回 適材適所コンピューティングへのアプローチ

これまで7回にわたり、「公益業界のプラットフォーム動向と展望」を詳細に解説してきました。特に「第6回」と「第7回」では、公益業界におけるクラウドサービスの導入状況に焦点を当てました。今回の最終回では、適材適所のコンピューティングに関して深堀します。プラットフォームに限定せず、幅広い視点から適材適所のコンセプトについて考察します。

アプリケーションはその性質が多様です。一部の社員のみが使用する内部アプリケーションから、地域住民全体に公開されるアプリケーションまで存在します。以下の図は、採用技術と利用者を軸にアプリケーションの特性を分析したものです（あくまでイメージ図であり、配置は正確ではないことにご注意ください）。

「採用技術」は次のように分類できます
（1）利用者体験を重視する技術
（2）安定稼働を重視する技術

開発手法では、（1）は「人間中心デザイン」「デザインシンキング」、（2）は「業務プロセス中心デザイン」と表現できます。アプリケーションの特性に応じたモダナイゼーションへのアプローチが重要となります。

地域住民向けアプリケーションで期待される利用者体験は、エネルギー供給企業ではなく、Amazonや楽天のようなプラットフォーマーによって設定されます。利用者は、日常使うプラットフォームでの体験をすべてのアプリケーションに無意識に期待する傾向があります。

「開発スピード」と「変更頻度」を評価の軸として考えてみます。「利用者体験重視」領域では、迅速な新規アプリケーションの提供と頻繁な変更が必要です。デジタルデバイスの進化に対応するために、敏速性が重要視されます。対照的に、「安定稼働重視」領域では新技術への追従はあまり求められず、数年間変更なしで運用されるアプリケーションも存在します。この領域では安定と確実な処理実行が求められます。アプリケーションの特性に応じて適切な開発手法を選定し、要求される品質も考慮する必要があります。

「開発スピード」の軸を「独自性」に置き換えます。高い独自性と頻繁な変更が必要なエリアでは柔軟性と迅速性が重要です。この領域では、オンプレミスやパブリッククラウドに関わらず、クラウドネイティブ技術を積極的に採用します。クラウドネイティブ技術の採用は、ロケーションとは無関係です。Gartner社の提唱するNewオンプレミス（IBM外のWebサイトへ）は、従来のオンプレミスとは異なり、クラウドネイティブ技術を活用できます。

独自性が低い領域では、パッケージまたはSaaSの採用がモダナイゼーション・アプローチの一つです。これにより、定期的なバージョンアップで新機能を提供し、技術変革に追従できます。この領域では、パッケージやSaaSが最有力の選択肢となります。

下図はシステム・コンポーネントの概念に置き換えたものです。異なる特性を持つ大小のコンポーネントが組み合わさり、システム全体を形成します。理想的には、ビジネス・コンポーネントがITコンポーネント（サブシステム）に対応することが望ましいです。また、サービス（機能）とデータを漏れなく、重複なく扱うことが重要です。図の左下エリアは、データの効率的な読み書きと大量処理を行うアプリケーションに特化しています。このようなアプリケーションには、OS間通信やプロセス間通信を避け、処理効率を優先するモノリシック・アーキテクチャーが適している可能性があります（2023年現在）。

対照的に、図の右上エリアは機動性を重視しています。サービス（機能）単位でOSやデータを含むコンポーネントが形成され、これらは疎結合で関連付けられています。複数のコンポーネントを使用して業務サービスを提供し、コンポーザブルな構成により、機能の追加や不要機能の廃止が容易に行えます。このアプローチは、マイクロサービス・アーキテクチャーの採用を意味し、安全かつ迅速なシステムの見直しを可能にし、変化に強いシステムを実現します。この領域は海外に比べて日本が遅れている分野ですが、今後のIT技術と開発手法の採用が加速することが期待されます。そのため、企業のITチームは今から十分な対策を講じておくべきです。

参考情報 IPA DX白書2023（IBM外のWebサイトへ）

さまざまな視点からアプリケーションの特性を考察しましたが、これを以前（第4回）紹介した「公益業界アーキテクチャー」にマッピングします。図の右上で変化が激しい領域は、フロント・サービス（フィールド・サービス）に対応します。この領域は新技術の継続的な導入により、利用者体験と業務効率化が図られます。マイクロサービス・アーキテクチャーが最適であり、DevSecOpsやコンテナ技術がこのエリアを支えます。一方、左下の効率性と安定稼働を重視するエリアはビジネス・サービスに対応し、モノリシック・アーキテクチャーが主流ですが、API化などの手法を用いてサービスとデータをフロントに提供することが必要です。

「公益業界アーキテクチャー（簡略版）」のデジタル・サービス層は、フロント・サービス（フィールド・サービス）とビジネス・サービスの間の調整層として機能します。この層はフロントに多様なビジネス・サービス（サービス・コンポーネント）を提供し、ビジネス・サービス層が持つサービスとデータをカタログ化（標準化）して提供します。これにより、フロント・サービスはビジネス・サービスについて深く考慮することなく、企業のサービスを利用できます。さらに、企業外を含むエコシステム全体のサービスも必要に応じて利用可能です。

ビジネス・サービス層も変化が見込まれます。主な変化として、規制料金システムのパッケージ化などが挙げられます。デジタル・サービス層の存在により、フロント・サービスはビジネス・サービス層の大きな変化に影響されずに、サービスを継続して活用できます。

下図は既存システムの移行先を「公益業界アーキテクチャー（簡略版）」にマッピングしたものです。アプリケーションの特性に応じて最適な移行先が異なり、モダナイゼーションの方法は複雑になる可能性があります。適切な移行先と方法の選択が重要です。以下に各層の特徴を整理しました

フロント・サービス（フィールド・サービス）層
• 顧客・パートナー向けアプリケーション
• 既存フロントのDXアプリケーション
• 変更が頻繁に必要なアプリケーション
• 複数のデータセンターを使用した分散処理が効果的なアプリケーション
• AIなどの最新技術を取り入れる事で価値が高まるアプリケーション
• マネージド・サービスの活用で運用を軽減するアプリケーション
• クラウド・サービスのコンテンツ配信（キャッシュ）やセキュリティー機能が有用なアプリケーション

デジタル・サービス層
• 主にビジネス・サービス層のサービスを利用するアプリケーション（サービス提供層）
• 主にビジネス・サービス層のデータを利用するアプリケーション（データ提供層）
• オンプレでクラウド・ネイティブ技術を活用するアプリケーション（Newオンプレプレミス）

ビジネス・サービス層
• 一元化された大量バッチ処理を短時間で完了させる必要があるアプリケーション
• 高い保守安定性を要求されるアプリケーション
• 最新のセキュリティー技術（耐量子暗号など）の採用が求められるアプリケーション

モダナイゼーションのアプローチについて説明しましたが、実際にはアプリケーションはさらに複雑です。第6回で紹介したアプリケーション別のクラウド対応状況（下図の右側）と、今回説明した「安定領域」と「変化領域」のアプローチを組み合わせる必要があります。さらに、次の要因も考慮する必要があります。

• 外的要因：規制の撤廃や約款の変更可否などで、システムの改修（構築）規模が大きく変わる可能性があります。
• アーキテクチャー：業務アプリケーションが設計された時代に応じて、採用されているアーキテクチャーが異なります。公益業界では40年以上前のアプリケーションが稼動している場合も多く、2030年以降の運用を前提にアーキテクチャーを再検討する必要があります。アーキテクチャー変更の有無はモダナイゼーション手法を検討する上で重要な要因です。
• ブラックボックス化リスク：アプリケーションの保守においては、保守要員の確保が非常に重要です。特に古いアプリケーションが多い公益業界では、設計を熟知した要員の退職リスクも考慮する必要があります。
• 言語（開発環境）：現行アプリケーションで採用されている言語はモダナイゼーション判定の重要なインプットになります。一方、言語の変更（リライト）や開発環境の刷新だけでは多くの場合本質的な問題解決には至りません。業務アプリケーションのアーキテクチャーを変更が不要で且つ保守要員を確保できる場合おいては、開発環境の刷新や言語の変更が有効な場合もあります。一方、言語や開発環境に注目し過ぎると、アプリケーションの本質的な問題を解決せずに改修作業を実施し、不必要な投資を行うリスクがあります。まずはアプリケーションのアーキテクチャーとブラックボックス化リスクの検討が推奨されます。
• 接続先システム要件：接続先システムによって、アプリケーションの変更が難しい場合があります。発電所のシステムと連携するアプリケーションは、発電所側のシステム変更に合わせて変更する必要があるかもしれません。接続先システムの整理はモダナイゼーションのロードマップ策定において重要です。

モダナイゼーションの手法と実施時期を決定するために考慮すべき多くの要因について説明しました。IBMでは、公益業界版のモダナイゼーション簡易診断シートを用いて、現行アプリケーションの整理を支援しています。モダナイゼーションのアプローチを検討しているお客様は、ぜひ弊社の担当営業にお問い合わせください。

これまでの8回にわたる連載で、公益業界のプラットフォームについて詳細に整理しました。この情報が、モダナイゼーションに直面している担当者の方々にとって有益であれば幸いです。

最近、生成AIの台頭にともない、公益業界のアプリケーションにおけるAIの活用が再び注目されています。他業界での活用、特にコールセンター業務へのAIの採用の状況をみると、公益業界においてもさまざまな業務エリアにおいて採用されるでしょう。加えて、今回紹介したモダナイゼーションの領域においても「AI for Code」の活用が拡大すると予測されます。モダナイゼーションのロードマップにおいては、特にAIを含む最新技術の情報収集と、採用技術の定期的な見直しが重要です。機会があれば、これらのトピックについてもさらに詳しく解説したいと思いますが、プラットフォームの現状と方向性に関する説明は、今回で終了します。

連載「公益業界におけるプラットフォームの現状と方向性」

第1回 統合か共存か、2種の料金システム
第2回 旧料金システムの終活
第3回 Z世代にバトンを渡す“システム運用”
第4回 “旧料金システム”のモダナイゼーション
第5回 モダナイゼーションの壁
第6回 クラウドサービスの活用
第7回 クラウド・サービスとオンプレミスの共存