CFOのためのAI変革ブループリント：Airwallex財務部門の取り組みから学ぶ4つの判断

はじめに

AirwallexのCFO、Pranav Sood

Airwallexに入社する前、私はプライベート・エクイティ（PE）が出資する企業のCFO20人以上に、財務部門でAIをどこに使っているかを聞いて回りました。見えてきたのは、AI活用が一部にとどまり、想像していたよりも進んでいないという実態です。多くのCFOが挙げた障壁は、少人数のチーム、リスクを避ける姿勢（特に経理部門）、そしてデータの整備不足という3つでした。試行が行われていたのは主にFP&A（財務計画・分析）で、予算と実績の差異分析や経営報告用のスライド作成が中心でした。

私が受けた印象は、多くのチームが今の業務にAIを付け足しているだけで、業務そのものを見直すところから始めたチームはほとんどない、というものでした。財務部門におけるAIの可能性は、誰もが考えているよりはるかに大きい。そう確信して、私はこの役職に就きました。

私の経歴は少し変わっています。私は会計士としての訓練を受けていないCFOで、戦略コンサルティング、事業運営、ゼネラルマネジメント、プライベート・エクイティを経てここに来ました。その経験から、何を変えるかを決める前に「何がその仕事を動かしているのか」を問うこと、そしてデータが完璧にそろう前に仮説を検証することが習慣になっています。この2つは、財務部門の変革を始めるうえで役立つ出発点になりました。

CFOの仕事は、まず基本を確実に押さえることから始まると私は考えています。具体的には、正確な報告、適切な資本配分、そしてリスクの適切な管理です。これらは決して譲れません。変えるべきなのは、それらにかかる時間であり、その時間を取り戻す手段がAIです。AIで生まれた時間は、事業が財務部門に求めているのに、なかなか手が回らなかった仕事に充てられます。たとえば、規制当局やパートナー、顧客との信頼関係を築くことや、社内の同僚が難しいビジネス上の判断を下すのを支えることです。

Airwallexでは、財務部門が自らの変革を主導し、それを製品開発のロードマップのように運営しています。私は、どの財務部門も自らの変革を主導すべきだと考えています。この取り組みを進めるなかで、入社前に話を聞いたCFOたちのことを何度も思い出しました。私たちが今学んでいることの多くは、彼らが第一歩を踏み出す助けになったはずです。

このガイドは、そうしたCFOたちと、同じ出発点に立つすべての財務リーダーに向けたものです。私たちが下した4つの判断を順番に示し、それぞれから何を学んだか、そして他の財務チームにも渡せるツールを紹介します。途中でいくつも失敗をしましたが、それもあえて残しています。おそらく最も役に立つ部分だからです。このガイドから1つだけ持ち帰るなら、個々のツールよりも「進める順番」であってほしいと思います。これから始める方もいれば、部分的には私たちより先を行っている方もいるでしょう。自社のチームに役立つところを取り入れ、それ以外は読み流してください。これは私たち自身の部門を変革している記録であり、私たちがたどった遠回りを、皆さんが少しでも避けられれば幸いです。

このブループリントの使い方

このガイドは、私たちが推奨する順番で4つの判断を追っていきます。これから財務部門でのAI活用を始める場合は、最初から順に読んでください。それぞれの判断は、その前の判断を土台にしているからです。すでにAIの導入を進めている場合は、今まさに直面している判断の章から読んでください。

第1章：データ基盤を整える では、すべてのチームが同じ定義に基づいて仕事をし、AIが信頼できる数字を扱えるように、財務データをどう作り直したかを紹介します。チーム間でデータの意味がそろっていない場合や、AIを載せられるほどデータを信頼できていない場合は、ここから始めてください。

第2章：自動化の前に業務を洗い出す では、財務部門のすべての業務を記録し、時間がどこに使われ、負荷がどこで集中しているかを把握した方法を説明します。チームの時間がどこに使われているか、まだはっきりつかめていない場合は、ここから始めるとよいでしょう。

第3章：部門ごとにロードマップを作る では、経理（コントローラー部門）、トレジャリー（資金管理）、税務、FP&Aの各部門が、洗い出した業務の全体像をそれぞれの優先順位にどう落とし込んだかを紹介します。自動化できる業務の候補は見えているものの、各チームがどれから着手すべきかが決まっていない場合に特に役立ちます。

