freeeのプロダクトと外部サービスとの連携機能を開発しているコアエンジンチーム。こちらの記事では、freeeのミッション『スモールビジネスを、世界の主役に。』を実現させるために、チームが果たしている重要な役割とこれまでの取り組みをコアエンジンチームの長幡と田邉が語ります。

自動連携機能は、お客さまがfreeeを選ぶモチベーション

（長幡）

2015年11月、エンジニアインターンとしてfreeeに入社した長幡は『freee会計』の開発に携わります。

約1年半にわたるインターン期間を経て新卒入社すると、それから一貫してコアエンジンの開発に携わり続け、2023年末まで組織全体のジャーマネ（※）を担当してきました。

長幡「コアエンジンチームでは『freee会計』を中心に、銀行・クレジットカード・レジ・決済サービスなどの外部サービスとの連携機能を開発しています。

この機能の存在により、従来通帳や明細書などから転記・仕訳作業が必要だった状況から、『ボタンをポチ！』と押すだけで同じ転記作業がほぼ完結することを実現しています。これがデータ連携による業務の“自動化”です」

2017年に中途入社した田邉も、一貫してコアエンジンチームに在籍しています。チームが“コアエンジン”と呼ばれている理由について語ります。

田邉「『freee会計』における自動化・業務効率化のコア（核）となるエンジンを開発しているチームであることが由来です。

実際、お客様へのインタビューやアンケートなどでも、『freee会計』を使う理由として外部サービスとのデータ連携機能を挙げていただけることが多々あるので、身が引き締まる思いです。

コアエンジンはfreee独自の用語で、他社さんでは『外部連携サービス開発チーム』や『データアグリケーションチーム』と呼ばれていたりします」

2人が、コアエンジンチームで働く上で心がけていることを語ります。

田邉「お客さまにfreeeを選んでいただき、継続して使っていただくモチベーションの1つとなるのが自動連携機能。まずこの機能を安定させて稼働させることがマストだと考えています。

当たり前に動く機能として、いつも使えて、いつも正しくデータが表示されるように心がけています。責任は大きいですよ」

長幡「それに加えて、預かってる情報がセンシティブなので、それらを適切に管理することを心がけています」

コアエンジンを構成する4チームと、それぞれの役割

イベントに登壇中の田邉（左）と長幡（右）

コアエンジンチームでは『freee会計』と、外部サービスツール連携のための『マイクロサービス』の2つの開発を行っています。

長幡「データ取得の流れを説明すると、まず『マイクロサービス』が外部サービスからデータを持ってきて、マイクロサービスの中に保存します。そのデータを『freee会計』が参照して、ユーザーにわかりやすい形に変換して表示しています。あいだにワンクッションを置いた形で、連携機能全体を実現しています。

『freee会計』ではマイクロサービスと連携するための部品のようなものを開発し、『マイクロサービス』では主に外部サービスと連携するための部品のようなものと、マイクロサービスそれ自体を開発しています」

田邉「現在使用しているマイクロサービスは、ここ数年で作られた新しいものです。以前は『freee会計』のRailsアプリケーションの1モジュールとして開発していたのですが、移行しました。

その移行のための開発もする必要があり、システムのコードの書き方によって、情報処理の早さや処理できるデータの量が変わってくるので、なかなか大変な作業でした」

コアエンジンチームは、さらに細かく「基盤」「品質」「マイクロサービス開発・銀行／クレジットカード」「マイクロサービス開発・EC/決済」の4つのチームに分かれています。

長幡は全体のジャーマネを担当し、田邉は基盤チームに所属しています。それぞれの役割について語ります。

長幡「ひとくちに“連携”と言っても、連携先には銀行・クレジットカード会社・ECサイト・POSレジなど様々な種類があり、それぞれ取り扱ってるデータの構造が違います。

『マイクロサービス開発・銀行/クレジットカード』『マイクロサービス開発・EC/決済』の2チームは、それぞれの領域に特化して新規連携先の開発、連携機能の改善を行っています。また前述したRailsモジュールで動いていた連携機能をマイクロサービスに移行するのも担当しました。

『品質』チームは主にユーザーから見たデータ連携機能の品質向上を目指すチームです。様々な原因で連携機能が止まってしまったり、誤った形で明細取得をしてしまうことが少なからずあるので、それによってお客様に迷惑をかけてしまわないよう、可能な限りエラーを減らすなど、機能としての品質と価値を上げていくことをメインテーマにしています」

田邉「私の所属する『基盤』チームは、システム運用を担当しており、データ連携機能のシステム基盤の改善を通して、チーム内の生産性や直接的な機能の向上を目指すチームです。

インフラ面ではプロダクト内のSRE、DBRE的役割として、IaC化やEKSクラスタの管理、DBのパフォーマンス改善などを担当し、プロダクト面ではデータ連携システム全体に横断するようなロジックの修正と改善、社内モジュールの導入などによる生産性の改善などを行っています。

また、いわゆるPSIRT/CSIRT的な役割としてプロダクトセキュリティの改善、組織的セキュリティ統制上の改善など、セキュリティ面からのアプローチも重要なチームの役割です。

担当領域は広く、求められている期待値は多岐に渡っていますが、一定期間フォーカスする領域を決めて、集中して改善を進めています」

コアエンジンの業務の難しさ——必要とされる膨大なドメイン知識と臨機応変な対応力

コアエンジンの業務の複雑さ・難しさは、連携先が多岐に渡ることに由来していました。

長幡「開発にはそれぞれの連携先のドメイン知識が必要になります。

例えばクレジットカードの利用明細をデータとして取得する場合、返品・リボ払い・カードの再発行などをどう扱うかという問題、つまりクレジットカード固有の振る舞いを考える必要があります。

