「ものづくり」と「金融機関」を両立させる、ウェルスナビのサービス開発の舞台裏

「ものづくり」と「金融機関」を両立させるレシピ

岸田崇志氏（以下、岸田）：はじめまして。ウェルスナビの岸田です。私はCPOという立場でプロダクトチームを管掌しています。本日は、ウェルスナビでどのようにプロダクト開発を進めているか、という話ができればと思っています。

前半は私の自己紹介と「WealthNavi（ウェルスナビ）」のサービスについてです。私は1月に入社したのですが、「実際に入ってみるとこういう感じなんだな」みたいなところも含めて、組織やカルチャーの話もさせていただきます。

あとは、現在サービスのリニューアルを進めているのですが、それをどのように進めているかという4つのトピックで、お話したいと思います。

私はウェルスナビでCPOを努めていますが、もともとは2000年ぐらい、ちょうどインターネットが日本に普及し始めたころに、インターネットを用いた音声伝送技術やP2Pなどを研究開発していました。将来は技術ドリブンでいろいろな事業に携わりたいをと考えていたので、2000年代はさまざまな低レイヤー技術の基礎研究や応用研究をしていました。

一方で、そういった技術はより多くの人に結局使われなければ意味がないと考えるようになり、当時オープンソースを活用し、オンプレで高トラフィックを捌く経験を積みたく、グリー株式会社に入社をしました。

入社後、実際にやっていたのはインフラではなく、内製ゲームのエンジニア兼プロダクトマネージャーとして、ガラケー時代の『釣り★スタ』というタイトルのWebエンジニアから始まり、内製のゲーム全般の統括などもやっておりました。

数々のサービスを作った後で、エンジニアが技術ドリブンで事業を進めるというのはおもしろいなと思う一方で、ゲームに留まらず、そういった技術をより社会に使えるような事例を増やしたいと思い、社会課題を解決するためLITALICOという会社でエンジニア組織の立ち上げ、及び福祉・教育のアプリをグローバル展開した後、ウェルスナビで執行役員CPOをやらせていただいています。

ウェルスナビについて

ここからはウェルスナビについてお話します。入社する際に1つのポイントだったのが、ビジョンに「ものづくり」という言葉が入ってたことです。

自分のイメージの金融機関とのコントラストというか、ギャップというか、ワードの組み合わせがすごくおもしろくて、実際にどういうかたちで進めているのかに興味があって入社しました。

「WealthNavi」は、働く世代が「将来、年金などどうなるんだろう？」といった不安感もあるなかで、働きながら資産運用するためにはいろいろな知識が必要になりますので、そういったところを支援するアプリケーションです。

ノーベル賞受賞者の提唱した理論に基づいた資産運用のプロセスを中心として自動化しています。富裕層など、限られた層だけが実現してきた資産作りを、ポケットの中にあるスマホで手軽に始められることが特徴のアプリケーションです。

会社の立ち上げに関しましても、創業者の柴山が自らプロトタイプを開発していたりと、エンジニアに対しての理解がある経営陣でエンジニア視点から見てもプロダクトドリブンで仕事が進めやすい環境です。

我々の取り組む資産運用ロボアドバイザーですが、グローバルに視点を向けてみると、非常に伸びている分野です。なので、もちろん日本でも利用者が増えていくべき分野だと思っています。

グローバルの位置づけにおいてもCB Insights Future of Fintech 2017の「Fintech 250」の資産運用をリードする16社の1つに、ウェルスナビは選ばれており、注目されています。

ロボアドバイザーの中でもいま運用者数、預かり資産ともにNo.1でして、サービスリリース以降順調に伸びてきています（注：一般社団法人日本投資顧問業協会「契約資産状況（最新版）（平成30年3月末現在）」よりモーニングスター社調べ（平成30年8月時点））。

この成長のペースはグローバルに見てもすごく早いペースでして、これからも成長を続けどんどんサービスを伸ばしていかなければいけないところです。

開発チームについて

では、どんなチームで開発しているかというところですが、いろいろな異業種の専門家の融合チームかなと思っています。

