住友生命保険は現在、DX（デジタルトランスフォーメーション）人材の育成を推進している。その活動の中心で、DXを起こすこととその方法について現場で試行錯誤してきた筆者が、DXの勘所を分かりやすく説明する。第2シリーズとしてDX実務で感じたこと、役に立つ考え方などを紹介していきたい。
前回は、DXプロジェクトを引っ張る企画・推進人材にとって必要なのはプロジェクト管理能力、社内調整／政治力、そしてイネーブラー（enabler）を上手に使うことだと話した。今回はそうした人材にとって特に必要になる能力について説明する。
前回記事 DXのシステム構築はなんとかなる、まずは「地道なプロジェクト管理」から筆者はDXに悩む人からいろいろ質問されることが多い。その1つに「DXでどのような物を最初に購入したか」がある。それは何であろうか。データ分析ツールか、スマホアプリ開発ツールか。どれも違う。最初に買ったのは、なんと英語を日本語に翻訳するソフトウエアであった。
DX成功の基本は「プロジェクトリスクは何か」
前回も説明したがDXプロジェクトも従前のシステム開発もプロジェクト管理の基本は変わらない。特に既存システムの変更を伴う大規模なプロジェクトの場合、プロジェクト全体を眺め「どこを現行システムで対応し、どこを新規システムとして構築するか」を考えることになる。
さらに「どの部分を既存人材で対応し、どの部分を外部委託するか」「両者のつなぎ部分をどうするか」「テスト計画をどうするのか」などを考えてプロジェクト計画を作ったり、進捗管理をしたりする地道なプロジェクト管理が必要だ。特に重要になるのは「リスクの洗い出しとその対策」である。
住友生命のDX型健康増進型保険「Vitality」は、筆者ら開発チームにとって初めてなことが多かった。だからリスクもたくさんあった。その中でも筆者がリスクと感じたのは「英語によるコミュニケーション」と「DX特有のビジネス用語（ビジネスの仕掛け）」の知識不足である。これらについて課題や対策、教訓を紹介したい。
大量の「英語の仕様書」に苦しむ
Vitalityは、南アフリカのディスカバリー社が20年以上前から開始し、現在では世界で販売されている健康増進プログラム付き保険である。基本となる健康増進アプリをディスカバリー社が開発し、保険部分やポイントプログラムである「Vitalityコイン」を日本で開発することになっていた。
今でこそ、Vitalityアプリの機能の一部（健康アドバイス機能など）は日本でも作っているが、最初のうちは全て海外で開発していた。仕様書、要件定義、機能提示書は英語である。会議も全て英語だ。
これには最初から苦しむことになった。ディスカバリー社から送られてきたVitalityアプリの基本仕様書、機能書などの大量の文書はもちろん英語だった。それまで仕事で英語を使ったほとんどなかったから、英日の翻訳が必要になり、英語翻訳ソフトを買いに走る状況になった。
筆者は、Vitalityプロジェクトでは「英語でのコミュニケーション」をリスクと認識し、翻訳ソフト以外にも、いろいろ対策を模索した。その中に「英語が堪能で海外でのシステム開発経験があり、保険が分かる人を探すこと」があった。
しかしこれが見つからない。（1）日本に住んでいて（2）日本語が上手で（3）英語に堪能、（4）システムに詳しく（5）保険が分かる人がそういるはずもない。これには胃が痛い思いだった。結局、これらの条件に合うのは日本在住のインドの人材だった。このインド人の能力がすごく、英語のコミュニケーション問題は一気に解決した。
さらに良かったのは、最初はつらかった英語資料にも、そのうち慣れたことだ。気が付くと英語のまま普通に読めるようになった。日本語に翻訳していると時間がかかるし面倒だ。大事なものだけを日本語にしているうちに、ほぼ意味が取れるようになった。
最初は無理だと思うことも、手間を省こうと工夫しているうちにできるようになる。諦めないで何でも試して解決していくことが必要だ。このようにプロジェクトリスクを認識し、解決策を地道に試す。この手順はDXプロジェクトでも普通のシステム開発でも変わらない。これは筆者たちがVitalityで得た教訓の1つだ。
