kintoneタスク管理の設計方法｜依頼・期限・担当・レビューが流れない構成

kintoneでタスク管理を作るとき、最初に作りたくなるのはToDo一覧です。

タスク名、担当者、期限、ステータス、優先度、メモ。

この程度のアプリなら、すぐに作れます。

ただし、チームで使うタスク管理にするなら、ToDo一覧だけでは足りません。

タスク管理で本当に困るのは、タスクを登録できないことではなく、次のような状態です。

• 誰からの依頼か分からない
• 何をすれば完了なのか決まっていない
• 担当者が空欄、または複数人になって責任が曖昧になる
• 期限はあるが、レビューや確認の期限が別にない
• 案件、問い合わせ、日報、プロジェクトとつながらない
• ステータスが「対応中」のまま放置される
• 通知が多すぎて、期限超過や未対応が埋もれる
• かんばんやガントを入れたが、元のタスク設計が崩れている

kintoneでタスク管理を作るなら、最初に設計すべきなのは「タスク管理アプリ」ではありません。

依頼元、担当、期限、状態、完了条件、レビュー、関連案件、通知をどう分けるかです。

kintoneタスク管理で最初に決めるべきなのは、ステータス名ではなく、「どこから発生したタスクで、何をもって完了とするか」です。

この記事では、ToDo一覧の作り方ではなく、kintoneでタスク管理を崩れにくい業務システムとして設計する方法を整理します。

kintone案件管理の設計方法はこちら
Excelからkintoneへ移行する考え方はこちら

先に結論：タスク管理はToDo一覧だけで作らない

kintoneでタスク管理を作るとき、タスクアプリ1つだけでも始めることはできます。

ただし、業務で使うなら、最初から次の情報を分けて考えます。

分けるもの	1レコードの意味	役割
依頼元	案件、問い合わせ、日報、会議、プロジェクト	タスクがなぜ発生したかを示す
タスク	1つの作業	担当、期限、状態、優先度を持つ
完了条件	そのタスクが終わった基準	成果物、確認項目、完了定義を明確にする
レビュー	1回の確認、差し戻し	完了前の確認、承認、再対応を残す
作業履歴	1回の対応メモ	何をしたか、なぜ遅れたかを残す
一覧・通知	見るべき状態	期限超過、未担当、滞留、レビュー待ちを拾う
連携ログ	1回の外部連携	Slack、Teams、カレンダー、開発チケット連携の成否を追う

タスクアプリは、作業の中心です。

ただし、タスクアプリにすべてを書き込む場所ではありません。

案件から発生したタスクは案件とつなぐ。

問い合わせから発生したタスクは問い合わせとつなぐ。

会議で決まった宿題は議事録や活動履歴とつなぐ。

レビューが必要なタスクは、確認者と完了条件を持たせる。

この分け方にすると、タスクの現在状態だけでなく、なぜ発生し、誰が確認し、何が終われば完了なのかまで追えます。

kintone公式のプロジェクト・タスク管理用途ページでも、担当者、スケジュール、プロセス管理、リマインド通知、グラフなどを使って進捗を見える化する使い方が紹介されています。

kintone公式：プロジェクト・タスク管理にkintone

重要なのは、この機能を「タスク一覧」ではなく、依頼から完了確認までの業務設計として使うことです。

kintoneタスク管理が向く業務と向かない業務

kintoneは、すべてのタスク管理ツールを置き換えるものではありません。

向いているのは、タスクを案件、顧客、問い合わせ、日報、申請、プロジェクトなどの業務データとつなげたい場合です。

kintoneに向くタスク管理	理由
案件に紐づく営業タスク	顧客、案件、活動履歴とつなぎやすい
問い合わせ後の社内対応	受付、対応、確認、解決を追える
日報や会議から出る宿題	発生元を残し、担当と期限を決められる
部署横断の依頼管理	依頼者、対応者、確認者を分けられる
承認やレビューが必要な作業	プロセス管理で確認・差し戻しを扱いやすい
定型業務の進捗管理	一覧、通知、期限、担当偏りを見られる

一方で、次の条件が強い場合は、専用ツールと分けた方がよいです。

