Lark で士業事務所(税理士・社労士・行政書士) の業務基盤を作る — 5〜20 名規模の実装パターン

士業事務所が業務基盤を見直すべき 3 つの構造的圧力

結論：2025 年〜2026 年にかけて、士業事務所は「専門業務の特化 SaaS だけ強化する」段階から、「事務所運営そのものを 1 つの業務基盤に統合する」段階に移行しなければならない。理由は、専門業務の効率化だけでは吸収できない 3 つの圧力が同時に来ているからです。

士業事務所の所長と話していると、「特化 SaaS は入れている。でも事務所全体としての生産性は思ったほど上がらない」という相談が増えています。実は、ここ数年で士業を取り囲む環境は連続的に変化しており、特化 SaaS の効率化効果を、別のところで発生したコスト増が吸収してしまう構造になっています。圧力の正体は以下の 3 つです。

圧力 1: 電子申告・インボイス・電帳法という 3 連発の制度対応

国税庁の発表によると、法人税申告書の e-Tax 利用率はすでに 9 割を超える水準で推移しており、所得税申告書も 7 割前後に達しています（国税庁「e-Tax の利用状況」公表ページ 参照）。ほぼすべての法人顧問業務が電子申告を前提とせざるを得ない状況です。これに加え、2023 年 10 月のインボイス制度開始以降、令和 8 年度税制改正（2026 年 3 月 31 日成立）により、免税事業者からの仕入税額控除の経過措置が見直されました。改正後のスケジュールは「2026 年 10 月 1 日〜2028 年 9 月 30 日：70% 控除／2028 年 10 月〜2030 年 9 月：50% 控除／2030 年 10 月〜2031 年 9 月：30% 控除／2031 年 10 月〜：完全廃止」と段階化され、当初の予定（2026 年 10 月から 50%）よりも 2 年延長されました（国税庁「令和 8 年度税制改正特集」参照、2026 年 6 月確認）。さらに電子帳簿保存法の改正で、電子取引データの保存ルールも顧問先ごとに個別運用が必要です。

これらの制度変更は「特化 SaaS の対応バージョンを入れれば終わり」ではありません。顧問先ごとに「どの帳簿をどの形式で保存しているか」「インボイス登録番号は登録済みか」「電子取引データはどこに格納されているか」を、事務所として横串で管理する必要が出ています。これは特化 SaaS ではなく、顧問先マスタ・案件 DB・書類保管場所の一元管理という、業務基盤レイヤの仕事です。

圧力 2: 慢性的な人手不足と「経験者採用が取れない」

厚生労働省「労働経済の分析（労働経済白書 2024）」では、専門・技術職の有効求人倍率は 2.0 倍前後で高止まりが続いており、士業事務所が経験者を採用しようとすると獲得競争が激化しています（労働経済白書 2024 厚生労働省 参照）。一方、IPA「DX 動向 2024」によれば中小企業の DX 取り組み比率は 約 4 割（着手段階を含む）に留まり、人手不足を IT 投資で吸収できている事務所は限られます（IPA「DX 動向 2024」参照）。

この状況で士業事務所が選べる現実的な打ち手は、「採用を増やす」ではなく「未経験者・若手・パート時短スタッフでも、有資格者と同じ情報基盤の上で動ける構造を作る」しかありません。これは、属人化していたエクセル管理表・紙ファイル・所長のメモを、誰もがアクセスできる業務 DB と業務マニュアルに置き換える話です。特化 SaaS だけでは、ここは埋まりません。

圧力 3: 顧問先の DX 要請と「先生も DX してください」問題

顧問先である中小企業は、freee／マネーフォワード／kintone／Slack／Microsoft 365 を導入し、確実に DX を進めています。すると顧問先から「先生のところは紙でやり取りしてるの？」「申告書ステータスを Slack で教えてほしい」「LINE じゃなくチャットツールで履歴を残したい」といった要請が来るようになります。士業事務所の DX が遅れていることが、顧問契約の継続リスクとして顕在化しはじめています。