金融・SIerというところでは、きちんとした信頼性を持ったシステムを作れるエンジニアが重要なため、そういった経験を持った方が多いです。また、いま私が担当しているクライアントアプリの部分に関しては、インターネット系やゲーム、メディアアプリなどを作ってきた経験を持つメンバーが多いです。

そして、資産運用の部分に関しては、金融知識やノウハウを持つ方が多数いらっしゃるので、どう伝えるかを一緒に考え、ナレッジを僕たちエンジニアがうまくプロダクト化という名の翻訳をして、リリースするということを重視しています。

ですので、社内のチームは、アプリチーム・金融システムチーム・サービスシステムチームと分かれていて、私は現在アプリチームを担当しています。

ユーザビリティを追求するチーム、また信頼性を担保できるチームがあったり、今後スケールしていくためのアベイラビリティを担保できるチームがあったりと、相互に補完しながら、スピード感と信頼性を担保しながら進めていけるようなチーム構成になっています。

僕たちアプリチームはSwiftやKotlinを主に使っています。APIはサーバーサイドKotlinで構築しています。また、「分析基盤が充実しているな」というのが入ってみての印象です。分析基盤にひと通りのデータがあるので、「どんな方向に進めるか？」という意思決定する時に、すごく助かっています。

ウェルスナビの技術的位置づけ

世の中にはいろいろな技術スタックがあるものの、技術視点でウェルスナビではどのような位置づけかを説明します。

縦が既存技術・新規技術、横軸が既存市場・新規市場で分けた時に、我々のポジションはどこなのか。

もともと金融取引系の市場があるなかで、既存技術・新規技術云々にかかわらず、まだまだ技術を活用するとより良くなる余地がある領域だと思っています。なので、いろんな技術を良いかたちで翻訳して使っていって、より多くの人にメリットを届けることが我々のミッションです。

この先いくつか事例があるのですが、FISCのガイドラインに準拠し、公開システムとして日本で初めて証券システムをAWS上に構築しています。他には、金融機関とつなぎ込みの部分では率先していろいろな技術を導入して、多くの人に使っていただいています。

あとは応用研究として、東大の松尾研と、行動経済学に基づいて長期運用を補佐できるような仕組みも共同研究しています。

ウェルスナビのサービス開発

ここまでが前段で、ここからが本論です。「どのようにサービス開発をしているか？」についてです。

ウェルスナビのサービス開発において重視していることを話すのですが、一般的には金融って少し難しいイメージがあるかと思います。

これは弊社でお客様にアンケートを採った結果ですが、上位は「情報収集が大変だ」「誰に相談していいかわからない」「どの情報を信じていいかわからない」など、要するに「難しそう」とか「複雑だ」みたいなイメージを持たれる方が多いのかなと思います。

さらにもう少し考えてみると、その先にはやはり「難しい」だけじゃなくて「不安」もすごくあるのかなと思います。

ですので、プロダクトを作るうえで大事にしているのは、「難しい」に関してはシンプルにするということ、「不安」に関しては安心や信頼を持ってもらうということが重要であると考えています。

ここからはそれらをどうやって実現しているのか、5つの事例をお話しします。

コードのリファクタリングというワードはよく聞くと思いますが、サービスが進化するためにはサービスのリファクタリングも必要であると考えています。ちょうどサービスのリニューアルを進めるなかで、サービスの本質やコンセプトがちゃんと伝わってないんじゃないかとか、わかりやすくないのではないかと考えました。

これらのことを文章や口頭の説明に頼らず、プロダクトでわかりやすく伝えることが、サービスのリファクタリングだと思っています。要するにサービスの本質やコンセプトを伝える作業です。

コンセプトをプロダクトで表現する

1個目は「コンセプトをプロダクトで表現する」です。

そもそもスマートフォンの画面はすごく小さいですし、表示領域も限られるので、思想やコンセプトをプロダクトで全部表現しようと思うと、なかなか難しいです。一方で、そこは腕の見せどころかなと思っていて、コンセプトの翻訳者であるということを考えています。

