kintoneガントチャートの設計方法｜タスク・人員・工程を崩さない構成

kintoneでガントチャートを使いたい、という相談は多いです。

工程表をExcelで作っている。

タスク一覧では全体の流れが見えない。

誰がいつ何をするのか分かりづらい。

予定変更が起きるたびに、日付を手で直している。

担当者や設備が重複しても、気づくのが遅い。

この状態なら、ガントチャートは有効です。

ただし、kintoneにガントチャートを追加しても、工程管理や人員配置が自動で整うわけではありません。

本当に困るのは、次のような状態です。

• 案件と工程が同じレコードに混ざっている
• 工程とタスクの粒度がバラバラになっている
• 開始日・終了日はあるが、工数や作業量がない
• 担当者を複数入れているが、責任者が分からない
• 設備、車両、会議室などの予約が人の担当欄に混ざっている
• 前工程が終わらないと始められない作業を表現できない
• ガント上で日程を動かせるが、誰が何を変えたか残らない
• 遅延理由と次工程への影響が記録されない
• 個人のカレンダー予定とkintoneの工程予定がずれる
• 専用の工程管理システムに任せるべき制約計算までkintoneで抱えている

ガントチャートは、工程管理の入口として分かりやすい画面です。

しかし、画面より先に設計すべきなのは、工程データの持ち方です。

kintoneガントチャートで最初に決めるべきなのは、どのプラグインを入れるかではなく、「案件・工程・タスク・人員・設備をどのレコード単位で分けるか」です。

この記事では、プラグインの機能比較ではなく、kintoneでガントチャートを業務システムとして使うための設計を整理します。

kintone工程管理の設計方法はこちら
kintoneタスク管理の設計方法はこちら
kintoneカレンダーの設計方法はこちら

先に結論：ガント表示より工程データの持ち方が重要

kintoneでガントチャートを使う方法は、主にプラグインやカスタムビューです。

多くのプラグインでは、開始日、終了日、担当者、進捗、グループなどをもとに、レコードを横棒で表示できます。

ドラッグ操作で日程を変更できるものもあります。

担当者別、工程別、日・週・月などの表示切り替えに対応するものもあります。

これは便利です。

ただし、ガントチャートの前提になるデータが崩れていると、画面だけきれいになっても現場判断には使えません。

まず、次の情報を分けます。

分けるもの	1レコードの意味	役割
案件・プロジェクト	1つの案件、工事、製造オーダ、社内プロジェクト	納期、顧客、優先度、責任者を持つ
工程	案件を構成する大きな段階	設計、準備、施工、検査、納品などを表す
タスク	実際に担当者が行う作業	担当、開始日、終了日、状態、完了条件を持つ
人員・設備	担当者、チーム、車両、機械、会議室	予定を割り当てる対象
稼働枠	働ける時間、使える時間、予約済み時間	重複や過負荷を判断する
依存関係	前工程、待ち条件、開始条件	どの作業が終わらないと始められないかを示す
変更履歴	1回の日程変更、担当変更	誰が、いつ、なぜ変えたかを残す
遅延理由	1つの遅延、停止、保留	原因、影響、対策を次工程に戻す
連携ログ	1回の外部連携	カレンダー、チャット、専用システムとのズレを追う

ガントチャートは、このデータを見せる画面です。

工程データの代わりではありません。

たとえば、案件レコードに「担当者」「開始日」「終了日」を置いただけでは、案件全体の期間しか見えません。

工程ごとの前後関係も、担当者の負荷も、設備の重複も分かりません。

逆に、タスクを細かくしすぎると、横棒が増えすぎて誰も見なくなります。

ガントチャートを使うなら、まず「ガントに出す粒度」と「管理上必要な粒度」を分けます。

粒度	例	ガントへの出し方
案件	A社サイト改修、B工事、C製造オーダ	親バー、グループ、絞り込み
工程	要件確認、設計、手配、作業、検査	主要バーとして表示
タスク	資料作成、部材発注、現場確認	必要に応じて展開表示
作業実績	6月9日 2時間作業、検査1回	ガントではなく実績一覧で管理
コメント・相談	チャット、メモ、確認依頼	ガントには出さず履歴に残す

