kintoneアプリ作成の設計方法｜Excelをそのまま移さない業務DBの作り方

kintoneでアプリを作成するとき、最初に悩むのは作り方です。

サンプルアプリを使うのか。

はじめから作るのか。

ExcelやCSVを読み込むのか。

既存アプリをコピーするのか。

テンプレートを使うのか。

これらは、どれも正しい選択肢です。

しかし、実務で問題になるのは、どのボタンから作るかではありません。

何を1アプリにするかです。

既存のExcelや紙帳票をそのまま1つのkintoneアプリにすると、次のような状態になりがちです。

• 顧客名、案件名、商品名が自由入力になり、表記揺れが増える
• 1レコードに最新状態、過去履歴、添付、承認メモが混ざる
• 誰が入力する項目か分からない
• 承認者だけが編集すべき項目を全員が編集できる
• 一覧が多くなり、どれを見ればよいか分からない
• 通知条件が作れず、未対応が残る
• Excelでは便利だった横持ちの列が、kintoneでは検索や集計に使いにくい
• 取引データとマスタ情報が混ざり、変更時に全レコードを直すことになる
• アプリを作った人しか意図を説明できない

kintoneアプリは、単なる表ではありません。

フォーム、レコード、一覧、グラフ、通知、アクセス権、プロセス管理、コメント、変更履歴を持つ業務の単位です。

そのため、アプリ作成で最初に決めるべきなのは、フィールド名や見た目ではありません。

そのアプリの1レコードが、業務上の何を表すのかです。

kintoneアプリ作成で最初に決めるべきなのは、作成方法ではなく、1レコードが何を表し、誰が入力し、誰が判断する業務なのかです。

この記事では、kintoneアプリ作成を、操作手順ではなく、Excelや紙業務を使い続けられる業務DBに変えるための設計として整理します。

kintoneデータベースの設計方法はこちら
kintone Excel読み込みの設計方法はこちら
kintone一覧カスタマイズの設計方法はこちら
kintoneワークフローの設計方法はこちら

アプリ作成前に業務フローを整理する

kintoneでアプリを作成する前に、今の業務フローを確認します。

見るべきなのは、入力フォームだけではありません。

誰が受け付けるのか。

誰が確認するのか。

誰が承認するのか。

どのタイミングで状態が変わるのか。

どの一覧を見て作業するのか。

どの情報を後から集計するのか。

この流れを見ないままアプリを作ると、入力はできても業務が進まないアプリになります。

確認すること	例
入力者	営業、現場、管理部、顧客、外部担当者
確認者	上長、経理、管理者、担当部署
更新タイミング	受付時、作業開始時、承認時、完了時
状態	下書き、申請中、確認中、差し戻し、完了
一覧	自分の未対応、承認待ち、期限超過、完了一覧
通知	新規登録、期限前、差し戻し、完了
権限	入力できる人、閲覧だけの人、承認できる人

たとえば、問い合わせ管理アプリを作る場合、問い合わせ本文だけを入れるアプリでは足りません。

受付日時、顧客、問い合わせ種別、担当者、対応期限、ステータス、対応履歴、完了日、再発防止メモが必要になるかもしれません。

さらに、顧客情報は顧客マスタへ分けるべきかもしれません。

対応履歴は別アプリへ分けるべきかもしれません。

添付ファイルは別の文書管理ルールが必要かもしれません。

この分割判断が、アプリ作成の品質を決めます。

Excelをそのまま移してはいけないケース

Excel読み込みは便利です。

kintone公式ヘルプでは、ExcelまたはCSV形式のファイルを読み込んで、アプリの作成と同時にファイル内のデータをインポートできると説明されています。

kintoneヘルプ：アプリを作成する方法

ただし、Excelを読み込む前に、そのExcelがアプリに向いている形か確認します。

次のようなExcelは、そのまま移すと崩れやすいです。

