エンジニアtype - エンジニアのシゴト人生を考えるWebマガジン
  • TOP
  • キーパーソン
  • 旬ネタ
  • コラボ
  • ノウハウ
  • 女子部
  • キャリア

FinTechは「破壊」ではなく「共生」がカギ~Moneytreeが構想する金融×技術の未来

タグ : API, FinTech, Moneytree 公開

 

収支残高を一括管理できる個人向けのアプリとしてスタートしたMoneytreeが、この1年で会計業界や金融機関と連係した大きな発表を連発している。

>>資産管理アプリ「Moneytree」と会計ソフト「弥生シリーズ」が連携開始
>>マネーツリーとTKCが業務提携

Moneytree上で最新の口座情報を表示するために独自開発したデータアグリケーションの技術を、『MT LINK』と名付けてAPIとして公開。提携企業とともに、エンドユーザー向けに新たな価値を生み出していく考えという。

彼らが思い描くFinTechの未来とはどのようなものなのか。従業員18人の小さなスタートアップは、どのような戦略でそれを実現していくというのか。Moneytreeの共同創業者の1人であり、現在は営業部長兼MT LINK開発責任者であるマーク・マクダッド氏に話を聞いた。

金融機関が「自社で全てやる」時代の終焉

Moneytree 営業部長のマーク・マクダッド氏

Moneytree 営業部長のマーク・マクダッド氏

—— 御社はこの1年、会計、金融系の企業と連係して大きな発表を連発しています。こうした連係の先に思い描いているFinTechの未来とは?

これからのFinTechを語る前に、これまでのFinTechについて話す必要があります。今でこそ金融機関さんやSIerさんにFinTechを持ちかけると乗ってくれるようになりましたが、去年、同じような提案を行ったある銀行さんに言われたのは、「FinTechなんてもうずいぶん前からやってきているよ」という言葉でした。

どういう意味か詳しく聞いてみると、それは「とある技術を使うことで、行内の業務が効率的になった」という話でした。確かにFinance+Technologyという意味ではそれもFinTechかも知れませんが、僕らが目指す未来はそうではありません。

今年は弊社に限らず、FinTech元年と言われるほどこの業界が盛り上がっています。それが意味するのは、「金融機関が自社で全てをやる時代が終わった」ということです。

これからは金融知識を持っている会社と、テクノロジーの知識を持っている我々のような会社がコラボレーションすることで、エンドユーザーとってにより便利な、できれば安いサービスを提供していくことが目的になっていくと思います。

——よく「APIエコノミー」という言葉を耳にしますが、APIのやり取りというのが、そうした構想を実現する上でのキーになっていく?

我々のサービスの強みはデータアグリゲーション。複数の口座などからデータを集める技術を持っています。これをAPIとして誰でも使えるように公開したのが、MT LINKです。同じように各企業が自分たちの強い部分をAPI化してくれれば、我々だけではできないことでも実現できるようになる。

先ほども申し上げたように、「ブランド囲い」をするプレイヤーは行き詰まり、良くも悪くも全てがオープンになっていく。それはエンドユーザーから見れば良いことです。自分の目的に最も合ったサービスをその都度、選べば良いわけですから。

一方で、企業側は全てをやろうとするのではなく、自分の強いところにフォーカスして磨いていくことが求められるでしょう。

そのインターフェースがAPIということです。Techの分野ではこうした話はすでに当たり前のことになっていますが、将来的には金融機関なども含めた多くの分野でAPIエコノミーは実現していくと思っています。

—— 金融機関の方でも、そうした未来に向けた動きがすでにあるのですか?

すでに公になっている例で言えば、NTTデータが10月に、共同利用型インターネットバンキングサービスの「AnserParaSOL」にAPI連携機能を追加すると発表しています。

同様に弊社でも、日本IBMとの連携を発表しました。IBMが持つBluemixのクラウド技術環境に弊社のAPIを接続し、銀行側が簡単に接続できるための準備を進めています。

Techの分野ではよく「disrupt」という単語が使われますが、我々が目的とするのはdisruptではありません。既存のエコシステムにジョインさせてもらい、我々の強みを提供することで、付加価値を生み出すということです。