ガントに何でも出すと、見える化ではなくノイズになります。

ガントに出すべきなのは、開始日・終了日・担当・前後関係を持ち、日程変更が業務に影響するものです。

kintoneガントチャートが向く業務と向かない業務

kintoneのガントチャートは、業務データと工程予定をつなげたい場合に向いています。

特に、案件、顧客、受注、問い合わせ、タスク、日報、作業実績がkintoneにある会社では、工程予定もkintone側に寄せる意味があります。

kintoneガントチャートが向く業務	理由
案件ごとの作業進行	案件、顧客、活動履歴とつなげられる
工事・施工の人員配置	現場、担当者、車両、作業日をまとめて見られる
小規模な製造・加工工程	受注、工程、作業実績、遅延理由を残しやすい
社内プロジェクト管理	タスク、担当、期限、確認者を管理しやすい
保守・点検の予定管理	顧客、機器、作業予定、報告書をつなげられる
部門横断の進行管理	担当部署、期限、状態、レビューを一覧化しやすい

一方で、次の条件が強い場合は、kintoneだけで完結させない方がよいです。

kintoneだけでは重い業務	理由
分単位の設備制御	現場設備、制御システム、MESの領域になる
複雑な山積み・山崩し	能力計算や制約条件が専用化しやすい
大規模開発のチケット管理	ブランチ、レビュー、リリース、障害管理は専用ツールが向く
個人予定の細かい調整	招待、空き時間、繰り返し予定はカレンダーが向く
数万件規模の工程表示	表示性能、絞り込み、権限設計が重くなる
原価・購買・在庫引当を含む生産計画	基幹や生産管理システムとの整合が必要になる

Ribbit's worksのガントチャートプラグインでは、kintoneのカスタムビュー上で日・週・月のスケール切り替え、ドラッグによる日程変更、担当者やカテゴリによるグループ化が紹介されています。

Ribbit's works：ガントチャートプラグイン

ペパコミのkintoneガントチャート人員配置プラグインでは、工事別・人別のガント表示、ドラッグ操作による日付・時間調整、必要人数管理、同期間の重複配置を防ぐ考え方が紹介されています。

ペパコミ：kintoneガントチャート人員配置プラグイン

これらの機能は、現場の運用に合えばかなり役に立ちます。

ただし、プラグインを選ぶ前に、自社の業務が「工程を見たい」のか、「人員配置をしたい」のか、「タスク状態を動かしたい」のかを分ける必要があります。

ガントチャートは、工程の見た目を作る道具です。人員配置、設備予約、遅延対応、承認変更まで扱うなら、表示機能より先に業務データの境界を決めます。

案件・工程・タスク・担当者を分ける

ガントチャートで最も崩れやすいのは、案件、工程、タスク、担当者を1つのアプリに詰め込む設計です。

たとえば、次のようなフィールドを1レコードに持たせたとします。

フィールド	例
案件名	A社工事
工程名	現地作業
タスク名	配線確認
担当者	田中、佐藤
開始日	2026-06-10
終了日	2026-06-12
状態	対応中

小さく始めるなら、これでも動きます。

しかし、案件が増えるとすぐに困ります。

1案件に複数工程がある。

1工程に複数タスクがある。

1タスクに主担当と補助担当がいる。

同じ担当者が別案件にも入る。

工程の開始条件が前工程の完了に依存する。

この構造を1レコードに押し込むと、日程変更、担当変更、進捗確認がすべて同じ場所で起きます。

履歴も追いづらくなります。

基本は、次のように分けます。

アプリ	1レコードの単位	主な項目
案件・プロジェクトアプリ	1案件、1工事、1製造オーダ	顧客、納期、責任者、優先度、全体状態
工程アプリ	1案件内の1工程	工程名、順序、予定開始、予定終了、前工程、担当部署
タスクアプリ	1工程内の1作業	作業名、担当者、期限、状態、完了条件
担当者・チームマスタ	1人、1チーム	所属、役割、対応可能業務、標準稼働
設備・リソースマスタ	1設備、1車両、1会議室	種別、利用可能時間、使用制限
稼働枠アプリ	1人・1設備の1期間	空き、予約済み、休み、稼働不可
変更履歴アプリ	1回の変更	変更対象、変更前、変更後、変更理由、変更者
遅延・課題アプリ	1つの遅延・課題	原因、影響範囲、対策、再開予定