Excelの状態	kintoneで起きる問題
1行に複数回の履歴が横並び	履歴を検索、集計、追加しにくい
顧客情報と案件情報が同じ表	顧客名変更時に複数レコードを直すことになる
セル結合が多い	フィールド化しにくい
見出しが複数行	フィールド名とデータの境界が曖昧
色やコメントで状態を表す	ステータスや選択肢に変換する必要がある
空欄が意味を持つ	未入力なのか、対象外なのか分からない
数式で集計している	kintone側の計算、グラフ、別集計アプリを考える
担当者名が自由入力	ユーザー選択や担当者マスタに変える必要がある

Excelは、見た目と計算を1つのシートにまとめられます。

kintoneは、入力、状態管理、権限、一覧、通知、集計を分けて設計します。

そのため、Excelの1シートがkintoneの1アプリになるとは限りません。

むしろ、Excelの1シートを次のように分けることがあります。

• 顧客マスタ
• 案件管理
• 対応履歴
• 添付ファイル管理
• 集計用アプリ
• 連携ログ

Excelをkintoneへ移すときは、列をそのままフィールドにするのではなく、マスタ、取引、履歴、集計に分けてからアプリ化します。

kintone Excel読み込みの設計方法はこちら

マスタ・取引・履歴・集計に分ける

kintoneアプリ作成では、業務データを4つに分けると整理しやすくなります。

区分	1レコードの意味	例
マスタ	1社、1商品、1部門、1担当者	顧客マスタ、商品マスタ、社員マスタ
取引	1案件、1注文、1申請、1問い合わせ	案件管理、注文管理、申請管理
履歴	1回の対応、1回の作業、1回の変更	対応履歴、作業日報、連絡履歴
集計	1日、1月、1担当、1商品など	月次実績、担当別件数、部門別集計

マスタには、正式名称、コード、利用状態を持たせます。

取引には、状態、担当者、期限、金額、承認状況を持たせます。

履歴には、いつ、誰が、何をしたかを残します。

集計には、判断やレポートに使う単位を持たせます。

この分け方をせずに1つのアプリへ詰め込むと、次のように詰まります。

• 顧客名変更で過去案件まで直す必要がある
• 商品名の表記が揺れて集計できない
• 履歴を追加するたびに横に列が増える
• 最新状態と過去の経緯が混ざる
• 権限を細かく分けにくい
• 通知条件が複雑になる

kintoneには、ルックアップや関連レコード一覧など、アプリ同士をつなぐ機能があります。

kintoneルックアップの設計方法はこちら
kintone関連レコード一覧の設計方法はこちら

ただし、つなぐ前に、どのアプリが正本かを決めます。

顧客名の正本は顧客マスタ。

案件状態の正本は案件管理。

対応履歴の正本は対応履歴アプリ。

このように決めておけば、アプリが増えても迷いにくくなります。

サンプルアプリ・Excel読み込み・はじめから作成の使い分け

kintone公式ヘルプでは、アプリ作成方法として、サンプルアプリ、はじめから作成、Excel/CSV読み込み、テンプレートファイル、既存アプリの再利用、登録済みテンプレートが紹介されています。

どれを使うかは、業務の成熟度で決めます。

作成方法	向いているケース	注意点
サンプルアプリ	まず業務イメージを試したい	そのまま本番にしない
はじめから作成	業務フローと項目が整理されている	設計に時間をかける
Excel/CSV読み込み	既存データを移行したい	Excelの形を先に整える
既存アプリの再利用	同じ業務を別部署へ横展開したい	古い設定や不要項目を引き継がない
テンプレート	標準化したアプリを複数作りたい	テンプレートに含まれない運用ルールも管理する

初心者向けのチュートリアルでは、ポータルからアプリを作成し、フィールドを配置してアプリを作る流れが説明されています。

kintoneヘルプ：アプリをはじめから作成する

操作としては、フィールドを置けばアプリは作れます。

しかし、実務では次の判断が必要です。