特に、世代交代で経営者が交代した顧問先からは、「先代から続いている顧問だが、デジタル対応の遅れを理由に変更を検討したい」というケースが、ここ 2 年で目に見えて増えています。事務所側の業務基盤を整えることは、顧客リテンションの根幹に直結するのです。

3 つの圧力に共通する答え：「事務所の OS」を持つこと

圧力 1 は横串の顧問先・書類管理を、圧力 2 は属人化解消・マニュアル化を、圧力 3 は顧問先との連携基盤を求めています。3 つに共通する答えは、特化 SaaS の上か下に「事務所の業務 OS」を 1 枚乗せ、その上で特化 SaaS をデータソースとして組み合わせる構造です。本記事では、その「業務 OS」の最有力候補として Lark を提案します。なぜなら、Lark は業務 DB（Base）／文書 (Docs・Wiki)／チャット (IM)／承認ワークフロー／メール／カレンダー／ビデオ会議を 1 アカウントで提供し、士業事務所のような「複数機能を有機的に組む」用途に最適化されているからです。

士業特化 SaaS の現在地 — 強い領域とカバーしない領域

結論：士業特化 SaaS（KiteRa／オフィスステーション Pro／A-SaaS／達人シリーズ等）は「専門業務そのもの」では他に代え難い強さがある。一方、「顧問先マスタ・案件進捗・社内コミュニケーション・書類テンプレート管理」という事務所運営の横軸は構造的にカバーしない。Lark は後者の役割を引き受けるツール。

士業事務所の所長と話すと、「特化 SaaS を否定したいわけではない」というのが共通認識です。むしろ、専門業務での精度・法令対応速度・印刷帳票の質を考えれば、特化 SaaS の継続利用は必須です。問題は、これらの特化 SaaS は「業務 1 種類ごとに 1 サービス」という構造になっており、事務所全体を貫く運営レイヤをカバーしないことにあります。

税理士事務所の特化 SaaS マップ

税理士事務所が日常的に利用する主な特化 SaaS は、以下のような構造で整理できます（料金は各社公式ページの 2026 年 6 月時点）。

領域	代表サービス	強い領域
会計・税務クラウド	freee 会計（税理士向け）／マネーフォワード クラウド会計／弥生会計／A-SaaS（株式会社 A-SaaS）	仕訳・試算表・申告書作成・電子申告
税務申告ソフト	達人シリーズ（NTT データ）／JDL／TKC	法人税・所得税・相続税申告書の電子申告
給与計算	freee 人事労務／マネーフォワード クラウド給与／弥生給与	給与計算・年末調整・住民税
電子契約	クラウドサイン／GMO サイン	顧問契約書の電子締結

これらは「申告書を作る」「給与計算をする」という動詞ベースの業務には極めて強いです。しかし、「どの顧問先の月次決算が今どこまで進んでいるか」「領収書の回収状況はどうなっているか」「誰がレビュー待ちで止まっているか」は、特化 SaaS の中では断片的にしか見えません。

社労士事務所の特化 SaaS マップ

社労士事務所は、規程業務と手続き業務が並走する構造を持ちます。両領域でリーダー的なポジションを取るのが、KiteRa とオフィスステーション Pro です。

領域	代表サービス	強み
規程作成・改定	KiteRa Pro（株式会社 KiteRa）	就業規則・関連規程の作成・改定・履歴管理。社労士事務所での導入実績多数（KiteRa Pro 公式 参照）
手続き電子申請	オフィスステーション Pro（株式会社エフアンドエム）	入退社手続き・年度更新・算定基礎届の電子申請（オフィスステーション Pro 公式 参照）
給与計算	マネーフォワード クラウド給与／給与奉行クラウド	給与計算・賞与・年末調整
勤怠管理	KING OF TIME／ジョブカン勤怠	顧問先の勤怠データ集計

