脱Excelの進め方：kintone・AppSheetなど移行先の選び方

「脱Excel」は、Excelをすべてやめることではありません。業務の記録をどこで正本として持つか、誰が入力・更新・承認するかを整理し、問題が起きている部分を仕組みに移すことです。集計や分析はExcelに残し、登録・承認・正本だけを別の仕組みに移す併用も、有効な選択肢です。

見直す時期は、データの件数や利用人数だけでは決まりません。件数が少なくても、次のような困り事が続いているなら、運用か仕組みのどちらかを変える時期です。

• 二重入力・転記：同じ内容を、メール、Excel、別のシステムへ何度も入力している。
• 最新版が分からない：ファイルのコピーが増え、どれが正しいかの確認に時間がかかる。
• 担当者しか分からない：数式やマクロ、ファイルの置き場所を、一人だけが把握している。
• 権限を分けられない：閲覧だけでよい人も、全体を変更できてしまう。
• 数式や集計が壊れる：行の追加やコピーで、集計の範囲や数式がずれる。
• 同時に更新できない：複数の人が同じデータを更新し、上書きや入力の衝突が起きる。
• 承認の履歴が残らない：誰がいつ承認・変更したかを、後から確かめられない。

一方で、一人で使う集計表や、問題が起きていない分析まで無理に移す必要はありません。入力の様式をそろえる、正本のファイルと更新する人を決める、変更の手順を残すといった運用の改善で足りる場合もあります。どこまで移すかは、次の要件を整理してから判断します。

方式を比べる前に、業務の要件を書き出します。次の表は、社内で記入するための整理票です。記入例は、メールとExcelで管理している備品申請を想定した説明用の例で、実際の導入事例ではありません。

最初からすべての欄を埋める必要はありません。分からない項目は空欄にせず「未確認」と書き、誰がいつまでに確認するかを決めておくと、方式の比較や見積もりの依頼で前提がそろいます。業務の流れや、判断・例外の洗い出し方は、POA（プロセス指向アプローチ）の解説で詳しく扱っています。

要件を整理したら、移行先を比べます。SaaSはクラウドでサービスを提供する形を指す言葉で、kintone・AppSheet・Power Appsもクラウドで使うサービスです。そこで次の表は、技術の分類ではなく、「業務を既製の機能に合わせる」「基盤の上に業務アプリを作る」「処理を補助・自動化する」「個別に開発する」という選び方の違いで分けています。優劣の順位ではなく、業務のどの部分をどの方式に任せるかを考えるための表で、1つの業務で複数の方式を組み合わせることもあります。

kintone・AppSheet・Power Appsは、いずれも業務アプリを作る基盤です。kintoneは、データの管理、申請・承認などのプロセス管理、アクセス権、コメント、変更履歴などを組み合わせて業務アプリを構成します（kintoneの基本機能）。プロセス管理を使う場合は、設定の前に、業務の状態・担当者・操作を図にして整理しておくと進めやすくなります（プロセス管理の設計）。AppSheetは、Google Workspaceや既存の台帳などのデータを使ってアプリを作る基盤です。Power Appsは、SharePoint、Microsoft 365、Dataverseなどのデータとつないで業務アプリを作る基盤です（Power Appsとは）。

どれを選ぶかは、会社の規模や「承認向き・入力向き」といった単純な区別では決まりません。必要なデータの置き場所と接続、社外を含む利用者の範囲、権限と承認の流れ、他のシステムとの連携、契約、アプリを管理・変更できる体制を比べます。Microsoft 365やGoogle Workspaceを使っていることは候補を絞る手がかりになりますが、それだけでは決めません。また、画面を作れることと、データへの権限、自動の処理、業務全体の受入の条件を満たせることは、分けて確認します。

Microsoft 365を使っている場合、共有の台帳や進み具合の管理であれば、Microsoft Listsで足りるかを先に確認します。Listsはデータを共有・管理する仕組み、Power Appsは入力や操作の画面を作る仕組み、Power Automateは通知や承認などの処理をつなぐ仕組みです。Listsの標準の画面やルールで足りるなら、アプリやフローを加える必要はありません。足りない画面や処理がある場合に、Power AppsやPower Automateを加えるかを要件から判断します。ListsのデータはSharePointに保存され、SharePointの権限が適用されます（Microsoft Listsの概要）。ExcelのデータをListsに取り込めても、数式・マクロ（VBA）・権限・承認・関連するデータを含めた業務全体がそのまま移るわけではありません。必要な契約、SharePoint側の権限、フローの所有者と引継ぎを確認します。

