プロジェクト概要
- Client｜クライアント
- 株式会社ライトアップ
- Project｜プロジェクト
- 基幹システム kintone開発（基幹業務のアプリ群の開発、連携処理の開発、保守運用、追加開発）
- Industry｜業界
- 中小企業向け経営支援・AI活用支援
- Service｜支援領域
- kintone業務アプリケーション開発 / アプリ間の更新ルール実装 / バッチ処理・一括更新 / CSV出力・権限設計 / 仕様・機能一覧の文書化 / 監査対応書類の作成 / 保守運用（定例・軽微改修・稼働実績の報告）
- Period｜期間
- 2021年に開発を開始。2023年に開発完了報告書を提出して保守契約へ移行し、その後も追加開発を継続（2026年時点）
- Team｜開発
- ラフノート株式会社（eapグループ会社）。kintone担当、エンジニア、PM・インフラの体制で、定例ミーティングとGitHubで依頼を管理
代理店、契約条件、注文、請求・入金といった基幹業務のデータを、担当者が日々運用できる形でkintone上に持つ必要があった。構築対象には、保存時に関連アプリを更新するルール、定期的な自動削除などのバッチ処理、CSV出力、アプリ別の権限設計が含まれた。
依頼をGitHubのIssueに起こし、定例ミーティングで優先順位と仕様を確認しながら実装。アプリ間の更新条件やバッチ処理はPull Requestとして開発し、監査対応に必要な機能一覧、ルール仕様、CSV出力項目、権限表を文書として整備した。
基幹業務のアプリ群と更新ルール、バッチ処理、CSV出力、権限設計をkintone上に構築し、開発完了報告書を提出。以降は、担当者が対応する軽微な改修と、事前に連絡・見積を行うエンジニア稼働を切り分けた保守契約のもとで運用を続け、注文登録の一括登録など追加開発も見積・受注・本番移行計画・書類提出の流れで実施した。
中小企業の経営・業務改善を支援する会社の基幹業務を、kintoneの上に。開発から保守まで、ひとつの体制で続けた。
ライトアップ様は、中小企業向けの経営支援やAI活用支援を行う企業です。ラフノートは、同社が販売パートナー経由で提供するSaaSの開発・保守運用も担っており、その関係のなかで、社内の基幹業務をkintoneで構築する開発を2021年から担当しました。
開発の対象は、代理店、代理店との契約条件、商品、注文登録、請求・入金といった業務データです。kintoneの標準機能で管理できる範囲に加え、保存時に関連するアプリのデータを更新するルール、顧客・代理店の自動削除などのバッチ処理、裏側での一括更新、CSV出力、システム権限と各アプリの権限設計が求められました。
開発は、事業側の担当者からの依頼をGitHubのIssueに起こし、定例ミーティングで確認しながら進める形で継続しました。途中、ライトアップ様の監査対応として仕様書や開発完了報告書の提出が必要になり、ラフノートは機能一覧などの文書を整備して提出しています。2023年に開発完了報告書を提出したのち保守契約へ移行し、2024年以降も既存処理の改修や追加開発を、見積・受注・開発・本番移行・書類提出の流れで続けています。
見た目は軽微でも、kintoneの改修は作業量を要する。運用と開発を分けて回せる形が必要だった。
kintoneはノーコードで業務アプリを作れる一方、複数のアプリにまたがる更新ルールや、定期的に走るバッチ処理、CSVの出力項目、権限の設計は、実装と検証を伴う開発になります。ラフノートは、依頼のなかで「見た目上は軽微でも変更に作業量を要するもの」と、担当者だけで対応できる軽微な改修を切り分ける必要がありました。
もう一つの論点は、文書です。kintoneは通常のWebシステムのように画面仕様書を持たないため、監査対応で仕様書の提出を求められた際に、何をどう説明するかが問われました。ラフノートは、機能一覧、業務ルールの仕様、CSV出力項目、権限表、入力の流れをスプレッドシートとして整備し、開発を優先しながら文書を更新していきました。
読みどころ：相談から保守・追加開発までの7工程と、各工程で残した成果物。フェーズを分け、開発環境で確認してから本番へ移す流れが、初期開発でも追加開発でも繰り返されています。下段は確認と反映に使った環境の関係です。
案件記録（Slack上のやりとり・GitHubのIssue・提出書類）をもとに掲載用に再構成した図です。当時の納品資料そのものではありません。数値・固有名詞・設定内容は含みません。
依頼をIssueに起こし、定例で確認し、実装と文書を並行して進める。
ラフノートは、事業側の担当者からの依頼をGitHubのIssueとして起こし、定例ミーティングで優先順位と仕様を確認しながら実装を進めました。アプリ間の更新ルールやバッチ処理はPull Requestとして開発し、修正のたびに更新条件を記録しています。
開発の後半では、監査対応として求められた仕様書と開発完了報告書を作成し、機能一覧、ルール仕様、CSV出力項目、権限表を整備しました。開発完了報告書の提出後は、担当者が対応する軽微な改修とエンジニア稼働を分けた保守契約に移行し、稼働実績を請求項目別に集計して報告する形へ整えています。
読みどころ：ライトアップ様、ラフノートのkintone担当、エンジニア、PM・インフラの4者が、依頼から完了共有までのどの工程を担ったか。濃紺がその工程の主担当です。
案件記録（Slack上のやりとり・GitHubのIssue・提出書類）をもとに掲載用に再構成した図です。当時の納品資料そのものではありません。数値・固有名詞・設定内容は含みません。
業務アプリの構築、更新ルール、バッチ処理、CSV出力、権限設計、文書化、保守まで。
ラフノートが担ったのは、アプリの画面を作ることだけではありません。業務データの構造化からアプリ間の更新ルール、バッチ処理、出力、権限、そして監査対応の文書と保守運用まで、基幹システムとして使い続けるために必要な範囲を担当しています。以下は、Slack上のやりとりと稼働記録で確認できた範囲です。
読みどころ：追加開発の「注文登録の一括登録」を例に、業務上の要望がkintoneの制約と照合されてどう仕様になり、何が実装されたか。下段は初期開発の「注文から請求・入金データを作る」の対応づけです。
案件記録（Slack上のやりとり・GitHubのIssue・提出書類）をもとに掲載用に再構成した図です。当時の納品資料そのものではありません。数値・固有名詞・設定内容は含みません。
読みどころ：追加開発の本番移行を例に、開発環境での確認結果を移行計画にまとめ、コードレビューと立会いを経て本番へ反映し、先方確認と書類提出まで進めた流れ。下段は初期開発（2021年）の確認と反映の流れです。
案件記録（Slack上のやりとり・GitHubのIssue・提出書類）をもとに掲載用に再構成した図です。当時の納品資料そのものではありません。数値・固有名詞・設定内容は含みません。
2021年の開発開始から、追加開発、監査対応の文書化、保守契約への移行、追加開発の継続へ。
開発は一度に完成させる形ではなく、基幹業務のアプリ群を構築したのち、依頼に応じて機能を追加し、文書を整え、保守へ移行するという流れで進みました。
読みどころ：保守契約で担当が動く範囲とエンジニアが動く範囲をどう分けたか、運用開始後に届いた不具合・相談・要望が、調査と影響確認を経てどう判断され、何が反映されたか。提案だけで完了した対応も分けています。
案件記録（Slack上のやりとり・GitHubのIssue・提出書類）をもとに掲載用に再構成した図です。当時の納品資料そのものではありません。数値・固有名詞・設定内容は含みません。
基幹業務のアプリ群が稼働し、開発完了報告と文書を備えたうえで、保守契約のもとで運用が続いた。
本プロジェクトの到達点は、業務時間の削減や件数といった数値ではなく、基幹業務のデータがkintone上のアプリ群として稼働し、開発の内容を文書と報告書で説明できる状態になったこと、そして開発と保守を切り分けた体制に移行できたことにあります。
- 代理店、契約条件、注文、請求・入金の業務データを担当者が運用できる形にする必要
- アプリ間の更新ルール、バッチ処理、CSV出力、権限設計が標準機能の範囲を超える
- 監査対応に使える仕様・機能一覧がない
- 代理店・契約条件・商品・注文・請求・入金のアプリ群をkintone上に構築
- 保存時に関連アプリを更新する処理、自動削除などのバッチ処理、一括更新を実装
- 機能一覧、業務ルールの仕様、CSV出力項目、権限表、入力の流れを文書化
- 開発完了報告書を作成し、監査法人向けの仕様資料とあわせて提出
- 軽微改修とエンジニア稼働を切り分けた保守契約に移行
- 追加開発を見積・受注・本番移行計画・書類提出の流れで継続
- 代理店、代理店契約条件、商品、注文登録、請求・入金、顧客といった基幹業務のデータを、kintone上のアプリ群として構築した。
- 代理店アプリ・代理店契約条件アプリの保存時に、関連するアプリのデータを更新条件に応じて更新する処理を実装し、修正を重ねた。
- 顧客・代理店の自動削除などのバッチ処理、裏側での一括更新、サブスクリプションデータの作成に対応した。
- CSV出力項目、システム権限と各アプリの権限、業務ルールの仕様、商品の入力の流れを含む機能一覧をスプレッドシートとして整備し、監査対応の仕様資料として提出した。
- 営業担当用の注文登録フォーム、代理店権限の管理、顧客・代理店の自動削除、経理連携用の項目追加、三ヶ月ルールの改訂などの追加機能を、質問表と定例で仕様を確定し、開発環境で確認したうえで本番へ反映した。
- 開発完了報告書を作成・捺印して提出し、担当者による軽微改修とエンジニア稼働を切り分けた保守契約へ移行した。
- 稼働時間をタスク単位で記録し、新規開発・保守定額・保守追加の内訳で報告する運用に整えた。
- 2024年以降も、請求・入金データの月次バックアップ、振込ステータスのチェック処理の改修、計上日の自動設定、会計連携用CSV出力の仕様変更、注文登録の一括登録用アプリと夜間バッチ処理を追加開発として実施し、開発環境での先方テストや本番移行計画を経て本番へ反映した。
利用部門、利用者数、業務時間の削減、処理件数などの数値は、正確性と掲載可否の確認が取れたもののみ掲載する方針のため、本記事では掲載していません。契約条件や金額も掲載していません。
本プロジェクトは、ラフノートがeapグループに加わる（2025年12月）以前から続いた、ラフノート株式会社による開発実績です。eapグループでは、kintoneを含む業務システムの設計・開発・保守運用を、eapの事業支援と同じ体制で進めています。
担当者の声
「業務で実際に使うシステムだからこそ、必要な機能を形にすることに加え、運用の中で出てくる確認事項や変更にも対応していただけることを重視しています。」
今回のkintone開発では、ラフノートの皆さんと業務上の要望や仕様を確認しながら、開発を進めてきました。実際の運用を踏まえて相談し、必要な対応を一緒に検討できる点を心強く感じています。