ZAC・弥生から freee へ移行。会計システムで最初に決めるのは承認・権限・記録

「IPO（株式の上場）を目指しているが、経理・総務などの管理部門に専任がいない。会計システムをどう選べばいいか」——この手の相談が増えている。

以前、自分が担当したプロジェクトで、会計まわりの仕組みを全面的に入れ替えた。それまでは ZAC（案件ごとの予算と実績の管理に強い、会社の中心の業務を1つにまとめたシステム）で仕事を回し、数字は会計ソフトの弥生会計にまとめて流し込んでいた。これを、クラウドの会計ソフト freee の複数の製品（会計・販売など）に移した。検討から移行完了まで人も時間も相当かかったし、やってみて初めて分かったことも多かった。

入れ替えの話になったのは、困りごとが3つ積み重なったからだ。申請と承認の流れが形だけになっていた。事業が大きくなり、事業ごとの予算と実績を追いきれなくなった。帳簿の数字を、元の取引までたどれなかった。この記事では、その経験をもとに「会計システムを選ぶとき、何を考えるべきか」を整理する。

前半は、IT や会計の仕組みに詳しくなくても読めるように書いた。当時の用語での言い方や、稟議の経路の整理の例、案件の番号の桁の決め方といった細部は、後半の「担当者向け」にまとめた。

▼入れ替えた理由：困りごとが3つ積み重なった

当時、表に出ていた困りごとは大きく3つだった。

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

▼選ぶ前にやったこと：困りごと15〜20個を、お金の流れの図と3段の整理で「条件」にした

製品を比べる前に、事業部の仕事の流れを図（フローチャート）に書き出した。お金の流れが見えないと、どの場面で帳簿への記録（仕訳）が発生するか、それぞれの仕事で会計上どんな処理が起きるかが分からないからだ。

受注 → 納品 → 請求 → 入金、あるいは発注 → 検収（届いたものを確かめる）→ 支払。こうした流れを1つずつ書き出すと、システムに何をやらせる必要があるかが具体的に見えてくる。これをやらずに製品を比べ始めると、後から「この仕事はどのシステムで処理するんだっけ？」という話になりがちだ。

あわせて、表に出ている困りごとを1つずつ、次の3段で整理した。

これを困りごとごとに繰り返すと、「必ず要る条件」と「できればあればいい条件」の優先順位が自然と見えてくる。条件が領域ごとに分かれるので、どのシステムを比べればいいかの整理にもなる。

当時は大小15〜20個の問題点を洗い出し、最終的に短くまとめて上に提案した。

▼何で選んだか：10〜20サービスを比べ、最後は「この先どう育つか」

選定では10〜20ほどのサービスを見た。必要な条件を満たすかは、すべての候補で確かめた。freee は必要な条件を多く満たしていた。ただ、最後の決め手は機能の多さだけではなく、開発の考え方（この先、製品をどの方向に育てるか）だった。

当時の freee の開発の考え方は「統合させていく」ことだった。会計と人事労務を統合する、会計と契約管理を統合する——最終的にすべての業務が会計に行き着く形で、製品同士がつながっていくという方向だ。

それまでの ZAC は、会社の中心の業務を1つにまとめたシステムだった。freee のこの考え方は、とても魅力的だった。中長期で「より使いやすくなっていくだろう」という見通しが持てたことが、決め手の一つになった。

▼7割は仕組み、3割は運用：乗せきれない部分の補い方を先に決める

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

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

たとえば、こういうことがあった。案件を「大きな案件」と「その中の小さな案件」の2段で分けて、案件ごとの原価を管理したかった。しかし当時の freee 販売（freee の販売管理の製品）では、案件を2段にできなかった（その後、案件に独自の項目を足せる機能が出ている。後半に書いた）。そこで、案件につける番号の桁に「どの取引先の、どの大きな案件の、どの小さな案件か」という意味を持たせた。番号ごと書き出して、表計算ソフトで番号を分解すれば、2段で集計できる。細かい桁の決め方は後半に書いた。

「痒いところに手が届かない」場面は必ず出てくる。大事なのは、「どうシステムに乗せるか」から「乗せきれない部分をどう運用で補うか」へ、考え方を切り替えることだ。

▼上場を目指すなら最初に決めること：承認・権限・記録の3つと、帳簿の分け方