• このアプリは本番利用か、試作用か
• 既存データを移すのか、これから入力するのか
• 似たアプリを今後も作るのか
• 権限や通知をどこまで最初に設定するのか
• 既存Excelを分割してから読み込む必要があるか

HubSpotの解説でも、kintoneアプリ作成の基本的な方法として、サンプルアプリやExcelファイルからの作成などが紹介されています。

HubSpot：kintoneアプリ作成の方法

こうした手順記事は入口として有用です。

ただし、業務で使うアプリでは、作成方法よりもアプリの責任単位を先に決めます。

フィールド・一覧・グラフの設計

アプリの形が決まったら、フィールド、一覧、グラフを設計します。

設計対象	決めること
フィールド	入力項目、選択肢、必須、初期値、重複禁止
一覧	誰が何を見るか、どの条件で絞るか
グラフ	何を集計し、誰が判断するか
コメント	レコード内で会話するか、履歴アプリへ分けるか
添付	kintoneに置くか、外部ストレージへ分けるか
変更履歴	何を後から追う必要があるか

フィールドは、入力者の視点で並べます。

管理者が見たい順番ではなく、入力者が迷わない順番です。

たとえば、申請アプリであれば、次のように分けます。

ブロック	項目例
申請内容	申請種別、目的、金額、希望日
申請者情報	申請者、部署、連絡先
承認情報	承認者、承認日、差し戻し理由
経理確認	支払予定日、会計処理、証憑
管理情報	ステータス、期限、最終更新日

一覧は、入力者、承認者、管理者で分けます。

入力者は自分の下書きや差し戻しを見ます。

承認者は承認待ちを見ます。

管理者は期限超過や集計を見ます。

kintone一覧カスタマイズの設計方法はこちら

グラフは、最初から作り込みすぎないほうがよいです。

まず、業務判断に必要な件数、金額、期限、分類を確認します。

グラフを見て次に何をするのかが決まっていない場合、ダッシュボード化しても使われません。

kintoneダッシュボードの設計方法はこちら

権限・通知・プロセス管理

kintoneアプリ作成では、フォームだけでなく、権限、通知、プロセス管理をセットで考えます。

設定	役割
アクセス権	誰がアプリ、レコード、フィールドを見られるか
通知	いつ、誰に、何を知らせるか
プロセス管理	ステータス、作業者、アクションを管理する
コメント	レコードごとの相談や確認を残す
変更履歴	誰が何を変更したか追う

たとえば、経費申請アプリなら、申請者、承認者、経理、管理者で見える項目や編集できる項目が違います。

申請者は、自分の申請を作成・修正する。

承認者は、承認や差し戻しを行う。

経理は、支払予定日や会計処理欄を更新する。

管理者は、全体を確認する。

この役割を考えずに全員編集可で始めると、後から事故が起きます。

通知も同じです。

新規登録時、承認待ち、差し戻し、期限前、期限超過、完了時で通知先が違います。

kintone通知の設計方法はこちら

プロセス管理は、状態が変わる業務に向いています。

申請中、確認中、承認済み、差し戻し、完了など、状態と担当者がある業務では、最初から検討します。

kintoneワークフローの設計方法はこちら

kintoneアプリは、フォームだけ作って終わりではありません。権限、通知、プロセス管理まで含めて初めて業務アプリになります。

作成後の改善サイクル

kintoneアプリは、作成して終わりではありません。

実際に使うと、必ず変更が出ます。

項目を追加したい。

選択肢を変えたい。

一覧を増やしたい。

通知が多すぎる。

承認ルートを変えたい。

権限を細かくしたい。

こうした改善を、場当たり的に入れるとアプリが崩れます。

作成後は、改善サイクルを決めます。

タイミング	見ること
初回利用後	入力しづらい項目、必須の過不足
2週間後	未対応一覧、通知量、担当者の迷い
1か月後	集計、権限、プロセス管理の不足
3か月後	アプリ分割、マスタ化、外部連携の必要性