kintoneだけでは重いタスク管理	理由
開発チケット管理	ブランチ、PR、リリース、障害管理はBacklogやJira等が向く
個人の軽いToDo	kintoneアプリ化すると入力が重くなる
カレンダー中心の時間管理	予定、空き時間、繰り返し予定はカレンダーが向く
チャット上で即時に流れる軽作業	SlackやTeamsのスレッドで足りる場合がある
大規模プロジェクトの工程管理	ガント、依存関係、工数、ベースライン管理が重くなる

ここで無理に「全部kintoneでやる」と決めない方がよいです。

kintoneは、業務データとタスクをつなげるには強いです。

ただし、個人のメモ、開発チケット、予定表、チャットの短いやり取りまで抱え込むと、タスク管理が重くなります。

kintoneをタスクの正本にするのか、案件や問い合わせから発生する業務タスクの管理場所にするのかを先に分ける ことが重要です。

タスク・依頼元・案件を分ける

タスク管理で最初に決めるべきなのは、タスク名ではありません。

そのタスクが、どこから発生したかです。

依頼元が分からないタスクは、優先順位も完了条件も判断しづらくなります。

依頼元	タスク例	つなぐ理由
案件	見積作成、資料送付、社内確認	顧客や売上見込みと関係する
問い合わせ	調査、回答、再発防止	対応期限や顧客影響がある
日報	翌日の確認、上長レビュー	現場作業と改善につながる
会議	宿題、決定事項の実行	誰がいつまでにやるかを残す
プロジェクト	設計、実装、検証、レビュー	前後工程や担当分担がある
申請	承認前の補足、差し戻し対応	プロセス管理とつながる

タスクアプリには、最低限次の項目を持たせます。

フィールド	型	設計意図
タスク名	文字列	作業内容を短く識別する
依頼元種別	ドロップダウン	案件、問い合わせ、日報、会議、プロジェクトなど
関連案件	ルックアップ、関連レコード	案件から発生した作業を追う
関連問い合わせ	ルックアップ、関連レコード	問い合わせ対応とつなぐ
依頼者	ユーザー選択	誰からの依頼かを残す
担当者	ユーザー選択	誰が実行責任を持つか
確認者	ユーザー選択	誰が完了確認するか
期限	日付、日時	いつまでに終えるか
状態	ステータス	未着手、対応中、確認待ち、完了、保留
完了条件	テキスト、選択肢	何をもって完了かを明確にする

依頼元を自由入力にしすぎると、あとで追えません。

案件や問い合わせなど、すでにkintone上にアプリがあるものは、関連レコードでつなぎます。

まだアプリがない場合でも、依頼元種別だけは選択肢にしておくと、あとから分けやすくなります。

ステータスと完了条件

タスク管理でよく起きるのが、「対応中」のまま止まる問題です。

原因は、ステータスが悪いというより、完了条件が決まっていないことです。

まず、ステータスは少なく始めます。

ステータス	意味	次に必要な行動
未着手	まだ作業を始めていない	担当者と開始予定を確認する
対応中	担当者が作業中	作業履歴や中間状況を残す
確認待ち	実作業は終わり、確認者待ち	確認者がレビューする
差し戻し	修正が必要	担当者が再対応する
完了	完了条件を満たした	履歴として残す
保留	今は進められない	保留理由と再開条件を残す
取消	やらないことになった	取消理由を残す

ステータスは、プロセス管理で扱うか、ドロップダウンで扱うかを決めます。

レビューや差し戻しが必要なら、プロセス管理の方が向いています。

kintoneでは、プロセス管理に一覧、通知、アクセス権などを組み合わせて運用できます。

kintoneヘルプ：プロセス管理と組み合わせると便利な設定

完了条件は、タスク本文に書くだけではなく、できるだけ構造化します。

タスク例	曖昧な完了条件	よい完了条件
見積作成	見積を作る	PDFを作成し、営業責任者が確認済み
問い合わせ回答	回答する	顧客へ回答し、問い合わせ状態を解決に変更
資料修正	資料を直す	指摘3点を反映し、最新版URLを添付
日報確認	日報を見る	コメントまたは差し戻しを入れる
データ確認	データを見る	不備一覧を更新し、確認済みにする

完了条件がないタスクは、担当者の感覚で終わります。

確認者がいるタスクでは、担当者の「終わった」と確認者の「完了でよい」がずれることがあります。

このズレをステータスと完了条件で吸収します。

タスク管理で重要なのは、完了ボタンを押せることではなく、完了と判断する基準が依頼者・担当者・確認者で揃っていることです。

担当者・期限・優先度の設計

