kintone一覧カスタマイズの設計方法｜探す一覧から判断する一覧へ変える

kintoneの一覧画面は、毎日よく使われます。

問い合わせ一覧。

案件一覧。

タスク一覧。

承認待ち一覧。

期限超過一覧。

売上予定一覧。

在庫不足一覧。

こうした一覧が増えると、次のような相談が出ます。

一覧を見やすくしたい。

行に色を付けたい。

一覧にボタンを置きたい。

カード形式にしたい。

ダッシュボードのように見せたい。

標準一覧ではなく、カスタマイズビューを作りたい。

ただし、ここでいきなりJavaScriptやプラグインから考えると失敗しやすくなります。

• 一覧が多すぎて、どれを見ればよいか分からない
• 「未対応一覧」と「要対応一覧」の違いが曖昧
• 行色は付いているが、次に何をすればよいか分からない
• ボタンはあるが、押してよい条件が決まっていない
• 担当者別、期限別、ステータス別の一覧が重複している
• カスタマイズビューを作ったが、モバイルで使いにくい
• 一覧画面で大量データを取得し、表示が重くなる
• JavaScriptを直せる人がいなくなり、一覧だけが残る

一覧は、レコードを探すためだけの画面ではありません。

業務で使う一覧は、判断とアクションの画面です。

担当者が、今日やるべきレコードを見つける。

上長が、承認待ちと差し戻しを確認する。

管理者が、期限超過や異常値を見つける。

経理が、請求対象と保留対象を分ける。

営業が、次に連絡すべき顧客を判断する。

このように、一覧ごとに使う人と判断を決めることが、kintone一覧カスタマイズの出発点です。

kintone一覧カスタマイズで最初に決めるべきなのは、見た目ではなく、その一覧を見た人が何を判断し、次に何をするかです。

この記事では、kintone一覧カスタマイズを、実装方法ではなく、標準一覧、カスタマイズビュー、JavaScript、プラグインを使い分ける業務設計として整理します。

kintoneカスタマイズの設計方法はこちら
kintoneタスク管理の設計方法はこちら
kintoneプロセス管理の設計方法はこちら
kintoneダッシュボードの設計方法はこちら

一覧は判断とアクションの画面

kintoneの一覧を設計するときは、まず「何を並べるか」ではなく「何を判断するか」を決めます。

一覧の目的	見る人	判断すること	次の操作
今日の自分のタスク	担当者	今日対応すべきものは何か	詳細確認、対応開始
期限超過	管理者	遅れているものは何か	担当者確認、期限再設定
承認待ち	承認者	承認すべきものは何か	承認、差し戻し
差し戻し	申請者	修正が必要なものは何か	修正、再申請
異常値	管理者	金額、日数、件数が通常と違うものは何か	原因確認
次回連絡	営業担当	次に連絡すべき顧客は誰か	連絡、履歴更新
請求対象	経理	今月請求すべきものは何か	請求処理

一覧名も、この判断に合わせます。

「一覧1」「営業一覧」「管理者用」では、使う人が迷います。

「自分の未対応」「今日対応」「期限超過」「承認待ち」「請求対象」「差し戻し中」のように、見た瞬間に用途が分かる名前にします。

一覧を増やす前に、既存一覧を棚卸しします。

• 使われている一覧
• 似た条件の一覧
• 作成者しか意味を知らない一覧
• 古い業務名が残っている一覧
• 一時的な確認用なのに残っている一覧

一覧が多いほど、現場は探します。

使う一覧を絞り、一覧名と条件を揃えるだけで、カスタマイズなしでも使いやすくなることがあります。

標準一覧で整える項目・絞り込み・ソート

一覧カスタマイズでは、まず標準一覧で足りるかを確認します。

kintone公式ヘルプでは、レコード一覧画面で条件を指定してレコードを絞り込み、担当顧客、今月の案件、未着手タスクなどの一覧を複数用意できることが説明されています。また、絞り込み条件とソートを設定し、保存した一覧を切り替えられることも案内されています。

kintoneヘルプ：一覧に表示するレコードを絞り込む

標準一覧で最初に設計するのは、次の3つです。

設計項目	決めること
表示項目	判断に必要なフィールドだけを並べる
絞り込み	担当者、期限、ステータス、区分などで対象を絞る
ソート	期限、重要度、更新日、金額など、見る順番を決める