この分け方にすると、ガントチャートに出すデータを制御しやすくなります。

案件ガントなら、案件と工程を中心に表示する。

タスクガントなら、工程とタスクを中心に表示する。

人員配置ガントなら、タスク、担当者、稼働枠を中心に表示する。

設備予約ガントなら、タスク、設備、予約時間を中心に表示する。

同じ「ガントチャート」でも、見る目的によって軸が変わります。

見たいもの	横軸	縦軸	主なレコード
案件全体の進行	日付	案件、工程	工程レコード
担当者の負荷	日付、時間	担当者	タスク、稼働枠
設備の予約	日付、時間	設備、車両、会議室	リソース予約
タスクの状態	日付	タスク、担当者	タスクレコード
遅延の影響	日付	工程、前後関係	工程、遅延理由

この軸を決めずにプラグインを入れると、設定項目は埋められても、現場で「結局どの画面を見ればよいのか」が曖昧になります。

開始日・終了日・工数・依存関係を設計する

ガントチャートには、開始日と終了日が必要です。

ただし、日付だけでは工程管理になりません。

日付、時間、工数、進捗、依存関係を分けて持つ必要があります。

項目	型の例	設計意図
予定開始日	日付、日時	ガント表示の開始位置
予定終了日	日付、日時	ガント表示の終了位置
実績開始日時	日時	実際に始めた時刻
実績終了日時	日時	実際に終わった時刻
予定工数	数値	必要な作業量を見積もる
実績工数	数値、集計	かかった時間を戻す
進捗率	数値、計算	表示上の進み具合
前工程	関連レコード、ルックアップ	依存関係を示す
開始条件	選択肢、テキスト	着手してよい条件を残す
遅延理由	関連レコード	日付変更の理由を記録する

ここで注意したいのは、「終了日」と「期限」は別物だということです。

終了日は、作業期間の終わりです。

期限は、いつまでに完了していなければならないかです。

たとえば、6月10日から6月12日まで作業し、6月13日午前に確認する場合、予定終了日と確認期限は異なります。

項目	例	用途
予定開始日	6月10日	ガントの開始
予定終了日	6月12日	ガントの終了
確認期限	6月13日 午前	確認者への通知
納期	6月15日	案件全体の締切

これを1つの「期限」だけで表現すると、ガントの線、担当者の作業締切、確認者の締切、顧客への納期が混ざります。

ガントチャートを使うなら、最低でも次の判断をしておきます。

判断	推奨
日単位か時間単位か	人員配置・設備予約なら日時、工程表なら日付から始める
予定と実績を分けるか	分ける。予定変更と実績遅延を混ぜない
進捗率を手入力にするか	最初は状態から計算、必要なら手入力を併用
前工程を持つか	工程管理なら持つ。単純タスク管理なら任意
親子関係を持つか	案件、工程、タスクの3階層までに抑える

依存関係は、最初から複雑にしすぎない方がよいです。

「前工程が完了したら開始できる」

「承認が終わったら着手できる」

「部材入荷後に作業できる」

この程度から始めます。

複雑な制約条件、設備能力、部材引当、段取り替えまで自動計算したいなら、kintoneのガントだけで抱えるべきではありません。

その領域は、専用の工程管理、スケジューラ、生産管理システムに任せる判断が必要です。

人員配置・設備予約・重複チェックの考え方

ガントチャートで多い用途が、人員配置です。

誰が、いつ、どの案件に入るのか。

どの設備や車両を、いつ使うのか。

ここを見たい場合、担当者欄だけでは足りません。

人員配置には、少なくとも次の情報が必要です。

項目	例	設計意図
主担当	田中	作業責任を持つ人
補助担当	佐藤、鈴木	作業に入る人
必要人数	3人	作業に必要な人数
必要スキル	電気工事、検査、設計	対応可能者を絞る
稼働可能時間	9:00-17:00	配置できる時間帯
休み・不在	有休、出張、別現場	配置不可の理由
設備・車両	車両A、検査機B	人以外の予約対象
重複可否	不可、条件付き可	同時間に割当できるか