第4章：誰がツールを作り、どう完成させるかを決める では、ばらばらだったAIの試行錯誤から、部門全体で使えるツールを共通の方法で作る体制へどう移行したかを説明します。チームが作るツールがなかなか完成しない、あるいは共有されない場合は、この章から読んでください。

各章では、まず出発点となった状況を示し、次に何を行い、その過程で何を学んだかを、うまくいかなかったことも含めて紹介します。各章の最後には、得られた教訓と実際に取ったステップをまとめていますので、自社のチームでも同じアプローチを試してみてください。

第1章：データ基盤を整える

AIはすぐに導入できますし、そうしたくなるのも無理はありません。私たちもそこから始めましたが、本当の効果は、まずデータ基盤を整えることから生まれると、すぐに気づきました。

多くのCFOが、財務データはAIに扱わせるには機密性が高すぎるのではないか、と問います。私たちの経験からすると、その前に問うべきことがあります。それは「自社の財務データは、AIが確実に使えるほど整理されているか」です。セキュリティの問題に見えるものが、実はデータの準備不足の問題であることは少なくありません。データが分散していたり、定義がそろっていなかったり、管理が行き届いていなかったりすると、AIがそのデータで出した結果を信頼するのは難しくなります。質の悪いデータの上に対話型のインターフェースを載せても、誤った答えに速くたどり着くだけです。

一般的な進め方は、AIツールを契約し、データにつなぎ、分析を出すというものです。私たちにとってうまくいった順番は、その逆でした。まず事業に必要な示唆（インサイト）を定め、そのために必要なデータを特定し、そのうえで全チームが合意でき、AIも読み取って正しく推論できるデータ辞書（各データ項目の意味を定義した一覧）を設計しました。ツールやAIの利用料に投資する前に、自社の財務チームが次の3つの問いに「はい」と答えられるか確認しておく価値があります。

1. 財務データについて、唯一の信頼できる情報源（シングル・ソース・オブ・トゥルース）があるか。

2. 全員が同じ方法で指標を定義しているか。

3. その定義を機械が理解できるか。

どれか1つでも答えが「いいえ」なら、この章から始めるのがよいでしょう。ここでは、私たちが想定以上に苦労した部分も含めて、3つすべてに「はい」と答えられるようになるまでの道のりを紹介します。

データ基盤の整備に責任を持つ

私たち自身も、これらの問いにいつも答えられたわけではありません。年換算の売上高が2018年の500万米ドル未満から現在の13億米ドル超へと伸びる間、私たちは正確性を優先し、各プロダクトの担当者がそれぞれ独自のデータ構造（スキーマ）を定義していました。数字自体は正しかったものの、互いにかみ合っていませんでした。時期によっては、プロダクト部門と財務部門で、アクティブな顧客数が異なることもありました。

社内データをBigQueryからDatabricksへ移行した際、私たちはその移行を機に基盤をゼロベースで見直しました。つまり、既存の構造をそのまま移すのではなく、手元にあるものをすべて点検し、一から作り直したのです。将来どう使うかを前提に設計し直し、財務部門が再構築の仕様書を書き、エンジニアリング部門が移行を実行しました。

この役割分担こそ、まず真似していただきたい点です。エンジニアリング部門はデータの移し方を知っており、財務部門はそのデータがどんな意思決定を支えなければならないかを知っています。データ移行やERP（基幹業務システム）の切り替えを控えているなら、それが仕様書を書く絶好の機会です。自社の意思決定を土台に築いた基盤は、何年にもわたって機能し続けます。

意思決定から逆算してデータを決める

手元にあるデータから始めたくなるものですが、私たちは、チームが下す意思決定から始めるほうが理にかなっていると気づきました。月次決算で数字の変動を説明するコントローラーには、あるデータの組み合わせが必要で、変動分析（フラックス分析）を行うFP&Aには、また別のデータが必要でした。こうしたニーズを一覧にしたことで、どの分析軸（ディメンション）が必要かがわかりました。そこから分類体系を作り、名称を決め、どのデータをどのテーブルに入れるかを合意しました。