たとえば、タスク一覧であれば、次のように分けます。

一覧名	絞り込み	ソート
自分の未対応	担当者がログインユーザー、ステータスが未完了	期限の昇順
今日対応	期限が今日以前、ステータスが未完了	重要度、期限
期限超過	期限が昨日以前、ステータスが未完了	期限の古い順
承認待ち	ステータスが承認待ち	申請日の古い順
差し戻し	ステータスが差し戻し	更新日の新しい順

一覧に表示する項目は、できるだけ絞ります。

判断に使わない項目を並べると、横に長くなり、重要な情報が埋もれます。

一覧で見る項目と、詳細画面で確認する項目を分けます。

一覧に出す	詳細画面で見る
顧客名、案件名	長い説明文
担当者、期限、ステータス	詳細な対応履歴
金額、重要度	添付ファイル
次アクション	社内メモ全体
最終更新日	変更履歴

標準一覧でできることをJavaScriptで作る必要はありません。

絞り込み、ソート、表示項目で足りるなら、標準一覧のほうが保守しやすくなります。

kintone一覧カスタマイズは、標準一覧の表示項目、絞り込み、ソートで判断できるところまで整えてから、JavaScriptやカスタマイズビューを検討します。

なお、公式ヘルプでは、モバイル版ではアプリ管理権限の有無にかかわらず絞り込み条件を保存できないことも補足されています。

現場がスマートフォンで使う一覧は、PCで保存した一覧をどう使うか、モバイルで追加操作が必要かまで確認します。

担当者別・期限別・ステータス別の一覧設計

実務で使いやすい一覧は、担当者、期限、ステータスで分けることが多いです。

軸	代表的な一覧	使う場面
担当者	自分の未対応、担当未設定、チーム別	個人やチームの処理対象を確認する
期限	今日対応、期限超過、今週期限	優先順位を決める
ステータス	承認待ち、差し戻し、完了前	プロセスの滞留を見る
区分	重要案件、クレーム、保留	管理者が重点確認する
金額	高額案件、請求対象、異常値	経理・管理者が確認する
更新日	長期間未更新、最近更新	放置や変化を見つける

この軸を混ぜすぎると一覧が増えます。

たとえば、次のような一覧は重複しやすいです。

• 自分の未対応
• 自分の今日対応
• 自分の期限超過
• 営業部の未対応
• 営業部の期限超過
• 管理者用未対応

すべて作る前に、誰が何を見るかを決めます。

担当者は「自分の未対応」と「今日対応」を見る。

上長は「チーム期限超過」と「承認待ち」を見る。

管理者は「担当未設定」と「長期未更新」を見る。

このように役割ごとに絞ると、一覧が増えすぎません。

ステータス別一覧は、プロセス管理と合わせます。

kintoneプロセス管理の設計方法はこちら

プロセス管理のステータス名と一覧名がずれていると、利用者が迷います。

「承認待ち」というステータスなら、一覧名も「承認待ち」にします。

「確認中」「要確認」「レビュー待ち」のような似た言葉が混在している場合は、ステータス設計から見直します。

行色変更・ボタン追加・一括処理の使いどころ

標準一覧で判断しにくい場合、行色変更、ボタン追加、一括処理を検討します。

ただし、これらは目立たせるための機能ではなく、次の行動を明確にするための補助です。

カスタマイズ	向いているケース	注意点
行色変更	期限超過、重要度、異常値を見つける	色の意味を少なくする
ボタン追加	一覧から次アクションへ進む	押してよい条件を決める
一括処理	複数レコードの状態変更や出力	取り消し、権限、ログを確認する
集計表示	件数、合計、滞留を上部に出す	詳細レコードへ戻れるようにする
関連データ表示	関連アプリの状態を一覧で見る	API呼び出し過多に注意する

行色は、使いすぎると意味が薄れます。

赤は期限超過。

黄は今日対応。

青は確認待ち。

この程度に留めます。

ボタン追加は、さらに慎重に設計します。

たとえば、一覧に「完了にする」ボタンを置く場合、次を決めます。

• 誰が押せるか
• どのステータスのとき押せるか
• 押したらどの項目が更新されるか
• コメントや理由は必要か
• 間違って押したとき戻せるか
• ログは残るか

cybozu developer networkでは、レコード一覧画面にボタンを配置する方法、一覧に設定した絞り込み条件を使ったカスタマイズビューの作成、任意のカスタマイズビューだけに処理を適用する方法などが紹介されています。

