住友生命保険は現在、DX（デジタルトランスフォーメーション）人材の育成を推進している。その活動の中心で、DXを起こすこととその方法について現場で試行錯誤してきた筆者が、DXの勘所を分かりやすく説明する。第2シリーズとしてDX実務で感じたこと、役に立つ考え方などを紹介していきたい。
前回は、DXではスマートフォンを前提としたシステム構築が大変であることを説明した。今回は、DXでパートナー企業とシステム接続した際、苦労したエピソードを紹介する。
前回記事 DXで一番つらいのは「スマホ」のシステム開発、解決の糸口は目の前にあったパートナー企業とのシステム接続仕様が決まらない
DXを語る上で、API（アプリケーション・プログラミング・インターフェース）は欠かせない。APIはオンラインかつリアルタイムで異なるシステム同士を接続しやすくするものであり、「APIで接続可能なシステム」とは、「他のシステムと接続しやすい」という意味と同義で使われる。
筆者が開発に携わってきたDX型健康増進保険「Vitality」には、利用者がスポーツ用品やウエアラブルデバイス、ホテル宿泊を販売するパートナー企業の商材を最大4割引きで購入できる制度がある。このためVitalityのシステムとパートナー企業とのシステム接続が必要だった。
Vitalityの担当になるまで、筆者たちは一度に多くの企業とシステム接続をしたことがなかった。それも、同業の金融業との接続ではなく、スポーツ用品メーカー、ヘルシーフードの通販会社、コンビニチェーン、ホテルなどという異業種であるからなおさらだ。どのような交渉や接続をすればよいか全く分からなかった。
共同開発をする南アフリカのディスカバリーとのセッションにおいて、先方から「システム接続にはAPIを使えばよい。APIを使えば簡単だ」との話があったが、当時、住友生命ではAPIを使ったシステム接続の経験がなかった。API接続仕様も分からなければ、そのようなシステムも存在していなかった。
ネット通販を手掛けているようなパートナー企業はAPI接続で問題なかったが、API対応していないパートナー企業は、API接続に難色を示した。API対応は既存のシステムに多額のコストをかけて改修しないといけないからだ。パートナー企業ごとに事情が異なっていたので交渉はスムーズに進まない。
困った筆者は、ディスカバリーと共同で、課題を1つひとつ洗い出し、対策を練る必要があった。API接続が難しいパートナー企業は、バッチ処理でのファイル交換という古典的な方法や、それも厳しい場合は、CSVファイルを電子メールでやり取りするなど手作業での方法を考える必要があったのだ。
DXプロジェクトとして先進的な仕事ができると喜んでいた筆者たちであったが、パートナー接続においては、「とても古典的なシステム間接続」という手法を併用する必要があった。逆にいえば、古典的な知識でもDXでは十分に役立つことが分かったので、過去のスキルは生かせるものだと思った。
パートナー企業が増えて人手が足りなくなる
Vitalityの目玉の1つはいろいろな商材を割り引きで購入できることなので、パートナー企業の数は重要だった。1社や2社ではあまりにも寂しく、Vitalityプログラムの価値が下がってしまうからだ。このため、パートナー企業を増やすべく、交渉チームは多くの企業に声を掛けていた。
それ自体はよいことなのだが、システム開発担当の立場では、パートナー企業が増えると、その数だけ接続の仕様を検討して、プログラム実装を行い、テストする。稼働後は運用保守が必要になる。パートナー企業の数だけ人手が増えてしまうことは避けたかった。
パートナーとのシステム接続には、3人のエンジニアをアサインしていた。パートナー企業の数が3社になるまでは1社1人で対応していたが、4社を超えると一気に増えだした。このため、3人のエンジニアは数社掛け持ちとなり、パートナー企業ごとに接続仕様を確認し、個別に最適な設計をすることになったので多忙を極めたのである。
パートナー企業はさらに増えていったが（最終的に11社）エンジニアを増やすことができなかったので、現場は疲弊した。「このままではまずい」と思った筆者たちのチームは対応を考えることにした。最初はアイデアが浮かばなかったが、考えれば出るものだ。3日後に思い付いた。