同じ考え方は、より小さな規模でも使えます。2024年に経理チームがERPを導入した際、後工程でどのデータ項目が必要になるかを検討し、勘定科目表に該当するデータ列を追加しました。その1つが、すべての費用、未払計上、コストについて取引先（ベンダー）を記録する列です。当社の予算はベンダー単位で設定されているため、今ではAIがベンダー別・部門別に予算と実績を比較でき、誰かが手作業で分析を作り直す必要はありません。同様に、予算IDが損益計算書（P&L）上のすべてのコストを予算項目に結び付けています。

すべてを1つの信頼できる情報源に結び付ける

多くの財務チームには、他よりも信頼している「数字のバージョン」が1つあるはずです。土台にすべきなのはそれです。私たちは、財務部門が報告の基礎としている、照合済みの元帳にモデルを結び付けました。

トレジャリーチームも資金について同じことを行いました。チームは、どの口座が存在し、どうつながっていて、どのように開設・閉鎖・維持されているかという、銀行口座の全体像を作り直しました。この基盤が今では、流動性管理、トレジャリーのリスクダッシュボード、日々の資金残高の管理を支えています。

財務の全部門で定義を合わせる

税務、トレジャリー、経理、FP&Aは、それぞれ異なる切り口でデータを必要としていたため、同じ指標でもチームによって意味が異なることがありました。たとえば、「市場別売上高」というごく一般的な指標について、ある売上がどの市場に属するかを各チームに尋ねてみました。

• 経理は、請求書を発行したAirwallexの法人が所在する市場に計上しました。

• FP&Aは、顧客の所在する市場に計上しました。

• 税務は、申告がその両方に依存するため、両方を必要としていました。

つまり、正しい答えが3つあり、市場別売上高の数字も3つあったのです。チーム間で共有するすべての指標でこれを繰り返せば、会議がまず「誰の数字が正しいか」の議論から始まってしまう理由も容易に想像できるでしょう。

私たちは、地道な作業でこれを解決しました。各指標を一度だけ定義し、その定義を文書にし、担当者を1人決めたのです。プロジェクト全体で最も大変な部分でしたが、最も真似していただきたい部分でもあります。すべてのチームが定義づくりに参加したからこそ、どのチームもその定義を理解し、実際に使うようになりました。

人だけでなく機械にも伝わる定義を書く

表形式のデータへのアクセスを与えられたAIエージェントは、各列が何を意味するかを命名規則から推測するしかありません。そこで私たちは、AIモデルが読むことを前提に、データ辞書のすべての項目について平易な言葉で説明を書き、その上にContext Hub（AIが判断に必要な背景情報を参照するための仕組み）を構築しました。Context Hubを読んだエージェントは、各項目の意味、どの法人が計上したか、数字がどのように照合されたかを把握できるため、独自の解釈ではなく私たちの定義に基づいて作業できます。

そのうえでAIを導入する

こうした基盤が整えば、活用の場面は自然に広がります。たとえば、先月EMEA（欧州・中東・アフリカ）地域で営業費用がなぜ変動したのかを説明するには、以前は元帳を開き、タグを追いかけ、比較を手作業で作り直す必要がありました。今ではアナリストがHex、Cursor、ClaudeなどのツールでAIエージェントに尋ねるだけで、変動の要因ごとに整理された結果が返ってきます。基になるデータは照合済みで、定義も文書化されているため、その答えを信頼して行動に移せます。

ただし、作業がなくなるわけではありません。過去の期間のデータは現在の基準でタグ付けされていないため、過去にさかのぼる変動分析では、今も担当者がデータを掘り起こす必要があります。また、新しいプロダクトを出し、新しい市場に参入するたびに、まだ定義されていない分析軸が生まれます。違いは、そうした新たな抜けが、すでにしっかりした基盤の上に追加されていくようになったことです。

得られた教訓

1. 財務部門が仕様書を書き、エンジニアリング部門が移行を実行しました。チームが下す意思決定を一覧にし、データが何を保持すべきかをそれらの意思決定から決めました。

2. 1つの指標に、1つの定義と1人の担当者。特にチームごとに指標の定義が異なっていた部分について、AIモデルが容易に理解できるようにデータを定義しました。

3. タグは先回りして追加しました。ERPの導入時にベンダー列を加えたことで、のちにAIが予算と実績を比較できるようになりました。

第2章：自動化の前に業務を洗い出す