こちらも、「顧問先 A の助成金申請がどの段階か」「規程改定の承認が誰で止まっているか」「過去の顧問先別の相談履歴がどこに残っているか」は、特化 SaaS 単体では追いきれません。

行政書士事務所の特化 SaaS マップ

行政書士は許認可・契約書・遺言相続・ビザなど業務範囲が広い反面、業務領域ごとに「業務特化型のクラウド」が分散している実態があります。建設業許可申請の管理クラウド、ビザ申請進捗管理クラウド、補助金申請支援サービスが個別に存在し、事務所内で複数を使い分けるケースが一般的です。事務所として「全案件の進捗を 1 画面で見る」基盤は、特化 SaaS では構築されていないのが現状です。

「特化 SaaS が埋めない 3 つの穴」を整理する

3 つの士業類型に共通する、特化 SaaS が構造的に埋めない穴は次の 3 つです。

• 顧問先マスタの横串: 各特化 SaaS は顧問先 ID を独自に持つが、事務所として「この顧問先には誰と誰が関わり、どのサービスを契約しているか」という統合ビューがない
• 案件進捗の見える化: 「月次決算」「申告書」「給与計算」「助成金申請」「許認可申請」の進捗ステータスを、所長・スタッフ全員が 1 画面で確認できる場がない
• 事務所内ナレッジ蓄積: 顧問先別の対応履歴・特殊事情・所長判断のロジックが、口頭・メモ・属人化したエクセルに散在し、引き継ぎ不能

この 3 つの穴を埋める「業務 OS」として、Lark は最適な構造を持っています。次章で具体的に解説します。

Lark を士業の業務基盤にする 4 つの柱

結論：Lark は「Base（業務 DB）・Wiki（ナレッジ）・承認（ワークフロー）・IM／メール（連携）」の 4 機能を 1 アカウントで提供する統合スイートです。士業事務所はこの 4 つを、上記の「特化 SaaS が埋めない 3 つの穴」に対して、それぞれ役割分担して配置します。

Lark は ByteDance Ltd. が運営するワークプレイスプラットフォームで、Lark Suite 公式の料金ページ（larksuite.com）によると、無料の Starter（20 名上限）、Pro（年払い 1 ユーザー月額 1,420 円、税抜）、Enterprise（年払い 1 ユーザー月額 1,820 円、税抜）の 3 プラン構成です（2026 年 6 月時点）。士業事務所 5〜20 名規模では、原則 Pro プランを選択することになります。

柱 1: Lark Base（業務 DB）— 顧問先マスタ・案件 DB・期限管理の心臓部

Lark Base は「Excel に近い表計算インターフェース」と「Notion／kintone のような関連リンクと自動化」を両立したリレーショナル DB です。Lark Suite ヘルプセンター（larksuite.com）の仕様によると、Pro プランで 1 テーブルあたり 20,000 行、Enterprise で 50,000 行まで保持可能です（2026 年 6 月時点）。士業事務所では、以下のテーブルを作るのが基本構成です。

• 顧問先マスタ: 顧客 ID／法人名／代表者／契約サービス（顧問契約・スポット）／契約開始日／担当者／インボイス登録番号
• 案件 DB: 案件 ID／顧問先ID（顧問先マスタへのリンク）／案件種別／ステータス／期限／担当／レビュー者
• 期限管理ビュー: 「申告期限」「給与計算締切」「許認可更新」をカレンダー／ガントで横串表示
• 領収書／添付ファイル DB: 顧問先ごとに領収書・契約書 PDF を集約（Lark Drive と連携）

Base はビュー機能で「担当者別」「ステータス別」「期限別」のフィルタを切り替えられるため、所長は「今日レビューすべき案件」、スタッフは「自分が今週やるべき案件」を 1 つの DB から別の角度で見ることができます。Lark Base 設計の基礎は「Lark Base が中小企業の業務効率を変える 3 つの理由」で詳しく解説しています。