これは例えると「100の言葉を1つの画面で表現する」作業かなと思います。要するに、今日のように直接フェイス・トゥ・フェイスで話せばサービスの魅力は伝えられます。ですが、1つの画面でそれを表現できるかというと、それは難しい作業です。

やはりFintechは歴史のある金融の仕組みをアプリ化するということですので、いままで自分が携わってきたアプリと比べても、100以上というか1,000の言葉くらいのイメージです。そのくらい難しい分野であると感じています。

また、規制・ガイドラインがいろいろありますし、金融知識やノウハウを知っておく必要があります。なので伝えるべきことが多いですし、守らなければいけない要素も多いです。そこに対して企業として重要な信頼性も担保しなければいけないので、そのバランスを取りながら進めることが重要です。

なので、伝えたいコンセプトを決めてから、企画やデザインを経て実装に至った時に、実際は半分しか伝わっていないというケースがあります。ではどうするか？　というところをお話します。

言語化して考える

プロダクトで「伝える」ということのファーストステップで意識していることとして、「言語化して考える」ということをやっています。機能を設計する時に意外と言語化できてないケースや、言語化しづらい機能は多いためです。

ですので「○○を伝えたいため、○○が重要だと考え、○○という機能を用意、100人中○○人が理解し」みたいな感じで、一度言語化してみることによって、「本当に必要なんだっけ？」と自己反芻することで施策をイメージ化し、精度を上げることをやっています。振り返る時も「どんなことを振り返るか？」という視点も入れているので、結果として何を解決したいんだっけ？と予め考えてえおくようにします。

一例ですが、いきなり実装するのではなく、どんなかたちであれ、まずは小さくアウトプットしてみることがポイントかと思います。

そして、次にそうして機能が決まった後にどのように進めていくのか、いつも悩みの種かと思います。例えば、緊急度と重要度の軸で考えた時、ほとんどを緊急にマッピングしたり、どれも重要に見えてきたりとやりたいことがまんべんなくマッピングされてしまうケースが意外に多いのではないでしょうか。

よくあるのが、捨てるということができずに、すべての優先度が高く見えてしまうということです。では、どのように判断をしているかというと、機能をトリアージします。

「トリアージ」というのはもともとフランス語が語源で、コーヒー豆とかブドウなどの選別に用いられていた基準です。現在は災害救助の際のラベリングにも使われています。私たちはそれを開発に応用していて、4つの軸で優先順位を決めています。

「100人中何人が使うか？」、要するに効果の広さです。より多くの人が使ってくれるのかということ。そして「改善の幅」、つまり効果の高さ。あとは「自分がその施策に自信があるか？」、効果の確度ですね。そして最後は実装コストです。「すごく良さそうだけど、実装コストは高いのか、低いのか？」。効果が良さそうで、実装コストも見込めるものは当然やることに組み込みます。

次にやらないことを決めることが重要です。そもそも、ちゃんと使われないものはやらないほうがいいと思います。そこで、この4つの軸にもれたものはまず「やらない」と決めます。

一方で、「効果はわからないがたぶん良さそう」というような不確実性のあるものもチャレンジすることが大事だと思っていて、プロジェクトやタスクの間の空いた時間でできるようにしておくこと重要かなと思っています。完全に効果ドリブンではなくてもそういったところも実現するための余地を残しておくのが大切です。

最後に、いまはできないけど将来やるものもマッピングし可視化しておくことも必要で、ほっとくとそのまま実現されないということが起きがちですが、それを防ぐためにまず可視化します。

どのようにやるかというと、ロードマップにマッピングするとこんな感じになります。

横は時間軸で、縦は開発でこなせるタスク量です。限られた時間でなんでも開発できるわけではないので、タスクのイメージをこのよう可視化します。「やる」ものは手前から埋まっていきます。続いて「やらなければいけないけれど今はできないもの」は「やらねば」として、黄色い円にして埋めていきます。

やらないことを決めることで何が良いかというと、空きができるんですよね。その隙間に、「効果はないかもしれないけど、やったほうが良い」という要素を緑の円にして詰め込んだり、一方で白い丸で空白を書いておきます。

