キヤノンマーケティングジャパン（キヤノンMJ）は7月2日、同社グループの基幹系システムを刷新したと発表した。これはPaaS（Platform-as-a-Service）に相当する共通基盤で、「攻めのIT」への転換という目標のもと、実現に2年を費やしたという。
今回構築した共通基盤の社内呼称は「iCap（Integrated Common Applications Platform）」と呼ばれ、これまでシステムごとにバラバラだったデータ連携、認証、運用管理、帳票、ワークフローの5つの主要機能を共通化した。同社グループは2012年に開設した「西東京データセンター」で、顧客向けのITサービスとグループ内向けのシステムを運用しており、「iCap」も同施設の環境で構築されている。
キヤノンMJの主力事業はキヤノン製品の国内向け販売やサポートだが、2008年にグループ内のIT企業として「キヤノンITソリューションズ（CITS）」を設立するなど、IT事業を拡大してきた。2019年度から3カ年の中期経営計画の中では、ITソリューションによる増収増益を戦略の1つに位置付ける。
「iCap」の構築はその一環で、企業顧客のデジタル変革支援にとって必要とするクラウド対応の本格化やアプリケーション開発などへのITリソースのシフトが主な目的になる。システム基盤については、西東京データセンター開設後から仮想化共通基盤（IaaS「SOLTAGE」のサービス基盤の一部をグループ内向けに運用している）へ順次移行させてきたが、大半の業務システムのアプリケーションやPaaS相当の機能はサイロ化した状態が続いていたという。
同社IT本部 ITアーキテクト部長の田中太郎氏は、「グループ各社の業務システムの多くがサイロ化したオンプレミスで稼働し、よく言われるようなIT予算の8割を運用コストが占める非効率的な状況だった。導入製品のサポートが終了するタイミングなどもあり、運用改善によって開発投資への割合を拡大させると同時に、デジタル変革に伴うクラウド化や開発力の強化も進める必要があった」と話す。
共通基盤化した5つの機能における狙い（出典：キヤノンマーケティングジャパン）
田中氏よれば、共通基盤の構想自体は前からあり、2017年頃に本格的な検討を始め、2年をかけて構築した。ポイントは、（1）業務システムごとにバラバラだった認証機能の共通化とガバナンスの強化、（2）システム間連携の疎結合化とサービスレベルの最適化、（3）開発の生産性と品質の担保――の3点になる。
まず統合認証基盤では、従業員が複数のIDで各種業務システムを利用する状況を踏まえ、一部SaaSへの切り替えを含む認証連携の導入で、シングルサインオン化と権限管理の強化を図った。SaaSではMicrosoftのOffice 365やSharePoint、Teams、Skypeなどを導入、認証連携にはオージス総研の「テミストラクト」を採用した。「ID連携サービスが人気だが、多くはユーザー数に応じたライセンス体系で、約1万7000人がいる当社グループの規模ではかなりの費用になることが課題だった」（田中氏）
システム間連携では、サイロ化したシステム同士の密結合状態を解消すべく、新たに「IBM InfoSphere DataStage」をベースとするデータ連携基盤を構築。システムの独立性を高めることで、万一の障害時の影響範囲を極小化させるとともに更改時の作業工数を減らし、クラウド連携も容易にした。
運用面でも、「従来はシステムごとのサービスレベルを厳密に定義しておらず、一律に最高レベルを設定してしまい運用コストが肥大化していた」（田中氏）という。このため、システムの重要度に応じたサービスレベルを設定してコストを最適化させていく運用に変更した。併せてCITSによる運用監視やログ管理、ITILに準拠した運用業務プロセスの管理などを整備し、ITサービスマネジメントを確立する。
開発の生産性と品質の担保に関しても、システムごとにバラバラだった帳票系とワークフローを統一させた。ここでは、「imageWARE Form Manager」や「Web Performer」などグループ自前の製品を活用している。
今回のiCap構築により、同社では運用コストの20％削減と開発効率の30％向上を見込んでいる。また、外部パブリッククラウドサービスとの連携も始めている。田中氏によれば、一部ウェブサイトの基盤を自社からAmazon Web Services（AWS）に移行させており、ノウハウの習得とコストの削減を図れているとのこと。2021年には会計系システムなどもクラウドに移行する予定だという。
田中氏は、一連の取り組みから留意や検討すべきポイントも見えてきたと話す。
例えば、iCapで共通基盤化した機能は、これまでインフラエンジニアがシステムごとに運用していたが、今後はその多くの運用を自動化していく。端的には、定常時にインフラエンジニアのリソースに余裕が生まれる一方、多かれ少なかれアプリケーションエンジニアのリソースを運用にも割り当てることになる。また、新規あるいは追加の開発（非定常時）でインフラリソースを変更する場合は、インフラエンジニアのノウハウやリソースが必要になる。
「IaaSやPaaS領域の運用をある程度自動化できれば、エンジニアの負担が減り戦略的に動けるようになる。ただ、非定常時のインフラ対応をどうすべきかなどの課題が起きかねない。要件定義の段階から運用フェーズを十分に考慮して設計していくことが重要になる」（田中氏）
SaaSなどを利用する際でも、例えば障害時の運用に留意すべきという。例えば、同社では以前にコールセンターシステムへの接続が西日本地域だけ遮断され、東日本地域ではこの障害が起きなかった。原因は当時導入していたセキュリティサービスのバージョンアップで、バージョンアップが行われた西日本地域で障害が起き、バージョンアップが行われなかった東日本地域では影響がなかった。
「事前に、どの地域のサービス提供基盤でバージョンアップが行われるのかが分かれば、回避できたはず。サービス提供会社によっては詳しい運用計画や状況をユーザーに明かさないので、提供会社のポリシーをきちんと把握しておくことが肝心だ」（田中氏）とアドバイスしている。
