Table of Contents
B2B SaaS パネルディスカッション (Authlete for B2B SaaS)
この文字起こしは、2022 年 12 月 7 日に開催された Authlete Customer and Partner Meetup 2022 のパネルディスカッションです。 SmartHR さま、マネーフォワードさま、弥生さまをパネリストとしてお迎えし、B2B SaaS 分野における API 認可・ID 連携の必要性と、そのために必要な OAuth/OIDC、そして Authlete 導入の効果についてお伺いしました。
登壇者
- パネリスト
- 株式会社 SmartHR 代表取締役 CEO 芹澤雅人氏
- 株式会社マネーフォワード クラウド ERP 本部 API 推進部 部長 根津陽氏
- 弥生株式会社 開発本部 次世代プロダクト開発 データ API PM 飯田武之氏
- モデレーター
- 株式会社 Authlete ソリューション戦略担当 VP 工藤達雄
はじめに
工藤 (Authlete): それでは次のセッションに移りたいと思います。Authlete のお客さまをお招きしたパネルディスカッションになります。今回は B2B SaaS 分野での導入をいただいている 3 社のみなさまにお越しいただいております。
ちょっとだけ前振りをさせていただくと、こちらの、公開して良いとおっしゃっていただいているお客さまのリストになりますけれども、最近非常に B2B SaaS のお客さまが増えています。今日登壇いただいているみなさまをはじめ、ヤプリさんや、FOLIO さん、海外ではカスタマーサクセスの分野の SaaS で導入していただいているお客さまがいらっしゃいます。
ということで、本当にいろんな分野にお使いいただいているんですけども、とくに B2B SaaS は我々としても非常にホットであると認識しており、この場をつくらせていただきました。
ご登壇いただいている方々をご紹介します。まずは左から、SmartHR の芹澤さま。お二方目が、マネーフォワードの根津さまです。一番右にいらっしゃいますのが、弥生の飯田さまです。パネルの進行は、わたし工藤が務めさせていただきます。
まず、SmartHR さん、マネーフォワードさん、弥生さんの順に、各社さまがどのようなビジネスをされているか、それぞれご紹介いただきます。SmartHR の芹澤さんからお願いします。
自己紹介
SmartHR
株式会社 SmartHR代表取締役 CEO芹澤雅人氏
芹澤 (SmartHR): わたしたち SmartHRは、“SmartHR” という B2B SaaS プロダクトを提供しています。
「Employee First. すべての人が、信頼し合い、気持ちよく働くために。」をミッションに働きやすい環境作りを後押しするサービスを提供しています。一言で言うと、バックオフィス向けの作業効率化などをしていくサービスです。
わたしたちのコアな機能には、従業員一人一人にアカウントを発行し従業員自ら SmartHR を使って、たとえば引っ越した・結婚した・子供が生まれた、といったライフイベントごとに自分自身の情報を変更・申請していただくものがあります。
自然と情報が SmartHR に集まってくるような機能を提供していて、とてもたくさんの人事情報を扱っており、それらを柔軟に無理なく貯めていけるようなデータベースを備えています。
もともとは社会保険の手続きを簡略化するために集めたデータを使っていたんですけど、あまりにも集まるデータの価値が高いので、人事労務、社会保険手続き以外のバックオフィス分野でそれらのデータ活用を展開しております。
このスライドは SmartHR の大まかな利用の流れを描いたもので、真ん中の「蓄まる」の部分に書いてある「労務管理」はわかりやすくバックオフィス業務を効率化する DX の分野です。その隣にある「人材マネジメント」は、いわゆるタレントマネジメントの分野で、従業員のエンゲージメントを高め、一人一人がポテンシャルを発揮して働ける組織づくりをサポートする機能を提供しています。
また、自社で新しい事業展開の際にデータ活用をしているんですけど、さらにそれをサードパーティーに公開することを古くからやっています。
サードパーティーとは Web API を使ってデータをやりとりしています。その認可の部分に OAuth を採用しておりまして、そこを自前で実装するのではなく Authlete を使って解決しています。この取り組みは 2017 年頃から行っていまして、Authlete さんとは長いお付き合いをさせていただき、この場に呼ばれております。どうぞよろしくお願いします。
工藤 (Authlete): ありがとうございました。非常に長く使っていただいており、ありがたく思います。続きまして、マネーフォワードの根津さまにお話しいただきたいと思います。
マネーフォワード
株式会社マネーフォワードクラウド ERP 本部 API 推進部 部長根津陽氏
根津 (マネーフォワード): みなさんはじめまして、マネーフォワードの根津と申します。よろしくお願いいたします。
弊社は 2012 年に創業し、実は今年 2022 年、10 周年を迎えております。東証プライムに上場しております。
弊社は、「マネーフォワード ME」という To C 向けのお金の見える化サービスと、「マネーフォワード クラウド」という To B 向けのバックオフィスサービスを主に提供しております。おそらく大半の方には、家計簿の会社という認知が強いかと思いますが、売上の半分以上は「マネーフォワード クラウド」、すなわち To B 向けが占めております。
バックオフィスと言いましても、弊社は幅広く提供しております。規模では、個人事業主から、ミッド、エンタープライズといった上場企業、大企業にもご利用いただいており、領域についても、経理財務、いわゆる会計や請求から、一部 SmartHR さんと被るところなんですけれども、人事・給与・勤怠といった HR まで幅広くカバーしています。「マネーフォワード クラウド」として、いわゆる ERP と呼ばれるような、包括的なバックオフィスサービスとして提供しております。
そんな中で、製品も業務単位で細かく分けて提供しておりまして、大体 20 以上、管理系の基盤も含めるともう少しあります。すべてを弊社製品でバックオフィスを構築していただけると、我々としてはもちろん嬉しいのですが、昨今バックオフィスが複雑化してきている中、弊社以外のいろいろな SaaS 製品を組み合わせて業務を行っているというのが現状であり、業務効率化の文脈で必然的に API が必須になってきます。
その背景で今年からそういった文脈に力を入れていこうというところで、OAuth 認可の基盤の開発で Authlete さんを採用しました。本日はどうぞよろしくお願いいたします。
工藤 (Authlete): いまの根津さんのお話の中で、B2B SaaS 分野で共通の方向性のようなものがあるかもしれません。このあとお話しさせていただければと思います。続きまして弥生の飯田さまにお話をいただきます。
弥生
弥生株式会社開発本部 次世代プロダクト開発 データ API PM飯田武之氏
飯田 (弥生): 弥生株式会社の飯田と申します。どうぞよろしくお願いいたします。
創業自体は、非常に歴史が古く、1978 年から変遷を経て、現在に至っています。従業員数も 850 名、こちらはカスタマーセンターなども含む規模となります。開発はだいたい 300 名ぐらいの規模で、システム開発をしています。
弥生と言いますと、会計ソフトの会社みたいなイメージを持たれている方も多数いらっしゃると思います。弊社としてもそこから脱却しなければいけないというのもあり、会計ソフトに限らず、給与業務、商取引業務のデスクトップアプリケーションから始まり、クラウドサービスにも展開しています。また、お客さまの業務を支援する意味でも、サポートにも非常に力を入れているという状況になります。
加えて、最近では事業支援のサービスとして、起業、資金調達から、会計事務所の紹介などのサービスを現在展開しています。
こちらが、業務支援のサービスという意味で、バックオフィスの業務を効率化させるソフトです。上がクラウドサービス、下がデスクトップアプリケーションのラインナップになっております。企業会計、商取引業務で、現在、サービスを提供しています。
もうひとつのサービスが事業支援サービスです。企業が生まれてから事業継承するまで、創業から成長、成熟して再生に至る流れの中で、お客さまの業務を支援していくサービスも現在展開しています。
工藤 (Authlete): ありがとうございます。いまお話しいただいたように、デスクトップアプリとクラウドアプリがある中で、興味深い点があると思い、お話を伺っていきます。
本日のお題
工藤 (Authlete): 今日のパネルのトピックとして、4 つ考えております。
まず各社さまが、いろいろなサービス・ビジネスを展開されている中、API 認可・ID 連携にどう取り組まれているのかをお伺いします。
2 点目として、今回 OAuth・OpenID Connect をお使いになっていますが、その中での課題をお話しいただきます。
3 点目として、2 点目とちょっとつながるんですけど、Authlete を選定していただいたということで、その決め手と、導入していただいてどうだったかといったところをお伺いしていきます。
そして今後の展望ということで、これは各社のビジネスならびに、技術を使ってどうするかですとか、業界としてどうあるべきかといったところを、お伺いしていきたいと思います。
API 認可・ID 連携への取り組み
権限の管理
工藤 (Authlete): まず、API 認可・ID 連携の取り組みについてです。おそらく各社さんそれぞれ、サービスが複数ある中の連携が一点あるのと、それをどうやって外部のサードパーティーに提供するか、という 2 つがあると思います。
サービス間連携について、取り組まれている内容としてはどういったものがあるか、まず芹澤さんからお願いします。
芹澤 (SmartHR): 社内のサービス間連携はかなり歴史が古く、サードパーティに公開するよりずっと前から OAuth の技術を使っています。
その当時、いろいろな技術を検討しました。やっぱり大切なのが、誰が操作しているのかをちゃんと特定することです。権限管理をきちんとしたいっていうのは「バックオフィス SaaS あるある」で、B2B の経験がある人はもう首がもげるくらい頷くと思うんですけど、誰によって認可されたのかって情報が無いと何も始まらないんですよね。
その情報をきちんと持つために、OAuth を使って認可をした上でその人に適切な情報を与えているのが社内のサービス連携です。
工藤 (Authlete): 根津さんがいま非常に深く頷かれていました。権限管理のところ、B2B SaaS 特有のところは、どういったものがありますか?
根津 (マネーフォワード): まさにおっしゃった通りだな、と思って頷いていました。権限管理はその企業の規模が大きくなればなるほどすごく複雑化していきます。履歴を持たせたいだとか、権限の条件を細かく、CRUD の一つ一つすべて分離したいだとか、複雑化していき、誰が何をできるようになるのかを、細かくシステム上に設計する必要があります。その権限設計に API 認可自体の権限も含まれるので、芹澤さんのお話は、わかるなって思っていました。
芹澤 (SmartHR): けっこう「あるある」ですよね。
根津 (マネーフォワード): 「あるある」ですね。
工藤 (Authlete): 弥生さんは、古い部分と新しい部分と、権限も非常に歴史のあるものになっているのではないかと思いますが、そのあたりはいかがでしょうか?
飯田 (弥生): 弥生はデスクトップアプリケーションから始まっています。インターネットにつながってない世界で動いていたものを、クラウドサービスと連携させて、クロスセルでお客さまに使っていただくときに、どのデスクトップを持っているのかなどをしっかりと権限管理しなければいけません。
要するに、パソコン 1 台に対して 1 個のパッケージを入れるといった考え方です。それを ID で人とひもづけるところに難しさがあり、複雑化を招いている点でもありますが、そこをなんとかしていかなきゃいけないっていうのは常にやっているところです。
ID の管理
工藤 (Authlete): 権限とか ID を管理する際、いわゆるマルチテナント、複数のお客さまがひとつの環境に載る感じだと思います。そういった、分離しながら権限をどう渡していくかというのは、どういうかたちで取り組まれているのでしょうか?
飯田 (弥生): 基本的には、クラウドで使う 1 つの ID を取得していただき、そこに使っている製品をお客さまに登録してもらうことで、それに付随するサービスを使えるようにする、みたいな権限管理をしています。なので、バックエンド側にある複数の権限管理システムを見に行って、一つに集約する、といったことをしています。
工藤 (Authlete): その意味だと、一人に一つ ID を渡すという意味では、SmartHR さんは非常に面白いやり方、たとえば、会社が変わっても一つのID を使い続けるというお話があったかと思います。
芹澤 (SmartHR): 人間、働いていると転職したりするじゃないですか。そういったときに、IDを持ち越せるといいよね、とずっと考えています。まだその半分も実装できないんですけど、将来的にはひとつのIDをどんどん使い回して、いま所属しているところ、いままで所属していたところのテナントにそれぞれ入って、データを取れることができたらいいなと思っています。
工藤 (Authlete): 自分のアイデンティティを持ち歩くのは非常に先進的な方向だなと、以前伺って思いました。
おそらく根津さんのところでも、ERP という非常に大きいソリューションの中で、どういったかたちでサービスが分かれていて、どういったかたちで ID を統合しているか、その分離と集中についてはどのようにお考えですか?
根津 (マネーフォワード): 弊社には 2 つの ID の概念があります。ひとつは、各 1 ユーザーが持つ、マネーフォワード ID というものです。これと別に、事業者・会社ごとの ID があります。そこは N:N でひもづいています。なので、1 人のユーザーが、複数の事業者に所属・連携するしくみになっています。
というのも、たとえば経理ですと、本社の経理と子会社の経理を兼務しているので、両方の事業者にも所属している必要があるというケースが一例としてあるんですね。事業者の ID とユーザーの ID を、細かくひもづけて、さらに各サービス毎に、ユーザーに付与するログイン権限や機能の操作権限を分けているという状況になっています。
元々は家計簿から始まって、個人の家計簿をやっていく過程で、会社の家計簿、いわゆる会計の方、すなわちクラウド会計に派生して、隣接する経費や請求、給与といった領域にも進出するなど、徐々に事業領域が広がってきました。そうなっていく過程で、IDとしての相互依存性の課題が出てきて、ここ数年で、ユーザー の ID や事業者の ID といったところの横串の共通基盤を構築してきました。
OAuth/OIDC 基盤構築の課題
共通の基盤作り
工藤 (Authlete): 2 つ目の話に入っていこうかなと思うんですけれども、横串でやる場合に OAuth 2.0、もしかしたら OpenID Connect もあるかもしれませんが、そのような共通の基盤を作る際の課題となったのは、どういったところでしょうか?
根津 (マネーフォワード): さきほど申し上げた通り、まず、ユーザーの ID（マネーフォワード ID）と事業者の ID がすでにあって、認証の部分、誰がっていうところに関しては、すでに基盤を持っていました。そこから、外向けのパブリック API としての認可を、基盤としてどうやって構築していこうかと。
さきほどお見せした、20 以上あるプロダクトのうち、いくつかはすでに個別にパブリック API を提供しているんですが、認可の基盤を、OSS 等を使って各プロダクトが個別に実装していくと、複数製品をご利用いただいているユーザーさまは、それぞれ製品毎に異なる仕様でアクセストークンを取ってきて、認可してみたいになっていきます。そうすると、API を利用して連携を構築する際にかなり手間がかかります。
それを踏まえると、API を強化、提供していくにあたって共通の基盤が必要であると。ただ弊社独特の、ユーザーの ID とか事業者の ID の情報を組み合わせて基盤を作らなきゃいけないので、そういった社内の基盤同士の連携性が、今回認可基盤を作るときの一番の課題だったかなと思います。
工藤 (Authlete): 芹澤さんのところは、わりと早い段階から API 認可の基盤を共通化されたかと思いますが、どういった背景があったんでしょうか?
芹澤 (SmartHR): わたしたちはかなり早い段階から Authlete を入れていて、IDがバラバラな状態がまったく無かったんです。最初から、SmartHR の従業員情報基盤とアカウント基盤をハブにして、今後社内のいろんなサービスを作っていこうという思想があったので。
いま 20 前後ぐらいサービスがあるんですが、いずれも独自の認証基盤は持っていないんです。ユーザーには見えない形で SmartHR のアカウントを使ってシングル・サインオンしているのですごく綺麗ですね。最初にそういう思想をちゃんと作っておいてスケールさせていけたのは、かなりラッキーなことだったと思っています。
OAuth/OIDC への対応
工藤 (Authlete): 飯田さんはそのあたり、おそらく過去のいろいろな積み重ねというところから、今回の OpenID Connect / OAuth 対応というものがあると思いますが。
飯田 (弥生): 弊社は Authlete さんを導入したのが実はつい最近でして、今年の 7 月に旧認証基盤からリプレースを実施した状況です。
それまでも、OAuth 2.0 に準拠した認証ソリューションを使っていたんですが、それを使ってもう 7, 8 年経とうかというタイミングに来ていて、いろいろ手を入れるのが難しい時期にきていました。さらにその認証まわりで今後サービスを拡充していくところを踏まえると、新しいものを導入していかないといけない、というのがありました。
いくつかのサービスを比較・検討させていただいた中で、今後の拡充性を踏まえて、Authlete さんを今回採用させていただいています。
工藤 (Authlete): 弥生さんの場合には、従前の API 認可基盤があって、Authlete に入れ替えられたものと思います。そうすると、OAuth 2.0 への取り組みは非常に早かったですね。
飯田 (弥生): クラウドサービスをローンチしたのが、たぶん 10 年弱ぐらい前だと思うんですけど、そのタイミングから取り組んでいました。サービスに個別でログインというのはお客さまにとって不利益になるので、当時ソリューションを導入してシングル・サインオンを実現しました。
あと弊社のサービスの中で、たとえば POS レジや請求書の情報等を、他社のクラウドサービスと連携して弊社サービスに取り込むサービスがあります。そこでも、お客さまに認可してもらいAPI 連携を実現しており、OAuth2.0 の仕組みで認可し、連携しているものになります。
工藤 (Authlete): 課題として、もう一方で、OAuth の仕様の難しさというところもあるかなと思っていたんですよね。
たまに、OAuth ってオープンな仕様だから誰でも作れるって言われたりするんですけど、本当に作れるのかっていうと、どうなんでしょうね? この場で言うのはものすごいポジショントークっていう感じですが。まず、スクラッチから作るという発想については、芹澤さんはいかがですか?
芹澤 (SmartHR): 結構難しいのではないでしょうか。いわゆる車輪の再発明にしかならない気もしていて、ゼロから作ることはないと思います。
認可サーバーを立てるためのライブラリの利用を当初検討していました。しかし、バージョンアップや運用コストなどを考えると、あまり割に合わないんじゃないか、と当時思いましたね。
工藤 (Authlete): マネーフォワードさんには マネーフォワード ID という基盤がありました。そこを今回使わなかったのは、なにか課題があったのでしょうか?
根津 (マネーフォワード): マネーフォワード ID 自体は認証の基盤で、認可の仕組みを持っていなかったのが一番大きいかなと思います。
Authlete 選定の決め手と導入効果
Authlete を知ったきっかけ
工藤 (Authlete): いろいろな観点からの課題があったかと思うんですけど、今回 Authlete をご採用いただいて、そもそも、Authlete を知ったきっかけを伺ってもいいでしょうか。飯田さんからお願いします。
飯田 (弥生): 現行の認証サービスをリプレースしないといけないってなったときに、まずはテックリードがインターネットで調査し、一番最初に Authlete さんが出てきました。
あと、当時使っていたソリューションのバージョンアップ版とか、またそれ以外のサービスと比較検討しましたが、OAuth の勉強をエンジニアがしていたときに、参照した Qiita 記事が、後々知ったんですけど川崎さんの記事だったとか、そういう話は聞きましたね。
工藤 (Authlete): 芹澤さんにも、そのあたりをすごく語っていただけるんじゃないかと思っているんですけど、いかがですか?
芹澤 (SmartHR): きっかけですか。もうちょっと遡ると、もともと存じ上げていたんですよ。わたしは元エンジニアなんですけど、API 周りが好きで情報収集していて、こういうサービスがあるんだなって、なんとなく頭の片隅にあったのが最初です。
次に、弊社と Authlete 社って、同じベンチャーキャピタルの Coral Capital さん（当時 500 Startup Japan）が入っていますよね。Coral さんから紹介があったんです。「うちの投資先にこういうのがあるんだけど使わない?」 と。それで、ああ知ってます、という流れで。
たまたまそのとき、さっき触れたサービスの分離を始めようとしていて、使えるかもしれないってなと思って、まずはわたしがプライベートでアカウント作っていじってみたんです。
そうしたら、あまりにもデベロッパーエクスペリエンスが高い。ドキュメントの精度も高いですし、かんたんに試せて、いやこれめちゃくちゃいいなって思って、そのまま導入したというところです。
工藤 (Authlete): 当時 Twitter で逐一実況されていて。「イントロスペクション最高かよ」みたいな。
芹澤 (SmartHR): めちゃいいなと思いましたね。ひと通りそろっているんですよね。かゆいところに手が届く良さがありました。
工藤 (Authlete): 根津さん、Authlete という名前はご存知でしたか? こちらからお声がけしたというのはありますが、その以前に。
根津 (マネーフォワード): 弊社は Authlete さんからお声がけいただいたのがもともとのきっかけですが、さきほどの弥生さんの話にもあった通り、うちもこういった基盤を作るにあたってネットで記事を調べていて、それを書いた人を見ていくと、あ、Authlete の中の人だな、みたいなところからつながって、であれば話を聞いてみたいというか、信頼できるなってところはけっこうありましたね。
芹澤 (SmartHR): 川崎さんの Qiita がだいたいヒットするんですよね。
根津 (マネーフォワード): 読んでいると「書いた人」のところに同じ人の名前が毎回書いてある、という。
工藤 (Authlete): サーチエンジン最適化の限界を感じますね。そのあたりの施策って我々何もやってないんですよ、本当に。
芹澤 (SmartHR): そもそも数が少ないのかもしれないですね。あそこまで詳細に書かれている記事がなかなか無いので。ぼくも、社内で OAuth がわからないですみたいな人がいるときに、速攻で、Qiita のこれ見ておけば大丈夫だからという感じで、川崎さんの記事を使っています。
導入検討のプロセス
工藤 (Authlete): Authlete を使って、いま芹澤さんからおっしゃっていただいた通り、非常に使いやすい点を評価いただいているのかなと思います。実際に導入を決めたというか、はじめにトライアルをして、そのあと、これは使えそうだということで、プロダクションに持っていく感じだと思うんですけど、どれくらいの期間でできたか、飯田さんいかがですか?
飯田 (弥生): 検討自体は、たぶんお声がけしてから最終的に経営承認を得るまで、2〜3 ヶ月ぐらいだったと思います。
その間にいくつかの観点で比較検討して、機能的には、アクセストークンを発行する上でこういった機能がほしいってものをみたときに、他社さんだと無かったり廃止されていたりした中で、Authlete さんには存在していました。
あと弊社でも、ログイン画面とかは自前のものをそのまま使いたいというのがありました。IDaaS 系のサービスだと、ログイン画面とか、多要素認証とか、そういうのを全部コミコミで提供しますよ、みたいなものだったりします。そうしたときに、既存のデータをどうそれらのサービスと同期させようかとか、考えなければいけないことが多くあります。
その中で Authlete は「認可エンジン」に特化していて、非常に導入しやすいのが、決め手のひとつだったかなと思います。
コンポーネントとしての Authlete
工藤 (Authlete): UX の自由度で評価いただくケースが多いんですけど、根津さん、いかがですか? Authlete って部品じゃないですか。その前段を作れるという点で、良かったことがあれば。
根津 (マネーフォワード): みんなの銀行さんのお話にもあったんですけど、まさにそこがすごい良かったなと思ってます。
Authlete を採用理由は大きく 2 つです。もともと マネーフォワード ID と事業者の ID という基盤を持っていたので認可の部分だけほしかったことと、それらを組み合わせて構築しないといけないので、逆に変に作り込まれていると、ちょっと使いにくいな、と。
Authlete のように、コンポーネント型で API SaaS みたいなかたちで提供されているほうが我々としては使いやすかった、っていうのは大きかったです。
デベロッパーから見た Authlete
工藤 (Authlete): デベロッパー的な観点から、芹澤さん、具体的にどういった点が使いやすいか、もっとマニアックなところをお話ししていただいてもいいですか?
芹澤 (SmartHR): ぼくが API マニアとして思うのは、仕様書がすごく大事だということです。仕様書を読んだときに、わかりやすいとか、網羅されているとか、サンプルがちゃんと書かれているとか、レスポンスがきちんと過不足無く書かれているのは、やっぱり最初の DX（デベロッパーエクスペリエンス）として効いてきますよね。そこをきちんとされているのは、めちゃくちゃいいなと思いました。
一回実装しちゃうと、API のつなぎこみの部分ってそんなに意識しないじゃないですか。最初の部分がほとんどのような気がしていて、そこの体験が圧倒的に良かったなと思います。
工藤 (Authlete): ありがとうございます。とくに SmartHR さんには、導入していただいて、5 年ぐらい経つんですよね。
芹澤 (SmartHR): そうですね、5 年ぐらいですね。
今後の展望
工藤 (Authlete): 4 番目に入っていきますけど、いま作られたものを、どういうかたちで広げていくかをお伺いします。
芹澤 (SmartHR): 先程の自社紹介でもご説明したように、サードパーティーにデータを提供してこそサービスの真価が発揮されると思っております。その部分をどんどんやっていきたいです。
OAuth って、パッと理解しにくい。複雑ですよね、こう、行ったり来たりとか。そこをいかにサードパーティーにも理解していただいて、トラブル無く組み込めるか。さらに OAuth の概念だけではなく、B2B だと権限やマルチテナントみたいな考え方もあったりして、結構イニシャルの学習コストが高いなと思っています。
それを乗り越えて各社さんのサービスにインテグレートしてもらう、もしくはうちのプラットフォームに乗って新しくアプリを作るような枠組みも少しずつ取り組んでいます。
そういった事例を増やしていくことが、今後の API まわりのチャレンジかなと思っております。
工藤 (Authlete): 根津さん、いかがですか? 今後 ERP からどんどん広げていく方向、また高度化として認可基盤で提供する機能を増やしていく方向と、2 つあるかと思います。
根津 (マネーフォワード): 基本的には芹澤さんのお話にあったようなかたちと我々も一緒です。第三者との連携を強化することでもう一段マネーフォワードの価値を高めていく、今回構築した API の認可基盤はそれを支えるものとして、API を利用する開発者が効率よく利用できるよう利便性を高めていこうというところが、あります。
また、細かく製品ごとに開発チームがいるんですが、まだ API の提供をしている製品は一部で、まさにこれからなんですね。その際に、社内の開発チームが API を効率よく実装できるようにする、いわゆる社内のデベロッパーエクスペリエンスを上げていきたいです。
工藤 (Authlete): 飯田さんとしては、今後、デスクトップクライアントとか、利用する範囲が広がってくるというのがあると思うんですね。あと、サードパーティーもあるというところで、いかがでしょうか?
飯田 (弥生): もともとデスクトップを管理する ID と、今クラウド中心で管理している弥生 ID とをひもづけて、どんどん弥生 ID に、基本的には全部集約していきます。
もっと言うと、弊社は、事業コンシェルジュを目指していく方向、お客さまのありとあらゆるお困りごとに対応していくということを掲げています。弊社一社だけで当然できることではないので、いろんな会社さんと協力しながら進めていきます。そのときには、API と認可のしくみを提供し、シングル・サインオンできるようにして、よりシームレスにお客さまにサービスを届けるところを、今後のターゲットとして、頑張って広げていかないといけないな、というところです。
工藤 (Authlete): ずっとお使いいただいているということと、今後のビジネスの発展にお役立ていただけるとのことで、非常に心強く思いました。ありがとうございました。
