Japanese IT management

2024年のDevRel予測は、予算管理の厳格化と活動成果の強化が予想されています。日本では目標設定がゆるく、海外の取り組みが浸透しつつあります。また、コミュニティと教育が重視され、ローカライゼーションやパーソナライゼーションが必要とされています。企業内でのDevRel文化の確立も今後の課題です。

　オンプレミスインフラあるいはクラウドサービスに構築したアプリケーションと、SaaS（Software as a Service）を併用する場合、企業のIT部門はデータのサイロ化（連携せずに孤立した状態になること）という課題に直面する。この課題について、調査会社 Forrester Researchでシニアアナリストを務めるデビッド・ムーター氏は次のように分析する。「SaaSと非SaaSの対立というよりも、アプリケーションの量の問題だ」 ムーター氏によれば、今や大企業では何百というアプリケーションを利用することも珍しくない。アプリケーション間の接続数は理論上、新しいアプリケーションが追加されるたびに指数関数的に増加する。つまり、個々のアプリケーション間をポイントツーポイント（2拠点間）で結び、管理するのは持続可能な方法ではないということだ。IT部門はどうすればいいのか。 そもそも「API」の役割は？ 「SaaSの利用が無秩序に拡大しているからといって、企業が従来利用していたシステムが一夜にして消え去るわけではない。置き換えるには膨大なコストがかかる」とム―ター氏は指摘する。ムーター氏はITリーダーに対し、レガシーシステムを、クラウドサービスで動作することを前提に構築する「クラウドネイティブアプリケーション」と連携させることで延命を図る方法を検討するよう勧めている。 ただし、例えレガシーシステムから脱却しても、アプリケーション間の連携は依然としてIT部門にとって負担だ。ビジネス要件の変更が生じた際、従来のIT部門は変更に対処するために、アプリケーション間やデータベース間をいかに接続するかを検討してきた。「扱うアプリケーションの数が少なければその方法で済んだが、現在は、接続が指数関数的に増加するという問題にぶつかっている」（ムーター氏） ムーター氏によれば、今後のIT部門が注力すべき領域はAPI（アプリケーションプログラミングインタフェース）だ。「IT部門は誤解していることがあるが、企業に価値を生み出すのはビジネスプロセスであり、アプリケーションではない」とムーター氏は断言する。同氏が勧めるのは、ビジネスプロセスとその要件を定義した上で、要件を満たすにはどんなアプリケーションを構成する必要があるのかを考えるやり方だ。この時、APIはビジネスプロセスとアプリケーションをつなぐ存在となる。 実際にAPIが生きる場面について、ムーター氏は次のように説明する。「例えば、新しいパートナー企業のために受注処理が必要になった時だ。3つの受注管理システムと8つのERP（統合基幹業務システム）を新しいパートナー企業と接続することなく、受注処理APIを呼び出すだけで済む」 短期的には、ポイントツーポイントで接続を構築する方が容易だ。社内に存在するアプリケーションが限られており、将来的に規模の拡大や再利用が必要ない状況であればわざわざAPIを開発しなくてもよい。ただしムーター氏は次のように提言する。「将来のことを考えれば、基本的に各企業は業務プロセスのニーズに沿ったAPIにアプリケーションを組み込む努力をすべきだ」 データ統合ツールで何ができる？ SaaSとSaaS以外の企業向けシステムにおけるデータの統合に関しては、データ統合ツールの採用を検討する方法もある。 Forrester Researchのバイスプレジデントでプリンシパルアナリストを務めるミシェル・ゲッツ氏によれば、データ統合ツールはデータの収集と分類、更新、変更、削除、結合、整合性維持、クレンジング（不正確なデータの排除）などの機能を持つ。データ統合によって、以下のような効果が期待できるという。 データレイク（構造化データと非構造化データをまとめて保管できるデータベース）やデータウェアハウス（DWH）へのデータの取り込み ストリーミングデータのパイプライン（処理手順）のオーケストレーション（設定や管理の自動化） 異なる基盤にあるデータのマッピングと照合 「データ統合のプロセスを、アプリケーションの連携や自動化プロセスとまとめる場合は、APIがパイプ役を担えるだろう」（ゲッツ氏） 後編は企業のデータ統合におけるトレンドを分析するとともに将来を予測する。…