次に採用すべきはファイナンスエンジニアかもしれない理由

財務の歴史には、時代ごとに希少なスキルがありました。会計、次にディールメイキング、そして計画策定と指標管理です。a16zがYou Need a New CFO（英語）で述べたように、「今日の希少なスキルは、まったく新しいもの、つまりオペレーティングシステム（業務の仕組み）を設計することです」。私は、この新しいスキルには新しい役割が必要だと考えています。その1つがファイナンスエンジニアです。

企業は、インターネットのスピードからエージェントのスピード（英語）へと移りつつあります。財務部門は、市場、法人、通貨をまたいで、価格設定、事業拡大、資本配分をほぼリアルタイムで導かなければなりません。OpenAIでは、Sarah Friarがゼロデイ決算（英語）の実現に取り組んでおり、財務を定期的な機能ではなく、継続的に動く機能として運営しようとしています。

Airwallexでも、私のチームはこの原則を取り入れてきました。わくわくする取り組みですが、AIの乱立を招くおそれもあります。何十ものツール、ばらばらの基準、そして最後の一歩で止まってしまうプロジェクトです。

ファイナンスエンジニアが必要な理由

シチズン開発者（エンジニアではない現場の担当者で、自らツールを作る人）は、誰よりも業務領域を理解しています。彼らがつまずくのは、範囲の決定やデータへのアクセスから、本番環境への展開や情報セキュリティ（InfoSec）対応まで、ツールづくりを取り巻くあらゆる部分です。現実的には完成させられない野心的なプロジェクトを始めてしまう人もいます。

全体像に責任を持つ人がいなければ、2つのシナリオのどちらかに陥りかねません。何も作られないか、あまりに多くのことが始まって何も完成しないかです。

半分はプロダクトマネージャー、半分は作り手

ファイナンスエンジニアは、作る価値のあるプロジェクトを見極め、それが確実に本番運用に乗るようにします。

プロダクト面では、まずロードマップに責任を持つことから始まります。当社のファイナンスエンジニアは、担当者、テスター、障害となっている事項を明確にした取り組みの管理表を運用し、Slackで毎週進捗を共有しています。この見える化が、物事を前に進め続けます。

また、シチズン開発の標準的な進め方も定めています。たとえば、どのプロジェクトにも、たとえ数段落であっても製品要求仕様書（PRD）が必要です。最初に要件を定義しておけば後の時間を節約でき、より簡単な解決策が見つかることもよくあります。シチズン開発者には、早い段階でベータテスターを募り、共同オーナーとして関わり続けてもらうことも求めています。そうすれば、最初のバージョンをリリースした後も開発のスピードが落ちません。そして技術的な問題やセキュリティ上の障害があるときは、ファイナンスエンジニアと協力して解決策を探し、InfoSecとの調整を行います。

同じくらい重要なのが、学んだことを共有することです。私たちは毎週AIのデモを行い、アプリのデータベースとFAQを整備しているため、誰もゼロから始める必要がありません。また、財務部門の誰もが取り入れて実行できる、繰り返し使えるAIの業務フローであるスキル（Skill）も共有しています。これにより、チームはそれを作る時間を減らし、出力を確認することにより多くの時間を使えます。

この役割のもう半分は、自ら作ることです。当社のファイナンスエンジニアは、最も複雑で影響の大きいプロジェクトを自ら担当しています。

鍵となるのは実用性

ファイナンスエンジニアに私がまず求めたのは、実用性を見極める確かな目です。今日では、アプリ、スクリプト、エージェントのスキルなど、さまざまな方法で課題を解決できますが、大切なのは、その仕事に合った適切な手段を選ぶことです。

たとえば、予算データの収集です。私たちは専用ツールの構築を検討しましたが、関係者はGoogleスプレッドシートを好んでおり、専用アプリを作れば例外的なケースに際限なく対応しなければならないことがわかりました。そこで代わりに、各シートを当社の統合フォーマットに変換するスキルを作りました。これにより、予算担当者は使い慣れたやり方を続けられ、私たちは何週間分もの開発時間を節約しつつ、自動化の恩恵も得られました。

一方で、ローカルで実行するスキルだけでは足りない業務フローもあります。たとえば法定報告は、チームをまたいだ協力が必要です。そこで私たちは、監査済みのテンプレート、マッピング、統制を備えた社内アプリケーションを構築し、AIエージェントがMCP経由で操作できるようにしました。各チームは共通の画面でレポートを確認でき、エージェントはレポートの下書き作成と相互検証をすばやく行えます。

次に私が求めたのは、関係を築く力です。業務の専門家（SME）は製品要件を理解していますが、優れたファイナンスエンジニアは、彼らが想像もしていなかった自動化の可能性に気づかせます。初期の段階では、ファイナンスエンジニアは、専門家がまだ何の恩恵も感じていないうちに、彼らの時間を割いてもらう必要があります。専門家が協力するのは、その人に好感を持っているから、経営陣が期待しているから、あるいは好奇心があるからです。主に好奇心からだと思いたいところですが、たいていは最初の2つです。だからこそ、関係づくりがとても重要なのです。

関係づくりは財務部門の外にも広がります。ほとんどのプロセスはデータ、プロダクト、エンジニアリングにまたがっているため、前に進め続けるには明確な担当者が必要です。税務チームが元帳、請求、カード発行の各システムにまたがってデータを追跡するのに2週間を費やしたとき、こうした領域横断の仕事こそ、ファイナンスエンジニアが力を発揮する場面だと明らかになりました。

優れたファイナンスエンジニアは、もともとエンジニアではなかった

私の経験では、優れたファイナンスエンジニアの多くは、解決したい課題に何度も直面するうちにソフトウェア開発を身につけた財務の人材です。

そのため私は、職務経歴書よりも、その人が何を作ってきたかを重視します。仕事をしているなら、何を自動化してきたか。学生なら、個人プロジェクトやハッカソンに取り組んでいるか、GitHubは活発か。日常生活でも最新のツールを使い、スマートフォンからコーディングエージェントを動かすほどか、といった点です。

好奇心も同じくらい重要です。私は候補者に、独学で身につけた技術的な概念を説明してもらうことがあります。エージェントを動かす仕組み（ハーネス）がどう機能するかでも、HTTPリクエストがクライアントからサーバーへ届き、また戻ってくる流れでもかまいません。それらが専門外なら、よく知っている分野を選んでもらっても大丈夫です。私が聞き取りたいのは、仕事上の必要からではなく、個人的な興味から生まれた知識の深さです。

最後の資質はオーナーシップです。経営陣や支援先のチームから賛同を得るために努力し、自ら勢いを生み出せる人を求めています。それがなければ、優れた作り手であっても壁にぶつかるでしょう。

財務部門は今、事業成長のエンジンになっている

CFOとしての私の仕事は、もはや事業がどう動いているかを報告するだけではありません。事業を動かす仕組みそのものを設計する手助けをすることです。つまり、財務部門が財務のAIロードマップに責任を持つということです。現状を定義し、取り組みの優先順位を決め、データ基盤に責任を持ちます。

ツールだけでは、そこにたどり着けません。出発点は、チームに適切なスキルがそろっていること、そしてAI導入の基準を定め、全員がうまく作れるよう支援するファイナンスエンジニアがいることです。私の考えでは、それこそが財務部門を事業成長のエンジンに変えるための鍵となる採用です。

当社のファイナンスエンジニアが、チームのAI変革を主導する仕事について語っています。動画はこちら（英語）からご覧いただけます。