自動化の文化がスタートアップ発の改革を後押しする

—— 「新しい付加価値」にはどんな例が挙げられますか?

Moneytreeに「フットワークの軽い連携」が可能な裏には、少人数で開発するためのさまざまな工夫があるという

Moneytreeに「フットワークの軽い連携」が可能な裏には、少人数で開発するためのさまざまな工夫があるという

IBMの勉強会でもお話したのですが、すぐに思いつくのは地方銀行にありがちな問題です。地方銀行にはよく、「一体型」といってキャッシュカードとクレジットカードが一緒になっているケースがありますが、「一体型」とは言っても実際にはそれぞれの基幹システムは別です。

そのため、財布に入っているカードは1枚でも、ユーザーは明細を見たいと思ったらそれぞれ違うサイトを参照しなければなりません。弊社のデータアグリゲーションを使えば、それを一つにするという提案が比較的簡単にできますね。

もちろん、銀行自身でもやろうと思えば基幹システムの統合は可能でしょう。でも、おそらくそれは億円単位のプロジェクト。システムを動かすのには検証も非常に手間が掛かります。我々のアグリゲーションであれば、それが2カ月程度できますから、非常に「フットワークの軽い連携」が可能であると提案できるでしょう。

—— 御社に「フットワークの軽さ」があるのはなぜでしょうか?

もちろん技術的には企業秘密が多いですが、「少人数であること」は一つのキーワードと言えるでしょうね。

人間はある面でどんなPCより優れた「機械」ですが、人数が増えるとどうしてもコミュニケーションに投資しなければならないコストが増えます。時間的にもそうですし、資料や根回しの手間がかかり、誤解を招く可能性も高まります。

弊社の従業員は現在18人。開発はその半分程度です。できるだけ少人数で回すために、毎回のように起きるプロセスは可能な限り自動化する文化になっています。

例えば、現在進行中の開発のスケジュールをポーズして、2日間は何を作ってもいいというHackDaysという社内イベントを定期的に実施しているのですが、そこでアイデアとして出るものにも、自動化の話は多いです。

また、少人数開発を実現するための取り組みとして、ベンダーさんが提供している技術を最大限に活用することで、自分たちはビジネス上、最も大切なところにフォーカスするということも心掛けています。

例えば弊社ではAWSを使っていますが、Amazonユーザーはどんどん下の層のことは考えないで済むようになっています。弊社のエンジニアも、どういう体制にするかのテンプレートを書いたり、自動化するプログラムを書いたりはしていますが、「EC2の台数を管理する」といった仕事をしている人はいません。

——自動化するプログラムを書いたり、新しい技術にキャッチアップしたりする手間はどう考えていますか?

当然手間はありますが、AWSの例で言えば毎年CTOが渡米してカンファレンスで勉強するようにしています。新しい技術はそれこそHackDaysだったり、社内ツールだったりで試してみて、使えそうなら実装するという流れです。

それに、手間が掛かるとは言っても、だいたいのエンジニアは新しくて面白そうな技術は「とりあえず使ってみたい」と考えるものですからね(笑)。

非Tech企業との橋渡しとしてSIerの存在価値は続く

—— 話をやや戻して、日本の伝統的な金融機関と交渉する上で超えなければならないハードルはどこにあるでしょうか?最初からうまくいきましたか? 

Moneytreeは設立して3年ほどが経ちますが、同じことを創業直後の3年前にやっていたら、おそらくダメだったと思います。似たような話を実際にしてみても、「発想としては面白いけれど、日本では現実的ではない」と言われることが多かった。

現在は金融機関の方でも、エンドユーザーに他の企業とは違ったバリューを提供しないとビジネスが成立しなくなるという危機感が高まってきています。なので、残るは技術的ハードルということになります。

例えば、今までクラウドを使ったことがない企業がクラウドを使い始めるのに、どうすればいいのか。そこはいろいろな工夫のしどころだと思いますが、弊社では既存のSIerと組むという手段を採りました。