何かを自動化する前に、私たちは財務チームが行っているすべての業務を1つのスプレッドシートに書き出しました。これにより、財務部門の全員が、時間がどこに使われているかを同じ視点で把握できるようになりました。

財務部門の多くの人には、AIに任せたい仕事が1つはあるものです。しかし、チームの時間がどこに使われているかという共通の業務マップがないまま、そうした仕事を1つずつ自動化し始めると、どのプロジェクトが部門全体に最も大きな違いをもたらすのかが見えにくくなります。そうなると、優先順位は、自分の要望を最も強く主張した人によって決まりがちです。

私たちは、より公平にプロジェクトの優先順位を決めたいと考えました。そこでまず、財務部門とコーポレート・デベロップメント部門のすべてのチームに、自分たちの業務を1行ずつ記録してもらいました。その結果、年間で数十万時間に及ぶ600件の業務をまとめたデータベースができあがりました。

すべての業務を同じ形式で洗い出す

各チームは、同じ列に沿って自分たちの業務を記述しました。

• カテゴリ：業務の種類。

• プロセス：その業務がチームの業務フローのどこに位置するか。

• 頻度：日次、週次、月次、年次、または不定期か。

• 時間：1回あたりにかかる時間。

• 現在の成熟度：その業務が現時点でどこまで自動化されているか。

• 目標の成熟度：現実的にどこまで自動化できるか。

現在の成熟度と目標の成熟度の差から、各業務にどれだけの作業が残っているか、注力する価値があるかがわかりました。結果を部門別・地域別に分けると、スプレッドシートはヒートマップになり、チーム同士を比較して、同じ種類の業務に他よりはるかに多くの時間を使っているチームを見つけられるようになりました。

初期の失敗の1つは、成熟度の尺度を解釈の余地がある状態のままにしていたことです。そのため、あるチームの「ほぼ自動化済み」が別のチームの「ほぼ自動化済み」と一致せず、結果をきれいに比較できませんでした。自社で試す場合は、各成熟度レベルが何を意味するか、各列にどの程度の詳しさが必要かを最初に合意しておくとよいでしょう。そうすれば、すべてのチームが同じ方法で業務を記述できます。

繰り返し発生する業務から始める

当社の業務の約80%は繰り返し発生するものです。日々の資金ポジションの把握と銀行勘定の照合、仕訳の入力、経費や請求書の承認、毎月または四半期ごとに提出する同じ税務申告などです。こうした業務は決まった手順に沿って進むため、着手するには最もわかりやすい領域でした。日次の業務であれば、一部を自動化するだけでも、それが動く日ごとに効果が積み上がります。定型業務を1時間減らすごとに、その時間を、規制当局からの照会への対応や、通常とは異なる取引について現地で判断を下すことなど、チームの判断力が最も必要とされる不定期の業務に回せます。

年間の作業時間よりも、負荷のピークを優先する

年間の作業時間は1年を通じた業務の総量を測るものですが、負荷のピークは、その業務がいつ集中するかに目を向けます。当社の財務チームにとって最大のピークは月次決算です。この時期は、チーム間の依存関係がある厳格な手順に沿って、全員ができるだけ早く帳簿を締めようと動きます。年間では数時間しかかからない業務でも、その後ろに並ぶ全員の作業を止めてしまうことがあり、ミスが起きやすいのもこうした場面です。FP&Aには、年間予算の策定という別のピークがあります。

自社の業務マップに対して問うと役立つのは、「決算2日目にどの業務が遅れたら、最も多くの人の作業が止まるか」という問いです。年間の作業時間が最も長い業務よりも、そちらから始めるほうがよい場合が少なくありません。私たちが最初に狙ったのは、本来よりも時間がかかっている月次決算の業務です。そこで1時間短縮するごとに、後工程のチームがそれだけ早く作業を始められるからです。

実際に業務を担う人に話を聞く

チーム全体の担当者へのインタビューを約20時間行ったところ、スプレッドシートだけでは見えなかったピークが明らかになりました。各チームに、業務がどこで滞るのか、そして全員が手一杯になるのはいつかを尋ねたことで、表の列からは抜け落ちていたことがわかりました。

こうした対話からは、うれしい発見もありました。税務では、一部の国・地域の申告を支えるデータとプロセスが想定以上に整っていることがわかり、チームはその国・地域では現在のプロセスを維持したうえで、他の国・地域のお手本として活用しました。