AppSheetとGASは役割が異なります。AppSheetは、データを入力・参照・承認するアプリの画面を作る仕組みです。GAS（Google Apps Script）は、スプレッドシートやメール、カレンダーなどのGoogleのサービスを操作するスクリプトを書く仕組みで、集計や通知などの補助・自動化に向きます。入力と承認はAppSheet、定期的な集計や通知はGASのように、併用することもできます。Microsoft 365の環境では、Power Automateが同じように自動化の候補になります。なお、GASはExcelのマクロ（VBA）をそのまま実行できるものではありません。Excelのファイルをスプレッドシートなどへ移す場合も、数式・マクロ・書式・共有の設定がすべて引き継がれるとは限らないため、移す前に確認します。

既存のSaaSどうしをつなぐ定型的な連携だけが目的なら、連携サービスで足りる場合もあります。連携の進め方は、ZapierとMakeによる業務自動化で扱っています。

複数の人が同時に使う業務では、同じデータを同時に変更したときの扱いを確認します。たとえばAppSheetの公式ヘルプは、変更の単位は1行で、ほぼ同時に同じ行が変更された場合は後の変更が残ると説明しています（複数ユーザーとの同時使用）。これは行ごとの扱いの説明で、在庫の引当や複数の行にまたがる更新など、業務全体の整合性を保証するものではありません。kintone、Power Apps、Pleasanterなど、他の基盤を使う場合も、同時の更新や在庫の予約、複数のデータにまたがる処理の扱いは確認が必要です。在庫の二重引当や、同じ請求の二重処理が問題になる業務では、それを防ぐことを受入の条件として決め、候補の方式で満たせるかを確かめます。データベースやAPI、アプリどうしの連携を使えるというだけで、この条件が満たされるわけではありません。

GASには、1回の実行時間や1日の利用量などの上限があり、上限を超えるとスクリプトの実行は止まります。上限はアカウントの種類によって異なり、変更されることもあるため、公式の割り当ての一覧で確認します。また、時刻やファイルの編集をきっかけに動く「インストール可能なトリガー」は、トリガーを作成した人のアカウントで実行されます（インストール可能なトリガー）。作成者の異動や退職、権限の変更で処理が止まらないよう、どのアカウントで動かし、誰が引き継ぐかを決めておきます。

Pleasanter（プリザンター）は、台帳や進み具合の管理などの業務アプリを、ノーコード・ローコードで構成できる候補です。無償で使えるオープンソースのCommunity Edition、年間サポートの契約で使える機能を拡張したEnterprise Edition、サーバーを用意せずに使えるクラウド版（Pleasanter.net）があります（Pleasanterの公式サイト）。ダウンロードして自社で管理する環境に置くか、クラウド版を契約するかで、自社が担う責任と費用の分け方が変わります。

• 自社で管理する環境に置く場合：サーバー、データベース、認証、更新、監視、バックアップと復元、障害時の対応を、誰が担うかを決める。
• クラウド版を使う場合：必要なプラン、利用者の数、使う機能、データの保管場所、提供側が担う運用の範囲、データを出力する方法を確認する。自社でサーバーを構築する必要はない。
• 費用：ソフトウェアを無償で使える条件と、構築・移行・基盤・保守の費用、有償の機能やサポートの費用を分けて比べる。無償の版を使っても、運用にかかる費用がなくなるわけではない。
• 要件：独自の業務ルール、権限、同時の更新、連携、履歴などは、採用する版と構成で必要な条件を満たすかを確認する。

整理票と比較表を使って、3つの業務で候補を絞り込む例を示します。いずれも説明用の記入例で、実際の導入事例や、特定の製品を採用すべきという結論ではありません。

備品申請の例で、整理票から判断までの流れをたどります。整理票では、正本を申請の台帳とし、申請者・承認者・総務で見られる範囲を分け、承認後に数量を変えたら再承認とする、と書きました。この要件は、申請・承認の機能を持つ業務専用SaaSの設定で満たせる可能性があります。kintone・AppSheet・Power Appsなどの業務アプリ基盤で申請の画面と承認の流れを作る方法も候補になります。候補は既存の環境で絞り込めます。たとえばMicrosoft 365を使っているなら、まずListsの台帳と標準の機能で足りるかを確認し、足りない画面や処理だけをPower AppsやPower Automateで補うかを検討します。一方で、社外の人も申請するか、ライセンスが必要な利用者は誰か、承認の流れを変えたときに設定で対応できるかは、まだ確認していません。これらを確かめてから、SaaSの設定で足りるか、業務アプリを作るかを決めます。月次の集計は、引き続きExcelで行えます。