柱 2: Lark Wiki（ナレッジ蓄積）— 業務マニュアルと顧問先別ドキュメント

Lark Wiki は階層構造のドキュメント管理で、業務マニュアル・規程テンプレート・顧問先別の特殊対応メモを集約します。Lark Wiki は権限が階層継承される設計のため、「全所員に共有」「特定パートナーのみ」「個別案件チームのみ」を柔軟に切り替えられます。

士業事務所では、以下の階層構造が典型です。

• 事務所共通マニュアル: 受任プロセス／請求フロー／コミュニケーションルール／緊急連絡手順
• 業種別 SOP: 月次決算 SOP／法人申告 SOP／給与計算 SOP／許認可申請 SOP
• 顧問先別ドキュメント: 顧問先 A／顧問先 B…と並べ、各顧問先の特殊事情・パスワード（は別管理）・過去判例メモ
• 規程テンプレート: 就業規則ひな型／賃金規程ひな型／秘密保持契約書ひな型

Wiki と Base はリンクで連携するため、「Base の顧問先マスタ → クリック → Wiki の顧問先別ドキュメント」という遷移を 1 アクションで作れます。これは特化 SaaS では実現できない強みです。

柱 3: Lark 承認（ワークフロー）— 申告書チェックと規程改定の二重承認

士業事務所の業務は、ほぼすべてが「担当者作成 → 所長／パートナーレビュー → 顧問先送付」の 2 段階承認構造を持ちます。これを口頭・チャット・メールで回すと、「いつ・誰が・どこまで承認したか」が残らず、年末や年度末に問題が起きたときの追跡が困難になります。

Lark 承認では、テンプレート化された承認フロー（例：申告書チェック申請）を作り、申請者が「対象顧問先・案件 ID・申告書 PDF」を添付して提出 → レビュー者が承認／差戻し → 承認後は自動的に案件 DB のステータスが「レビュー完了」に更新、という流れを構築できます。承認の操作は Lark App（モバイル）からも可能なため、所長が外出先でも判断できます。Lark 承認ワークフローの具体的な作り方は「Lark 承認ワークフロー実装ガイド」で解説しています。

柱 4: Lark IM／メール — 顧問先別チャットと履歴の自動保存

Lark IM は Slack や Teams と同等のチャット機能を提供しますが、士業事務所での真価は「顧問先別グループチャット」と「事務所内案件チャット」を 1 アプリで分離管理できる点にあります。さらに、Lark メールを契約すると、独自ドメインのメールも Lark の中で送受信できます。

運用パターンとしては、以下のようになります。

• 顧問先 A グループ: 担当税理士 1 名＋スタッフ 1 名＋顧問先 2〜3 名で構成。月次決算データの受け渡し、領収書写真の送付、簡易な質問対応
• 事務所内チャネル: 全所員＋業務カテゴリ（税務／労務／許認可）チャネルを用意。所長判断を仰ぎたい場合に投稿
• Lark メール: 公式書類の送付・受領は引き続きメールベースで運用。Lark 内のチャット履歴と並行管理

大事なのは、Lark IM のチャット履歴はチャネル単位で永続保存され、検索可能なことです。「3 ヶ月前、顧問先 A から受け取ったあの資料はどこ？」が、検索で 5 秒で出てきます。これも、LINE や Gmail では実現しにくい運用です。

税理士事務所の実装パターン

結論：税理士事務所では「顧問先マスタ・月次決算 DB・申告期限カレンダー・領収書回収状況」を Lark Base 4 テーブルで構成し、freee／マネーフォワード／達人シリーズなどの特化 SaaS とは ID 連携ではなく「顧問先 ID と案件 ID の対応表」で運用するのが現実的です。

想定モデル：所長 1 名＋税理士 2 名＋スタッフ 4 名＋パート 3 名 = 10 名規模

10 名規模の税理士事務所をモデルに、Lark Base で何をどう設計するかを具体化します。顧問先数は法人 40 件・個人事業主 30 件・スポット 20 件、年間で約 100 件の申告書を作成する事務所を想定します。