業務マップをもとに優先順位を決める（長いリストになることを覚悟する）

業務マップは、私たちが直感的に感じていたことの多くを裏づけました。同時に、それまで欠けていたものも与えてくれました。チーム全体で共有され、直感を検証できる客観的な視点です。作業時間、頻度、負荷のピーク、本来あるべき状態からの距離で業務を順位づけし、その優先順位の根拠を説明できるようになりました。

この洗い出しからは約100件の自動化プロジェクトが生まれ、その多くはチーム内のシチズン開発者（エンジニアではない現場の担当者で、自らツールを作る人）が手がけました。それらをより多く完成させる方法は第4章のテーマです。その前に、各チームが業務マップのうち自分たちの担当部分を独自のロードマップに落とし込みました。それが第3章の内容です。

得られた教訓

1. チームが評価を始める前に、各成熟度レベルを定義しておく必要がありました。当初は解釈の余地を残していたため、結果をきれいに比較できませんでした。

2. 月次決算のボトルネックを生む業務に注目しました。年間で数時間しかかからない業務でも、決算時にはそれを待つすべてのチームを遅らせることがありました。

3. 実際に業務を担う人に話を聞きました。約20時間の対話によって、スプレッドシートでは見えなかった負荷のピークが見つかりました。

第3章：部門ごとにロードマップを作る

財務部門全体で1つのAIロードマップを作るのが、最もすっきりした方法に見えるかもしれません。しかし、私たちの業務マップからは、部門ごとに独自のロードマップが必要だとわかりました。業務が繰り返される形も、ピークの来方も、部門ごとに異なるからです。

業務を洗い出したことで、財務部門全体で時間がどこに使われているかを共通の視点で把握できました。同時に、4つの部門の働き方が大きく異なることも見えてきました。経理では、ほとんどの業務が繰り返し発生し、月次決算に集中します。トレジャリーは、ルールに基づく日次の業務を大量に処理します。一方、FP&Aと戦略財務は、判断を要する複雑で将来に向けた問いに多くの時間を使います。そして税務は、多くの国で同じような法令順守（コンプライアンス）の義務を負っており、地域ごとに対応の仕方が異なります。

以下では、各部門が業務マップのうち自分たちの担当部分をどのようにロードマップに落とし込んだかを紹介します。あわせて、自社のチームが似た働き方をしている場合にどこから始めるとよいかもお伝えします。

経理：繰り返し業務と月次決算のピークから時間を生み出す

経理は財務部門の作業時間の中で最も大きな割合を占め、その業務の86%が繰り返し発生します。グループ・フィナンシャル・コントローラーのRalph Karstenが詳しく調べたところ、業務の半分が日次であることがわかりました。つまり、一部を自動化するだけでも、営業日ごとに効果が積み上がるということです。業務は、調達、買掛金管理、出張・経費精算などの標準的なプロセスを担うシェアードサービスセンター（SSC）と、地域チームに分かれています。地域チームは、規制当局からの照会から各地域のライセンスに関する質問まで、不定期の業務や年次の業務に時間の約40%を使っています。

繰り返し発生する業務の多くは定型的であるため、経理のロードマップはそこから始まり、自動化した1時間ごとに、地域のコントローラーが判断を要する仕事に集中できるようになります。最も時間を奪っていたのは調達業務でした。調達は、もはや事業に合わなくなったプラットフォームで運用されていたのです。今年後半には、経理チームは現在の調達システムをAirwallexに切り替える予定で、これにより、より多くのプロセスを自動化し、業務マップで明らかになった課題を解決できるようになります。

月次決算には、別の種類の負荷がかかります。チーム全員が緊張感を持ち、できるだけ早く帳簿を締めるためにフル稼働する時期です。決算はチーム間の依存関係がある厳格な手順に沿って進むため、1つのボトルネックが、その後ろで待つ全員を止めてしまいます。こうした負荷が、私たちが決算の早期化に投資してきた大きな理由です。以前は10日かかっていましたが、経理チームは現在、ゼロデイ決算の実現に向けて取り組んでいます。

自社のコントローラーが1週間の大半を繰り返し業務に費やしているなら、最も早く自動化の効果が出るのは、おそらく日次の業務です。

トレジャリー：日々の大量業務をルール化し、資金予測は分解して進める

