基幹業務をkintoneの
アプリ群として構築し、
開発から保守運用まで
担った開発支援

クライアント

株式会社ライトアップ

プロジェクト

基幹システム kintone開発（基幹業務のアプリ群の開発、連携処理の開発、保守運用、追加開発）

業界

中小企業向け経営支援・AI活用支援

支援領域

kintone業務アプリケーション開発 / アプリ間の更新ルール実装 / バッチ処理・一括更新 / CSV出力・権限設計 / 仕様・機能一覧の文書化 / 監査対応書類の作成 / 保守運用（定例・軽微改修・稼働実績の報告）

期間

2021年に開発を開始。2023年に開発完了報告書を提出して保守契約へ移行し、その後も追加開発を継続（2026年時点）

開発

ラフノート株式会社（eapグループ会社）。kintone担当、エンジニア、PM・インフラの体制で、定例ミーティングとGitHubで依頼を管理

kintoneはノーコードで業務アプリを作れる一方、複数のアプリにまたがる更新ルールや、定期的に走るバッチ処理、CSVの出力項目、権限の設計は、実装と検証を伴う開発になります。ラフノートは、依頼のなかで「見た目上は軽微でも変更に作業量を要するもの」と、担当者だけで対応できる軽微な改修を切り分ける必要がありました。

もう一つの論点は、文書です。kintoneは通常のWebシステムのように画面仕様書を持たないため、監査対応で仕様書の提出を求められた際に、何をどう説明するかが問われました。ラフノートは、機能一覧、業務ルールの仕様、CSV出力項目、権限表、入力の流れをスプレッドシートとして整備し、開発を優先しながら文書を更新していきました。

1. Before支援前

   基幹業務をkintoneで管理したい

   代理店、契約条件、注文、請求・入金の業務データを、担当者が日々運用できる形でkintone上に持つ必要があった。標準機能だけでは、アプリ間の更新ルールやバッチ処理、権限設計を表現しきれない。

2. Bottleneck本質的なボトルネック

   開発と運用を切り分け、文書で説明できる状態にする

   エンジニアが稼働する開発と、担当者で対応できる軽微な改修を分けて管理する。監査対応に耐える仕様・機能一覧を、開発と並行して整備する。

3. To-Be目指す状態

   依頼を受け、確認し、実装し、保守で支える

   GitHubと定例で依頼を管理し、更新ルール・バッチ処理・CSV出力・権限をkintone上に実装。開発完了報告書を提出したうえで、稼働実績を報告しながら保守契約で運用を続ける。

案件記録（Slack上のやりとり・GitHubのIssue・提出書類）をもとに掲載用に再構成した図です。当時の納品資料そのものではありません。数値・固有名詞・設定内容は含みません。

ラフノートが担ったのは、アプリの画面を作ることだけではありません。業務データの構造化からアプリ間の更新ルール、バッチ処理、出力、権限、そして監査対応の文書と保守運用まで、基幹システムとして使い続けるために必要な範囲を担当しています。以下は、Slack上のやりとりと稼働記録で確認できた範囲です。

• 01業務アプリの構築

  代理店アプリ／代理店契約条件アプリ／商品／注文登録／請求・入金アプリ／顧客／サブスクリプションのデータ

• 02アプリ間の更新ルール

  代理店アプリ・代理店契約条件アプリの保存時に、関連する商品・注文登録・請求・入金を更新条件に応じて更新する処理／経理側の識別子を請求・入金アプリに設定する処理

• 03バッチ処理・一括更新

  顧客・代理店の自動削除などのバッチ処理と、その修正／裏側での一括更新の実行と仕様のとりまとめ／サブスクリプションデータの作成とエラー調査

• 04出力・権限

  CSV出力内容の調査と出力項目のとりまとめ／システム権限と各アプリの権限設計

• 05文書化・監査対応

  機能一覧・概要のとりまとめ／業務ルール（三ヶ月ルール）の仕様／CSV出力項目／権限表／商品の入力の流れ／開発完了報告書の作成と捺印提出

• 06進行管理・保守運用

  GitHubのIssue／Pull Requestでの依頼管理／定例ミーティングと質問表への回答／タスク単位の稼働記録と稼働実績の提出／保守契約への移行（軽微改修とエンジニア稼働の切り分け、事前連絡ルール、請求内訳の分離）