タスクには担当者と期限が必要です。

ただし、「担当者」と「関係者」を混ぜると責任が曖昧になります。

項目	意味
依頼者	タスクを依頼した人
担当者	実行責任を持つ人
確認者	完了確認やレビューをする人
関係者	参考共有される人
代理担当	担当者不在時に引き継ぐ人

担当者は、原則1人にします。

複数人で作業する場合でも、実行責任者は1人にします。

複数人を担当者にすると、「誰かがやるだろう」になりやすいからです。

期限も、1つだけでは足りないことがあります。

期限	意味
作業期限	担当者が作業を終える日
確認期限	確認者がレビューする日
顧客回答期限	顧客や依頼者へ返す日
再開日	保留タスクを見直す日

優先度は、緊急度と重要度を混ぜすぎない方がよいです。

優先度	意味
高	顧客影響、期限超過、売上影響がある
中	通常の期限内で対応する
低	期限に余裕があり、後回しにできる

より厳密にするなら、優先度を1つにせず、緊急度、重要度、顧客影響を分けます。

項目	例
緊急度	今日中、今週中、来週以降
重要度	売上影響、顧客影響、社内改善
顧客影響	あり、なし、社内のみ
期限超過	自動判定

担当者別の負荷を見る場合は、タスク数だけでなく重さも見ます。

1分で終わる確認と、3日かかる資料作成を同じ1件として数えると、負荷が見えません。

最初は見積工数をざっくり持たせるだけでも十分です。

通知とリマインド

タスク管理で通知を増やしすぎると、逆に見られなくなります。

通知するのは、行動が必要な状態だけです。

通知する状態	通知しすぎない方がよい状態
担当者が未設定	タスク名の軽微な修正
期限が近い	メモ欄の追記
期限を過ぎた	完了済みタスクの閲覧
確認待ちになった	参考コメントの追加
差し戻しになった	優先度の軽微な変更
保留の再開日になった	連携成功ログ

kintoneのリマインダー通知や条件通知を使う場合も、通知先を絞ります。

状態	通知先
新規依頼	担当者
期限前	担当者
期限超過	担当者、責任者
確認待ち	確認者
差し戻し	担当者
高優先度	担当者、責任者

通知の目的は、情報共有ではなく、放置を防ぐことです。

すべてのタスク更新を通知すると、重要な期限超過や確認待ちが埋もれます。

一覧も同じです。

全件一覧より、例外一覧を作ります。

一覧	条件	見る人
自分の未完了	担当者が自分、完了以外	担当者
期限超過	期限が過去、完了以外	担当者、責任者
未担当	担当者が空	管理者、依頼受付担当
確認待ち	状態が確認待ち	確認者
差し戻し	状態が差し戻し	担当者
保留見直し	再開日が近い	担当者、責任者
高優先度	優先度が高、未完了	責任者

レビューと差し戻し

タスク管理では、作業完了と業務完了が違うことがあります。

担当者が作業を終えた。

しかし、確認者が見ていない。

依頼者の期待と違う。

成果物が添付されていない。

この状態で完了にすると、あとで戻ります。

レビューが必要なタスクでは、確認待ち、差し戻し、完了を分けます。

状態	誰が操作するか	意味
対応中	担当者	作業している
確認待ち	担当者	作業は終わり、確認依頼中
差し戻し	確認者	修正が必要
完了	確認者、または担当者	完了条件を満たした

レビューでは、差し戻し理由を残します。

差し戻し理由	例
成果物不足	添付、URL、資料が足りない
内容不備	指示と違う、確認項目が漏れている
期限変更	優先度や依頼内容が変わった
追加確認	別担当や顧客への確認が必要
対象外	そもそも対応不要だった

差し戻しをコメントだけで扱うと、あとで集計できません。

差し戻し理由を選択肢として持たせると、どの種類の不備が多いか分かります。

レビューが多すぎる場合は、タスクの完了条件や依頼の出し方が曖昧な可能性があります。

差し戻しは、担当者の問題だけではなく、業務設計の問題として見るべきです。

かんばん・ガント・一覧の使い分け

タスク管理では、かんばんやガントチャートを使いたくなります。

ただし、表示形式を先に決めると失敗します。

まず決めるべきなのは、誰が何を判断したいかです。

