Lark Wiki で社内ナレッジを蓄積する — 中小企業の属人化解消 30 日プラン

「ベテラン社員が辞めると、業務が止まる」「あのお客様への対応手順は山田さんしか知らない」— 中小企業のナレッジ管理は、組織が小さいほどキーパーソン依存になり、誰かが抜けた瞬間に売上と顧客対応に直撃します。中小企業庁の中小企業白書 2024でも、人手不足倒産が前年比 4 割増という記載があり、後継者・熟練人材の喪失が経営リスクとして強調されています。

本記事では、Lark Wiki(法人向けナレッジ管理機能)を使って中小企業の属人化を 30 日で解消する実装プランを、公式仕様の最新スナップショット + Notion / Confluence / kintone との TCO 比較 + 自社運用の知見をもとに解説します。アウフヘーベンジャパン株式会社は群馬・前橋を拠点に Lark 導入を支援しており、自社 EC 事業でも Wiki に手順書・社内 FAQ・取引先別対応マニュアルを集約し、ベテラン依存の業務を月 8 件 → 月 1 件に圧縮した実証データを保有しています。

結論 — 属人化解消は「書く文化」より「探せる構造」で決まる

属人化解消は、社員に「ドキュメントを書け」と命じることではなく、書いた瞬間に「探せる・繋がる・更新される」構造を先に用意することです。Lark Wiki はスペース(部門・プロジェクト単位の入れ物)→ ページ(無限階層)→ ブロック(段落・表・データベース)という 3 層構造を持ち、検索・権限・他 Lark 製品(Docs / Base / Messenger)との連携が同一アカウントで完結します。書く前に「どこに置くか」が決まっていれば、書く側のハードルが半分以下になります。

Notion や Confluence は「書きやすさ」「美しさ」では先行しますが、中小企業にとっての本丸は「無料 / 安いプランで何人まで使えるか」「業務 DB(Lark Base)とどれだけ近い導線で繋がるか」「ベテランが辞めても探せる権限設計を作れるか」の 3 点です。本記事ではこの 3 点を軸に、Lark Wiki が中小企業に最適である理由と、30 日で形にする具体ステップを示します。Wiki だけでは解けない業務 DB 領域についてはLark Base が中小企業の業務効率を変える 3 つの理由もあわせてご覧ください。

中小企業の属人化が起きる 4 つの構造的原因 — 「個人の意識」ではなく「仕組みの欠落」

「うちの社員は共有意識が低い」と嘆く経営者は多いですが、属人化は精神論ではなく構造で起きます。中小企業に共通する 4 つの原因を整理します。

原因 1: ドキュメントの置き場所が「フォルダ」で、検索しても出てこない

共有フォルダ(NAS / Google Drive / OneDrive)に Word・Excel・PDF が散らばっている状態では、ファイル名検索しかできず、本文の中身は通常検索の対象になりません。結果として「あったはずだが見つからない」が常態化し、ベテランに口頭で聞く方が早くなります。これは「フォルダ思考」のままナレッジを溜めることの限界で、中小企業庁の中小企業白書 2024でも、業務効率化におけるデータ検索性が経営課題として明示されています。

原因 2: 権限設計が「全員見える or 一部しか見えない」の二択になっている

共有フォルダの権限は「読み取り / 編集 / 不可」の粒度で、ページ単位の細かい制御ができません。経理マニュアルを「経理 3 名だけ書ける、他部署は読める」のような設定をしたい場合、フォルダを分けるしかなく、結果として「経理が変更しても他部署は古い版を見続ける」という事故が起こります。Lark Wiki のページ単位権限なら、同じスペースに置きながら編集者と閲覧者を分けられます(出典: Lark 公式ヘルプ「ウィキの権限設定の紹介」)。

原因 3: 「書く人」と「読む人」が同じ場所にいない

Slack / Chatwork / メールでナレッジが流れ、後から検索できない。Notion に書いても普段の会話は別ツール、というように「書く」と「読む」が分断されているとナレッジは育ちません。Lark は Wiki・Docs・Messenger・Meetings・Base が同一アカウント・同一通知導線に統合されているため、「Wiki ページを更新した瞬間に Messenger で関係者に通知が飛ぶ」「会議中に Wiki ページを開いて議論する」が同じ画面内で完結します。

原因 4: ベテラン社員にとって「書く」インセンティブがない

「自分しか知らない」が職場での価値になっている社員にとって、ナレッジを書き出すのは自分の存在意義を希釈する行為です。これは精神論で解決できません。経営側で「ナレッジ化された業務は標準業務、属人業務は属人手当の対象から外す」のような評価制度を整える必要があります。仕組み(Lark Wiki)と制度(評価制度)の両輪で初めて属人化は溶けます。仕組み側だけが先行しても定着しないため、中小企業 DX 失敗率 64% を回避する 5 ステップで論じた「制度と運用を同時に設計する」原則が効きます。

