ネット生保立ち上げ秘話（12）システム構築 - 岩瀬大輔

生命保険の「無印商品」

「お二人は、どのような生命保険会社を作りたいとお考えですか」
溜池山王の交差点付近から乗り込んだ黒い日本交通のタクシーの助手席には、小型カメラを手にしたテレビ東京のディレクター。後部座席に座る僕と出口に向けて、カメラを回しながらインタビューが始まっていた。

出口は慣れないカメラに向かって、少し緊張した面持ちで、ゆっくりと答えた。
「はい。私たちは、いわば、生命保険の『無印商品』を作りたいと思っています」
僕は即座に脇をつつきながら、耳元で囁いた。
「・・・出口さん、『無印商品』じゃなくて『無印良品』でしょ・・・」

数日後のニュース番組では、CM後の番組を紹介する短いカットに、この二人の漫才のようなやり取りが使われていた。「どうなるか、凸凹コンビの挑戦！」というナレーション付きで。

新宿御苑の森の中

この日は、初めての引っ越しだった。そもそも、今のオフィスには僕らのデスクは3.5個しかなかった。出口、僕、高尾の次に入社した馬場には、プリンターが置いてあった小さい台の上で、作業をしてもらっていた。

2007年5月。マネックス、あすかDBJ、三井物産、新生銀行、セブン＆アイホールディングスの5社を対象とする第三者割当増資が決まった。立ち上げメンバーとなるスタッフも、続々と決まっていった。いよいよ本格的な会社作りをするために、当初は、開業まで引っ越さないでいいよう、約50名のスタッフを想定し、150坪強のオフィスを探していた。だが、ある先輩起業家に相談したところ、以下のようなアドバイスを受けたのだった。
「まだ数人しかいない小さなベンチャーが、いきなりガランとしたオフィスに移転するのは、気が緩んでよくない。小さなオフィスを『やどかり方式』で移り歩く方がいい。お金は多少かかるかも知れないが、士気への影響を考えたら、追加で発生するコストなど大したことはない」

このアドバイスを受けて、150坪ではなく、当面は50坪のオフィスを探すことにした。このときの我々の条件は、1）50坪前後、2）家賃は安く、3）創業株主であるあすかDBJとマネックスと、霞ヶ関へのアクセスが悪くないこと、そして仮住まいになることは分かっていたので、4）できるだけセットアップコストを安く抑えられること。

この条件で探し始めたが、オフィスビルの需給はタイトで、なかなかいい物件が見つからない。まぁ、ここで妥協するか、そう思った物件を見に行ったときに、同行してくれたオフィスデザイン会社の社長が耳打ちしてくれた。
「岩瀬さん、ここも悪くないけど、もっといいところが出てきたから、一緒に見に行かない？僕のお客さんが今度引越しすることになっていて、まだ不動産市場には出ていないんだけど、緑がたくさんあって、すごくいいところだから。彼らのオフィスを、そのまま居ぬきで使えそうだ」

そのままタクシーに乗り込んで着いたのが、千駄ヶ谷と新宿御苑の間に位置するオフィスだった。入った瞬間、気に入った。細長いオフィスの片側は一面広い窓になっており、奥の会議室はまるで新宿御苑の森のなかで会議をやっているようで、今にも木々や鳥が迷い込んできそう。千駄ヶ谷の駅から坂を上がってくる道は朝の心地よい散歩となったし、気持ちに余裕があるお昼時は、少し足を伸ばして、新宿御苑前界隈の名店を食べ歩いた。

システム開発スタート

新オフィスに引っ越してやるべきことは、保険会社のオペレーションを行うための事務システムを立ち上げることだった。

このためには、大きく以下のステップが必要だった：
1）会社の事務フローを整理する
2）それを実現するためのシステム構成などを考える
3）構築するためのITパートナーを選定する
4）設計図を描き、システムを構築し、テストで確認しながら直していく

保険会社の「本業」は「保険を売ること」、そうイメージしている人も多いかもしれない。確かに、一般に保険会社との接点はテレビのCMだったり、営業員だったりする。また、社内でも営業を最重要視している保険会社も多い。

しかし、実際には、保険の本業は、「保険を引き受けて、契約を保全し、保険金を支払う＝保険事務」である。すなわち、健康状態に応じて引き受けの可否を決め、契約期間中のお客さまの書変更手続きに対応し、請求があった場合に迅速に支払う、という業務こそが、保険会社としてもっとも重要な業務なのである。
新しいネット生命保険会社としての保険事務体制を構築していく際に中核となったのが、自称「保険事務のオタク」である古川と、ネット金融オペレーションのプロである馬場の二人だ。

当社の事務構築がどこから始まったのかというと、出口が二本の人差し指で書き上げた10数ページの業務要件定義書だった。これに加え、手書きで書いた5枚ほどのフローチャートもあった。

これを見た古川が、驚いて言った。
「え？出口さん、保険の事務やったことあるんですか？」
「いいや、ないよ。なんで？」
「いや、ここまで詳しく書かれちゃうと、自分が付け足すことがないんですけど・・・」

この時点では出口はすでに、ウェブの画面の申込からその後の顧客管理から保険金支払までを、プロを唸らせるほどかなり細部にわたり、頭にイメージを描いていたようだった。

これを元にして古川と馬場らの手によって、事務フローが精緻化され、詳細の業務要件定義書が作られていった。マーケティング担当の松岡がそれをウェブの画面イメージに落とし込み、実際に利用している画面のプロトタイプを作った。