cybozu developer network：一覧画面のカスタマイズ

一覧にボタンを置くと、便利になります。

一方で、誤操作のリスクも上がります。

特に一括処理は、対象条件、確認画面、処理結果、失敗時の扱いを決めます。

一覧のボタン追加は、操作を減らすためではなく、押してよい条件、更新する項目、失敗時の戻し方まで決めてから実装します。

カスタマイズビューが必要なケース

標準一覧では表形式が中心です。

カード、表計算風、集計表、ガントチャート風、ダッシュボード風の表示が必要な場合は、カスタマイズビューを検討します。

cybozu developer networkでは、カスタマイズビューについて、表形式やカレンダー形式の一覧の代わりにHTMLで自由に表示をカスタマイズできる一覧だと説明されています。また、カスタマイズビューとレコード一覧イベントを組み合わせることで、カード形式などの見た目を作れることも紹介されています。

cybozu developer network：カスタマイズビューを作成してみよう

カスタマイズビューが向いているのは、次のような場合です。

ケース	理由
カード形式で見たい	顧客、案件、求人、問い合わせなどを視覚的に把握したい
集計表を表示したい	予算と実績、担当別件数、月別金額を一覧で見たい
一覧と詳細を同時に見たい	レコード選択と詳細確認を同じ画面で行いたい
画像やファイルを見せたい	作業写真、商品画像、図面の確認が多い
操作ボタンを整理したい	次アクションを画面上にまとめたい

ただし、カスタマイズビューは自由度が高い分、保守も重くなります。

標準一覧でできる絞り込みやソートまで作り込むと、標準機能の良さを失います。

また、カスタマイズ形式の一覧を作成・編集するにはkintoneシステム管理権限が必要です。

運用中に一覧を変える人、コードを直す人、表示崩れを確認する人を決めておきます。

Ribbitの記事では、カスタムビューをHTMLとJavaScriptで構築し、標準一覧では表現しづらいUIを作る方法が解説されています。

Ribbit：カスタマイズビューでレコード一覧を見やすくする

このような実装は有用ですが、一覧の目的が曖昧なまま作ると、凝った画面なのに使われない状態になります。

カスタマイズビューを作る前に、誰が何を見て、どの操作をするかを決めます。

プラグインとJavaScriptの使い分け

一覧を変える方法は、JavaScriptだけではありません。

プラグインで足りる場合もあります。

方法	向いているケース	注意点
標準一覧	絞り込み、ソート、表示項目で判断できる	一覧名と条件を整理する
プラグイン	行色、カード表示、ガント、表計算風UIなど既製機能で足りる	製品の対応範囲、モバイル、解約時を確認する
JavaScript	一覧ボタン、条件表示、独自集計、外部リンクなど個別要件	保守担当、エラー表示、権限を設計する
カスタマイズビュー	HTML/CSSで独自レイアウトが必要	表示速度、再利用、管理権限を確認する
外部ダッシュボード	複数アプリ横断や高度な集計が必要	kintone一覧だけで抱え込まない

プラグインは、よくあるUI要件を早く導入できます。

しかし、プラグインの仕様に業務を合わせる必要があります。

JavaScriptは個別要件に合わせられますが、保守対象になります。

どちらを選ぶかは、次の観点で決めます。

• 似た要件が他部署にもあるか
• モバイルでも必要か
• データ更新を伴うか
• 権限別に動きを変えるか
• 将来の項目追加に耐えられるか
• 誰が保守するか

一覧を単なる見た目の問題として扱うと、判断を誤ります。

業務の一覧が多い会社では、一覧設計そのものが運用のルールになります。

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

モバイル表示と保守の注意点

一覧カスタマイズでは、モバイル表示と保守を必ず確認します。

現場、営業、管理者がスマートフォンで見るなら、PC向けの横長一覧はそのまま使いにくいことがあります。

観点	確認すること
モバイル表示	重要項目だけ見えるか
ボタン操作	指で押しやすいか、誤操作しにくいか
表示速度	一覧表示時にAPIを呼びすぎていないか
権限	見た目の非表示だけで守っていないか
保守	一覧条件、JavaScript、プラグイン設定を誰が管理するか
変更履歴	どの一覧をいつ変えたか残しているか
戻し方	表示崩れや処理失敗時に戻せるか