当社のトレジャリーチームは毎日、40以上の通貨と数億ドル規模の資金を管理しており、業務の75%が日次で発生します。アラート対応やリバランス（口座間の資金の再配分）から、為替（FX）、資金保全（セーフガーディング）、受取利息の管理まで多岐にわたります。業務マップからは、そうした業務の17%がきわめて自動化しやすいことがわかり、チームはすでにその部分で順調に成果を上げていました。

リバランスは以前、「残高が10万米ドルを超えたら資金を移す」といった固定のしきい値に頼っていました。現在は、さまざまなシグナルに反応するプログラムされたルールで動いています。資金予測は、外部の構造化されていないデータや人の判断に依存するため、より難しい領域でした。そこでチームは、一度にすべてを自動化しようとするのではなく、予測のプロセスを1つずつ分解して進めています。

自社のトレジャリーチームが今も固定のしきい値に基づいて資金を移動させているなら、最初に見直す価値があるのはリバランスでしょう。

FP&Aと戦略財務：準備作業を省き、判断は人に残す

FP&Aと戦略財務の業務の多くは、あいまいさや多面的な分析、そして多くの判断を伴うため、自動化の難易度が高いと分類されました。特に予算策定は、プロセス全体として自動化するのが困難です。しかし、その中の作業の多くは、提出物の確認、形式の統一、比較資料の作成といったものでした。そこで、まずその部分から着手しました。

当社のアナリストは、AIの支援を受けたコーディングで、FP&Aの業務を一元化するハブを構築しています。このハブでは、AIが毎月約3,000件の会計仕訳を予算項目と照合しています。当社は個々の支出項目のレベルで予算を組んでいるため、損益計算書全体から任意の支出項目まで、手作業なしで掘り下げられます。また、ハブには毎月の実績が確定し次第取り込まれるため、予算策定のプロセスでは最新の結果に照らして各部門からの要求を評価できます。

予算管理ツールは、各部門から提出された予算案を受け取った時点で検証・集約し、これまでアナリストが手作業でそろえていた形式の違いにも対応します。これにより、提案された支出の全体像を早い段階で把握でき、各チームと選択肢を検討する時間が増えます。その時間は、数字がなぜ変動したのかを調べることにも充てられます。私たちはアナリストに対し、意思決定を軸に問いを立て、自分自身の結論を覆し得る根拠も探すことを求めています。

自社の計画策定チームの業務が自動化するには複雑すぎると感じるなら、その周辺にある準備作業から始めるのが、たいていはより現実的です。

税務：地域をまたいで標準化し、ツールは一度だけ作る

当社の税務チームは26カ国にわたる税務コンプライアンスを管理しており、コンプライアンス業務の最大75%を自動化できます。業務マップからは、地域間の共通点がいかに多いかが見えてきました。どの地域も似たような申告を準備していましたが、数字は各地域のコントローラーから、それぞれ独自の情報源とプロセスで集めていました。そのため、地域ごとにツールを作っていたら、同じツールを何度も作ることになっていたでしょう。

そこで、まず各地域が1つのプロセスと1つのデータセットに合意し、チームはすべての地域が使えるツールを1つだけ作りました。現在、付加価値税（VAT）と物品サービス税（GST）の申告はほぼエンドツーエンドで動いています。買掛金と売掛金からデータを取り込み、納税額を計算し、申告書の下書きを作るまでを一連の仕組み（パイプライン）が担います。外部の税務代理人は、申告書を作成するのではなく、その下書きをレビューする役割に変わりました。申告プロセスの内製化をさらに進めることで、年間約100万米ドルの削減を見込んでいます。次は移転価格文書、続いて直接税とFATCA（米国の外国口座税務コンプライアンス法）に基づく報告に取り組む予定です。

得られた教訓

1. 日次の業務が、最もわかりやすい出発点でした。チームの業務の半分が日次であれば、一部を自動化するだけでも、営業日ごとに元が取れます。

2. 判断が必要な業務では、その周辺の準備作業を自動化しました。FP&Aは予算案の確認と集約から始め、トレジャリーは資金予測を1つずつ分解して進めました。

3. 何かを作る前に、地域をまたいでプロセスを標準化しました。税務はまず1つのプロセスと1つのデータセットに合意し、そのうえで、どの地域でも使えるツールを1つ作りました。