ペパコミの人員配置プラグインでは、業務ごとの必要人数、工事別・人別表示、同じ期間に別工事へ同じ人員を配置できない考え方が紹介されています。

このような機能を使う場合も、元データ側で「誰を何に割り当てているのか」を明確にしておく必要があります。

担当者を1つのユーザー選択フィールドに詰め込むだけでは、主担当、補助担当、確認者、共有先が混ざります。

設備や車両を担当者欄に入れるのも避けた方がよいです。

人は人のマスタ。

設備は設備のマスタ。

会議室や車両はリソースのマスタ。

それぞれを分けて、割当レコードでつなぎます。

割当対象	管理方法
人	ユーザー選択、担当者マスタ、チームマスタ
車両	車両マスタ、予約レコード
機械	設備マスタ、稼働予定
会議室	リソースマスタ、予約予定
外注先	取引先マスタ、発注・依頼レコード

人員配置ガントで重要なのは、横棒を動かせることではなく、動かした結果として誰の稼働枠と何の予約が変わるのかを追えることです。

重複チェックも、最初にルールを決めます。

重複の種類	判断例
同じ担当者が同時間に複数案件へ入る	原則不可
同じ車両が同時間に複数現場へ入る	不可
同じ設備を段取り替え込みで使う	前後に余裕時間を持たせる
補助担当が短時間だけ重なる	条件付きで可
管理者が複数案件を兼務する	表示はするが警告に留める

すべてをシステムで禁止すると、現場調整が回らない場合があります。

逆に、すべて警告だけにすると、重複が常態化します。

「禁止する重複」と「警告に留める重複」を分けることが重要です。

プラグインで対応する範囲と外部カレンダーに逃がす範囲

kintoneのガントチャートは、標準機能だけで完結しないことが多いです。

ガント表示、ドラッグ操作、日・週・月の切り替え、かんばんとの切り替え、人員配置、リソース管理などは、プラグインやカスタムビューを検討します。

えんのしたのガントチャート＆かんばんボードでは、日・週・月の切り替え、ガントとかんばんの2つの視点、クイック編集、ドラッグ操作、祝日対応、進捗の自動計算などが紹介されています。

えんのした：ガントチャート＆かんばんボード

この種のプラグインは、工程やタスクの画面体験を良くします。

ただし、プラグインに任せる範囲と、kintoneアプリ側で持つ範囲は分けます。

領域	kintoneアプリで持つ	プラグインに任せる
案件・工程・タスク	レコード構造、親子関係、状態	表示、並び替え、グループ化
開始日・終了日	フィールド、入力ルール	ガントバーとして表示
担当者・設備	マスタ、割当、重複ルール	人別・設備別の表示
進捗	状態、完了条件、実績	進捗バー、色分け
変更	変更理由、承認、履歴	ドラッグ操作、クイック編集
通知	期限、遅延、重複、未確認	表示上の警告
権限	変更できる人、見られる範囲	UI上の操作制御

特に注意すべきなのは、ドラッグ操作です。

ガント上でバーを動かせると便利です。

しかし、誰でも日程を動かせると、現場は混乱します。

変更内容	その場で許可するか	理由
自分のタスクの予定日を1日動かす	条件付きで許可	影響範囲が小さい場合がある
案件全体の納期を変える	承認が必要	顧客、売上、契約に影響する
前工程より前に後工程を開始する	原則不可	依存関係が壊れる
担当者を別部署へ変更する	承認または通知が必要	負荷や責任範囲が変わる
設備予約を重複させる	原則不可	物理的に使えない
遅延理由なしで終了日を延ばす	許可しない	後から改善できない

外部カレンダーとの境界も決めます。

kintoneは、案件や工程の正本として使いやすいです。

一方で、個人の予定調整、招待、空き時間、繰り返し予定は、Google CalendarやGaroonなどの方が向く場合があります。

予定の種類	正本に向く場所	理由
案件工程	kintone	案件、顧客、タスク、実績とつながる
作業担当の割当	kintone	進捗、遅延、実績へ戻せる
個人の会議予定	外部カレンダー	招待、空き時間、繰り返しに強い
会議室予約	外部カレンダーまたはkintone	運用ルール次第
工事車両・設備予約	kintone	案件や作業実績と紐づけたい
全社会議・休暇	外部カレンダー	個人予定と連動しやすい