一覧画面で関連アプリの情報を取得する場合、API呼び出し回数にも注意します。

レコードごとに関連情報を取得すると、件数が増えたときに表示が重くなります。

必要な項目だけ取得する。

表示件数を絞る。

詳細確認は別画面に任せる。

集計は夜間処理や別アプリへ出す。

こうした判断が必要です。

kintone API制限の設計方法はこちら

また、一覧カスタマイズはアプリの業務変更と連動します。

ステータス名が変わる。

担当者項目が変わる。

期限フィールドが増える。

承認ルートが変わる。

アプリを分割する。

このたびに、一覧条件やJavaScriptが古くなる可能性があります。

一覧の保守担当、変更申請、レビュー、反映手順を決めておきます。

よくある失敗

kintone一覧カスタマイズでは、次の失敗が起きやすいです。

一覧を増やしすぎる

担当者ごと、部署ごと、期限ごとに細かく作ると、どれを見るべきか分からなくなります。

役割ごとに本当に見る一覧を絞ります。

一覧名が曖昧

「確認用」「管理用」「営業一覧」では、使い分けが分かりません。

「自分の未対応」「期限超過」「承認待ち」のように、判断内容を名前に入れます。

行色に意味が多すぎる

赤、青、黄、緑、紫などを使いすぎると、誰も意味を覚えません。

色は、期限超過、今日対応、確認待ちなど少数に絞ります。

ボタンの条件が曖昧

一覧にボタンを置く場合、押してよいステータス、権限、更新項目、失敗時の扱いを決めます。

ボタンを置いただけでは、業務の責任は明確になりません。

カスタマイズビューを作り込みすぎる

標準一覧で十分な内容まで独自HTMLにすると、後から直しにくくなります。

カスタマイズビューは、表形式では判断しづらい場合に絞ります。

モバイルで使えない

PCでは見やすくても、スマートフォンで横スクロールが多いと現場では使われません。

モバイルでは、重要項目と主要操作だけに絞ります。

一覧カスタマイズの仕様が残っていない

誰が何のために作った一覧か、どの条件で表示しているかが残っていないと、保守できません。

一覧名、目的、対象者、条件、保守担当を管理します。

実装前チェックリスト

kintone一覧カスタマイズを始める前に、次の項目を確認します。

確認項目	判断すること
目的	探す一覧か、判断する一覧か、操作する一覧か
利用者	担当者、上長、管理者、経理、現場の誰か
判断	未対応、期限超過、承認待ち、異常値など何を見るか
次アクション	詳細確認、承認、差し戻し、完了、連絡、出力のどれか
標準一覧	表示項目、絞り込み、ソートで足りるか
行色	色の意味が少数に絞れているか
ボタン	押してよい条件、権限、更新項目、失敗時対応があるか
カスタマイズビュー	HTML/CSSで作る必要が本当にあるか
プラグイン	既存機能で足りるか、モバイル対応はあるか
API	一覧表示時に大量取得していないか
モバイル	現場で見る項目と操作を絞れているか
保守	一覧条件、コード、プラグイン設定を誰が管理するか

この表が埋まれば、標準一覧で済むものと、カスタマイズが必要なものを切り分けられます。

Bitlightに相談できること

Bitlightでは、kintone一覧カスタマイズを、見た目の調整ではなく、業務判断と次アクションの設計として整理します。

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

• 担当者別、期限別、ステータス別の一覧設計
• 未対応、承認待ち、期限超過、異常値の条件整理
• 標準一覧で足りる範囲とカスタマイズが必要な範囲の切り分け
• 行色変更、一覧ボタン、一括処理の設計
• カスタマイズビュー、JavaScript、プラグインの選定
• モバイル利用を前提にした一覧設計
• API呼び出し、表示速度、保守担当の整理
• 一覧名、条件、用途、変更履歴の棚卸し

一覧は、kintoneで最もよく見られる画面のひとつです。

ここが整理されていないと、データは入っていても業務が進みません。

kintone一覧カスタマイズは、一覧を飾る作業ではなく、担当者が見るべきレコードを見つけ、判断し、次の操作へ進むための画面設計です。

標準一覧で整える。

必要なところだけ行色やボタンを足す。

表形式では判断しづらい場合だけカスタマイズビューを使う。

この順番で設計すれば、一覧は「探す場所」から「動く場所」に変わります。