第4章：誰がツールを作り、どう完成させるかを決める

財務チームに初めてAIツールを渡したとき、業務に最も近い人たちがすぐにツールを作り始め、最良のアイデアの多くは彼らから生まれました。その過程で学んだのは、そうした作り手にも、範囲の決め方、テスト、リリースについての共通の基準が必要だということです。それがあって初めて、ツールを完成まで導き、部門全体で共有できるようになります。

財務部門の全員がツールの作り手になる必要はないと私たちは考えています。ただ、全員が仕事でAIを使うようになってほしいと思っています。AIを使ったツールづくりの最初の1年、私たちはシチズン開発、つまりエンジニアリングの経験がない会計担当者やアナリストが自分の業務の課題に気づき、それを解決するツールを自ら作るという方法で進めました。この方法は、上からでは決して見つけられなかった機会を掘り起こしましたが、一方で144個ものツールが生まれ、その大半は完成前に止まってしまいました。シチズン開発は機会を見つけるのは得意でしたが、それを部門全体が頼れるツールに仕上げるには、さらに支援が必要でした。

業務に最も近い人にツールを作ってもらう

私たちの経験では、実際に業務を担う人のほうが、どのエンジニアよりもその課題をよく理解しています。そして今では、AIのおかげで、自分でコードを書かなくてもツールを作れます。当社のシニア会計担当者の1人はAIを使ったツールづくりを独学で身につけ、給与データの集約にかかる時間を2日から10分に短縮しました。これは、15個のファイルをまとめて匿名化する必要があったプロセスです。

別のメンバーは、Oracleにこの機能が追加されるのを待つのではなく、Macのユーザーが仕訳を直接入力できるようにするAirQuireというツールを作りました。このツールは、入力と同時に取引データを補完し、明細の説明や必須項目が正しく入力されているかもチェックします。

税務チームも同じ考え方で、エンジニアではなく12年以上の経験を持つ税務の専門家を採用し、自動化とAIだけに専念してもらっています。彼は、これまでにプロセスの自動化を経験してきた税務責任者とシニアマネージャーの指導を受けています。

シチズン開発が止まりやすいところに注意する

シチズン開発をそのままにしておくと、活動は活発になる一方で、成果のまとまりは弱くなり、プロジェクトは完成度70%のあたりで止まりがちでした。ノウハウはそれぞれのツールを作った人の手元にとどまり、共通のロードマップがなかったため、他のチームがすでに完成させたツールを別のチームが作り直すこともありました。グループ・フィナンシャル・コントローラーのRalph Karstenは、3つの地域が互いを知らないまま、同じ問題の解決に何週間も費やしかねないことに気づきました。また、ツールの大半はダッシュボードやアプリケーションで、誰かがデータを入力し、出力を次のシステムに運ぶ必要が残っていました。

これに対するRalphの答えが、AIイノベーション・プログラムでした。すべての地域をつなぐ中央の運営委員会を置き、どのプロジェクトも製品要求仕様書（PRD）を書くところから始めるというルールを設けたのです。このプログラムが成果を上げたことから、私たちはそれを財務部門全体に広げました。

基準を決める人を採用する

PranavがCFOとして最初に下した判断の1つが、自身の直属で、財務部門全体のAI変革に責任を持つファイナンスエンジニアの役職を新設することでした。財務チームではまだ珍しい採用ですが、彼はいずれ一般的になると考えています。個人の工夫を、4つの地域の40人が頼れるプロセスに変えることは、プロダクトづくりのスキルであり、財務チームがこれまで身につける必要がほとんどなかったものです。

当社のファイナンスエンジニアであるAndrey Lebedevは、ツールの範囲をどう決め、どうテストし、いつ本番運用に出せると判断するかの基準を定めています。チームにツールを作る余力がある場合は指導役を務め、余力がない場合は一緒にツールを作ります。

すべてのツールづくりに同じ4つのステップを適用する

私たちは、多くのツールを中途半端に作るより、数を絞ってでも完成させ、そのすべてが使われる状態を目指しています。そのため現在、すべてのツールづくりは同じプロセスに沿って進めています。

1. 範囲をきちんと決めます。後で最も多くの時間を節約できるのがこのステップだからです。