Lark Wiki でできる 4 つのこと — 公式仕様の最新スナップショット(2026 年 6 月時点)

Lark Wiki は単なるドキュメントツールではなく、複数形式・複数階層・複数権限を一体で扱える「法人向けナレッジ管理システム」として設計されています(出典: Lark 公式「Wiki — 法人向けナレッジ管理システム」)。中小企業の属人化解消に直接効く 4 つの機能を、公式情報ベースで整理します。

機能 1: 複数フォーマットを 1 ページに同居させられる

Lark Wiki のページは、ドキュメント(Docs)・シート(Sheets)・マインドマップ・データベース(Base)を同一ページ内にブロックとして埋め込めます(出典: Lark 公式 Wiki 製品ページ)。「業務手順は Docs、顧客リストは Base、KPI 推移は Sheets」を 1 ページにまとめられるため、Wiki から別ツールに飛ばずに必要情報に到達できます。

機能 2: パーソナライズされた全文検索

Wiki 内の全ページ本文・表内テキスト・添付ファイルが検索対象となり、検索結果は閲覧者の権限と過去のアクセス履歴を考慮して並び替えられます(出典: Lark 公式 Wiki 製品ページ)。「フォルダのどこに置いたか覚えていない」をゼロにできるのが、共有フォルダから移行する最大の動機です。

機能 3: 3 段階の権限ロール × ページ単位の継承

Wiki スペースには「管理者・編集者・閲覧者」の 3 ロールが存在し、ページごとに閲覧・編集・コピー・印刷・エクスポートを個別に設定できます(出典: Lark 公式ヘルプ「ウィキの権限設定の紹介」)。たとえば「給与計算マニュアルは経理 3 名だけ編集可、役員のみ閲覧可、他社員は存在自体を見えなくする」のような設計が可能です。

機能 4: Confluence / Word / Excel / CSV / XMind からのバッチ移行

Confluence・Word・Excel・CSV・XMind 形式のファイルを Wiki に一括インポートでき、構造を保ったまま移行できます(出典: Lark 公式 Wiki 製品ページ)。「既存の Confluence や Notion から乗り換えたいが、過去資産が壊れるのが怖い」という移行不安は、この機能で大幅に下がります。Notion 移行の具体手順はNotion vs Lark Base 移行 30 日プランで別途解説しています。

Notion / Confluence / kintone との TCO・機能比較(30 名規模・2026 年 6 月時点)

ナレッジ管理 SaaS の選定は「ページ単価」ではなく「使い切るための統合度」で決まります。同じ 30 名規模で 3 サービスを並べたとき、Lark の優位はチャット・カレンダー・会議・業務 DB が同一ライセンスに同梱されている点です。

※ Lark Pro 料金は Lark 公式プランページ、Notion 料金は Notion 公式料金ページ、Atlassian Confluence 料金は Atlassian 公式料金ページ(チーム規模・年払い適用で 1 ユーザー $5.42〜$5.75 程度、円換算は 1USD=157 円で概算)、kintone 料金は サイボウズ公式料金ページを 2026 年 6 月時点で参照。為替・キャンペーンで変動するため、最終確認は各社公式サイトで実施してください。

Confluence 単体は安く見えますが、チャット(Slack 別途)・業務 DB(Jira / kintone 別途)・会議(Zoom 別途)を足すと 30 名で年額 ¥150〜200 万円規模になり、Lark Pro 単独(¥51 万円)との差は容易に 3〜4 倍に開きます。kintone はレコード型 DB に強みがありますが、Wiki 的なロングフォームの文章ナレッジには向かず、kintone との詳細比較はLark vs kintone 中小企業向け比較ガイドを参照してください。Microsoft 365 系との比較はLark vs Microsoft Teams 比較で扱っています。

30 日で社内ナレッジを Lark Wiki に集約する週次ロードマップ

属人化解消は「全部署同時に Wiki に書け」と号令をかけても回りません。下記の 4 週ステップで、対象範囲を絞り、定着パターンを 1 つ作ってから横展開するのが成功率を最大化します。当社で複数の中小企業に伴走した経験と自社 EC 事業での実装をもとに設計したロードマップです。

Week 1: 「これ書けば全社が動く」5 ページの特定 — 棚卸しと優先順位付け

全社の業務手順を一気に書き出すのは不可能なので、最初の 5 ページを決め切ります。優先順位の決め方は「①その担当者が休んだら売上が止まる業務」「②新人が入ったとき必ず質問される業務」「③直近 3 か月でクレーム / トラブルが起きた業務」の 3 軸で 10 件ほど候補を出し、ベテラン社員と経営陣で 5 件に絞り込みます。アウフヘーベンジャパンの自社 EC では、楽天店舗の受注対応 SOP・キャンセル処理手順・返品手順・卸先別の出荷指示・経理月次締めの 5 つを最初に書き起こしました。