銀行についても同じで、合併があったらどうなるか、口座番号の変更があったらどうなるかなど、ひとつひとつの事象に対してfreee側のシステムをどう対応させていくか考えないといけません。

freeeは連携先の種類も数も多いので、その分ドメインに関する知識は膨大に求められますね」

田邉「そのうえ、新規の連携先が増える時にも考えることがたくさんあります。

既存のドメイン知識で対応できるものであればうまく適合するように作ることができますが、未知のドメインの場合はfreeeとしてどう扱うべきか考えるところからスタートするので、そのぶん難易度は上がります。

具体的には、連携先のAPIの仕様書を読み込んで、ドメインが適合した上でfreeeがやりたいことを実現できるのか分析する必要があります。モノが出来上がる前からAPIをどのように使うかを考えながら分析するので、想像力が求められますね」

一度うまく連携できたら終わりというわけではありません。

長幡「連携先システム仕様が変更されたり、相互にシステム不具合が発生してしまうなど、常々様々な理由で連携機能が提供できない事象が発生します。同時多発的に発生することもあります。

そのため、我々のチームでは常に変化を察知してすぐに対応できるような仕組みを作ることを心がけています」

取得したデータを『freee会計』に取り込む時にも、考慮しないといけないことがあると言います。

長幡「会計上のデータとしてどう取り込まれるべきか把握していないと、データそのものは正しいけれど、会計のデータとしては正しくないみたいなことが起きてしまうことがあり得ます。例えば税率や税込・税抜の区別などが正しい値として表れなかったり、経費になるか、どの勘定科目に紐づくべきかという判断も誤ってしまいます。

1行の明細が会計としてどういう意味を持っているかを常に意識して、正しい状態でデータを取り込むことが理想です」

『freee会計』のユーザーインターフェースも考慮すべき点がありました。

田邉「これは『freee会計』全体にも関わる話かも知れませんが、複雑なものを、わりと単純なものとしてユーザーに見せられるようにしています。しかし、その裏に複雑さを隠してるがゆえに、ユーザーからするとブラックボックスのように感じてしまうことがあるんです。

簡単にしたい、わかりやすく表現したいところと、完全にユーザーが制御できるようにしたいところ、この相反する事象をバランス良く取り扱うのは難しく、常に頭を悩ませています」

スモールビジネスの皆様に、究極の自己実現をしてもらうために

時系列を少し遡りますが、2人が口を揃えて「大変だった」というプロジェクトがあります。それは、2019年から2020年にかけて行われた、全国のほぼ全ての銀行とのAPI連携の実現でした。これはお客様にも特に価値を感じていただいている機能です。

2020年5月までに、プロジェクトを完遂する必要がありました。実現できなければ銀行口座とのデータ連携ができず、ユーザへの提供価値が損なわれてしまうので、いわば社運を賭けた挑戦でした。

長幡「何が大変だったか一言でいうと、数です。財務省のHPによると、信用金庫・信用組合・農協などを含め、当時全国に銀行は922行ありました。

共通のAPIの製品を導入している銀行様もいらっしゃって、まとめて実装できることはありましたが、それでもかなりの数を個別に開発する必要がありましたが、それらのほぼ全ての銀行様の個人/法人口座とのAPI連携を実現しました」

田邉「銀行様とのAPI連携についてのコミュニケーションやスケジュール調整はfreeeのBIZ側の組織を経由してやってもらっていましたが、大変なことの一つでした。

さらにシステム的に繋がることが可能になっても、契約が成立していないと実際は使うことはできません。期間内に全て終わらせるためには、BIZ側と連携して契約の進捗を頭に入れながら、優先度を決める必要がありました。

期間内にほぼ全ての銀行様との連携がリリース時は、味わったことのない充実感がありました」

連携先が増えることは、freeeのミッション「スモールビジネスを、世界の主役に。」の実現に近づくことだと言います。

田邉「freee会計の連携機能としてお客様に対して『マジ価値（ユーザーにとって本質的な価値があると自信を持って言えること）』をもたらしているのは、経理業務の自動化・効率化の機能だと考えているんです。

freeeのメインのターゲットはスモールビジネスで、担当者がこれまで経理業務にどれだけの時間を割いてきたかといえば、計り知れません。

それが今は『freee会計』を使ってボタンをポチっと押すだけで、転記まで全て終わる時代になりました。連携先が増えるということは、1人でも多くの人がバックオフィス業務から自由になることに繋がります」

長幡「今までバックオフィス業務をしていた時間を自分の事業のために使うことができるようになると、例えば飲食業の人なら来月から出す新メニューを考えたり、店のレイアウトを変えてみたりすることができます。

そうすればお客さんがもっと定着するかもしれないし、売り上げが上がって従業員の雇用や、新店舗のオープンに繋がるかもしれない。

自分がやりたいことを事業として開業されていると思うので、もっと自分のやりたいことに時間を使って多くの人にその価値を届けることができるって、究極の自己実現だと思うんです。

日本中でそういう人たちが増えたら、まさにfreeeのミッションである『スモールビジネスを、世界の主役に。』が実現できるんじゃないかと。

コアエンジンチームは、その根幹となるところを作っているという自覚があります」

コアエンジンチームが目指しているのは「統合型経営プラットフォーム」の実現です。

そのプラットフォームにより、バックオフィス業務を統合し、自動化による業務全体の効率化を図っていますが、まだfreeeのプロダクトがカバーしていない業務領域が存在することも事実です。

仕組みとしては素朴にデータを取得しているだけかもしれませんが、外部サービスがカバーしている業務領域も含めて「バックオフィスの統合」を進めていくため、コアエンジンチームは走り続けます。