査定の事務については、大まかに次のように考えた。申し込みを行う契約者が画面の誘導に従い、自身の健康状態について記入を行う。これが記入された画面を見て、担当者が査定を行う。高度の医学的判断が求められる案件については、ワークフローでそのまま医長へ審査を依頼する。追加の質問があれば、ネット上に設けられた契約者の専用ページにて質問を行い、そこに回答を書き込んでもある。

一旦受け付けたのちに、申込に必要な本人確認書類のコピーやサインが必要な書面を、返信用封筒とともに送付する。必要があれば、健康診断書のコピーなども添付してもらう。これらを社内で処理して、申込手続きが成立し、契約者に対してはメールで通知を行うと同時に、保険証券を発送する。一連の手続完了まで、約一週間を目標とする。

堅牢性と柔軟性

システム構成については、大まかに以下のように考えた。まず、顧客の契約データを管理するシステムは、中堅生保を中心に実績がある、米CSC社のパッケージであるLife/Jというソフトウェアを選んだ。堅牢性という点では間違いがなかった。

次に、ウェブ経由で入ってくる顧客データの申込経路、および社内事務部門の査定から契約保全などのワークフローを支えるウェブアプリケーションについては、スピードと柔軟性を重視して、あるITベンチャーX社に依頼することにした。彼らはいわゆる「ラピッド・プロトタイピング」という開発手法を取っており、粗い画面の見本をどんどん生成していき、それをクライアントである我々が見ながら柔軟に修正していける、という特徴があった。

これによって、中長期で堅牢性が求められる契約管理データベースについては長年実績があるソフトを使いつつも、顧客や事務チームが日々扱うことになる画面インターフェイスやワークフローについては、僕たちならではの新しく創造的な取り組みを行うことが可能になると考えた。

そこから、システム開発業者を交えて、システム開発の要件に落とし込んでいった。キックオフミーティングに始まり、一つ一つの細かい手順について確認していく。当初は想定しなかったような細かいものがでてきて、仕様書はどんどん膨れ上がっていった。幸い、当社の商品は極めてシンプルであり、事務フローも同じくシンプルなのだが、それでも一つ一つのディテールを確定していなければならないところに、この保険事務のアートの部分があるように思えた。

これだけ細かい問題について熱意を持ってアイデアを出していけば、きっとお客さまにとって使い勝手のいいシステムができるに違いない。定例ミーティングに出席しながら、途中からそう確信するようになった。

そぎ落として太い幹を作る

システムのあり方については、絶えず社内で議論が行われていた。古川は職人肌なので、自身が前職で実現できなかったこと、理想の保険事務システム構築に燃えていた。

これに対して出口は理念としてではあるが、一回は徹底的にそぎ落として行き、本当にシンプルで必要最低限のものを作ることを迫っていた。以下の社内SNSのやり取りは、その哲学の衝突を象徴していた：

2007-08-14
タイトル：事務の考え方（古川）
出口さんと事務に関する話をすると、考え方の違いでよく議論になるのだけど、だいたいが今までと勝手が違って、戸惑ってしまう。

これまでのパターンだと、会社側からの細かな要求（それやんの！？的な）に、こちらが面倒くさがりながらも対応するというパターンだったのだが、今のパターンは、僕から細かな要求で、出口さんから押し返される、というパターンなのだ。

そうすると、議論が終わったあと、どうにも自分が保守派＆旧態派になったような気がしてしまい、なんとなく自己嫌悪のような不思議な気持ちになるのだ。少しのリスクを気にして、大胆に踏み込めない奴みたいな。それは僕的には、≒かっこ悪い奴であるのだけど、自分が一番そうなのではないか思うと、どうにもブルーになるのだ。

かといって、すべてに「はいわかりました」のイエスマンでは議論になんの発展もないし、存在価値もないので、主張すべきは主張し、相手の意見のよいところは取り入れるという姿勢で行こうと思っている。
しかし、この自己主張と相手意見の受容というのは、基本的に相反するものだから、そう簡単には折り合いがつかないのだろうとも思う。簡単に折り合いがつくというのは自己主張に明確な根拠がないということになるだろうし、絶対に譲らないとすると、平行線のままで解決しないだろうし。

それでも、事務処理に関する問題は、ロジカルな問題が多く、どんなアプローチをとるにせよアウトプットはあまり変わらない、ということが多い。なので、出来るだけ出口さんのポリシーに準じたアプローチにしようと思っています。でも意見はいいますけどね。反論しても、あくまでもポジティブなスタンスからの反論ととらえていただければと。

（コメント）
出口　2007/08/19 22:17
切ること、捨てること、はとても難しい。それを、やりたいのです。全ての場合を考えて、全て用意するのは、実は、簡単。全ての事象を抜き出して、それに発生確率（と言っても想定ですが）を掛けて、事務を、極力、シンプルにする。間違っていれば、ウェブベンダーのX社に、追加修正して貰えばいい。そのために、X社を選んだのです。枝葉への扉を開けておけば、いつでも、繋げます。まず、贅肉を徹底的にそぎ落とした、太い幹を作って欲しいのです。

思考錯誤を続けながらの、新しい「ネット生保」の太い幹となるシステムの開発は、着々と進んでいた。気づいたら社員は10数人に増え、神宮の花火大会も、ビアガーデンの季節も終わっていた。

（過去のエントリー）
第１回　プロローグ　
第２回　投資委員会　
第３回　童顔の投資家　
第４回　共鳴　　　
第５回　看板娘と会社設立　
第６回　金融庁と認可折衝開始
第７回　免許審査基準
第８回　100億円の資金調達
第９回　同志
第10回　応援団
第11回　金融庁の青島刑事
第12回　システム構築