徹底した標準化の推進
他社へのヒアリング、プログラム変換ツールの
PoCなどを実施し、プロジェクトを成就
要求されるスキルセットが
プラットフォームごとに異なる
1979年設立のソニー生命保険（以下、ソニー生命）では、基幹システムを代々IBMメインフレーム上で稼働させるとともに、さまざまな業務系アプリケーションをPCやオープン系サーバー上に構築してきた。開発は会社設立以来、内製主義を貫き、2014年時点における運用中のシステムは470本、開発中のシステムは35本（20人月以上）で、これをシステム部員170名、協力会社約1000名の態勢で回していた。
しかし当時、システム障害が頻発していたために新規開発が計画どおりに進まず、社員・協力会社とも疲弊しきっていたことは、Part 1で触れたとおりである。そして2014年4月に長谷川樹生氏がITデジタル戦略本部の本部長に着任し、システム部門の改革がスタートした。
改革の大きな方針の下、個別計画を立てるにあたって問題とされたのは、すでに保守切れとなっているシステムや近い将来保守切れを迎えるシステムが多数あることだった。それらはいずれもきわめて重要なシステムばかりである。
しかも、事業規模の急速な拡大と環境の変化に合わせて導入してきたシステムが多種多様な技術プラットフォームを採用しており、その維持管理に多大な負担がかかっていることも問題視された（図表1）。
「当時はプロジェクト・ファーストが当社の一般的な考え方で、プロジェクトが確定すると責任者がその都度最適な技術やプラットフォームを選択する形を採っていました。私もさまざまなシステムの開発を担当してきましたが、案件が発生するたびに調査と検証を行い、最適と考える技術・製品・ツールを採用してきました。そしてそうした選択が長期にわたって続けられてきた結果、会社全体で見るとさまざまな技術プラットフォームが乱立し、そのシステムの担当者でないと詳細がわからないという状況になっていました。その弊害は、要求されるスキルセットが技術プラットフォームごとに異なるので、開発や改修を弾力的に行えないことです。このことは、当社が掲げる顧客本位のサービス提供にとって重大な阻害要因でした」と説明するのは、ITデジタル戦略本部の加藤真史氏（グループウェア開発部 IS開発8課 主事）である。
Web領域に照準
3つの目標を設定
その加藤氏に、「今後30年を見据えたシステムの統廃合と技術標準の策定」の命が下ったのは2016年10月のことである。
「その当時はシステムの老朽化に伴う問題も多数顕在化し、障害時のサポート能力の低下も懸念され始めていたので、システムの統廃合や技術標準の策定は待ったなしの状況と言えました」と、加藤氏は振り返る。
加藤氏がまず着手したのは、全社で利用中のWeb関連システムの実態調査である。この作業では、2016年7月の本社移転に備えて作成されたシステムの棚卸し資料があったので利用し、全470システムのそれぞれの主管部署にヒアリングを行い、現状を把握した。
図表2は、そのまとめとして同社のシステム群がどのようなプラットフォームで稼働しているのかを示したものである。
「当社は開発言語で見ると、メインフレームはCOBOL、オープン系システムはJavaときれいにすみ分けができています。ただし、JavaのWebフレームワークの領域においては10種類にも上る多種多様な技術が使われ、今後もオープン系という性格上、さらに増えていく恐れがありました」（加藤氏）
そこで加藤氏は、技術標準の策定はWebの領域においてこそ急務の課題であると考え、次の3つの目標を設定した。
・Web標準プラットフォームの策定と構築
・既存システムの統合
・技術標準の規定と恒久的な維持・管理のための仕組み作り
「既存システムを統合するにしても、長期に使われる技術基盤の上で行わなければ価値はありません。そのこととWeb標準プラットフォームの策定は表裏一体の話で、両方を視野に入れて取り組むこととしました。また、新しい技術が次々に登場するなかでプラットフォームの乱立を未然に防止するには、技術全体を評価する全社的な基準とその維持・管理のための仕組みが不可欠です。それも合わせて検討を進めることにしました」と、加藤氏は目標設定の理由を語る。
加藤氏は、目標に従って具体的な取り組みをスタートさせる前に、生保企業を中心とする他社へのヒアリングを行っている（2016年末〜2017年前半）。テーマは、Web標準フレームワークの導入状況と、技術標準のコントロール方針、およびその維持・管理体制について。加藤氏は、「当社のポジションを理解しておくことは、目指すべき姿を考えるうえでポイントになると考えました」と話す。
ヒアリングの結果をマッピングしたのが、図表3である。技術標準の「コントロール」と「維持管理体制」の観点で見ると、「他社に遅れをとっている」ことが明らかだが、目標が達成されれば「立ち位置が大幅に改善される」（加藤氏）ことも示されている。「他社へのヒアリングは、取り組みへの弾みと励みになりました」と、加藤氏は言う。
技術の選定から
実機検証へと進む
Web標準プラットフォームのための技術選定は、次の4つを基軸に実施した。
・スタンダード技術であること（評価方法は、GitHubのStar数・Contributions数。Maven RepositoryのUsages数）
・技術の維持団体の活動が活発であること（バージョンアップの頻度が落ち、活動量が低下した団体は解散のリスクがある）
・技術を組み合わせた場合の相性がよいこと（組み合わせを軽視し非推奨の技術を採用すると、開発生産性に大きく影響し、プラットフォームの品質を左右する）
・容易にバージョンアップできる構成であること
そして、この基準に基づき選定した技術が図表4・図表5である（「グランドデザイン」と呼ぶ）。
たとえば「データアクセス（ORマッパー）」の選定では、SpringJDBC、MyBatis、Hibernateの3つを俎上に乗せ、「社内における利用実績」「業界における普及」「チューニングのしやすさ」「機能」「開発効率」の5つの観点で評価した。そして、リプレース時にGenerator（自動生成）機能を利用できるMyBatisを、最後まで競ったSpringJDBCを退けて選定している。
ただしこの選定は、机上での評価である。机上と現場では評価が異なることもままある。そこで加藤氏は、選定した技術を実機で検証するフェーズへと進んだ。
「これまでの経験で、採用した技術が想定どおりの挙動にならず、追加修正や業務要件の変更を余儀なくされたことがありました。それを防ぐために動作検証を行い、実際に確認することにしました」（加藤氏）
技術検証は、次のようなプロセスで実施した（図表6）。
①Web標準プラットフォームで要求される機能を整理し（26種の機能になった）、選定した技術を使って機能を設計・開発する（「アーキテクチャ設計」工程、図表7）
②設計・開発した26種の機能を実機検証（「技術検証」工程）
③①と②を並行して実施し、結果を随時、アーキテクチャに反映させる
検証は本番を想定した環境で実施した。たとえばデータベース・アクセスでは、本番で使用するのと同等のデータベース環境を用意し、それに対して開発した機能でDBアクセスライブラリの自動生成や各種データアクセスなどが正常に行われるかを確認するというものである。
検証の結果、想定外の挙動を11件検知し、アーキテクチャの設計を見直した。うち2件は、アプリケーション開発の通常のテストフェーズでは検知が難しいもので、「実運用に入ってから問題が発覚すると、ユーザーと開発現場に大きな影響を与える恐れがあるものでした。技術検証の必要性を改めて痛感しました」と、加藤氏は感想を述べる。
Web標準プラットフォームを構成する技術の検証を2017年末までに終え、「Web標準プラットフォーム v1.0」（2018年6月）を完成させたことによって、既存のWebシステムを統合する準備が整った。
既存のWebシステムは55本。このなかで、老朽化が進行しているものとセキュリティリスクが高いシステムを優先的に対象とし、廃止や別システムへの移管が検討できるものなどを除外して、移行対象システムを25本に絞った。
プログラム変換ツールは
大きな武器になる
統合にあたって最もコストがかかるのは、旧システムから新しいプラットフォームへの移植作業である。そこで、従来からの開発方法で25システムの移植・統合費用を試算したところ、投資計画の1.64倍になることが判明した。そこから、今回のプロジェクトでは不要となる業務要件定義などの費用を引いても1.4倍という予算オーバーの結果となった。これではプロジェクトを前に進められない。
実は加藤氏は、2016年10月に担当になった直後から、こうした事態も想定して対応策の検討を進めてきた。
「システムの移植・統合プロジェクトは、想像以上にコストがかかるのが通例です。それを見越して、どうコストを削減するか、どのように生産性を上げるかを当初から視野に入れ、いろいろと模索してきました」（加藤氏）
加藤氏が注目してきたのは、ソフトロード社のプログラム変換ツールを利用する移植である。前出の他社へのヒアリングの際にも、そのツールを使った移行経験をもつ1社を訪ねて変換の精度やコストなどを確認し、手応えをつかんでいる。ツールを利用できれば、手動による移植と比べてコストを大幅に圧縮できる可能性がある。
加藤氏は、ソフトロード社のツールによるPoCを強く進言。そして上層部の了解を得て、PoCへと進んだ。
PoCに先立ち、移行対象とした全25システムの技術特性の洗い出しを行った。その結果、IBMのWebフレームワークであるWACs（Web Application ComponentsS）を使用するシステムと、メインフレームのCOBOL資産をJavaからコールする仕組みが多いことが明らかになった。
PoCの対象プログラムとしては、4つの業務システムを選定した。この4つで、同社のシステムの技術特性をすべて網羅できる。
PoCの結果は、実施前の想定（変換率62.0％）を大きく上回る82.8％という高水準の変換率をはじき出した（図表8）。このツールを使って全25システムの移植・統合を行えば、投資計画の約40％（60.9％減）の費用で済むという試算が得られた。これでプロジェクトを前へ進めることができる。
加藤氏は、「今回のPoCにより、システム統合のコスト削減策としてプログラム変換ツールが大きな武器になることが確認でき、システムの移植・統合への大きな弾みとなりました」と述べる。
同社では2019年4月から、残りの21システムの移行・統合作業を進行させている。
「今のところ、新しいWebプラットフォーム上で想定外の事象やツールの不具合は発生していません。また、新規開発を進める部署に対してはWeb標準プラットフォームについての説明を行い、啓蒙と維持にも努めています。2020年度中には計画どおり、当社のWebシステムの大半を移行・統合できる見込みです」（加藤氏）
技術標準を維持・管理する
仕組みの必要性
一方、加藤氏が目標の3番目に掲げた「技術標準の規定と恒久的な維持・管理のための仕組み作り」に関しては、「目下、活発な議論を行い、検討中」という。
「当社における技術プラットフォーム乱立の問題を改めて突き詰めると、システムのアーキテクチャを決める際に基準とすべき規定がなかったことと、基準を維持しそれへの準拠をチェックする機能・組織が存在しなかったことが挙げられます。端的に言えば、当社全体の技術標準となるTA（テクニカル・アーキテチャ）と、TAを維持するステアリングコミッティの不在です。これらは、顧客本位のサービスを統制がとれたなかでタイムリーに提供していくためには不可欠な要素で、当社の課題と考えています」と、加藤氏は話す。
［IS magazine No.25（2019年９月）掲載］
････････
◎特集｜ソニー生命の挑戦 CONTENTS
PART 1 COBITに改めて注目し、4つのテーマと4つの柱を掲げる
PART 2 個別最適の流れに歯止めをかけ、「Web標準プラットフォーム」を策定
PART 3 あえて基幹システムから「ビッグ」スタートを切る
PART 4 運用改善専任チームの結成と「全運用担当者との面談」という手法
PART 5 業務の詳細な「手順化」により、コスト削減・開発スピード向上を目指す