Base 設計：4 テーブル構造

テーブル名	主なフィールド	関連リンク先
顧問先マスタ	顧問先 ID（自動）／法人名・屋号／代表者／契約サービス（顧問・スポット）／月次顧問料／決算月／インボイス登録番号／電子取引データ保管場所／担当税理士／契約開始日	→ 月次決算 DB／申告書 DB／領収書 DB
月次決算 DB	月次決算 ID／顧問先 ID（リンク）／対象月／領収書受領日／仕訳完了日／試算表完成日／顧問先送付日／ステータス（受領待ち／仕訳中／レビュー待ち／送付済）	→ 顧問先マスタ／担当者
申告書 DB	申告書 ID／顧問先 ID／申告種別（法人税・所得税・消費税・相続税）／対象年度／作成開始日／レビュー日／所長承認日／電子申告完了日	→ 顧問先マスタ／承認フロー
領収書／添付 DB	添付 ID／顧問先 ID／受領日／領収書枚数／電子取引データの有無／格納場所（Lark Drive／メール添付など）	→ 顧問先マスタ

運用ルール 5 つの基本

1. 顧問先 ID は事務所独自で発番（freee／達人とは独立）。各特化 SaaS で持つ ID は顧問先マスタにフィールドとして併記
2. 月次決算 DB のステータスはスタッフが更新。所長は「レビュー待ち」フィルタを毎朝確認
3. 申告書 DB のレビュー → 所長承認は Lark 承認フローで実施。承認時に PDF を添付、承認履歴が DB と連動して残る
4. 領収書受領は LINE／メールではなく Lark IM の顧問先グループに集約。Lark の自動化で月次決算 DB の「受領日」を自動更新（オプション）
5. 期限カレンダービューを月次決算 DB と申告書 DB に作り、所長は週次で「向こう 30 日に期限が来る案件」を一覧確認

kintone との比較で見る Lark Base の優位

kintone も士業向けに展開されています（kintone「士業の業務改善」公式 参照）。kintone は業務 DB として優秀で、士業事務所での活用実績も豊富です。一方で、kintone は「業務 DB」レイヤに特化しているため、チャット・承認・ナレッジ・メール・カレンダーは別サービスで補う必要があります（kintone スタンダードプラン 1 ユーザー月額 1,800 円・税抜、別途 Slack や Microsoft Teams や Notion を組み合わせる構成が一般的）。詳しい比較は「Lark vs kintone どっちを選ぶべきか」でも整理しています。15 名規模で計算すると、kintone 中心の構成は次の通りです。

ツール	単価（税抜）	15 名月額
kintone スタンダード	¥1,800	¥27,000
Slack プロ（年払い）	¥925	¥13,875
Notion Plus（ナレッジ）	¥1,650	¥24,750
合計	—	¥65,625

これに対し、Lark Pro 1 本で組むと、1,420 円 × 15 名 = 月額 21,300 円。コスト差は約 3 倍、年間で 50 万円以上の差になります。ただし、kintone の業務 DB としての成熟度は高く、すでに kintone を入れている事務所が無理に乗り換える必要はありません。新規導入なら Lark Pro 1 本、既存 kintone は併用も選択肢、というのが現実解です。

社労士事務所の実装パターン

結論：社労士事務所では「顧問先マスタ・給与計算スケジュール・入退社手続き DB・規程改定 DB・助成金申請 DB」を Lark Base 5 テーブルで構成し、KiteRa・オフィスステーション Pro・給与計算クラウドは特化用途で並走させる。

想定モデル：社労士 2 名＋スタッフ 5 名＋パート 3 名 = 10 名規模

10 名規模の社労士事務所をモデルに、顧問先 50 社、毎月 50 社の給与計算と入退社対応、年 30 件の助成金申請を扱う事務所を想定します。

Base 設計：5 テーブル構造