そうすることによって、時間の隙間を「改善しなきゃいけないけど、できていない」といったことに充てることができます。やらないことを決め、優先順位と時間を決めることによって無駄がなくなりますし、擬似的な20パーセントルールじゃないですが、エンジニアにとってもやりたいことができるようになります。

サービスをジブンゴトに置き換える

もう1個は、我々はサービスについて「自分たちが本当に使いたいか？」という前提で考えています。サービスのグロースを考える前に、「自分たちが1年後、5年後も使っていたいサービスだと本心から思えているの？」ということが重要であると考えています。

我々は長期・積立・分散を目標としたサービスを作っているので、2週間、1ヶ月、3ヶ月といった短期視点ではなく、半年後・1年後・10年後を見据えたサービス設計が必要となります。これは自分にとっても今までになかった経験で、非常に面白いですし、本質的なサービス設計ができると思っています。

また自分たちが使わないものをユーザーさんに使ってもらうわけにはいかないので、こんなフレームワークで考えています。

例えば、「6ヶ月後、○○になっていたらイヤだけど、○○になっていたらうれしい」みたいな感じで言語化します。このポイントは、ネガティブなことも書くところです。本当は「こうなったらうれしい」だけではなく「こうなったらイヤだ」というところも出てくると思うので、「そのギャップをいかに埋めるか？」。そしてそこから「自分たちのサービスは、半年後にそこを埋められるのか？」ということを設計します。

この根本にあるのが、なんとなくのサービス設計はなくすということです。「こう使ってほしい」みたいな思いこみは、ある意味作り手のエゴでもあると思うので、「本当はどう使われてたか？」を振り返ることが大切だと思っています。作り手と使い手の認識のギャップはどうしても出てきてしまうので、その前に自分たちのなかでも認識ギャップを作る前に明確にして、「そうなったらイヤだ」というポイントを減らす必要があります。

社会課題の翻訳者になる

世の中の技術は指数関数的に伸びています。AI・IoTなどの新しい技術が取り沙汰される一方で、多くの人は生活実感はないことが課題だと思っています。

新しい技術で「生活が豊かになった」とか「すごく便利になった」ということが意外と少ないんじゃないかと思っています。そこで我々が意識しているのは、今ある技術を必要とされている領域に組み合わせて提供すること、これを技術の翻訳と呼んでいます。技術を翻訳することで「いかに伝えやすくするか？」や、「どうやって生活実感につなげるか？」という部分がとても大事だとおもっていて、その存在にWealthNaviがなっていければと考えています。

なので、技術力も大事ですし、プロダクトを翻訳していくことも重要なので、いかに多くの人に使われて、伝えて、より多くの人に「良い」と感じてもらうかという部分を大切にしています。そういった仲間を、今後どんどん増やしていきたいなと思っています。

おわりに、この5ヶ条やビジョンに共感したり、作り方に共感した方は、ぜひお話を聞いていただければと思います。以上となります。ありがとうございました。

（会場拍手）

開発チームにおけるカルチャーの違いについて

司会者：岸田さん、ありがとうございました。質問を受け付けたいと思いますがいかがでしょうか？

（会場挙手）

質問者：お話ありがとうございます。サービス開発チームが、インターネット系や金融系、SI系など、いろいろなバックグランドの方でチームができていると思いますが、バックグラウンドが違うとカルチャーも違ったりするのではと思いました。そのギャップであったり、ギャップを埋めるためになにかやっていることはありますか？

岸田：そうですね。カルチャー面に関しては「意外とギャップが少ないな」という印象です。入社前は、「金融だから堅いんじゃないか」と思っていましたが、エンジニアでも基本的には金融への興味がある方が多いのと、それぞれがスペシャリストの集団なので、それぞれの専門性を尊重して進めるカルチャーです。取り組みとしては社内の勉強会なども頻繁に開催されていたり、シャッフルランチといって部署を横断したランチなど、コミュニケーションは円滑になるような施策は多いです。アットホームな雰囲気もあり、そういうベースのカルチャーがあるのでうまくいっているのかもしれません。

質問者：ありがとうございます。

司会者：ありがとうございます。それでは岸田さん、ありがとうございました。

岸田：ありがとうございました。

（会場拍手）