IBMにはハイブリッドクラウドという商品がありますから、いきなりフルクラウドを使うのには抵抗があるという企業に対しては、まずは各社のオンプレミスのデータセンターにクラウドを設置することで仮想化技術を体験してもらう、といった提案ができます。

日本の場合は我々のようなスタートアップがダイレクトに働きかけるよりも、各企業から信頼を得ているSIerが間に入り、クッション役を果たしてもらった方がうまく浸透していくのではないかと考えています。SIerが持つ信頼と蓄積ノウハウは、将来的にも価値を持ち続けると思います。

—— 他に非Tech企業を巻き込んでいく上で技術的なハードルとなりそうな部分はありますか?例えば金融機関はセキュリティの問題にも敏感ではないですか?

たしかにその通りです。今まではクローズドだったAPIがオープンになっていくわけですから。ただ、「オープン」という言葉はしばしば誤解されているように感じます。オープンなのは仕様であって、誰でも使えるということではありません。誰が使えるかは認証の問題であって、セキュリティの話とは別です。

—— マネタイズに関してはどんな考え方をお持ちですか?

ここまで会計業界、金融業界の各社と実際にやり取りしてきましたが、ひと口に金融と言ってもいろいろな職種があり、その使い道は千差万別です。

我々はお客さまに合わせて、API連携することによってどのような価値が生まれるのか、といったコンサルティングまでを行っています。なので「API1本に対していくら」といった通り一遍の決め方はできない。ケースバイケースというのが質問に対する答えです。

我々はまだアーリーなステージにいるので、ユースケースを勉強しているところでもあります。なので現状は「オープン価格」のようなもの。事例を積み重ねていけば、いずれは「標準価格」を設ける方向に進んでいけると思います。

APIエコノミーの時代に求められるのは「T型」人材

Moneytreeの前にはIT人材派遣の仕事をしていた時期もあるというマルチなキャリアのマクダッド氏。APIエコノミーの時代に求められる人材とは?

Moneytreeの前にはIT人材派遣の仕事をしていた時期もあるというマルチなキャリアのマクダッド氏。APIエコノミーの時代に求められる人材とは?

—— そうした商談はどのような体制で行っているのでしょうか?

現状、営業担当は営業部長である私だけです。ただ、今後は金融機関向けの営業も増えてくるでしょうし、先日大きな投資を受けることもできたので、エンジニアとともに営業スタッフの採用にも力を入れていく予定です(Moneytreeの採用ページはコチラ)。

—— 商談にもかなりの技術的知識が必要かと思います。マークさんはエンジニア出身とお聞きしましたが、今もコードを書いているのですか?

いえ。ただ、コードレビューはするようにしています。メールに通知されるので思わず見てしまうという側面もありますが(苦笑)。

先ほども申し上げたように、我々がやろうとしていることには未知のことがまだまだ多いです。お客さまと話す中で新たなニーズが分かれば、それに応じて方向を細かく修正していかなければならない。APIに関してもアジャイルである必要があるということです。

例えば、複数のAPIをゲートウエイに統合するのは可能ですが、一つのAPIを分岐させるのは現状は技術的に難しい。ですから、将来提供することになるであろう機能のために、コード的にも可能性を残しておく必要があります。

その点、お客さまのニーズを一番敏感に感じ取れる私がコードレビューに参加することで、「この言語を使ってしまうとライブラリが限定されてしまうので、ビジネスのニーズに合わない」といった提言が素早くできます。

どんな組織であっても、階層的になってしまうと動きはどうしても遅くなります。私はオフィスでも常にCTOの隣に座っており、「今日はお客さまからこんな話をされた」、「近い将来こういうことも考えないといけない」という具合に、既存のロードマップに“横やり”を入れる立場でもあるのです。

—— 今後は営業スタッフを増やしていくとのことですが、御社の採用方針、ひいてはAPIエコノミーの時代に求められる人材像についてお考えを聞かせてください。

営業に関してはいわゆるテクニカルセールスと呼ばれる分野になると思いますが、実際の商談の場面では「このAPIはどういう意味?」と技術的な内容を聞かれることも多くなるでしょう。その度に「担当に確認します」と答えているようではスピード感は失われますから、商品の仕様書は全て理解しておいてほしいですね。