Week 2: Wiki スペース設計と権限ロール設定

スペースは「部門別」ではなく「読み手別」で切るのが鉄則です。「営業部」「経理部」のように作ると、部門横断のナレッジ(全社共通 FAQ など)が宙に浮きます。推奨構成は「①全社共通(誰でも読める)」「②部門専用(その部門のみ編集、他部門は閲覧可)」「③機密(役員のみ閲覧 / 経理 3 名のみ編集)」の 3 つ。各スペースに管理者を 1 名置き、編集権限を持つ社員を Week 1 で書く 5 ページの担当者だけに限定して始めます。権限の詳細はLark 公式ヘルプ「ウィキの権限設定の紹介」を参照してください。

Week 3: 5 ページの執筆 — ベテランへの「30 分インタビュー」で代筆する

「ベテランに書け」と命じても書きません。代わりに、新人または管理職が 30 分インタビューして代筆する方式が圧倒的に立ち上がりが早い。Lark Minutes(AI 議事録)でインタビューを録音すれば文字起こし・要約が自動で出るため、書き起こし負荷も最小化できます。詳細はLark Minutes × AnyCross で議事録ゼロ運用を参照してください。1 ページあたり「目的・対象者・前提条件・手順・トラブル時の対応・連絡先」の 6 ブロックをテンプレ化しておくと、執筆者間でばらつきが出ません。

Week 4: 「Wiki に書いてから話す」運用ルールの定着 — 30 日目のレビュー会

30 日目に経営層 + ナレッジ担当 + ベテラン社員 5 名前後のレビュー会を 60 分設定し、5 ページの完成度・運用ルール・次の 5 ページの選定を決めます。運用ルールで最も重要なのは「同じ質問が 2 回出たら、回答者が即 Wiki に書き、URL をチャットで返す」。これを徹底するとナレッジは自動的に蓄積されます。当社の中小企業 DX 伴走支援および自社 EC 事業の運用経験では、この運用ルールを 90 日続けると Wiki ページ数は概ね 60〜80 ページに到達し、新人質問の多くが Wiki 検索で自己解決するようになる傾向が見られます(参考値、組織規模・業種により変動)。

導入後に「読まれない Wiki」化する 3 つの失敗パターンと回避策

Lark Wiki を導入しても、運用設計を誤ると「書いた人しか読まない」「最新の情報がどれか分からない」状態に陥ります。当社が現場で見てきた失敗パターンと、その回避策を整理します。Lark 全体の導入失敗パターンはLark 導入失敗パターン 3 つ — 中小企業が避けるべき落とし穴もあわせてご覧ください。

失敗 1: 「書きたい人が書きたいだけ書く」状態を放置する

ナレッジ熱心な 1〜2 名が大量にページを作る一方、他の社員は読まない、という二極化は最頻出パターンです。回避策は「書く前に置き場所が決まっている」状態を作ること。Week 2 で設計したスペース構造・命名規則・テンプレ 6 ブロックを共有し、新規ページ作成時には必ずスペース・親ページ・テンプレを選ばせます。これだけで「とりあえずトップ階層に作って終わり」を防げます。

失敗 2: 古い情報が残り続けて「どれが最新か分からない」

Wiki は書きやすい分、古いページが残り続けます。回避策は「半年ごとに更新日が止まっているページを棚卸しする運用ルール」と、「ページ末尾に最終確認日・次回確認日・確認担当者を必ず書くテンプレ」の 2 つ。さらに、重要ページは Lark Base のレコードとして登録し、有効期限フィールドを設けて期限超過を Messenger に通知するワークフロー化が有効です。

失敗 3: 検索ヒットしても本文が長すぎて「結論」に辿り着けない

ベテランが書いたページは背景説明が長く、結論が末尾に追いやられがちです。回避策はテンプレで「最初の 3 行に結論・対象者・所要時間を書く」を強制すること。長文の手順書ほど、検索ヒット時に「これだ」と判断できるサマリーを冒頭に置くことで読了率が上がります。長文ページは目次ブロックを冒頭に挿入し、H2 / H3 で見出し階層を切ることで、ページ内ジャンプも容易になります。

自社 EC 事業での実証 — 「ベテラン依存業務」を月 8 件 → 月 1 件に圧縮

アウフヘーベンジャパンは自社 EC 事業(楽天・Amazon・自社サイト)を運営しており、2024 年時点では受注対応・卸先別出荷・経理締めの 80% を代表と古参スタッフ 2 名が抱える状態でした。「あの人がいないと止まる」業務が月 8 件発生していた典型的な属人化組織です。Lark Wiki + Lark Base への集約を 60 日かけて行い、現在は同様の業務停止リスクが月 1 件以下に低下しています。具体的に効いた施策は次の 3 点です。