ガントチャート、かんばん、カレンダーは、似ていますが目的が違います。

画面	向いていること
ガントチャート	期間、前後関係、全体工程を見る
かんばん	状態、担当、次に動かすタスクを見る
カレンダー	日付、時間帯、予定の空き・重複を見る
一覧	条件で絞り、未対応や異常値を拾う
グラフ	件数、遅延、負荷、進捗率を集計する

1つの画面にすべてを期待しない方がよいです。

工程の全体像はガント。

今日やることは一覧やかんばん。

時間帯の重複はカレンダー。

遅延や負荷はグラフ。

このように役割を分けます。

変更権限・遅延通知・履歴管理

ガントチャートを業務で使うと、必ず日程変更が起きます。

問題は、日程変更そのものではありません。

変更理由、影響範囲、承認、通知が残らないことです。

日程変更には、次の種類があります。

変更	例	必要な管理
開始日の変更	着手を1日後ろ倒し	変更理由、前工程への影響
終了日の変更	作業完了が2日遅れる	次工程、納期、顧客影響
担当者の変更	田中から佐藤へ変更	負荷、責任者、通知
設備の変更	車両Aから車両Bへ変更	予約重複、利用制限
工程順の変更	検査を先に実施	開始条件、承認
案件納期の変更	顧客納期を変更	契約、見積、顧客合意

すべての変更に承認を入れると、運用が重くなります。

ただし、すべて自由にすると、ガントチャートはすぐに信用されなくなります。

現実的には、変更ルールを段階に分けます。

変更レベル	例	処理
軽微	自分のタスクを半日ずらす	履歴だけ残す
影響あり	同じ案件内で工程を1日ずらす	関係者へ通知
承認必要	案件納期、担当部署、設備予約を変更	責任者承認
禁止	前工程未完了なのに後工程を開始	変更不可、または管理者のみ

遅延通知も、通知しすぎない設計が必要です。

通知が多いと、誰も見なくなります。

通知すべきなのは、次のような状態です。

通知条件	通知先
予定開始日を過ぎても未着手	担当者、工程責任者
予定終了日を過ぎても未完了	担当者、確認者、責任者
前工程が遅れて後工程に影響	後工程担当、案件責任者
設備・人員が重複している	調整担当、工程責任者
遅延理由が未入力	担当者
案件納期に影響する遅延	営業、案件責任者、管理者

遅延理由は、自由入力だけにしない方がよいです。

集計できないからです。

遅延理由カテゴリ	例
顧客都合	仕様未確定、確認待ち、日程変更
社内都合	担当者不足、承認待ち、確認遅れ
外部要因	部材遅れ、外注遅れ、天候
品質	不具合、再作業、検査不合格
計画不備	工数見積不足、前提条件漏れ
その他	個別に記録

ガントチャートの信頼性は、予定通り進んだ線ではなく、予定が変わったときの理由・承認・通知・履歴で決まります。

よくある失敗パターン

kintoneガントチャートでよくある失敗を整理します。

1. まずプラグインを入れてしまう

ガントチャートを見たい気持ちは分かります。

ただ、プラグイン設定の前に、案件、工程、タスク、担当者、設備、稼働枠をどう分けるか決めます。

元データが曖昧なままガントを表示すると、画面だけ立派で、運用はExcel時代と変わりません。

2. すべてのタスクをガントに出す

ガントに出すべきなのは、期間と前後関係がある作業です。

「メールする」「確認する」「コメントする」のような短い作業まで出すと、横棒が増えすぎます。

短い作業は、かんばんや一覧で管理した方が見やすい場合があります。

3. 担当者欄に人も設備も入れる

担当者は人です。

設備、車両、会議室、外注先は別の管理対象です。

ここを混ぜると、重複チェックも権限管理も崩れます。

4. ドラッグ変更を誰でもできる

ガント上で日程を動かせるのは便利です。

しかし、案件納期、前後関係、担当者負荷に影響する変更まで誰でもできると、予定表が信用されなくなります。

変更できる範囲、承認が必要な範囲、禁止する変更を分けます。