2. 最小限の機能を備えた初期版（MVP）を3〜4週間で作り、週2回の進捗確認を行います。期限に間に合わなくなりそうなら、範囲を削って期日は守ります。

3. 他の地域のメンバー3〜4人に2〜3週間テストしてもらいます。彼らには、きちんとしたフィードバックを期待していることを事前に伝えておきます。

4. リリースしたら仕様を固定し、チーム全体で使うシートにリンクを1つだけ掲載して、すべての地域で利用を促します。

完成したツールとスキル（Skill）は、財務部門の誰もが使い、学べる共通の保管場所（リポジトリ）にまとめます。

そもそもソフトウェアが必要かを確認する

ツールが必要な課題もあれば、スキル（Skill）だけで足りる課題もあります。ここでいうスキルとは、チームのやり方どおりに作業する方法をAIモデルに伝える、文書化された指示のまとまりです。当社の人員数の照合は、双方向でデータを同期する計画ツールにすることもできました。しかしチームはまず、メンバーが今使っているスライドを離れて新しいツールに移ることがあるだろうか、と問いました。そうはならないことが明らかになったため、チームはスキルを作りました。このスキルは夜間にスプレッドシートを開き、行数を数え、スライド上のボックスの数を数え、すべての差異に印を付けて翌朝に知らせます。

変革をすべてのリーダーの仕事にする

当社の経営陣は、それぞれの部署の変革に責任を持ち、各リーダーにはAIがもたらす効率化に結び付いたOKR（目標と主要な成果）が設定されています。こうした効率化が実現するのは、ツールが部門全体で使われ、利用者がスプレッドシートとの併用をやめられるほどそのツールを信頼したときだけです。

得られた教訓

1. 範囲は削っても、期日は守ると決めました。3〜4週間でリリースしたMVPには、完成度70%で止まった多機能なツールよりも大きな価値があります。

2. 専門知識を基準に採用し、ツールづくりは後から教えました。税務チームは、コンプライアンス業務の自動化のために、エンジニアではなく12年以上の経験を持つ税務の専門家を採用しました。

3. 部門全体で使われて初めて、ツールが完成したとみなしました。仕様を固定し、リンクを1つにして共有し、すべての地域で利用を促すことで、1つの地域で作られた改善が、全員が頼れるツールになります。

どこから始めるか

このガイドで紹介した変化はすべて、小さく地味な一歩から始まりました。定義を合わせるワークショップ、業務を書き出したスプレッドシート、チームリーダーへのインタビュー、メンバーがすでに作っていたツールの一覧です。皆さんの最初の一歩は、4つの判断のうち、チームがまだ下していない最初の判断です。このガイド冒頭の「このブループリントの使い方」に戻り、今のチームに当てはまるものを見つけて、今週、経営陣の時間を1時間それに充ててください。

• データが最初なら、経理、FP&A、税務、トレジャリーの責任者を1つの部屋に集め、全員が報告している指標を1つ、それぞれに定義してもらいましょう。答えが1つにそろわなければ、そこが出発点です。

• 業務の洗い出しが最初なら、各チームに、毎週繰り返している業務とそれぞれにかかる時間を書き出してもらいましょう。

• ロードマップが最初なら、各部門の責任者に、1年のうちいつ業務がピークを迎えるか、そしてどの業務がいつ全員の作業を止めているかを尋ねましょう。

• ツールづくりが最初なら、チームがこれまでに作ったすべてのツールについて、誰が担当し、他に誰が使っているかを一覧にしましょう。

これらは一度終えれば済むものではありません。私たちは新しいプロダクトを出し、新しい市場に参入し続けており、そのたびに洗い出すべき新しい業務と、定義すべき新しいデータが生まれるからです。私たち自身も今なおロードマップに取り組んでいる最中で、事業の成長に合わせて、4つの判断をもう一度繰り返すことになると考えています。

最先端が動き続けていることこそ、今始めるべき最大の理由であり、その先頭に立つのに最もふさわしいのは財務部門です。財務部門はすでに、数字がどこから来て、時間がどこに使われ、事業がどの意思決定に依存しているかを知っています。データ基盤、業務マップ、そして基準づくりに費やす1カ月1カ月が、チームがこの先何年にもわたって積み上げていく土台になります。今のチームに合った判断を選び、1時間を確保して、始めてください。