テーブル名	主なフィールド
顧問先マスタ	顧問先 ID／法人名／代表者／契約サービス（顧問・スポット・助成金）／給与計算締切日／業種／従業員数／担当社労士
給与計算スケジュール	月次タスク ID／顧問先 ID／対象月／勤怠データ受領日／給与計算開始日／チェック日／顧問先送付日／ステータス
入退社手続き DB	手続き ID／顧問先 ID／対象従業員／手続き種別（社保新規／喪失／扶養／離職票）／受付日／電子申請完了日／ステータス
規程改定 DB	規程 ID／顧問先 ID／規程名（就業規則・賃金規程など）／改定要望日／ドラフト作成日／所長レビュー日／顧問先送付日／届出日
助成金申請 DB	申請 ID／顧問先 ID／助成金名／要件確認日／計画届提出日／支給申請日／受給予定日／成功報酬金額／ステータス

KiteRa と Lark Wiki の役割分担

KiteRa Pro は規程の作成・改定・履歴管理という「中身そのもの」を扱うのに対し、Lark Wiki は事務所として「どの顧問先のどの規程をいつ改定したか」というメタ情報を持ちます。両者は競合せず、補完関係です。具体的には：

• KiteRa Pro 側: 規程のテキスト本体、条文の改定履歴、関連法令との突合
• Lark Wiki 側: 顧問先別に「規程改定の意思決定メモ」「顧問先とのコミュニケーション履歴」「次回改定の予定」
• Lark Base 規程改定 DB: 改定案件のステータス管理、レビューワークフロー

この 3 層で運用すれば、特化 SaaS の強みを生かしつつ、事務所として「規程改定が今どこで止まっているか」を所長が 1 画面で把握できます。

助成金申請の二段構え承認フロー

助成金申請は社労士事務所の収益源として重要ですが、要件の細部を読み違えると不支給になる構造リスクが高い業務です。Lark 承認フローでは、以下の 2 段階承認テンプレートを作るのが効果的です。

1. 要件確認承認: 担当社労士が「この顧問先・この助成金で要件を満たす」と判断 → 所長または事務所のシニア社労士が要件突合を再確認 → 承認 → 計画届の作成に進む
2. 計画届・支給申請の最終承認: 担当が書類完成 → シニア社労士レビュー → 所長最終承認 → 電子申請

この承認履歴は Lark Base の助成金申請 DB に自動連動し、「いつ・誰が・どの根拠で承認したか」が永続的に残ります。顧問先からの問い合わせ対応・万一の指摘対応で、強い証跡になります。

行政書士事務所の実装パターン

結論：行政書士事務所は業務領域が広く、案件単価のばらつきも大きい。Lark Base では「案件種別ごとに独立した DB」ではなく、「統合案件 DB＋種別フィールド」の単一テーブル構造のほうが、所長の経営判断と人員配分に有効です。

想定モデル：行政書士 1 名＋スタッフ 2 名＋業務委託 2 名 = 5 名規模

5 名規模の行政書士事務所をモデルにします。年間で建設業許可 30 件、産業廃棄物許可 10 件、ビザ申請 20 件、相続・遺言 15 件、契約書作成 50 件を扱う事務所を想定します。

Base 設計：「統合案件 DB＋種別フィールド」モデル

テーブル名	主なフィールド
顧客マスタ	顧客 ID／法人名 or 個人名／業種／所在地／継続案件の有無／担当行政書士
統合案件 DB	案件 ID／顧客 ID（リンク）／案件種別（建設業許可・産廃・ビザ・相続・契約書）／受任日／成果報酬／実費／ステータス／担当／期限
書類テンプレート（Wiki 連動）	テンプレート ID／案件種別／書類名／Wiki ページへのリンク／最終改定日／改定担当
面談記録 DB	面談 ID／顧客 ID／案件 ID／面談日／対応者／面談メモ／次回アクション

統合 DB にするメリット 3 つ

