昨年12月東証マザーズに上場した、クラウド会計サービスを手がけるfreee。同社の佐々木大輔CEOは、上場後に公開された数々のメディアのインタビューで、「人工知能CFO」を実現したいと息巻いた。
そんなfreeeは現在、プロダクトのさまざまな箇所でAI（機械学習）を活用し、ユーザー体験を向上させている。
freeeのAI活用の現場はどんな組織なのだろうか？どのようにAIをプロダクトに落とし込んでいるのか？
freeeのBizDev、エンジニア、データサイエンティストの3名に、AIをプロダクトに組み込む際の苦労や、同様の取り組みをしている他社にも参考になるエピソードを語ってもらった。
プロダクトのさまざまな部分に入り込むAI
freeeでは、OCRを活用した帳簿の自動入力や、勘定科目の推測など、プロダクトのさまざまな部分でAIが活用されている。
昨年6月にリリースされた「資金繰り改善ナビ（外部サイト）」もそのひとつだ。これはfreeeのアカウントを持つ個人事業主や中小企業が、freeeのクラウド会計のデータをもとにした資金繰り予測や、融資を受けられる条件がわかるという機能。
資金繰り改善ナビ管理画面。出典：freeeウェブサイトより
この機能が生まれた背景を、サービス開発責任者の花井さんはこう語る。
「現場では、中小企業が資金繰りを予測できていない、そもそも口座の残高を把握できてないことは課題として挙がっていました。多くの中小企業は、通帳を見たり、ネットバンキングにログインしたりするタイミングで、今後数ヵ月資金繰りが大丈夫かを感覚的に捉えている状況だったんです」
通帳などを見るタイミングで、資金調達する必要があるか、調達する場合はどの金融機関からどのくらい調達できるかを考える。「場当たり的」なタイミングのため、数ヵ月後にキャッシュアウトすることがわかっていたとしても、調達のための手段がわからないといったケースもあったという。
そこで、資金繰り予測でそれらの企業に価値を提供するために、BizDevチームがfreee内部のAI開発チーム「スモールビジネスAIラボ」と機能開発を始めたのが約2年前だった。
花井一寛氏 金融事業部 サービス開発責任者
「もともと、これ以外の機能やほかのやりたいことについて、AIラボに定期的に相談はしていたんです。ニーズもある程度つかめていたため、この時期はこれをやってみましょうか、ということで始めたのが資金繰り改善ナビでした」
分析の前の「データ整備」に一苦労
資金繰り予測ナビを実装するにあたって苦労した点について聞くと、「データ整備」の部分だと、データサイエンティストの薄井さんが即答。
「社内には課金や離脱など、プロダクトの利用に関わる部分のデータはそろっていたんですが、預金残高を予測するのに適したデータは、データサイエンティストが分析しやすい状況になかったんです」
当時、預金残高の予測モデルを作成するのに必要な「どの変数が予測に寄与するのか」といったノウハウも社内に存在しなかったため、使えそうなデータはとりあえず収集することに。データを分析するのではなく、その準備から始めるのに苦労した、とエンジニアの横田さんは語る。
「データを取得するにあたって、エンジニアも手を動かす必要がありました。基本的に会計データは個々の会社ごとに処理しているのですが、今回は横串でまるっと取得する必要があり、これが厄介でした。そもそも隣の会社のデータを見られちゃまずい（笑）」
横田健志氏 プロダクト開発本部
データは横串で取得しなければならないが、その仕組み自体がない。データを適切に加工し、マイニングするためのデータセットの作成や、どのように効率よくデータを取得してサンプルを抽出するか、といった点に手間取ったという。
普通の会社（あえて普通という）であれば、この時点でベンダーに外注し、手間が増えそうだ。実際、AI系受託会社の提案を何社か受けたこともあるという。
しかし、各社から受けた提案はデータセットが存在することを前提としており、そもそも前段階のどのようにデータを取得するのか、どう加工するのかといった観点がなかったと花井さんは話す。
「結局、データを取得して加工するには、freeeのデータテーブルの意味を理解しなければならず、そこにリソースを張ることができるのかが提案を受けるうえでは重要でした。しかも、freeeは単なる仕訳マシンの会計ソフトでなく「取引」をベースとする構造。
freee自体の深い理解とデータ整備の視点とケイパビリティを、社外のベンダーに求めるのは難しかったうえ、収益を生むかもわからない。自社でやったほうがいいという結論になりましたね」
freee社内にはもともと、「データ基盤エンジニア」という職種はあったという。しかし、業務のスコープは主にファイナンス用の数字やビジネス上のKPI用の数字を取得してくるといったもので、プロダクトにデータを活用することを想定した職種ではなかった。
この件を機に、freee社内でデータエンジニアの必要性が叫ばれ始め、いまではデータ基盤チームの人数は当時と比べて倍増したという。
成功のコツは「心理的安全性」と「ホスピタリティ」
データ整備の苦労を乗り越えて、残高予測モデルの構築に成功した開発チーム。
しかし、この後、正式な機能としてのリリースに至るまでに1年半ほどの開きがある。freee finance labから資金繰り改善ナビが発表されたのは昨年6月だ。
関連プレスリリース（外部サイト）
freee finance lab、 スモールビジネスの資金繰りを改善する 総合的な金融サービスの提供を開始 - クラウド会計のデータをもとにした予測や、条件が事前にわかる融資サービスなどを「資金繰り改善ナビ」として展開 –
この開きはどういうことなのか。この疑問に答えるには、freeeのカルチャーに言及する必要がある。
そもそも、資金繰り予測をプロダクトに組み込むことは「本決まり」ではなかった。つまり、ある種のR&Dとして始まったプロジェクトだったのだ。
「モデル開発は半年くらいで終わり、そこから1年くらい潜っていたんです。その後、資金繰り改善ナビという正式な“場所”でリリースすることが決まって、さすがに正式に出すならもうちょっと詰めますか、となって実装に移りました（笑）」
薄井研二氏 スモールビジネスAIラボ データサイエンティスト
一見、見切り発車で、悪くいえばうまくいく気がしない。実際、AIプロジェクトでよく聞く話として、目的がハッキリしていない状態で開発に進むのは自殺行為だからだ。
機能のニーズもある程度しか把握できていない段階で、なぜエンジニアとデータサイエンティスト、ビジネス側のリソースを確保してプロジェクトに突っ込めるのだろうか？
「資金繰り改善ナビは、事前にユーザーヒアリングを綿密に行ったわけではありません。ビジネス側と普段からコミュニケーションを取るなかで、ある程度ニーズがあるとわかった段階で、じゃあやってみようと開発に踏み込みました。
R&D段階ではある程度自由度がないといけないと思うんです。機能開発の際、『実際に使われるのか』を考えだしたらキリがない。そういう意味で、まずは出してみて、使われるためにみんなで協力しあえる文化がありますね」
組織の線引きもあいまいで、プロジェクトごとの責任範囲はあるものの、その中で何をするかは個々人の判断に任される。データサイエンティストやエンジニアの工数を確保するにも、上長に打診して工数を確保してもらって……などの手続きは不要だという。
「freeeは全社的にホスピタリティの高い組織です。『あえて、共有する』というバリューもあるくらいで、全社的にコミュニケーションも活発です。心理的安全性のある組織と言えるでしょう。
加えて、ボトムアップの文化があります。大きく取り組む課題やロードマップはありますが、そのソリューションを上から指示されて開発するようなことはありません。今回も、そもそも会社の方針で資金繰り予測をやると決まったわけではなくて。みんながユーザーのためによかれと思って自律的にやっていますね」
「リリースして終わると思うな」「仲良くするのが一番大事」
このような組織文化は、他社が簡単に真似できるものではないだろう。freeeには「マジ価値指針」という行動指針があり、ユーザーに「マジ価値（ユーザーにとって本質的な価値があると自信を持って言えることをする）」を届けるという価値観が浸透している結果といえそうだ。
freeeのマジ価値指針。出典：freeeウェブサイトより
しかし、それでも何か読者の参考になることはないか……と思いながら聞いてみると、おもしろいエピソードを聞くことができた。
「薄井がつくったモデルを『薄井モデル』と呼んでいたのですが（笑）、それをどうプロダクトに実装すべきかで議論していて。
当時の勝手なイメージですが、いわゆるR&Dをするようなラボはソースコードが汚いという印象を持っていました。freeeはもともとRubyが強い会社なので、実装段階ではRubyに変換する想定でしたが、結果としては薄井の書いたPythonコードをそのまま使うことができたんです」
「実際、コミュニケーションさえ取れてれば実装まで持っていけたのに、という会社は多いと思います。データサイエンティストが気を使ったコードを書けていれば……とか。
資金繰り改善ナビについても、Pythonをそのまま使えばいいじゃん、という議論が可能だったからこそ実現できました。これをベンダーに依頼するとなると、ブラックボックス化してしまい難しかったと思いますね」
加えて、「リリースして終わると思うな」とも薄井さんは話す。
「リリースまでみんなでオーナーシップを持ってやりきることも大事ですが、リリースしても結局モデルを改善する必要もあるし、そもそもリリースどころかPoC（Proof of Concept…概念実証）でプロジェクトが頓挫してしまう企業も多い。これは、PoC段階までのリソースしか確保していないのが原因だと思います。
そのような企業は、結局『AIを活用した何か』を出したいだけだから失敗する。本当にそのサービスや機能が欲しかったら、本気でリリースまで持っていきますよね。『出す前提』で動くことが重要だと思います」
だからこそ、あまり「PoCという考え方をしないほうがいい」と薄井さんは言う。PoCで一定の結果が出ても、サービス化まで持っていけない企業が多い中、あくまでサービスとして世の中に発表する前提でAI開発に取り組むことで、競争力が生まれるのだろう。
そして、当たり前だが、普段からの共有ができていればいるほどコミュニケーションが活発になり、プロジェクトも進みやすい。意思疎通ができていなければ、双方の認識に齟齬が生まれ、プロジェクトが頓挫する可能性も高まる。これはAIに限った話ではない。
最後に、薄井さんのこの一言を紹介しておく。
「事業部とニーズの共有ができていればいるほどアイディアも浮かんできますし、エンジニアと意思疎通できなければ実装も上手くいかない。BizDev、エンジニア、データサイエンティストで仲良くすることが一番大事です」