表示形式	向いている判断	注意点
標準一覧	自分の未完了、期限超過、未担当を見る	条件設計が重要
かんばん	状態ごとの滞留を見る	ステータス定義が曖昧だと崩れる
ガント	期間、前後関係、工程を見る	依存関係や日程変更の運用が必要
グラフ	担当別件数、状態別件数、期限超過を集計する	件数だけでは負荷が分からない
カレンダー	期限や作業予定を日付で見る	実作業時間の管理とは分ける

かんばん表示は、未着手、対応中、確認待ち、完了のように状態の流れを見たい場合に向きます。

ただし、カードを動かすだけで業務が進むわけではありません。

完了条件、担当者、期限、レビューが決まっていないと、かんばんは見た目だけになります。

ガントチャートは、前後関係や期間を見る場合に向きます。

ただし、すべてのタスクにガントが必要なわけではありません。

1日で終わる細かいタスクまでガントに入れると、更新が重くなります。

プロジェクト、工程、期限が重要なものだけガントに載せる方が現実的です。

権限と更新責任

タスク管理は、複数人で更新するからこそ便利です。

しかし、全員が自由に直せると、責任が曖昧になります。

役割	閲覧	追加	編集	削除
依頼者	自分の依頼、関連タスク	依頼	依頼内容、補足	原則不可
担当者	自分のタスク、関連情報	作業履歴	状態、作業メモ、完了依頼	原則不可
確認者	確認対象タスク	レビュー	確認結果、差し戻し理由	原則不可
責任者	部門全体	タスク	担当変更、期限変更、優先度	制限付き
管理者	全体	全体	全体	制限付き
外部連携ユーザー	連携対象のみ	API対象のみ	API対象のみ	原則不可

削除権限は慎重に扱います。

タスクや作業履歴を削除できると、あとで依頼や対応経緯が説明できません。

間違えた場合は、削除ではなく、取消、無効、重複統合で扱う方が安全です。

kintoneでは、アプリ、レコード、フィールド単位でアクセス権を設定できます。

kintoneヘルプ：アクセス権の設定

タスク管理では、特に担当者、期限、優先度、完了状態を誰が直せるかを決めます。

依頼者が期限を自由に変えられるのか。

担当者が完了にできるのか、確認者だけが完了にできるのか。

責任者が担当変更できるのか。

ここを決めておかないと、タスクの状態が信用できなくなります。

外部ツールとの境界

タスク管理は、外部ツールとつながりやすい領域です。

SlackやTeamsで通知する。

Google Calendarで予定を見る。

BacklogやJiraで開発チケットを管理する。

フォームから依頼を受ける。

これらは便利ですが、先に責任範囲を決めないと崩れます。

連携先	kintoneで持つもの	外部に任せるもの
Slack・Teams	通知対象、対応状態、期限超過	即時相談、短いやり取り
Google Calendar	期限、作業予定の参照	空き時間、予定、繰り返し予定
Backlog・Jira	業務側の依頼、確認状態	開発チケット、PR、リリース、障害管理
フォーム	依頼受付、依頼者、添付	外部入力画面、本人確認
案件・顧客管理	関連案件、関連顧客	顧客情報や営業進捗の正本

通知連携では、成功通知より失敗や期限超過を重視します。

すべてのタスク更新をチャットに流すと、すぐに見られなくなります。

開発タスクは、無理にkintoneへ全部持たせない方がよいことがあります。

業務側の依頼や確認はkintone。

開発実装、レビュー、リリースはBacklogやJira。

このように分けると、現場と開発の責任範囲が明確になります。

kintoneタスク管理で崩れやすい失敗パターン

kintoneタスク管理の失敗は、機能不足より設計不足で起きます。

失敗	起きること	設計で直すこと
ToDo一覧だけ作る	依頼元や完了条件が分からない	依頼元、完了条件、確認者を持たせる
担当者を複数人にする	誰が実行責任を持つか曖昧になる	実行責任者を1人にする
期限を1つだけにする	作業期限と確認期限が混ざる	作業期限、確認期限、回答期限を分ける
ステータスが多すぎる	入力が揃わない	少ない状態から始める
完了条件がない	完了判断が人によって違う	成果物、確認基準を明文化する
レビューをコメントだけで行う	差し戻し理由を集計できない	確認待ち、差し戻し、理由を持たせる
通知を増やしすぎる	期限超過が埋もれる	未担当、期限超過、確認待ちだけ通知する
かんばんを先に入れる	見た目は良いが運用が崩れる	ステータスと完了条件を先に決める
すべてkintoneに集める	開発、予定、チャットまで重くなる	外部ツールとの境界を決める
削除権限を広く渡す	対応経緯が消える	取消、無効、重複統合で扱う

