IPO前提で失敗しない会計システム選定｜ZAC・弥生からfreee移行の実体験

「IPOを目指しているが、バックオフィス専任がいない。会計システムをどう選べばいいか」——この手の相談が増えている。

以前、自分が担当したプロジェクトで、ZACおよび弥生会計からfreeeの複数プロダクト（会計・販売管理・人事労務・業務委託管理・サイン）へ全面移管するという経験をした。検討から移行完了まで相当なリソースを投入したし、やってみて初めてわかったことも多かった。

この記事では、その実体験をベースに「スタートアップが会計システムを選ぶときに何を考えるべきか」を整理する。

▼なぜリプレースが必要になったか

まず前提として、なぜZAC・弥生会計から移行する話になったかを共有する。当時顕在化していた問題は大きく3つだった。

これらの問題が積み重なってシステムリプレースの話になった。逆に言うと、最初からシステムを正しく設計していれば避けられた問題でもあった。スタートアップが初期設計を丁寧にやるべき理由がここにある。

▼要件定義の進め方：フローチャートから始める

システム選定に入る前に、まずやったのが事業部のオペレーションをフローチャートで書き出すことだった。なぜかというと、お金の流れが見えないと「どういう仕訳が発生するか」「各オペレーションで会計上どういう処理が起きるか」が把握できないからだ。

受注→納品→請求→入金、あるいは発注→検収→支払といったフローを一つひとつ書き出すことで、システムに何をやらせる必要があるかが具体的に見えてくる。これをやらずにツールを比較し始めると、後から「このオペレーションはどのシステムで処理するんだっけ？」という話になりがちだ。

フローが可視化できたら、顕在化している問題を起点に以下の3段構造で要件を整理していく。

これを問題点ごとに繰り返すと、自然と「MUSTな要件」と「できればいい要件」の優先順位が見えてくる。また要件が領域ごとにカテゴリ分けされるため、どのシステムを比較すべきかの整理にもなる。

当時は15〜20個の大小さまざまな問題点を洗い出し、最終的にコンパクトにまとめて上申した。

▼freeeを選んだ理由：開発思想で選ぶという視点

システム選定では10〜20ほどのサービスを見た。もちろん機能面での要件確認はすべてのサービスに対してやっていて、freeeは必要な要件を多く満たしていた。ただ、最終的な決め手になったのは機能の充実度だけではなく、開発思想だった。

freeeの開発コンセプトは「統合させていく」ことにある。会計と人事労務を統合する、会計と契約管理を統合する——最終的にすべての業務が会計に行き着く形でシステムが統合されていくという方向性だ。

ZACは「あらゆるモジュールを統合した1つの基幹システム」だったため、このfreeeの思想は非常に魅力的だった。中長期的に「より使いやすくなっていくだろう」というイメージが持てたことが、導入の決め手の一つになった。

▼「7割システム・3割運用」という現実と向き合う

基幹システムの検討をするとき、「すべての業務プロセスをシステムに置き換えられるものを探そう」と考えがちだ。これは間違いではないが、実際にはそんなシステムは存在しない。

freeeを導入したときも「7割くらいは要件に合っていて期待通りの運用ができそう、でも3割はルールを固めて運用でカバーしないといけないな」というのが正直な印象だった。

具体的にはこういうケースが発生した。

「痒いところに手が届かない」ケースは必ず出てくる。大事なのは「どうシステムに乗せるか」ではなく「乗せきれない部分をどう運用でカバーするか」という発想の転換だ。

▼IPO前提で最初に設計しておくべきポイント

バックオフィス専任がいないスタートアップほど、初期設計を後回しにしがちだ。しかし後からリプレースや再設計が発生すると、移行コストは初期導入の何倍にもなる。IPOを見据えているなら、以下の4点は最初から設計しておくべきだ。

• ▶ 承認フローの設計：誰がどの申請を承認するか。兼務・組織変更を想定した柔軟な経路設計をしておく
• ▶ 権限管理の設計：誰がどのデータにアクセスできるか。「とりあえず全員管理者」は後で必ず問題になる
• ▶ 証跡管理の設計：申請・承認・変更履歴がシステム上に残る状態にする。監査対応で「誰が何をいつ承認したか」が追えることが前提になる
• ▶ 科目・取引先の設計：後から組み替えると過去データとの整合性が崩れる。勘定科目体系は最初から会計士・CFOと合意しておく

▼過剰設計・過小設計の判断基準

IPO準備中と聞くと「完璧な内部統制を最初から作らないといけない」と思いがちだが、それも間違いだ。設立初期から上場企業レベルの内部統制を設計しようとすると、運用コストで現場が回らなくなる。

判断基準はシンプルで、「今の事業規模・フェーズで本当に必要か」を軸にする。

個人的な経験則でいうと、「承認フロー・権限管理・証跡管理の3点だけは最初からやる、それ以外は事業フェーズに合わせて段階的に整備する」が現実的なバランスだと思っている。

ただし、「今はシンプルでいい」という話と「将来の拡張余白を確保する」という話は矛盾しない。むしろ両立させることが大事だ。

たとえば承認フローで言うと、今は「部長承認のみ」でシンプルに運用しつつ、将来「チームリーダー→部長→本部長」という多段階フローに変更したくなったとき、システム側でそれが設定できる構造になっているかどうか。この「設計可能な余白の広さ」は、ツール選定時に必ず確認しておくべきポイントだ。

今の運用に合わせてシンプルに作ること自体は正しい。ただ、将来の統制強化に対応できない設計に閉じてしまうと、事業フェーズが上がったタイミングで再設計・リプレースを余儀なくされる。選ぶシステムが「どこまで作り変えられるか」を、デモの段階で確認しておくといい。

▼まとめ：スタートアップが会計システムを選ぶときに大事なこと

実体験をもとに整理すると、会計システム選定で大事なことは以下に尽きる。

• ▶ まずオペレーションのフローチャートを書いてお金の流れを可視化する（仕訳・会計処理の発生ポイントを把握してからツール要件を整理する）
• ▶ ツール選定はDEMOで機能確認する（表面的な調査では判断できない制約が必ず出てくる）
• ▶ 何をシステムに任せて何を運用でカバーするかを先に決める（7割システム・3割運用カバーが現実）
• ▶ 機能だけでなく開発思想で選ぶ（中長期の方向性が合っているか）
• ▶ 承認フロー・権限管理・証跡管理の3点は最初から設計する
• ▶ 過剰設計より「今の規模に合った設計」を優先する

バックオフィス専任がいない初期フェーズだからこそ、外部の知見を借りて最初の設計を正しく作っておくことが、後々の工数削減とIPO準備のスムーズさに直結する。