案件種別ごとに別テーブルにせず、「統合案件 DB＋種別フィールド」で統一する設計には、行政書士事務所特有の理由があります。

1. 同じ顧客が複数業務を発注する: 建設業の顧客が、許可申請＋契約書作成＋遺言相談を順に依頼する。統合 DB なら「この顧客と過去にいくらやり取りしたか」が即座に出る
2. 担当・期限を 1 画面で見渡せる: 5 名規模の事務所では、所長が全案件を見渡せることが運営の生命線。種別をフィルタで切り替える運用で十分
3. 収益分析が単純: 「種別別・月別の売上」「成果報酬の平均単価」をピボットで即座に出せる

書類テンプレートを Wiki で運用する理由

行政書士業務の特徴は、業務領域ごとに必要書類が大きく異なり、行政庁の様式変更が頻繁にあることです。書類テンプレートをGoogle ドライブ／OneDrive のフォルダ管理で運用すると、改定履歴・改定理由が残らず、新人スタッフが「どれが最新か」を判断できない状態に陥ります。

Lark Wiki なら、テンプレートごとに「最新版」「改定履歴」「改定理由」「次回改定予定」を構造化して残せます。さらに、Lark Wiki はドキュメント単位でコメント機能があるため、テンプレートの一節について「ここは管轄が東京都の場合のみ」など、担当者のコメントを残せる運用が可能です。

コスト試算 — 15 名規模で年いくら違うか

結論：15 名規模の士業事務所が「Lark 1 本」「kintone＋Slack＋Notion」「Microsoft 365＋kintone」のいずれを選ぶかで、年間 30〜60 万円のコスト差が生じます。

構成	月額（15 名・税抜）	年額	主な特徴
Lark Pro 1 本	¥21,300	¥255,600	Base・Wiki・承認・IM・メール・カレンダー全部入り
kintone＋Slack＋Notion	¥65,625	¥787,500	3 サービス連携。kintone のプラグイン拡張で別費用増の可能性
Microsoft 365 Business Standard＋kintone	¥55,110	¥661,320	Teams＋SharePoint＋kintone。設計の自由度は高いが構築工数は最大
Google Workspace Business Standard＋kintone	¥51,000	¥612,000	Gmail＋Drive＋kintone。チャットは Google Chat 簡易版

各サービスの料金は 2026 年 6 月時点の公式ページ参照（Lark／kintone／Slack／Notion／Microsoft 365／Google Workspace）。価格は事務所側のライセンスのみで、各種特化 SaaS（KiteRa／オフィスステーション Pro／freee／達人）の費用は別途。

注意したい構造的なポイントとして、複数 SaaS 構成は単に料金が高いだけでなく、「ユーザー追加のたびに 3 サービスでアカウントを作る」「権限管理を 3 箇所で行う」「ログイン認証が複数」など、運用工数も増えます。15 名以下の事務所では、運用シンプルさを優先して Lark 1 本にまとめるメリットが大きくなります。

30／90／180 日 導入ロードマップ

結論：士業事務所の Lark 導入は、いきなり全機能をフル展開せず、「30 日で顧問先マスタ＋IM」「90 日で案件 DB＋承認」「180 日で Wiki ナレッジ整備」の 3 段階で進めるのが現実的です。

Day 0〜30：Lark IM と顧問先マスタの立ち上げ

• Day 1〜7: Lark Pro 契約、所員 5〜20 名分のアカウント発行、メール／カレンダー移行
• Day 8〜14: 事務所内 IM チャネル 5〜10 個立ち上げ（全社／業務カテゴリ別／プロジェクト別）
• Day 15〜21: Lark Base「顧問先マスタ」テーブル作成、既存エクセル顧問先リストをインポート、フィールド整備
• Day 22〜30: 顧問先と Lark IM 連携開始（一部顧問先から段階的に）、メール署名に Lark IM 案内追加