受注と在庫の例では、AppSheetを一律に候補から外したり、Webアプリなら解決すると決めたりはしません。予約・取消・同時の処理について受入の条件を決め、候補ごとに満たせるかを確認してから選びます。

費用は、方式ごとに対象の業務、利用人数、利用量、期間、税の扱いをそろえて比べます。月額の利用料だけで比べると、移行や保守、社内の作業にかかる費用が抜け落ちます。

• 初期：要件の整理、データの整理と移行、構築・設定、連携の設定、利用者への説明。
• 継続：利用者数に応じた契約、追加の機能、連携するサービスの利用料。
• 運用：保守と問い合わせへの対応、設定・仕様の変更、社内の確認や教育の時間、解約するときのデータの出力と移行。

まだ金額を確認できていない費用は、0円として扱いません。確認できた金額は小計として記録し、必要な費用に未確認のものが残っているうちは、どの方式が安いかの判断を保留します。

製品ごとに、契約で確認する点も異なります。

• kintone：必要なコース、コースごとの最低契約ユーザー数、社外の人をゲストとして招待する場合の契約、プラグインや連携サービスの費用を確認します。コースによって、外部サービスとの連携やプラグインなどの拡張機能を使えるかが異なります（kintoneの料金）。公式の「初期費用無料」は製品の契約についての説明で、アプリの設定やデータの整備、移行、保守の費用が不要という意味ではありません。
• AppSheet：Google Workspaceの有料エディションの多くには、組織で所有権を証明したドメインのユーザー向けに、AppSheet Coreのライセンスが含まれます（サブスクリプションの選び方）。ただし、必要な機能によっては上位のプランが必要です。利用に必要な資格は、作成者の契約や利用者、必要な機能によって異なります。組織外の利用者も含め、必要なライセンスと、AppSheet User Passを使える条件を確認してください（組織向けライセンス）。アプリの試作中は、基本的な機能を使って10人までの利用者で無償でテストできますが（AppSheetの料金）、本番の運用を無償で続けられるという意味ではありません。
• Power Apps・Power Automate：一部のMicrosoft 365のライセンスには、Microsoft 365のデータと標準のコネクタを使う範囲で、Power AppsとPower Automateの利用権が含まれます（Power Platformのライセンスの概要）。プレミアムのコネクタやDataverseなどを使う場合は、別のライセンスが必要になることがあります（Power Automateのライセンスの種類）。利用者、つなぐデータ、Dataverseが必要か、フローの対象と実行者を整理してから、必要な利用権を確認します。
• Pleasanter：ライセンス、有償の機能やサポート、クラウド版の契約と、自社で管理する場合の基盤・設定・更新・保守の費用を分けます。確認する点は、前の「Pleasanterを検討する場合」で扱っています。
• GAS：一律に0円とはせず、構築・保守の作業と、連携するサービスの費用を含めて比べます。

提案や見積もりを受けた後の比べ方は、システムの見積もり・ベンダー提案の比較方法で扱っています。Malakeの参考料金は、システム・アプリ開発のページに掲載しています。

移行は、業務全体を一度に切り替えず、対象を小さく分けて進めます。次の手順は、導入を進めるときに確認する流れです。

1. 対象と正本を決める：移す業務の範囲とExcelに残す範囲、切り替えた後の正本を決める。
2. データを整理し、方式を比べる：ID、重複、表記の揺れ、利用の権限を整理し、方式の候補を比べる。
3. 受入の条件を決める：代表的な入力・承認・取消の操作と、失敗したときや同時に変更したときに期待する結果を決める。
4. 試作で確かめる：利用を許可したデータと範囲で試作し、受入の条件を満たすかを確認する。
5. 移行したデータを照合する：件数だけでなく、項目の値、関連するデータ、金額、権限、必要な履歴が合っているかを確認する。
6. 切り替えて引き継ぐ：書き込む先を新しい仕組みに一本化し、問題があったときに戻す条件、管理者、変更の手順、障害時の代わりの手段を引き継ぐ。

並行して運用する期間に、Excelと新しい仕組みの両方へ自由に書き込めるようにすると、どちらが正しいか分からなくなります。並行期間中も、正本と書き込む先を決めておきます。切り替えた後も、古いファイルやアカウントをすぐに削除せず、保存する期間と場所、閲覧できる人を決めてから整理します。

着手する前に、次の項目を確認します。すべてに印が付いても、移行がうまくいくことを保証するものではありません。確認できていない項目を、誰がいつまでに確かめるかを決めるために使います。