全3283文字
PR

 住友生命保険は現在、DX(デジタルトランスフォーメーション)人材の育成を推進している。その活動の中心で、DXを起こすこととその方法について現場で試行錯誤してきた筆者が、DXの勘所を分かりやすく説明する。第2シリーズとしてDX実務で感じたこと、役に立つ考え方などを紹介していきたい。

 前回は、DXでIoT(インターネット・オブ・シングズ)を使う場合は技術に加えてデータ価値を考えることが必要だと説明した。今回はDXでのスマートフォンを使ったシステムに関するエピソードを紹介したい。

DXの一環で新たに開発する商品やサービスには、スマホが顧客接点を持つ大きな要素として欠かせない。ただシステム開発は手間取ることが多い
DXの一環で新たに開発する商品やサービスには、スマホが顧客接点を持つ大きな要素として欠かせない。ただシステム開発は手間取ることが多い
(出所:123RF)
[画像のクリックで拡大表示]
前回記事 IoTの真価はデータ取得にあらず、DXにおける「データで価値創造」の本質

 DX型健康増進保険「Vitality」の開発では何が大変だったか。手掛けたプロジェクトで大変だったものは数多くあるが、その中で一番を選べといわれれば、それは「スマホアプリを使ったシステム開発」だった。

顧客とサービスの接点はスマホが中心

 エピソードの背景として、筆者たちシステム開発チームが手掛けていたプロジェクトであるVitalityの概要に改めて触れたい。住友生命のVitalityは、「健康」という顧客体験価値にフォーカスした保険商品・サービスで、活動状況に応じて保険料が一定程度安くなるのが特徴だ。顧客の健康増進活動をサポートするため、ウエアラブルデバイスを装着して歩数データや心拍データなどのバイタルデータを取得する。顧客はスマホアプリで健康に関するアンケートに回答したり、健康診断結果を入力したりすることでポイントがたまる。

 ガーミンやポラールなどのウエアラブルデバイスを顧客のスマホにBluetoothでリンクして使うなど、顧客とVitalityの接点はスマホが中心(PCでも一部可能)である。

 このように、Vitalityでは、顧客のスマホを入出力デバイスとしてシステムを構築する必要があった。筆者たちの開発チームはそれまで本格的なスマホアプリを開発したことがなかったので、いろいろ戸惑うことが多かった。

 要件提示に苦労し、画面デザインに試行錯誤し、テストで途方に暮れた。今でこそ笑い話だが、2017年頃のVitalityプロジェクトの開発ピーク時は、毎日iPhoneやAndroidスマホ、高齢者用スマホなど、テスト用のスマホを何種類も使って、悪戦苦闘したものである。

Vitalityのスマホアプリ画面。iPhone(左)のOSのバージョンは15.6.1、Android(右)のOSのバージョンは11になる。画面表示の主な相違点はメニューの表示位置だ。iPhoneは画面下だが、Androidは画面左上の3本線にたたまれている。文字のフォントやサイズ、太さも異なる
Vitalityのスマホアプリ画面。iPhone(左)のOSのバージョンは15.6.1、Android(右)のOSのバージョンは11になる。画面表示の主な相違点はメニューの表示位置だ。iPhoneは画面下だが、Androidは画面左上の3本線にたたまれている。文字のフォントやサイズ、太さも異なる
(出所:住友生命保険)
[画像のクリックで拡大表示]

 消費者として考えれば、自分のスマホで多くのシステムを利用できることは便利だ。EC(電子商取引)サイトで商品を買ったり、サブスクリプション型動画サービスで映画を見たり、自宅や社外からオンライン会議に参加したりするなど、スマホを使えば高い体験価値が得られる。逆にスマホがなければとても不便で、体験価値は低いだろう。

 一方で、システム開発者の立場で見れば、スマホはシステム開発を難しくする要素である。「iOSやAndroidなどOSの種類が多い」「同じOSでもバージョンが違う」、さらに「利用者が最新のものだけを使うのではなく、かなり古いバージョンを使う」など設計の考慮と多くのテストケースが必要だからだ。

スマホのテスト用に中古ショップをはしご

 さらに、テストでは実機を使うので、多くの種類のスマホ実機を用意する必要がある。しかし、iPhoneやAndroidを売っている携帯キャリアの店舗やWebサイトには最新機種か、せいぜい数世代前の機種しかない。

 そこで筆者たちは、手分けして街の中古ショップの在庫状況をインターネットで調べて探しに行った。それでも欲しいスマホ実機を全て確保することは難しかった。筆者たちにスマホを効率的に集める知識があればよかったのだが、当時はなく、途方に暮れてしまった。

 テスト計画書を準備する時期になっても、スマホ実機を使った機能テストや操作性テストケースが書けない状況だった。仕方がないので「用意できたスマホ実機の範囲内でテストして、それ以外を稼働保証外としよう」ということも頭をよぎったものの、それは顧客の体験価値を下げるのであり得ないと思った。

 「何か良いアイデアはないか」とテスト関係の社内有識者に聞いてみたが、答えはない。社内に本格的なスマホアプリを設計した人がいないのだから当たり前である。そのように時間を過ごしてテスト開始時期が近づいてきたが、それでも良いアイデアは浮かばなかった。