この段階は「事務所全員が Lark を毎日触る」状態を作ることが目的。既存業務は変えず、コミュニケーションだけ移行します。

Day 31〜90：案件 DB と承認フローの構築

• Day 31〜45: 業種別 Base 設計（税理士なら月次決算 DB＋申告書 DB、社労士なら給与計算 DB＋手続き DB、行政書士なら統合案件 DB）
• Day 46〜60: 既存案件データを順次 Base に投入、担当割り当て、期限設定
• Day 61〜75: Lark 承認フロー設計（申告書チェック／規程改定／助成金）、所長レビュー運用
• Day 76〜90: 期限カレンダービュー設定、週次運営会議で Base の「期限間近」フィルタを画面共有

この段階で、所長は「今週レビューすべき案件」を朝 5 分の Base 確認で把握できる体験を作る。属人化の解消が本格的に始まります。

Day 91〜180：Wiki ナレッジ整備と運用定着

• Day 91〜120: 業務マニュアル（受任プロセス／請求フロー）を Wiki 化、既存の散在文書を移行
• Day 121〜150: 顧問先別 Wiki ページを段階的に整備、引き継ぎが多い顧問先から優先
• Day 151〜180: 書類テンプレート（規程・契約書・申請書）の Wiki 化、改定履歴の運用ルール化

180 日後の到達点は、「新人スタッフが入っても、Wiki と Base を見れば自走できる」状態。中小企業 DX の段階モデルは「中小企業の DX を 90 日で軌道に乗せる実践ロードマップ」でも体系化していますが、士業事務所はその応用版として 180 日で完了させるのが現実的です。

士業導入で踏みやすい落とし穴 5 パターン

これまで中小企業 DX を伴走してきた経験から、士業事務所での Lark 導入で特に踏みやすい落とし穴を 5 つに整理します。

落とし穴 1: 「特化 SaaS を全部置き換える」と勘違いする

Lark Base は業務 DB として強力ですが、freee／マネーフォワード／KiteRa／オフィスステーション Pro のような特化機能（仕訳エンジン、規程作成支援、電子申請の API 連携）は持ちません。Lark は「事務所運営の OS」、特化 SaaS は「専門業務エンジン」と役割を分けて考えるのが正解です。

落とし穴 2: 顧問先 ID を SaaS ごとに連動させようとする

理想を追って、Lark Base の顧問先 ID と freee の顧客 ID を API 連携で同期させようとすると、構築工数が膨らみ、ROI が遠のきます。5〜20 名規模の事務所では、API 連携ではなく「顧問先マスタに各 SaaS の顧客 ID をフィールドで併記」する手作業運用で十分。年に 1〜2 回の棚卸しでズレを補正します。

落とし穴 3: IM 移行をパート・所長・所員が同時にやらない

Lark IM 導入で最も多い失敗は、「所員は使い始めたが所長がメールを使い続ける」状態。所長が判断する場が IM に移行しなければ、IM の利用率は伸びません。導入初日から所長が朝の出勤連絡を IM で行い、社内の重要連絡もすべて IM 経由とするルールを作ることが必須です。

落とし穴 4: Wiki を「全員が書き込む」前提で設計する

Wiki ナレッジは「更新責任者を 1 人決めて他は読むだけ」のほうがメンテナンスされます。「全員で更新しよう」は美しいが現実的には誰も書かない。受任プロセス・請求フロー・業種別 SOP はそれぞれ責任者を 1 名アサインし、改定は責任者経由ルールを徹底します。

落とし穴 5: 既存の電話・FAX を急に切り替えようとする

士業事務所の顧問先には、デジタル対応に消極的な高齢経営者・地方の中小企業も多く含まれます。顧問先のデジタル成熟度に合わせて、電話・FAX・郵送・Lark IM・メールを使い分け、事務所内の運用基盤は Lark に統一する、という二層構造が現実的です。事務所側の業務効率は向上し、顧問先には従来のコミュニケーション手段を残せます。

よくある質問