第一に、Week 1 で論じた「これ書けば全社が動く 5 ページ」を 6 週間で計 28 ページまで拡大し、受注 SOP・楽天 RMS 操作・Amazon セラーセントラル操作・卸先別出荷指示・配送遅延時の謝罪文テンプレ・返品処理・経理仕訳パターンをすべて Wiki に集約。第二に、定型業務の進行ステータス(誰がどこまで処理したか)は Wiki ではなく Lark Base に切り出し、Wiki ページから「対応中の案件はこのリンクから」と Base ビューに飛ばす導線を作りました。Base 設計の考え方はLark Base 30 日 Excel 移行プランに整理しています。第三に、Slack や Chatwork で発生していた質問は「Wiki に書いてから URL を返す」運用に強制移行し、3 か月で同一質問の再発がほぼ消えました。詳細は中小 EC 事業者の Lark 活用事例 — 月 240h → 24h の実証で、業務時間ベースの効果を別途公開しています。

よくある質問

Q1. Lark Starter プラン(無料)でも Wiki は使えますか?

はい、Wiki は Starter プランから利用可能です。ただし Starter は 2025 年 3 月改定後、利用人数が 20 名までに縮小されており、21 名以上の組織は Pro プラン(¥1,420/u/月 税抜・年払い)が必須となります(出典: Lark 公式プランページ)。30 名規模なら月額 ¥42,600・年額 ¥511,200 です。

Q2. Confluence や Notion からの移行は実際どれくらいかかりますか?

Confluence は公式のバッチインポート機能を使えば 100〜300 ページ程度なら 1〜2 日で構造を保ったまま移行できます。Notion はワークスペース全体を Markdown / HTML エクスポートし、Lark Wiki に再構成します。ページ間の内部リンクは手動で張り直しが必要なため、ページ数 ×5 分程度を見積もりとしてください。500 ページ規模で 1〜2 週間が現実的です。

Q3. Wiki のページ数や容量に上限はありますか?

プランごとに合計ストレージ容量の上限が定められています。Starter は 100 GB、Pro は 15 TB、Enterprise は 15 TB + ユーザー数 × 30 GB という構成です(出典: Lark 公式プランページ)。一般的な文書ナレッジが中心であれば中小企業規模で容量がボトルネックになることは稀です。動画や設計図など大容量ファイルを多数置く場合は Pro 以上を選択してください。

Q4. ベテラン社員が「Wiki に書きたくない」と抵抗します。どう乗り越えますか?

本記事「Week 3」で示したように、ベテラン本人に書かせず、新人または管理職が 30 分インタビューして代筆する方式を強く推奨します。Lark Minutes で会話を録音すれば自動文字起こし・要約まで自動化されるため、ベテランは「いつもの仕事を説明する」だけで済みます。あわせて、評価制度面で「ナレッジ化された業務は標準業務」と位置付ける制度設計が必要です。仕組みと制度の両輪を整える視点は中小企業 DX 失敗率 64% を回避する 5 ステップを参照してください。

Q5. Lark Wiki と Lark Docs はどう使い分けるべきですか?

Lark Docs は単体ドキュメント(議事録・提案書・契約ドラフト等の「1 つの文書」)、Lark Wiki は複数ドキュメントを階層管理する「本棚 / 図書館」の役割です。Docs で作った文書を Wiki スペースに移動・登録すると、Wiki の検索・権限・階層の対象になります。実運用では「日常の作業は Docs、定着させたい知識は Wiki」と切り分けると整理しやすいです。

属人化解消の最初の一歩 — 60 分無料ヒアリング

Lark Wiki による属人化解消は、技術的には 30 日で立ち上がります。ただし「どの業務から書くか」「どう権限を切るか」「ベテランの抵抗をどう溶かすか」は組織ごとに最適解が変わります。アウフヘーベンジャパンは群馬・前橋を拠点に Lark 導入を支援しており、自社 EC 事業での実証データ(ベテラン依存業務 月 8 件 → 月 1 件、業務時間 月 240h → 24h)を踏まえた設計をご提案できます。Lark Partner CSM Certificate は 2026 年 6 月取得予定です。

本記事に関連する記事:
・Lark Base が中小企業の業務効率を変える 3 つの理由
・Lark vs kintone — 中小企業向け比較ガイド
・Lark vs Notion 2026 — どちらを選ぶか
・Notion vs Lark Base 移行 30 日プラン
・中小企業 DX 失敗率 64% を回避する 5 ステップ
・Lark 導入失敗パターン 3 つ — 避けるべき落とし穴
・Lark Minutes × AnyCross で議事録ゼロ運用 30 日
・中小 EC 事業者の Lark 活用事例 — 月 240h → 24h の実証