特に危ないのは、タスクを登録するだけで安心することです。

タスクは、登録された瞬間ではなく、完了条件を満たして確認された瞬間に価値があります。

登録数が増えても、未担当、期限超過、確認待ち、保留が見えなければ、管理できていません。

1週間で始めるなら、この順番で作る

最初から完全なプロジェクト管理を作る必要はありません。

小さく始めるなら、1週間で次の順番で設計します。

日	やること	成果物
1日目	タスクの発生元を整理する	案件、問い合わせ、会議、日報、プロジェクト
2日目	タスクアプリを作る	タスク名、依頼者、担当者、期限、状態
3日目	完了条件とレビューを設計する	完了条件、確認者、差し戻し理由
4日目	一覧と通知を作る	自分の未完了、期限超過、未担当、確認待ち
5日目	権限と更新責任を決める	依頼者、担当者、確認者、責任者、管理者
6日目	案件・問い合わせ・日報とつなぐ	関連レコード、ルックアップ、原本URL
7日目	外部連携の境界を整理する	Slack、Teams、カレンダー、Backlog、Jira

この段階で、複雑なガントチャートや自動化まで入れなくて構いません。

まず作るべき状態は、次です。

• 依頼元が分かる
• 担当者が1人に決まっている
• 期限と確認期限が見える
• 完了条件が書かれている
• 確認待ちと差し戻しが分かる
• 未担当と期限超過が一覧で見える
• 通知が必要な人だけに届く
• 外部ツールとの境界が説明できる

ここまでできれば、次にかんばん、ガント、Slack/Teams通知、カレンダー連携、開発チケット連携へ進めます。

逆に、この状態を作らないまま見た目を整えると、きれいに放置されたタスク一覧になります。

実装前に決めるチェックリスト

kintoneでタスク管理を作る前に、最低限次の質問に答えます。

質問	決めること
タスクの発生元は何か	案件、問い合わせ、日報、会議、プロジェクト、申請
1タスクの単位は何か	1作業、1成果物、1確認、1依頼
担当者は誰か	実行責任者、代理担当、関係者
完了条件は何か	成果物、確認項目、原本URL、状態変更
確認者は必要か	担当者完了でよいか、レビューが必要か
期限は何を持つか	作業期限、確認期限、顧客回答期限、再開日
ステータスは何段階にするか	未着手、対応中、確認待ち、差し戻し、完了、保留
優先度はどう決めるか	緊急度、重要度、顧客影響、期限超過
何を通知するか	未担当、期限前、期限超過、確認待ち、差し戻し
どの表示形式を使うか	一覧、かんばん、ガント、グラフ、カレンダー
誰が編集できるか	依頼者、担当者、確認者、責任者、管理者
何をkintoneに持たないか	個人メモ、開発チケット、予定表、短いチャット相談

このチェックリストに答えられない状態でタスクアプリを作ると、あとからフィールド追加、ステータス変更、通知の作り直し、権限変更が続きます。

小さく始めることはできます。

ただし、小さく始める範囲と、最初から設計しておく範囲は分けます。

依頼元、担当、期限、完了条件、レビュー、通知、外部ツールとの境界は、最初に決めた方がよいです。

まとめ

kintoneでタスク管理を作るときは、「ToDo一覧を1つ作る」と考えない方がよいです。

依頼元、タスク、完了条件、レビュー、作業履歴、一覧・通知、連携ログを分けます。

そのうえで、どこから発生したタスクか、誰が担当するか、何をもって完了か、誰が確認するかを決めます。

kintoneタスク管理の設計で大事なのは、タスクを見える化することではなく、依頼から完了確認まで責任と状態を説明できるようにすることです。

案件、問い合わせ、日報、会議、プロジェクトから発生する業務タスクなら、kintoneで十分に始められます。

一方で、個人の軽いToDo、開発チケット、予定表、チャット上の短い相談まで含むなら、kintoneは業務タスクの正本に寄せ、外部ツールと分ける判断も必要です。

かんばんやガントを入れる前に、まず依頼元、担当、期限、完了条件、レビューの責任範囲を決める。

それが、kintoneタスク管理を崩れにくくする一番の近道です。