管理部門に専任がいないスタートアップほど、最初の設計を後回しにしがちだ。しかし後からシステムの入れ替えや作り直しが起きると、移行の手間と費用は、最初に入れるときよりずっと大きくなる。自分のときも、検討から移行完了まで人も時間も相当かかった。上場を見据えているなら、承認・権限・記録の3つは最初から仕組みとして作り、帳簿の分け方はデータを入れ始める前に決めておくべきだ。

承認：誰が、どの申請を承認するか

兼務や組織変更が起きる前提で、承認ルートを柔軟に組めるようにしておく。

権限：誰が、どのデータを見られる・触れるか

「とりあえず全員が管理者」は、後で必ず問題になる。

記録：申請・承認・変更の履歴がシステムに残るか

監査では「誰が、何を、いつ承認したか」を追えることが前提になる。

もう1つ：帳簿の分類（勘定科目）と取引先の分け方

後から組み替えると、過去のデータと話が合わなくなる。勘定科目の体系は、データを入れ始める前に、会計士・CFO（財務の責任者）と合意しておく。

▼判断の分かれ目：やりすぎと足りなさは「今の規模で本当に要るか」で見分ける

「上場の準備中」と聞くと、「完璧な内部統制を最初から作らないといけない」と思いがちだが、それも間違いだ。設立して間もない頃から上場企業並みの仕組みを作ろうとすると、運用の手間で現場が回らなくなる。

見分け方はシンプルで、「今の事業の規模・段階で本当に必要か」を軸にする。

自分の経験則では、「承認・権限・記録の3つは、最初から仕組みとして作る。帳簿の分け方は、データを入れ始める前に決める。それ以外は、事業の段階に合わせて少しずつ整える」が現実的なバランスだ。

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

たとえば承認なら、今は「部長の承認だけ」でシンプルに回しつつ、将来「チームリーダー → 部長 → 本部長」と段を増やしたくなったとき、システムの設定でそう変えられるか。この「作り変えられる余白の広さ」は、選ぶときに必ず確かめておくべき点だ。

今の運用に合わせてシンプルに作ること自体は正しい。ただ、将来の統制の強化に対応できない作りに閉じてしまうと、事業の段階が上がったときに作り直しや入れ替えを迫られる。選ぶシステムが「どこまで作り変えられるか」を、デモの段階で確かめておくといい。

▼まとめ：自分の会社で確かめること

会計システムを選ぶ前、または今の仕組みを見直すときに、担当者（または委託先・会計士）と次を確かめておくといい。

• ▶ お金の流れを図にしてから、条件を整理しているか：受注から入金まで、発注から支払まで。帳簿への記録が発生する場面が分かってから、システムに求める条件を決める
• ▶ 候補の製品を、デモで確かめたか：調べるだけでは分からない制約が必ず出てくる
• ▶ 何をシステムに任せ、何を運用で補うかを先に決めたか：7割は仕組み、3割は運用が現実
• ▶ 機能だけでなく、開発の考え方を聞いたか：中長期の方向が自社と合っているか
• ▶ 承認・権限・記録の3つは、最初から仕組みとして作ってあるか：「全員が管理者」になっていないか。誰がいつ何を承認したかが残るか。帳簿の分け方は、データを入れ始める前に会計士と決めたか
• ▶ 今の規模に合った作りになっているか。同時に、将来作り変えられるか：承認の段を増やすといった変更が、システムの設定でできるか

管理部門に専任がいない初期の段階だからこそ、外の知見を借りて最初の設計を正しく作っておくことが、後々の手間を減らし、上場準備をスムーズにする。

▼担当者向け：設定と手順の詳細

ここからは、実際に要件を整理し、システムを設計する人向け。前半の言い方と、実際の名前の対応から。

前半の言い方と、実際の名前

稟議の経路を3段で整理した例

前半の3段の表を、実際に要件にしたときの粒度で書くとこうなる。

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

案件コードの桁設計（freee 販売で2階層の代わりにした）

やりたかったこと：freee 販売で「案件（大カテゴリ）＋案件（小カテゴリ）」の2階層を持たせ、案件別原価を管理する。当時の freee 販売では、機能的に対応できなかった。

代わりにしたこと：案件コードに属性情報を持たせた。

集計するときは、freee 販売から CSV で書き出し、スプレッドシートで案件コードを桁ごとにスプリットし、各桁がどの取引先・カテゴリに当たるかを Lookup する。これで2階層の案件別原価を追える。