>
>
公開日
最終更新日
サイボウズOfficeは、まずスケジュール共有と掲示板を全社の連絡基盤として定着させ、その後にワークフローやカスタムアプリへ利用範囲を広げると運用が安定します。
サイボウズOfficeの導入・運用を担当する情シス・総務担当者にとって、機能の多さよりも「誰が、どの情報を、どこで確認するか」を先に決めることが定着の分かれ目です。予定調整、会議室予約、全社連絡、申請業務を分散したままにすると、ツールを導入しても確認先が増えてしまいます。
本記事では、サイボウズOfficeの使い方を基本操作から整理し、kintoneとの違い、Garoonを選ぶ条件、パッケージ版からクラウド版へ移行する際の確認事項まで解説します。なお、サポート終了の対象はパッケージ版（オンプレミス）であり、クラウド版は対象外です。自社の契約形態はサイボウズ公式のサポート終了情報ページで確認でき、パッケージ版に該当する場合はクラウド移行の検討が必要になります。サイボウズの公式サポート終了案内によると、パッケージ版サイボウズ Officeの追加・継続ライセンス販売は2026年9月30日に終了します（パッケージ版製品 サポート終了情報）。サポート終了日はライセンス有効期限によって異なり、すべての利用者が一律2027年9月30日に終了するわけではありません。自社のライセンス有効期限は上記ページおよび契約書類で確認でき、その期限が移行完了の期限として逆算の起点になります。移行と社内定着を同時に進める判断材料として活用してください。
サイボウズOfficeでまず整える業務の全体像
サイボウズOfficeは、予定共有、社内連絡、申請・承認といった日常業務を、共通の画面で扱うためのグループウェアです。導入直後からすべての機能を公開するのではなく、「誰が」「どの情報を」「どこで確認するか」を機能ごとに決めると、連絡手段の重複を減らしやすくなります。
たとえば、スケジュールは会議室・訪問・不在予定の確認場所、掲示板は全社周知の掲載場所、ワークフローは承認履歴を残す申請場所、と役割を分けます。メールやチャットを完全に置き換えるかどうかを先に決めるよりも、情報の正式な掲載先を定義するほうが、利用者に伝わる運用になります。
初期設計では、次の3点を一覧にします。
利用者：全社員、部門長、申請者、承認者、システム管理者のうち、誰が操作・閲覧するか
情報：予定、全社通知、部門連絡、申請書、添付ファイルのうち、何を登録するか
確認場所：トップ画面、スケジュール、掲示板、ワークフローなど、どの機能を正とするか
この一覧を作ると、「掲示板に掲載した通達をチャットでも転送するのか」「承認済みの申請書を共有フォルダにも保管するのか」といった重複を、公開前に判断できます。機能の設定作業より前に、情報の入口と正式な保管先を決めることが、定着施策の土台になります。
基本的な使い方｜スケジュール・掲示板・ワークフローを役割で使い分ける
スケジュールは「空き時間」ではなく「予定の前提」を共有する
情シス・総務担当者が設定を行う場合、クラウド版とオンプレミス（パッケージ版）では管理画面の構成や設定項目が異なるため、操作前に自社の契約形態を確認します。
スケジュールには、会議の日時だけでなく、外出、在宅勤務、終日不在、会議室の利用など、周囲が調整時に知る必要がある予定を登録します。予定名だけでは判断できない場合は、参加者、場所、オンライン会議の案内、準備物を予定の詳細欄にまとめます。
登録ルールは、細かくしすぎると入力負担が増えます。「会議室を使う予定は施設も登録する」「終日不在は終日予定として登録する」「社外へ公開できない案件名は案件コードまたは抽象化した名称にする」といった、判断に迷いやすい場面だけをルール化すると運用しやすくなります。
掲示板は周知の掲載先を固定する
掲示板では、全社通知、部門通知、規程改定、社内イベントなどを扱います。投稿時には、件名、対象者、掲載期限、問い合わせ先をそろえます。たとえば「年末調整のお知らせ」だけではなく、「年末調整：対象者・提出期限・問い合わせ先」とすると、一覧画面でも必要な判断ができます。
掲示板の閲覧漏れを防ぐには、重要なお知らせを増やしすぎないことも欠かせません。緊急連絡、期限のある手続き、全社共通のルール変更を掲載対象とし、部門内の短期連絡は別の連絡手段に寄せると、掲示板の優先度が保たれます。
ワークフローは申請書の電子化だけで終わらせない
ワークフローでは、申請フォーム、承認経路、承認時に必要な判断材料をそろえます。最初に対象にしやすいのは、休暇申請、物品購入、出張、経費に関する申請など、申請者・承認者・必要項目が比較的明確な業務です。
フォームには、申請の目的、金額、希望日、添付資料の有無など、承認者が差し戻しを減らすために必要な項目を置きます。一方で、申請のたびに同じ説明を書かせる設計は入力負担を増やします。選択肢で固定できる項目と、案件ごとの補足が必要な項目を分けると、入力内容と承認品質の両方を整えやすくなります。
公開前には、一般社員の申請、代理申請、承認者の不在、差し戻し、承認後の訂正という5場面を想定してテストします。承認者が不在の場合の代行者や、差し戻し後に申請者がどこを修正するかまで決めておくと、運用開始後の問い合わせを抑えられます。
kintone・Garoonとの違い｜選定は「組織規模」と「業務を変える範囲」で考える
サイボウズOffice、kintone、Garoonはいずれも情報共有に使える製品ですが、中心となる用途が異なります。サイボウズ社は、サイボウズOfficeをグループウェア、kintoneを業務改善プラットフォームとして案内しています。サイボウズOfficeは、スケジュール、掲示板、電子決裁など、あらかじめ用意された機能を選んで使う形に向きます。kintoneは、部門や業務に合わせたアプリを構成し、案件管理、問い合わせ管理、台帳管理などを作り込む場面に適しています。出典：サイボウズ「サイボウズ Office と、どう違う？ kintone とは？」（サイボウズ Office と Garoon の違いを教えてください）
Garoonは、大規模組織でのグループウェア利用を想定した選択肢です。サイボウズ社の「移行先製品 比較表」では、クラウド版サイボウズOfficeの利用可能人数を5〜300名、Garoonおよびkintoneを10名から数千規模と案内しています。人数だけで決めるのではなく、組織階層、拠点数、ポータルの設計範囲、管理者の運用体制も判断材料にします。
製品 | 中心となる用途 | 検討しやすい場面 |
|---|---|---|
サイボウズOffice | 予定共有、社内周知、申請・承認などの日常的な情報共有 | 共通業務を標準機能中心で早く整えたい場合 |
kintone | 案件・台帳・受付など、業務に合わせたアプリの構築 | 部署固有の管理表や申請後の業務プロセスを見直したい場合 |
Garoon | 大規模組織向けのグループウェア運用 | 利用者数、組織構造、拠点・部門横断の運用設計が大きい場合 |
選定時は、「全社員に共通して使わせる機能」と「一部の部門だけで改善する業務」を分けて棚卸しします。前者が中心ならサイボウズOffice、後者が中心ならkintoneが検討対象になります。両方が存在する組織では、予定共有や全社連絡をサイボウズOfficeで扱い、部門の案件管理をkintoneで扱うように、役割を分ける運用も考えられます。
利用者数が300名を超える、または近い将来に超える見込みがある場合は、Garoonも比較対象に加えます。サイボウズ社は、パッケージ版サイボウズOfficeを300名以上で利用している、または利用が想定される顧客にGaroonへの移行を案内しています。対象人数、契約形態、提供状況は確認が必要です。自社の利用者数と組織運用を整理できれば比較検討に進み、整理できなければ先に利用部門・利用機能の棚卸しを行います。出典：サイボウズ「パッケージ版『サイボウズ Office』販売・サポート終了のお知らせ」
パッケージ版からの移行手順｜終了日ではなく契約・データ・業務影響から計画する
サイボウズ社は、パッケージ版「サイボウズ Office」の販売を2021年から2026年にかけて順次終了し、サポートを2027年に終了すると発表しています。継続サービスライセンス（1年）、再契約サービスライセンス、ユーザー数追加ライセンス、プレミアムアップグレードの販売終了日は2026年9月30日です。サポート終了日はライセンス有効期限によって異なるため、すべての利用者が2027年9月30日に終了するわけではありません。出典：サイボウズ「パッケージ版『サイボウズ Office』販売・サポート終了のお知らせ」「サイボウズ Office 10 継続更新のご案内」
パッケージ版を利用している場合、直ちにクラウド版へ移るという結論だけを先に置くのではなく、今後の利用方針を検討します。選択肢には、クラウド版サイボウズOfficeへの移行、Garoonやkintoneを含む別製品への移行、対象業務の整理・再設計、契約期間内での現行運用の継続があります。
1. 契約・バージョン・対象機能を棚卸しする
まず、管理者画面や契約書類で、利用中の製品バージョン、ライセンス有効期限、ユーザー数、利用コース、サービスライセンスの状態を記録します。ワークフロー、報告書、カスタムアプリなどは、サービスライセンスの有効期限終了後に閲覧や書き出しができなくなる機能があります。サイボウズ社の「パッケージ版『サイボウズ Office』販売・サポート終了のお知らせ」では、最終有効期限までのデータ書き出し・移行完了を案内しています。
ライセンス有効期限と対象機能が確認できた時点で、データ移行と業務移行の完了期限を逆算します。契約情報やバージョンが不明な場合は、利用部門への運用開始日の告知を保留し、一覧化を最初の完了条件にします。
2. 移行対象を「データ」と「運用」に分ける
移行対象には、予定、掲示板、ワークフロー、ユーザー、組織、添付ファイル、カスタムアプリ、通知設定、外部連携などがあります。ただし、すべてを同じ優先度で移す必要はありません。法令・規程・監査対応で保管が必要なデータ、日常業務の継続に必要なデータ、参照頻度が低く保管方法を別途決められるデータに分類します。
サイボウズ社は、パッケージ版サイボウズOfficeのバージョン6以降を利用している場合、パッケージ版のデータをクラウド版へ移行できると案内しています。実際に移行できるデータ、利用中の設定との差分、対象バージョンは、公式の「パッケージ版からクラウド版へのデータ移行手順」と「クラウド版へのデータ移行ツール」で確認します。確認結果により、移行ツールで移せるデータは試験移行の対象にし、対象外のデータは書き出し・保管・再登録の手順を別に作成します。
3. お試し環境で試験移行と業務テストを行う
クラウド版では、設定内容を契約後へ引き継げるお試し環境が案内されています。試験環境では、全データをいきなり投入する前に、代表的な部署・申請書・添付ファイルを選び、移行後に閲覧、検索、申請、承認、通知ができるかを確認します。出典：サイボウズ「クラウド版 購入方法」
業務テストでは、システム管理者だけで判定しません。総務には全社掲示と各種申請、営業には外出予定と会議室予約、部門長には承認・差し戻し・代理対応を操作してもらい、従来の業務で必要な情報が見つかるかを確認します。テスト結果は「移行可」「設定修正後に再試験」「別の運用で代替」の3区分で記録すると、切り替え判断を共有しやすくなります。
4. 本番切り替えでは二重入力の期間を短くする
本番移行日には、新旧環境へ同じ情報を長期間入力し続けない設計にします。二重入力が必要な場合も、対象を全機能に広げず、たとえば掲示板だけ、またはワークフローだけのように限定します。切り替え前に、旧環境へ最終登録する日時、新環境を正式な掲載先とする日時、旧データの参照方法、問い合わせ窓口を利用者へ知らせます。
切り替え後に確認するのは、ログイン可否だけではありません。予定の検索、掲示板の閲覧、申請・承認、通知、添付ファイルの閲覧といった、日常業務に直結する操作を確認します。監査ログの取得はサイボウズOfficeクラウド版プレミアムコースの管理画面（「システム管理」＞「アクセスログ」）で確認できます。スタンダードコースではアクセスログ機能が提供されていないため、利用部門からの完了報告と画面確認を移行判定の材料にします。
失敗を防ぐ定着のコツ｜段階導入・権限設計・利用状況の確認をセットにする
定着しない原因は、機能不足よりも「何のために使うのか」「以前の手段はいつまで使うのか」が曖昧なことにあります。導入時には、全機能を一斉公開するより、利用頻度が高く、ルールを説明しやすい機能から始めます。
段階導入の例
段階 | 公開する機能 | 運用上の狙い | 確認する指標 |
|---|---|---|---|
第1段階 | スケジュール、掲示板 | 予定確認と全社周知の掲載先を一本化する | 予定登録者数、掲示板の閲覧状況、問い合わせ件数 |
第2段階 | ワークフロー | 定型申請の紙・メール経路を置き換える | 申請件数、差し戻し理由、承認までの日数 |
第3段階 | カスタムアプリなどの個別機能 | 部門固有の管理業務を整理する | 二重入力の有無、表計算ファイルの更新頻度、部門からの改善要望 |
第1段階では、スケジュール共有と掲示板に対象を絞ります。利用者が「会議の空き時間はここで見る」「全社通達はここに載る」と理解できる状態を作ってから、承認業務や部門固有の業務へ広げます。
権限は最小限から始め、例外を記録する
権限設計では、全員が見てよい情報と、部門・役職で範囲を分ける情報を切り分けます。掲示板なら全社掲示と部門掲示、ワークフローなら申請者・承認者・管理者、スケジュールなら公開範囲と施設管理者を区別します。初期段階で個別の例外権限を増やしすぎると、異動時の見直しが難しくなります。
例外が必要な場合は、対象者、付与理由、見直し日、解除条件を管理台帳へ残します。人事異動や組織変更の際に、この台帳と組織情報を照合できれば権限変更を反映し、照合できなければ一時的な個別付与を増やさず、管理者による確認を先に行います。
よくあるつまずきと対処の考え方
掲示板を見てもらえない：メール・チャット・掲示板に同じ情報が分散している可能性があります。全社通知の掲載先を掲示板に固定し、転送する場合も本文を複製せず、掲載場所を案内する形にそろえます。
ワークフローが差し戻しばかりになる：申請書の必須項目が不足している、または記入例がないことがあります。差し戻し理由を分類し、頻出する理由があれば選択項目や説明文へ反映します。
予定が登録されない：登録対象が曖昧で、利用者が入力の価値を感じにくい状態です。不在予定、会議室利用、顧客訪問など、他者の調整に影響する予定を優先して登録対象にします。
管理者へ問い合わせが集中する：操作方法と運用ルールが混在していることがあります。ログインや登録方法は操作手順、どこへ掲載するかは運用ルールとして分け、問い合わせ内容を月ごとに整理します。
定着状況は、「ログインした人数」だけでは判断しません。予定登録、掲示板閲覧、申請・承認といった機能別の利用状況と、メール・紙・表計算への二重入力が残っているかを合わせて見ます。月次で確認する担当者と確認日を決め、利用が低い機能は、周知不足・権限不足・業務設計不足のどれに当たるかを切り分けます。
導入・移行前のチェックリスト
導入または移行の着手前に、次の項目を1枚の管理表へまとめます。担当者だけが把握するのではなく、総務、利用部門の責任者、承認者、システム管理者が同じ内容を参照できるようにします。
利用中の製品形態、バージョン、ライセンス有効期限、ユーザー数
利用している機能と、各機能の管理担当者
移行・保管・廃止に分けたデータの一覧
ユーザー、組織、役職、承認経路、施設の登録・更新担当
掲示板、スケジュール、ワークフローで守る利用ルール
試験移行の対象部署、代表業務、判定担当者、再試験の条件
本番切り替え日、旧環境の参照方法、問い合わせ窓口
切り替え後に確認する利用指標と、改善を判断する会議の頻度
パッケージ版の契約・サポートに関する日付は、サイボウズの「パッケージ版『サイボウズ Office』販売・サポート終了のお知らせ」と、自社のライセンス情報で照合します。ライセンス有効期限、対象バージョン、利用中機能が確認できれば移行日とデータ保管期限を具体化し、確認できなければ契約情報の確認完了を移行計画の最初の完了条件にします。
まとめ
サイボウズOfficeを定着させるには、機能を増やす前に、情報の掲載先と確認する人を決めることが出発点です。スケジュールは予定調整、掲示板は正式な周知、ワークフローは承認履歴を残す申請というように、役割を分けます。
パッケージ版を利用している場合は、販売・サポート終了のスケジュールだけで判断せず、ライセンス有効期限、利用バージョン、移行対象データ、日常業務への影響を棚卸しします。クラウド版への移行、Garoonやkintoneを含む移行先の比較、業務の再設計を選択肢として整理し、試験移行で代表業務を確認してから本番切り替えへ進めます。
運用開始後は、スケジュールと掲示板から段階的に公開し、権限の例外、差し戻し理由、二重入力の有無を定期的に見直します。利用者数だけでなく、業務が実際に新しい掲載先・申請経路へ移っているかを確認することで、定着状況を判断できます。
本記事の内容に誤り等がございましたら、こちらからご連絡ください。
監修
Admina Team
情シス業務に関するお役立ち情報をマネーフォワード Adminaが提供します。
SaaS・アカウント・デバイスの管理を自動化し、IT資産の可視化とセキュリティ統制を実現。
従業員の入退社対応や棚卸し作業の工数を削減し、情報システム部門の運用負荷を大幅に軽減します。
中小企業から大企業まで、情シス・管理部門・経営層のすべてに頼れるIT管理プラットフォームです。