改善時には、変更理由を残します。

誰の要望で、何の問題を解決するために、どの設定を変えたのか。

これを残さないと、半年後に誰も理由を説明できません。

アプリが増えてきたら、アプリ棚卸しも必要です。

• 使われているアプリ
• 似たアプリ
• 作成者不明のアプリ
• 権限が広すぎるアプリ
• 通知が止まっているアプリ
• Excel運用に戻っている業務

アプリ作成は入口です。

使われ続けるかどうかは、作成後の改善で決まります。

よくある失敗

kintoneアプリ作成では、次の失敗が起きやすいです。

Excelの列をそのままフィールドにする

Excelは見た目と集計をまとめられます。

kintoneでは、入力、一覧、権限、通知、集計を分けます。

列をそのまま移す前に、マスタ、取引、履歴へ分けます。

1アプリに全部入れる

顧客、案件、対応履歴、添付、請求、承認を1アプリに詰め込むと、後から検索や権限が難しくなります。

1レコードが何を表すかを明確にします。

自由入力が多すぎる

顧客名、商品名、担当者、ステータスを自由入力にすると、表記揺れが増えます。

選択肢、ユーザー選択、ルックアップ、マスタアプリを使います。

一覧を作らない

フォームだけ作っても、誰が何を見るか分かりません。

入力者、承認者、管理者ごとの一覧を作ります。

権限を後回しにする

最初に全員編集可で始めると、後から直すのが大変です。

閲覧者、入力者、承認者、管理者を分けます。

通知が多すぎる

登録、更新、コメント、期限前、期限超過をすべて通知すると、重要な通知が埋もれます。

通知は、次に動く人へだけ送ります。

改善履歴を残さない

変更理由が残っていないと、後から設定を戻せません。

アプリ管理者用メモや運用メモで、変更理由を残します。

実装前チェックリスト

kintoneアプリ作成を始める前に、次の項目を確認します。

確認項目	判断すること
業務目的	何の業務を、誰のためにアプリ化するのか
1レコード	1社、1案件、1申請、1履歴など何を表すか
入力者	誰がどのタイミングで入力するか
確認者	誰が確認、承認、差し戻しをするか
マスタ	顧客、商品、社員、部門を分ける必要があるか
履歴	1回ごとの対応や作業を別アプリにするか
一覧	自分の未対応、承認待ち、期限超過を作るか
グラフ	何を集計し、誰が判断するか
権限	誰が見て、誰が編集し、誰が承認するか
通知	いつ、誰に、何を知らせるか
作成方法	サンプル、Excel読み込み、はじめから作成、コピーのどれか
改善	作成後に誰が見直すか

この表が埋まると、アプリ作成方法を選びやすくなります。

すぐ試すならサンプルアプリ。

既存データを移すならExcel/CSV読み込み。

業務構造が見えているならはじめから作成。

同じ型を横展開するならコピーやテンプレート。

ただし、どの方法でも、業務設計を飛ばすと後で詰まります。

Bitlightに相談できること

Bitlightでは、kintoneアプリ作成を、操作手順ではなく、業務DBの設計として整理します。

相談できる内容は次の通りです。

• Excelや紙業務の棚卸し
• 1アプリにするもの、分けるものの整理
• マスタ、取引、履歴、集計への分割設計
• フィールド、一覧、グラフ、通知、権限の設計
• サンプルアプリ、Excel読み込み、はじめから作成の選定
• ルックアップ、関連レコード、プロセス管理の設計
• 作成後の改善サイクルと運用メモ整備

kintoneは、アプリを作りやすいツールです。

だからこそ、作る前の分け方が重要です。

kintoneアプリ作成は、Excelをkintoneへ移す作業ではなく、業務をマスタ、取引、履歴、一覧、権限、通知へ分け直す設計です。

この分け方ができれば、アプリを作った後も、入力者、承認者、管理者が同じデータを見ながら業務を進めやすくなります。