「理解する」というのは仕様書を全て読むというのではなく、「実際にAPI連携することができる」という方が近いかもしれません。だからできればコードを書ける人がいい。

社内ではよく「T型」人材が欲しいと言っているんです。幅広く何でもできる上に、何か一つ深い知識のある専門分野を持っている人。逆に専門分野だけに特化した「I型」人材は、だんだんと苦しくなっていくように思います。

—— 営業もできて開発もできるマークさんはまさに「T型」と言えますが、どんなキャリアを踏んだ人が「T型」になれるのでしょうか?

私自身は以前、IT系人材の派遣会社に勤めていた経験があって、そこで営業やコンサルティングを幅広く学びました。一方では幼少期から趣味で開発も行っていた。本業とは別に趣味の経験が活きる、というのはあり得る形かと思います。

またすぐに思いつく別の例は、技術者でありながらスタートアップをやろうとした経験のある人です。小さなアプリであっても市場に出した経験のある人は、嫌でも自然と販売や広報についても考えざるを得ない。

たとえ失敗に終わっていたとしてもいいんです。その大変さを理解していることが重要なように思います。

将来は人工知能アルゴリズムを用いて価値の「上積み」も

—— 将来的な構想について、お答えいただける範囲で教えてください。

先ほど効率的な開発に関する話をした中で、AWSが既存のサービスの上にどんどん新たなサービスを積み上げていっているという例を出しましたが、それと同じようなことをAPIの分野で考えています。

というのも、今出しているのと同じAPIをずっと提供し続けてたとして、10年先には同じことが銀行側にもできるようになっているかもしれない。なので、何か付加価値を出していかないと我々は生き残れないということです。

現時点で考えている「上の層=付加価値」としては、一つは、データアグリゲーション先をさらに増やすこと、もう一つは、アグリゲーションしたデータを分析した上で提供することです。

弊社ではアグリゲーションしたデータを分類するための自社製の人工知能アルゴリズムを開発済みなので、これに別のデータを適用することで、後者の価値を生み出すことも可能だと思っています。

—— 御社は日本のソフトウエア企業がなかなか果たせていない世界展開の目標も掲げていますが、APIを軸にした戦略はこれにどう絡んでいきますか?

その具体的な方法はまだ言える段階ではありません。ただ、APIは世界展開の一つのカギにはなるでしょう。APIは世界の共通言語。その気になればいくらでも他の市場に行くことができるだろうと思っています。

取材・文・撮影/鈴木陸夫(編集部)


編集部からのお知らせ

エンジニアに人気の求人

エンジニアtype姉妹サイト



人気のタグ
業界有名人 スタートアップ 開発 SE 転職 エンジニア プログラマー Web スキルアップ ソーシャル アプリ シリコンバレー プログラミング Android 起業 スマートフォン キャリア アプリ開発 えふしん SIer 技術者 UI btrax クラウド Webサービス スペシャリスト Apple Twitter Brandon K. Hill 英語 ギーク 村上福之 CTO Facebook Google デザイン IoT ツイキャス SNS 世良耕太 モイめし IT 30代 採用 赤松洋介 コーディング UX 20代 勉強会 プロジェクトマネジメント Ruby ITイベント Webエンジニア 中島聡 ビッグデータ 五十嵐悠紀 法林浩之 受託開発 iOS ウエアラブル LINE ドワンゴ モノづくり ひがやすを ロボット IT業界 コミュニケーション イノベーション ハードウエア MAKERS tips ゲーム SI ソーシャルゲーム Webアプリ 女性 インフラ iPhone マイクロソフト 女性技術者 研究者 トヨタ ノウハウ 自動車 チームラボ 息抜き プラットフォーム UI/UX システム ソニー Java 高須正和 和田卓人 開発者 グローバル エンジン 教育 イベント オープンソース ソフトウェア サイバーエージェント メイカームーブメント 家入一真 メーカー スーパーギーク 増井雄一郎 コミュニティ 女子会 IPA ニュース ソフトウエア テスト駆動開発 日産 音楽 TDD 40代 グーグル モバイル ベンチャー PHP TechLION

タグ一覧を見る