弊社（アプリスイート）が支援した AppSheet （アップシート） 導入事例の紹介です。この事例では、従業員約40名の専門・技術サービス業A社において、AppSheetを活用した案件管理アプリ、販売管理アプリの開発を行いました。クラウド会計システム「freee（フリー）」と連携できる高度な自動化を実現しましたが、現場レベルでの運用が難しく、操作ミスによる不具合が発生したため、リリース後のメンテナンスが必要になりました。
この事例では、高機能・多機能にするほど運用難易度が高くなるため、現場の運用レベルに合わせて難易度や自動化範囲を調整する必要があることが分かります。
💡この事例のポイント💡
- freeeとのAPI連携により案件発生から請求まで一気通貫管理システムを実現
- 高機能・多機能化が現場運用レベルを超え、メンテナンス負荷が増加
- 管理者目線でなく現場目線での要件定義と機能調整が重要
本ブログ記事及びサンプルデータの著作権は、当社に帰属します。AppSheetを学習する目的での個人使用を除き、無断での複製、転載、改変、翻案、公衆送信等の利用を禁止します。詳細は、ウェブサイト利用規約をご確認ください。
目次
1. 事例概要
A社は分析・調査・コンサルティングを専門とする技術サービス業で、従業員約40名の企業です。この会社では、コンサルティング事業と分析事業があり、それぞれ別々の管理手法を採用していました。
分析事業では、毎月大量の請求書を発行する必要があり、合算請求書の発行も必要でした。建設業に関する業務が多く、納品書と請求書の明細欄に工事番号を明記する必要があったため、汎用的な帳票作成サービスでは対応できず、独自様式の帳票を作成できるようにしなければなりませんでした。
クラウド会計システム「freee（フリー）」を使用して、請求データを収入取引として登録し、経費も支出取引登録して原価計算していました。コンサルティング事業では、クラウドCRMサービスで顧客管理、営業管理をしていました。
事例概要
| 項目 | 内容 |
|---|---|
| 業種 | 専門・技術サービス業（分析、調査、コンサルティング） |
| 社員数 | 約40名 |
| アプリ種別 | 案件管理、販売管理 |
| 背景 | 別のクラウド販売管理システムを試行していたが、freeeとの連携が難しく、機能や大規模データへの対応等の拡張性に不安があった。 |
| AppSheet でやりたいこと |
|
| 契約内容 | 開発委託プラン（GAS開発、外部API連携を含む） |
| 開発期間 | 5ヶ月 |
| 開発範囲 | 狭 ★★★ 広 |
| 開発難易度 | 低 ★★★★☆ 高 |
| 運用難易度 | 低 ★★★★★ 高 |
2. AppSheet を選定した理由
A社は別のクラウド販売管理システムを試行していましたが、freeeとの連携が難しいことが分かり、「AppSheetならfreeeと連携できるのではないか」ということで、アプリスイートに相談がありました。
2-1. 検討した背景
拡張性への不安
A社から相談されたのは、AppSheetで対応できるデータサイズの限界について、大容量のクラウドデータベースへの対応などについてでした。業務の拡大に伴い、扱うデータ量の増加に既存システムが対応できるかという懸念がありました。
自社独自の業務フローへの対応困難
コンサルティング案件と分析案件の管理手法が異なり、汎用システムでは、案件発生から請求データをfreeeに登録するまで、統合して一気通貫で管理できませんでした。
2-2. AppSheet 選定の決め手
freeeとの連携
弊社は、自社商品の農場管理システム「aKnow（エイノウ）」でfreee API連携開発の経験がありました。AppSheetは、AutomationからGoogle Apps Script（GAS）を呼び出すことができ、GASを経由してAPIを呼び出してfreeeと連携できます。
柔軟なカスタマイズ
複数業務（コンサルティング、分析）を統合した案件管理、販売管理システムをカスタマイズ開発することで、使用していたクラウドCRMサービス、その他サービスから乗り換えたいという要望に対応できます。
3. AppSheet でやりたかったこと
3-1. AppSheet で実現した機能
案件管理
案件発生から請求データのfreee取引登録まで、一気通貫で管理できる案件管理機能を構築しました。コンサルティング業務と分析業務で別々に管理していた案件項目を統合する一方で、ビュー（画面）はそれぞれの業務特性に合わせて分離しています。案件ステータスや請求期日の一覧表示により、プロジェクトの進捗状況を把握できるようになっています。
見積・請求管理
各案件に紐付く見積データ・請求データの作成機能に加えて、ボタンクリックによる合算請求データの生成機能を実装しました。Googleドキュメントのテンプレートを活用し、自社様式の帳票（見積書、納品書、請求書、合算請求書）をPDF出力できる仕組みを構築しています。帳票出力と同時に案件ステータスが自動更新される連動機能も組み込んでいます。
freee連携
請求データのfreee送信により収入取引データとして登録する機能を実装しました。既にfreeeに登録済みの請求データについては、AppSheet側でのデータ変更時にfreee側の取引データも連動して更新されます。さらに、案件データの変更（部門の変更、メモタグの追加変更、納品日や請求日の変更）時には、紐付く請求データとfreeeの取引データが自動で更新される仕組みになっています。取引先・品目データについても、AppSheetとfreee間での双方向同期を実現しています。
3-2. 技術的な工夫と困難だった課題
freeeの機能が増えるほど運用難易度が高くなる
A社はfreeeで部門とメモタグを使用して売上や原価計算などの集計を行っていました。当初、アプリスイートからは「集計機能はLooker Studioで行う方が安全」と提案しましたが、既存の運用を継続することを強く希望されました。このことにより、以下の問題に直面しました。
- freeeに取引登録後、部門を変更したりメモタグを追加することがある
- 操作ミスがあると、AppSheetとfreeeでデータの同期が崩れることがある
- 同期を保つには非常に慎重な操作が必要だったが、現場での手順の徹底が困難だった
結果として、運用開始後、データの不整合によるエラーが頻発し、その都度手動での修正作業が必要になりました。
運用難易度が高くなるほど、同期を保つことが難しくなる
AppSheet で外部サービスとAPI連携する際、外部サービス側の管理IDを取得してAppSheet側で保存する必要があります。その際に、操作ミスにより管理IDの保存が失敗すると、その後の全ての処理でエラーが発生します。具体的には、以下のような問題が発生しました。
- 取引先、メモタグ、取引登録の際に管理IDが空欄のままAPIを呼び出すことがある
- 必須項目（取引先）が空欄だったり、存在しないメモタグIDを指定することで、エラーが発生する
- 復旧には専門知識が必要で、現場では対応が困難だった
アプリスイートでは、この問題の原因を究明し、その後、問題の発生を防いで同期の信頼性を向上させる手法を確立しましたが、この事例では対応が間に合いませんでした。
自動化の範囲が広いほど、パフォーマンスに影響する
案件情報（ステータス、納品日、部門、メモタグ）が更新された際に、以下の処理を自動実行する設計にしていました。
- 請求書データを更新する
- 請求書明細データを更新する
- freeeに登録済みの取引データを更新する
このことにより、以下のような問題に直面することになりました。
- Automationで上記の手順を実行するとStepが数珠つなぎに増加する
- freee処理も含めるとBotの完了まで長時間を要する
- 処理中に呼び出すテーブルが増加し、アプリの動作が重くなる
自動化する範囲が広くなると、Automationで実行する処理が複雑になり、アプリのパフォーマンスに影響が出ます。この事例では、特に、案件情報（部門とメモタグ）の変更がfreeeに影響することがネックとなっていました。アプリスイートでは、その後、技術的に問題を回避できるようロジックを工夫するようにしています。しかし、この事例では、運用の複雑さが想定を超えており、ロジック変更やエラー処理の実装など、何度か改修する必要がありました。
4. 導入効果
この事例では、AppSheetでやりたかったことの基本的な機能は実現できましたが、高機能・多機能になるほど、現場の運用レベルでは使いこなすのが難しいことが分かりました。
はじめに、導入効果としては、
- 業務の一元化：コンサルティング事業と分析事業で別々に管理していた案件を、AppSheetで統合管理し、案件発生から請求データのfreee登録まで、一気通貫での管理が可能になりました。
- 汎用サービスではできない帳票作成：自社様式の見積書、納品書、請求書、合算請求書をボタンクリックでPDF出力できるようにし、建設業向けの工事番号明記などの特殊要件にも対応しました。
- freee連携：ボタンクリックで請求データをfreeeに収入取引として登録し、案件情報が修正された際に、freeeの取引データを自動で更新できるようにしました。
その一方で、以下のような運用負担が発生しました。
- 操作ミスにより、AppSheetとfreeeの同期が崩れてしまい、取引登録や案件情報の修正にともなう取引更新の際に、エラーが発生することがありました。
- 部門やメモタグのように機能を増やすほど、処理が複雑になり、エラー復旧や改修が必要になりました。
- 自動化の範囲を広げたことで、Automationの処理が重くなり、アプリの動作速度に影響が出ました。
5. 事例から得られた学び
5-1. 「できる」と「使える」の違い
技術的にアプリで「できる」ことが、必ずしも現場で「使える」とは限りません。この事例では、freeeとの高度な連携は実現できましたが、運用面で多くの課題が発生しました。
現場で本当に「使える」アプリにするためには、連携機能を必要最小限に絞ったり、双方向ではなく一方向からの連携に限定することが効果的です。機能を絞ることで安定性が向上し、エラーが発生しにくくなり、結果として現場で使いやすいアプリになります。
5-2. 手動操作を残すことの重要性
AppSheet で自動化を進めすぎると、AutomationのStepが数珠つなぎで増え、処理時間の長期化やアプリの動作が重くなるといったパフォーマンス問題が発生します。さらに、アクションを複雑に組み合わせるとBot間で競合が発生し、調整やエラー対応により多くの時間を要することになります。
完全自動化を目指すのではなく、あえて手動操作の部分を残すことで、システム全体の安定性を確保し、長期的にはエラー対応のコストを削減できます。
5-3. 管理者目線と現場目線のバランス
AppSheet の要件定義では、管理者目線と現場目線という2つの異なる視点があります。
| 項目 | 管理者目線 | 現場目線 |
|---|---|---|
| 重視すること | できるだけ多くの情報を管理・可視化したい | 入力がしやすく、使いやすい |
| アプリの特徴 | 入力項目が多く、複雑な処理や条件分岐が増える | 入力項目が少なく、多少の入力ミスがあっても大丈夫で、動作が軽い |
振り返ってみると、今回の事例は管理者目線の要件定義に偏っていました。開発過程では、フォームの入力項目が非常に多くなり、条件による項目の表示非表示制御が必要になりました。また、高度な自動化と外部サービス連携により、わずかな入力ミスでも後々大きな影響を与えるため、最初から完璧な入力が求められる、現場にとっては難易度の高いアプリになってしまいました。
この結果、高度化・多機能化が進みすぎて現場の運用レベルに合わないシステムとなり、本来の目的である業務効率化が十分に達成できませんでした。現場レベルに合わせて難易度を調整し、まず「使える」ことを確認してから段階的に機能を追加していくアプローチが重要です。
