2019年の現在は、デジタルトランスフォーメーション（DX）がIT部門の耳に入るようになった。定義や捉え方は企業によって異なるが、五輪特需や大型プロジェクトの活況が終わった先の2025年は、本格的なDXの時代が始まるであろう。しかし、期待されるDXは全社レベルで検討すべきビジネスの話か、IT部門が検討すべきITの話か――これまでのDXの前身に当たる方法論をもとに、2025年に想定される事象をシミュレーションし、その先のIT部門の年齢構成の変化も読み解きながら、DX時代のIT部門の姿を全8回の連載で占う。第1～4回はDXのガバナンス、第5～8回はDXのテクノロジーがテーマだ。
第7回では、企業がDXを推進する際に、クラウド側（パッケージ側）の仕様に合わせる「適用性」について解説した。ここでは、氷河期の寒さに適応すべくマンモスが毛を生やすのと同じように、企業もDXのシステム開発として、パブリッククラウド（パッケージ）への適用性が必要であることを解説した。本連載の最終となる第8回では、社内システムのDX化として、DXを推進する際のカスタマイズ（※）を解説する。
カスタマイズ：製品やパッケージなどのソフトウェアの資産に、提供元より承諾を得てソースコードを自社用に自由に直す開発。ただ、製品やパッケージ側は、2年に1回などバージョンアップがあるため、ソースコードの総入れ替えが発生する。カスタマイズをした企業は、自社で改修してしまったソースコードの変更箇所を控えておき、新しいバージョンに手作業で変更箇所を復元する。
DX推進での企業のカスタマイズとは？
第7回で解説した「適用性」とは、一見簡単そうであるが、従来のカスタマイズが好きなIT部門やお金で解決したいビジネスサイドから見ると、不便に違いない。つまり、ソフトウェア（製品）をカスタマイズせず、そのまま標準機能を使うと、今までの機能が使えないからである。
ビジネスサイドは「カスタマイズ主義者」
2025年に向けたDXにおいて、本連載の第1～6回に触れた内容は、どちらかと言えば新しいテクノロジーで“わくわく”する話であった。しかし、社内のシステムも担当する方には、社内システムのDX化も知りたいはずである。その際、モバイル、パブリッククラウド、ビックデータ、IoT、AI（人工知能）などのテクノロジーが、IT部門管轄のどのシステムに対応するのか、どのくらい予算がかかるのか、期間はどのぐらいか、どこが予算を捻出するのか検討する。
ただ、その際にはほとんどのIT部門がある程度実績のあるパッケージを製品として選定し、その製品を大幅にSI案件でカスタマイズするDX化を検討してしまうだろう。
図20.立教大学の認証基盤におけるシステム連携の構成図（出典：日本情報システムユーザー協会、2020年1月）
※クリックすると拡大画像が見られます
図20は、立教大学の認証基盤である。立教大学では、学生（約2万人）と教職員（約3000人）の人事システムに相当する認証基盤を持っている。この規模は、民間企業のカンパニー制や連結企業（グループ会社）の総数とほぼ同じである。
立教大学では、カスタマイズを極力避ける仕様で人事、IAG（アイデンティティ／アクセス／ガバナンス＝IDM製品、プロビジョニング）まで構築していた。具体的には、1999年にUW-IMAPサーバー（メール）から、2010年にはGoogle Apps（現在のG Suite）を採用してSAML 2.0認証を開始し、2012年には「学術認証フェデレーション（学認）」にShibboleth認証を開始した。2013年には、Office 365も平行して採用し、「Active Directory Federation Services」（ADFS）認証を搭載した。
カスタマイズより自前のシステムの設定（コンフィグの変更）
立教大学では、各フェデレーションを採用する際に、年数を掛けて接続（システム）変更をしている。また、単年度案件ではリスクが大きいとも考えている。大学の中でも新しいことを率先していたため、試験導入と安定稼動を兼ねるチャレンジ精神があった点は、現在のDXのテクノロジーと同じである。
ここで、立教大学において一貫しているポリシーは、学生・教職員の個人情報や関連するデータは無理にパブリッククラウド上へ展開しないことである。図20では、フェデレーションを使わなければ、個人情報を当時の海外のパブリッククラウド側にアップロードする必要があった。立教大学では、コンプライアンスがシステム開発より重要な要素と規定している。フェデレーションでは、ディレクトリーに相当する部分をパブリッククラウドにアップロードする必要がない点、従来の認証よりも進化している。