• 07追加依頼機能（2022年〜2023年）

  営業担当用の注文登録フォーム（kintone内で構築、登録時のSlack通知）／代理店権限の付与・失効と集計、振込ステータスの区分追加／顧客・代理店の自動削除／経理連携用の識別子や赤伝・修正区分の追加、会計連携用CSV出力の経理要件への対応／権限グループの整備／マスタ保存時に関連アプリを再ルックアップする自動更新／債権発生中の定義見直し、三ヶ月ルールの改訂（開発環境で先方が検証してから本番へ）／商品情報テーブルへの個数の追加

• 08追加開発（2024年〜2026年）

  請求・入金データの月次バックアップ処理／振込ステータスのチェック処理の改修（判定の優先順位と稼働日の見直し）／計上日の自動設定／会計連携用CSV出力の仕様変更（配分元と配分先が同一の場合の出力行の集約）／注文登録の一括登録用アプリと夜間バッチ処理（CSV取り込み、注文登録と顧客の同時更新、処理ステータス管理、画面からの手動実行）／いずれも概算工数の提示→承認・稟議→開発環境での確認（先方用アカウントでのテストを含む）→本番反映→先方確認の流れで実施

案件記録（Slack上のやりとり・GitHubのIssue・提出書類）をもとに掲載用に再構成した図です。当時の納品資料そのものではありません。数値・固有名詞・設定内容は含みません。

案件記録（Slack上のやりとり・GitHubのIssue・提出書類）をもとに掲載用に再構成した図です。当時の納品資料そのものではありません。数値・固有名詞・設定内容は含みません。

本プロジェクトの到達点は、業務時間の削減や件数といった数値ではなく、基幹業務のデータがkintone上のアプリ群として稼働し、開発の内容を文書と報告書で説明できる状態になったこと、そして開発と保守を切り分けた体制に移行できたことにあります。

何が変わったか

1. 支援前

   基幹業務をkintoneで持ちたい

   • 代理店、契約条件、注文、請求・入金の業務データを担当者が運用できる形にする必要
   • アプリ間の更新ルール、バッチ処理、CSV出力、権限設計が標準機能の範囲を超える
   • 監査対応に使える仕様・機能一覧がない

2. 支援後

   アプリ群と更新ルールを構築

   • 代理店・契約条件・商品・注文・請求・入金のアプリ群をkintone上に構築
   • 保存時に関連アプリを更新する処理、自動削除などのバッチ処理、一括更新を実装
   • 機能一覧、業務ルールの仕様、CSV出力項目、権限表、入力の流れを文書化

3. 成果

   開発完了報告と保守契約へ

   • 開発完了報告書を作成し、監査法人向けの仕様資料とあわせて提出
   • 軽微改修とエンジニア稼働を切り分けた保守契約に移行
   • 追加開発を見積・受注・本番移行計画・書類提出の流れで継続

• 代理店、代理店契約条件、商品、注文登録、請求・入金、顧客といった基幹業務のデータを、kintone上のアプリ群として構築した。
• 代理店アプリ・代理店契約条件アプリの保存時に、関連するアプリのデータを更新条件に応じて更新する処理を実装し、修正を重ねた。
• 顧客・代理店の自動削除などのバッチ処理、裏側での一括更新、サブスクリプションデータの作成に対応した。
• CSV出力項目、システム権限と各アプリの権限、業務ルールの仕様、商品の入力の流れを含む機能一覧をスプレッドシートとして整備し、監査対応の仕様資料として提出した。
• 営業担当用の注文登録フォーム、代理店権限の管理、顧客・代理店の自動削除、経理連携用の項目追加、三ヶ月ルールの改訂などの追加機能を、質問表と定例で仕様を確定し、開発環境で確認したうえで本番へ反映した。
• 開発完了報告書を作成・捺印して提出し、担当者による軽微改修とエンジニア稼働を切り分けた保守契約へ移行した。
• 稼働時間をタスク単位で記録し、新規開発・保守定額・保守追加の内訳で報告する運用に整えた。
• 2024年以降も、請求・入金データの月次バックアップ、振込ステータスのチェック処理の改修、計上日の自動設定、会計連携用CSV出力の仕様変更、注文登録の一括登録用アプリと夜間バッチ処理を追加開発として実施し、開発環境での先方テストや本番移行計画を経て本番へ反映した。

利用部門、利用者数、業務時間の削減、処理件数などの数値は、正確性と掲載可否の確認が取れたもののみ掲載する方針のため、本記事では掲載していません。契約条件や金額も掲載していません。

本プロジェクトは、ラフノートがeapグループに加わる（2025年12月）以前から続いた、ラフノート株式会社による開発実績です。eapグループでは、kintoneを含む業務システムの設計・開発・保守運用を、eapの事業支援と同じ体制で進めています。