入社当時の状況と、『freee会計』の大まかな進化
2017年7月にfreeeに入社して以降、一貫して『freee会計』の開発に携わってきた久保。これまで、さまざまなチームに所属しながらプロダクトの進化を担ってきました。入社当時について、こう振り返ります。
「前職はバックエンドエンジニアでしたが、Railsも触ったことがない状態で入社しました。
freeeは、今でこそ開発文化を言語化していて、その中の一つに『何でもやれる、何でもやる』がありますが、入社当時からその片鱗はあって、フロントエンドもバックエンドも本当に必要なことはなんでもやる必要がありました。
要は、フルスタックエンジニアをめざすというものです。振り返ると、技術的にはずいぶん鍛えられました」
入社当時、Railsの書き方が複雑で心配の種だったと語ります。しかし、そこにはスタートアップならではの理由がありました。
「プログラムは、基本的には上から順に実行されていくものですが、当時はコールバック（ある関数の完了をトリガーに、別の処理をさせる手法）が多用されていたせいで、かなり動きが複雑でした。どこで何が起きているのかをパッと見て理解するのが難しく、障害が発生したとき大変そうだなと思いました。
ただ、これはサボっていたわけではありません。当時のfreeeは、とにかく新しい機能をリリースすることを優先し、スピード感を持ってプロダクトを進化させることだけに注力していたのです。会社のフェーズ的にはしょうがないし、今考えても正しいやり方だったと思います。
エラーや障害が起きたらデータパッチを当てる方式で、即対応していました。応急処置みたいなものですね」
スピード感を優先して開発された『freee会計』。“機能の充実”と“ターゲットの拡大”がプロダクトの進化を支える両輪でした。
「2012年のリリース時は、スモールビジネスのみをターゲットにしており、経理部門が使うような機能しかありませんでした。そこから、経費精算など機能をどんどん増やすことで少しずつ従業員が使えるシステムへと進化し、徐々に従業員数の多い法人にも使っていただけるようになりました。
私が入社した2017年は、ちょうどエンタープライズプランができたころで、これから上場企業向けの機能も充実させていくぞというタイミングでした。そこから、さらに細かい機能を充実させ、他のプロダクトや銀行、クレジットカード、ECサイトなどとの連携を多く実現しました。
現在では、スモールビジネスをメインのターゲットにしながらも、ありとあらゆる規模のお客様に使っていただけるプロダクトになっています」
エンタープライズプランの販売拡大と、2019年の上場はプロダクトにも大きな影響を与えました。結果として「品質開発」チームが誕生し、久保はジャーマネ（※）となります。
「お客様の裾野が拡大すると『データに不整合が起こるのは、なんたることだ！』といったような意見をたくさんいただくようになりました。これまで、バグには応急処置で対応してきたけれど、それだけでは限界が来たのです。
そこで、本腰を入れて品質向上の取り組みを行うために品質開発チームが誕生しました。freeeが成長してきたからこそ必要になったのです」
※ マネージャーのこと。freeeでは単にメンバーの上に立つ者のことではなく、“タレント”であるfreeeのメンバーを叱咤激励し、成長・活躍をサポートする役割だと考え、ジャーマネと呼んでいる
品質開発チームの役割と、リファクタリングの重要性
所属する品質開発チームの取り組みについて語ります。
「債券、債務、消し込みなど『freee会計』の機能におけるデータの正誤が起こらないようにする取り組みや、機能拡張のアプローチを行っています。また、根本的な権限周りの仕様の変更など、品質の根幹に関わる部分の開発と改善を行っています。
開発の流れとしては、ヒアリングなどを参考にしてPdMと一緒に改善、開発が必要な部分を見出し、優先度を考えてどのように実現するか判断し、要件が決まったら実際に手を動かして開発しています」
主な改善方法に、リファクタリングがあります。
「リファクタリングとは、プログラムの外部から見た動作を変えずにソースコードの内部構造を整理することを指します。主な目的は、パフォーマンスの向上とソースコードの理解や修正を簡単にすることですね。
小さな事業所は、データ量が少ないのでバックエンドのフォーマットをそこまで気にする必要はなかったのですが、大量のデータを持ってるお客様が増えてきたので、パフォーマンスの課題にチャレンジする必要が生まれたのです。
これは、品質開発チームだけでなく、インフラチームを含めた全社での取り組みになりました」
固定資産機能のリファクタリングは、とくに大きな成果を上げたものの一つです。
「たとえば、パソコンなど金額のある程度大きなものを購入した場合は減価償却をする必要があり、『freee会計』に登録すると自動的に月毎の仕訳を作成し、償却が終わるまで管理できます。
昔からこの機能はありましたが、品質が良くなく問い合わせが多かった。じつは、『セールスチームが固定資産機能を売りたがっていない』という話も聞いたことがあり……それはまずいぞと、本気で動き始めました。
基本的に固定資産を持ってないお客様はほぼいないので、その部分だけ他社のプロダクトを使ってfreeeにデータを取り込むこともできるのですが、freeeは統合型経営プラットフォームを目標としており『freeeのプロダクトを使えばやりたいことが全部実現する状態』をめざそうとしているので、看過できる問題ではなかったんです。
1年ぐらいかけてリファクタリングを行いました。膨大なデータが蓄積されていたのですが、裏側のデータの持ち方からすべてを変えていったんです。
2023年現在、固定資産は『freee会計』で当たり前に使える機能となっています。改善がきっかけで契約してくれたお客様もいて、その話を聞いた時は感慨深かったです」
リファクタリングは、技術的にもビジネス的にも大切だと言います。
「ソースコードの理解や修正を簡単にすることは、新規機能開発のスケジュールを早めることにつながります。PdMが新しい要件を持ってきた時に、リリースまでの目処も立ちやすいです。
また、リリース後のバグの件数も減り、不具合が発生したときの原因究明も楽になります。
新機能の要望や品質改善のリクエストはたくさんいただくので、お客様の喜びにもつながっていると信じています。
反対に、新規機能開発のペースが鈍化すると、他のサービスとfreeeのプロダクトを併用する場合が多くなってしまいます。お客様に価値を届け、freeeを使い続けていただくためにも、効果的なリファクタリングを行うことはビジネス的にも重要なのです」
freeeの開発環境の変化と、雰囲気
久保が入社した当時と2023年現在の開発環境の変化について語ります。
「入社当時は、基本的には当時のプロダクト開発本部長とPdMが何を作るかについてすべて考えて、そこから降りてくる要件に沿ってエンジニア内で担当を分割しながら開発していました。
しかし、プロダクトの成長に伴いその方式では仕事が回らなくなったので、チーム内で意思決定して開発するようになりました。
2023年現在では、ボトムアップで何を作るか、どう作るかを議論して要件を決め、リリースまで終わらせています。freeeには『マジ価値（ユーザーにとって本質的な価値があると自信を持って言えること）』であれば、チームに裁量があり進めているける良い文化が根付いています」
新規メンバーに対するフォローアップ体制も整っていると言います。
「サービス自体が大きいので、入ってすぐに必要なことすべてをキャッチアップできるとは考えていません。新しく入社してきた方にはメンターがつき、わからないことはなんでも質問してもらっています。また、メンターでもわからない場合はSlackに投げれば誰かしらがそれに対して返答してくれます。
これは、freeeの開発文化で『世話を焼いていくスタイル』と言語化されており、チーム内外を問わず周囲を自分の知見で助けること。レビューすること。システムor人間のアラートに疾風迅雷のごとく反応することと定めています」
また、Slackでの雰囲気、コミュニケーションの取りやすさについてこう語ります。
「過去に誰かがつまづいたところは、Slack内を検索すると出てきます。膨大な知見の蓄積をもとに、みんなで調べて助け合っている環境ですね。
誰かの疑問に対して『そんなのもわからないの？』なんて意見は聞いたことがありません。わからないのは当たり前という前提で働いています。
現在は社内の人数も増えてきたので、Slack内で誰がどこの部屋にいるのか知らなくても相談できるように、絵文字を付けるようにしています。たとえば、Psirtの担当者の名前がわからなくても、Psirtの絵文字をつければ相談内容がPsirt部屋に流れるように仕組み化されています。
会社の規模が大きくなっても働きやすい環境づくりにはこだわりを持っていて、達成できていると思います」
これからfreeeに入社する人は、技術的なことの他にも関心を持って欲しいと言います。
「プロダクトがかなり増えてきたので、技術的なチャレンジの幅は広がったと思います。ただ技術的な関心だけではなく、お客様がfreeeのサービスを使うことでどういうふうに業務が良くなるのか──それに関心を持って、お客様体験をさらに良くしたいと考えている方に来ていただきたいですね。
やっぱり、自分が関わった機能をたくさん使ってくれてたら嬉しいじゃないですか。
また、何にでも興味を持って、閉じこもらずにチャレンジして欲しいです。Slackではいろいろな情報が流れてくるので、アンテナを立てて新しい機能や『freee会計』以外のプロダクトの状況などもキャッチアップして、仕事やコミュニケーションに生かして欲しいです。
freeeではエンジニア同士が自分のチームにこだわらず横でつながっているので、そこを楽しんでもらえる人だと良いですね」
統合型経営プラットフォームの実現に向けて
上場を達成し、数多くのプロダクトをリリースしているfreee。これからfreeeに入社するエンジニアが業務として期待できるおもしろさがあると久保は語ります。
「統合型経営プラットフォームを実現するには、これからサービス同士を切り分け、シームレスに連携させる必要があります。
今は『freee会計』にいろんな機能がくっついていて、何かを実行するたびに『freee会計』を呼び出している状況なんですね。まずは、『freee会計』から一つひとつの機能を引き剥がして分割していかないといけません。
これはけっこう難易度が高くて、データの不整合などパフォーマンス関連の問題がいろいろ出てくると予想されます。そこで、重大なインシデントになるような不整合を起こさないのはもちろん、パフォーマンスも落とさずにお客様がストレスなくプロダクトを使える状況を担保していきたいです。
なので、この難しさを楽しめる人に入ってきていただきたいですね」
切り離した後、シームレスに連携させる部分にも業務の楽しさがあると言います。
「じつは、統合型のサービスを作るというのはfreeeだけがやってることではなく、世の中にはそういうプロダクトはたくさんあります。
その上でお客様に『freeeのこれが良いんだよね』『ここが便利なんだよね』って言ってもらえるような統合の仕方をめざしています。
お客様から見た使い勝手、エンジニアから見たシステムの連携方法、どの切り口で見ても使いやすく開発しやすい状態に持っていくことが求められています。多面的にものごとを考え、freeeのプロダクトを次のフェーズに持っていくチャレンジがこれから待っているので、ワクワクしています」
2023年12月現在、債権債務開発チームで責任者を担当している久保。これからの目標を語ります。
「個人的な目標は、ずっと手を動かしていたいということですね。マネジメントだけではなく、いちエンジニアとしてコードを書いていたいです。また、統合型経営プラットフォームの構築に大きく貢献できるエンジニアでありたいなと思います。
俯瞰すると、freeeってすでに何か一つ良くするだけで日本の生産性がめちゃくちゃ上がるレベルのプロダクトになっているんですよ。レスポンスを1秒速くするだけで、プロセスを一つ省略できるだけで、freeeのプロダクトを使っているすべてのお客様が、その分の時間を別のことに割けるというポジティブな影響があるんです。
お客様全員の1秒の総量で考えると、日本全体で数年分を節約しているような改善になるんです。
そんなプロダクトの開発に関わっているので、これからも日本の生産性を上げるチャレンジをし続けたいと考えています」
※ 記載内容は2023年12月時点のものです