5. 予定と実績を同じ日付で上書きする

予定開始日と実績開始日を同じフィールドにすると、何が予定で何が結果か分からなくなります。

遅延分析もできません。

予定、実績、変更履歴は分けます。

6. 遅延理由を残さない

ガントチャートは遅延を見つけやすい画面です。

しかし、遅延理由を残さなければ、次回の計画に活かせません。

遅れた事実だけでなく、なぜ遅れたか、どこに影響したか、どう対処したかを残します。

7. カレンダーとの役割が曖昧になる

ガントは工程の期間を見る画面です。

カレンダーは日時の予定を見る画面です。

工事やプロジェクトの工程はkintone、個人の会議予定は外部カレンダーなど、正本を分けます。

8. 大量レコードをそのまま表示する

ガントチャートは視覚的に便利ですが、すべてのレコードを一画面で表示するものではありません。

案件、担当者、期間、状態などで絞り込む前提を作ります。

見る人ごとに、必要なガントを分けることも重要です。

まず決める設計チェックリスト

kintoneでガントチャートを作る前に、最低限次の項目を決めます。

確認項目	決めること
ガントの目的	工程管理、人員配置、設備予約、タスク管理のどれか
親レコード	案件、工事、プロジェクト、製造オーダのどれか
表示単位	工程を出すか、タスクを出すか、割当を出すか
横軸	日単位か、時間単位か
縦軸	案件、工程、担当者、設備のどれで見るか
開始・終了	予定と実績を分けるか
依存関係	前工程、開始条件、承認条件を持つか
人員配置	主担当、補助担当、必要人数を分けるか
設備予約	設備や車両を人と分けて管理するか
重複チェック	禁止する重複と警告に留める重複
変更権限	誰がガント上で日程を動かせるか
履歴	日程変更、担当変更、遅延理由をどこに残すか
通知	期限超過、未着手、重複、遅延を誰に知らせるか
カレンダー連携	個人予定や会議予定をどこで管理するか
専用システム境界	自動スケジューリングや原価管理をどこまで求めるか

このチェックリストが埋まらない状態でプラグインを選ぶと、導入後に設定変更が増えます。

逆に、ここが決まっていれば、どのプラグインを選ぶべきかも判断しやすくなります。

ガント表示が必要なのか。

かんばんも必要なのか。

人員配置が主目的なのか。

設備予約が必要なのか。

ドラッグ変更を使うのか。

進捗率を表示するのか。

この判断が、設定項目ではなく業務要件として見えてきます。

Bitlightに相談できること

Bitlightでは、kintoneのガントチャート導入を、プラグイン設定だけではなく業務設計として支援できます。

たとえば、次のような整理ができます。

• 案件、工程、タスク、作業実績のアプリ分割
• ガントに表示する粒度と、一覧やかんばんに逃がす粒度の整理
• 担当者、設備、車両、会議室などのリソース設計
• 主担当、補助担当、確認者、関係者の分離
• 開始日、終了日、期限、納期、確認期限の項目設計
• 予定と実績、変更履歴、遅延理由の分離
• ドラッグ変更を許す範囲と承認が必要な範囲の整理
• 期限超過、重複、遅延、未着手の通知設計
• Google CalendarやGaroon、専用工程管理システムとの役割分担
• 既存Excel工程表からkintoneへ移すときの段階設計

ガントチャートは、入れるだけなら早いです。

しかし、現場で使い続けるには、元データ、変更ルール、通知、権限、外部連携まで決める必要があります。

特に、人員配置や設備予約まで扱う場合は、最初の設計を間違えると後から直すのが重くなります。

kintoneガントチャートは、線を引くためではなく、工程・人員・設備・遅延対応を同じ業務データとして扱うために設計します。

「今の工程表をkintoneに移したい」

「ガントチャートプラグインを入れたが、運用が定着しない」

「人員配置や設備予約まで含めて設計したい」

この段階なら、先にアプリ構成と変更ルールを整理した方がよいです。

画面を作る前に、どのデータを正本にするかを決める。

そこから、ガントチャート、かんばん、カレンダー、一覧、通知を組み合わせる。

その順番で設計すると、kintoneのガントチャートは単なる見える化ではなく、現場の判断に使える進行管理になります。