kintoneで進捗をどう見せるか｜報告のために作り直さない組み方
「kintone kanri」で調べている人の多くは、すでにアプリを作り終えています。レコードは貯まっているのに、いま何がどこで止まっているのかが一目で分からない。月末になると、一覧を目で追って数えて、報告用の資料を別に作っている。この記事では、kintoneで進捗を見せるための部品が何に分かれているのか、それぞれに何ができて何ができないのかを、公式ヘルプで確認できる範囲で整理します。報告のために数え直さなくて済む組み方を目指します。
進捗を見せる部品は、4つに分かれている
kintoneで進行の状況が見える場所は、性格の違う4つの部品でできています。この4つの役割を分けて考えないと、1つの部品にすべてを担わせようとして行き詰まります。
1つめは一覧です。レコードを並べて、絞り込んで、必要な列だけを見せる場所です。日々の作業はここで行われます。
2つめはプロセス管理です。レコードに状態と担当を持たせて、次に誰が何をするのかを決める仕組みです。進捗の「進み方」を決めるのがここです。
3つめはグラフです。件数や合計を集計して、図や表として見せます。報告で使うのは主にここです。
4つめはポータルです。kintoneを開いたときに最初に出る画面で、自分に関係するものが集まります。
報告のたびに数え直しているチームは、たいてい1つめだけで運用しています。一覧を目で追って数えているので、件数が増えるほど時間がかかります。2つめと3つめを足すだけで、この作業のほとんどは消えます。
プロセス管理が、進捗の土台になる
まず押さえるべきは、プロセス管理です。公式ヘルプには次のように書かれています。
プロセス管理を設定すると、どの状態（ステータス）で、誰（作業者）が、何をする（アクション）かがアプリに追加されます。 出典: jp.kintone.help
ここで加わる3つの要素が、進捗を見せるための材料になります。状態があるから「どの段階に何件あるか」が数えられ、作業者がいるから「誰のところで止まっているか」が分かります。
プロセス管理を入れていないアプリでは、状態を表すフィールドを自分でドロップダウンとして作ることになります。それでも一覧の絞り込みには使えますが、大きな違いが1つあります。プロセス管理の場合、自分が作業者に指定されているレコードにだけアクションのボタンが表示されると説明されています。つまり、次に動く人にだけ操作が見える状態になります。
ドロップダウンで状態を持つと、誰でもどの状態にも変えられます。締まりのない運用になりやすく、気づいたら勝手に完了になっている、という事故が起きます。進捗を数字として扱いたいなら、プロセス管理を使うのが素直です。
自分の担当件数がポータルに出る
プロセス管理を入れると、ポータルの見え方が変わります。公式ヘルプには、kintoneのポータルに、自分が作業者に指定されているレコードの件数がアプリごとに表示されると書かれています。表示されたアプリをクリックすると、自分が作業者になっているレコードの一覧が開きます。
あわせて、作業者になったユーザーには自分宛の通知が届くと説明されています。通知をクリックすると、そのレコードの詳細が開きます。
この2つが揃っていると、作業する人は「自分が次に何をすべきか」を探さなくて済みます。進捗の表が嘘にならない条件は、作業する人が状態を進めてくれることです。そして、状態を進めてもらうには、自分の番が来たことが本人に分かる必要があります。ポータルの件数と通知は、その役割を担っています。
とりまとめる立場の人がやるべきことは、この仕組みを説明することです。「ポータルに数字が出ていたら、それがあなたの番です」という一文を配るだけで、催促の回数が目に見えて減ります。
状態をいくつ持つかで、使われ方が変わる
プロセス管理を設計するとき、最初に決めるのが状態の数です。ここで運用の寿命がほぼ決まります。
状態が少なすぎると、止まっている理由が読めません。「作業中」だけだと、手が動いているのか、外部の回答を待っているのかが区別できません。この2つは、とりまとめる立場からするとまったく違う状況です。
多すぎると、作業者がボタンを押さなくなります。押す前に「どれを選ぶのが正しいのか」を考える手間が生まれるからです。8つを超えたあたりから、目に見えて操作の回数が落ちると言われています。
現場で長く使われている設計は、だいたい4つから6つの範囲に収まっています。未着手、作業中、確認待ち、差し戻し、完了。この5つで大半の業務は説明できます。
もうひとつ決めるのが、誰を作業者にするかです。公式ヘルプでは、状態ごとにレコードを編集または確認して状態を変えるユーザーが作業者として指定されると説明されています。ここを部署やグループで指定すると、誰も自分ごとだと思わない状態になりがちです。人数の多いチームでは、いったんグループで受けて、そこから個人に割り当て直す流れにすると、滞留が減ります。
一覧には3つの形式がある
進捗を見せる2つめの部品が一覧です。公式ヘルプでは、表示の形式として表形式、カレンダー形式、カスタマイズの3種類が挙げられています。
表形式は、列にフィールド、行にレコードを並べる形です。表示する列と並び順、絞り込みの条件を設定でき、作業者と状態も列として出せます。一覧の画面のままフィールドの値を編集できるとも書かれているので、状態の確認と修正をその場でできます。
カレンダー形式は、日付のフィールドを選んで、その日付の欄にレコードを置く形です。締切が視覚的に分かるので、期日の管理には向きます。
カスタマイズは、HTMLで一覧の表示を作り込む形です。ここには制約が2つあります。契約がライトコースの場合は選べないと明記されていること。そして、選べるのはkintoneのシステム管理者だけだと書かれていることです。作り込みで進捗を見せる設計にするなら、契約のコースと権限の両方を確認してから決めてください。
初期設定で用意されている「すべて」の一覧には、表示するフィールドの指定や並び替えができないという制約があります。テーブル、テーブルの中のフィールド、作成者、更新者、作成日時、更新日時、関連レコード一覧、グループ、ラベル、スペース、罫線、カテゴリーは表示されないとも書かれています。業務に合わせて見せたいなら、新しく一覧を作るのが前提です。
カレンダー形式は500件で切れる
期日の管理にカレンダー形式を使うとき、必ず知っておくべき上限があります。公式ヘルプには、カレンダー形式の一覧では1ページにつき500件まで表示されると書かれています。500件を超える場合は、第一週の日曜から先頭の500件が表示されるとも説明されています。
これが意味するのは、件数の多いアプリでカレンダーを開くと、月の後半が丸ごと消えるということです。しかも、画面上には「省略されています」という表示が出るわけではありません。空いているように見えるだけです。
対策は絞り込みです。カレンダーの一覧を作るときに、自分の担当分だけ、あるいは進行中のものだけ、というように条件を付けておきます。全件を見せるカレンダーは、件数が増えた時点で嘘になります。作った直後は正しく見えるので、気づくのはたいてい何か月か後です。
あわせて知っておきたいのが、カレンダー形式の一覧をスペースのお知らせやスレッドに貼り付けると、表形式で表示されるという仕様です。スペースに貼って全員に見せる運用を考えているなら、カレンダーの見た目は再現されません。
一覧とグラフは、作りすぎると迷子になる
kintoneの制限値の一覧には、1つのアプリにつき一覧は1,000件まで、グラフも1,000件まで作れると書かれています。
この数字は上限として十分に大きいので、実務で当たることはまずありません。問題は逆で、いくらでも作れてしまうことです。
現場でよく起きるのは、誰かが自分用の一覧を作り、別の誰かも作り、半年後にドロップダウンに30個近い一覧が並んでいる状態です。こうなると、新しく入った人はどれを開けばよいのか分かりません。名前も「田中用」「臨時」「新しいほう」といった具合に、意味が読めないものが混ざります。
進捗を見せる目的なら、一覧は5つ前後に絞るのが読みやすい状態です。全件、自分の担当、進行中、期日超過、今月完了。この5つがあれば、たいていの確認は足ります。個人用の一覧を作る文化がある場合は、名前の付け方を決めておくと、後から整理できます。四半期に一度、使われていない一覧を消す時間を取るのも効果があります。
グラフの書式は、個別に設定できない
報告に使うグラフについて、知っておくべき制約があります。公式ヘルプには、グラフの色や文字サイズなどの書式は自動で設定され、各要素の書式を個別に設定することはできないと明記されています。
これは、社内の体裁が決まっている資料にそのまま貼りたい場合に効いてきます。色を揃えたい、特定の系列だけ強調したい、といった要望には応えられません。報告の資料の見た目を細かく整える必要があるなら、集計結果をファイルに書き出して、別のソフトで図を作ることになります。
逆に言えば、見た目にこだわらなくてよい場面では、そのまま使うのがいちばん早い選択です。報告の資料を毎月きれいに作り直しているチームは、まず「その体裁は本当に必要か」を確かめるほうが効果があります。体裁のために毎月3時間使っているなら、年間で36時間です。
なお、集計の条件はブックマークとして保存できると案内されています。毎回同じ条件で集計するなら、この機能で手数を減らせます。
絞り込みが重くなる境目
一覧を作り込んでいくと、開くのに時間がかかる場面が出てきます。制限値の一覧には、この点についての説明があります。絞り込みの条件の上限は指定する条件によって異なり、条件が多いとレコードの一覧の画面を開けないことがあると書かれています。
さらに、取得するフィールドの数が200万個を超える場合や、レコードの合計サイズが数十MBを超える場合、レコード情報の取得に失敗するとも明記されています。フィールドの数は、レコード数と表示する列の数を掛けた数です。5万件のレコードに40列を表示すれば200万個です。
つまり、件数が多いアプリで列を全部出すと、一覧が開かなくなります。進捗を見るための一覧なら、必要な列は多くありません。案件名、担当、状態、期日。この4つで足ります。列を減らすことは、見やすさのためだけでなく、開けるかどうかにも関わります。
1つのアプリに置けるフィールドは500個までと書かれていますが、ラベル、罫線、スペース、レコード番号、作成者、作成日時、更新者、更新日時はこの数に含まれないとも説明されています。テーブルの中のフィールドは、配置した数に1を足した数で数えられます。
リマインダーは、アプリごとに10個まで
期日が近いことを知らせる仕組みとして、リマインダーの条件通知があります。制限値の一覧には、1つのアプリにつき10個までと書かれています。
10個という数字は、使い方を決めておかないと意外と早く埋まります。状態ごとに通知を作り、担当ごとにも作り、期日の3日前と当日にも作る、という具合に増やしていくと、すぐに届きます。
設計の順番としては、まず「誰に、いつ、何を知らせたいか」を紙に書き出します。そのうえで、通知の数を10個の枠に収まるように束ねます。担当ごとに分けるのではなく、条件で1本にまとめられないかを考えるのが基本です。
通知が多すぎると、受け取る側が読まなくなります。これは上限の話とは別の、運用上の問題です。届く量が増えると、本当に急ぎのものが他に埋もれます。1日に5通を超えると、内容を見ずに消す人が出てきます。進捗の通知は、本当に動いてほしいときだけ届くようにするほうが効きます。
報告のために作り直さない組み方
ここまでに挙げた仕様を前提に、運用の形を順に決めていきます。
はじめに、報告で使う言葉と、プロセス管理の状態の名前を一致させます。報告では「確認待ち」と言っているのに、アプリの状態が「レビュー中」になっていると、集計から出た数字を報告の言葉に翻訳する作業が毎回発生します。名前を揃えるだけで、この作業が消えます。
次に、報告に必要な数字を洗い出します。多くの場合、必要なのは4つです。状態ごとの件数。担当ごとの件数。期日を過ぎている件数。今月完了した件数。この4つに対応するグラフを作っておきます。
3つめに、そのグラフの集計条件をブックマークとして保存します。毎月同じ条件で開けるようにしておけば、報告の作業は開いて数字を読むだけになります。
4つめに、数字の定義を文章にします。「期日を過ぎている件数」に完了したものを含むのかどうかで、数は変わります。この1行を決めておかないと、会議のたびに定義の確認から始まります。定義を書く場所は、アプリ管理者用のメモが向いています。設定を開いた人が必ず目にする場所なので、引き継ぎのときにも残ります。あわせて、その定義をいつ決めたのかを書いておくと、過去の数字と比べるときに条件がそろっているかを確かめられます。
5つめに、進捗が正しく数えられなくなる原因を監視する一覧を作ります。期日が入っていないレコード、作業者が空のレコード、最終更新から30日以上動いていないレコード。この3つを見張る一覧を作っておくと、数字が実態からずれ始めた時点で気づけます。
集計の結果は、ファイルとして出せる
報告の資料に数字を貼りたい場合、アプリから書き出せるものが何かを知っておくと手数が減ります。公式ヘルプには、アプリからファイルに書き出せるデータとして、レコード、レコードのコメント、集計結果、クロス集計表の4つが挙げられています。
つまり、グラフの元になっている集計の結果そのものを、ファイルとして取り出せます。画面を撮った画像を貼るのではなく、数字を貼れるということです。報告の資料が表計算ソフトで作られているなら、この形のほうが扱いやすくなります。
クロス集計表を出せる点も実務では効きます。担当ごと、状態ごとの件数を縦横に並べた表は、報告でそのまま使える形です。毎月この表を作るために一覧を数えているなら、書き出しに切り替えるだけで作業が消えます。
ただし、書き出しの操作にはアプリのアクセス権でファイル書き出しの権限が必要で、初期設定ではアプリの作成者だけに許可されていると書かれています。報告を担当する人がその権限を持っているかを、最初に確かめておいてください。権限が無いまま「書き出せません」と詰まるのは、よくある入口の失敗です。
1つのアプリにまとめるか、分けるか
進捗の見せ方を設計するときに、必ず出る論点があります。案件も作業も1つのアプリに入れるのか、分けるのかという判断です。
1つにまとめると、一覧とグラフが1か所で完結します。集計が単純になり、報告の作業は軽くなります。そのかわり、フィールドの数が増えます。制限値では1つのアプリにつきフィールドは500個までと示されているため、種類の違う業務を1つに詰め込むと、いずれ入力の画面が読めなくなります。
分けると、それぞれのアプリは見やすく保てます。かわりに、進捗を横断して見るには、アプリをまたいだ仕組みが必要になります。参照の設定を使う方法もありますが、参照の関係が増えるほど、後からアプリを移したり複製したりするときの手間が増えます。
判断の目安は、入力する人が同じかどうかです。同じ人が同じ画面で扱うものは1つにまとめ、入力する部署が違うものは分ける。この基準で切ると、あとから権限を分けるときにも素直な形になります。
関連して、カテゴリーという仕組みもあります。制限値では、親を含めて5階層まで、階層の合計は1,000個までと書かれています。案件を分類して一覧を切り替える用途に使えますが、階層を深くするほど、入力する人が選ぶ手間が増えます。進捗の管理が目的なら、2階層までに収めるほうが使われ続けます。
社外の人と共有するとき
協力会社や取引先に進捗を見せる場合は、ゲストスペースを使う形になります。制限値の一覧には、1つのゲストスペースに参加できるゲスト数に上限は無いと書かれています。一方で、料金ページにはゲストユーザーの月額が示されており、2026年9月時点でライトコースが1ユーザーあたり月700円、スタンダードコースが月1,440円と記載されています。いずれも税抜きです。
つまり、人数の制限は無くても、費用は人数に比例します。協力会社が多い業種では、ここが契約の重さに直結します。全員を入れるのか、窓口の担当者だけを入れるのかを先に決めておくと、見積もりがぶれません。
社外と共有するときにもうひとつ確かめておきたいのが、見せる範囲です。同じアプリを見せても、権限の設定によって表示される件数が変わります。数字を根拠に話す場では、相手の画面に何件出ているのかを先に確認しておくと、会話がかみ合わなくなるのを防げます。
困ったときに聞ける窓口の条件が変わる
運用を続けるうえで、詰まったときに誰に聞けるかは実務的な問題です。2026年6月29日付でサイボウズから告知が出ており、AIによるサポートを段階的に開始することと、ライトコースの電話サポートの窓口を2026年9月の定期メンテナンスをもって終了することが示されています。
同じ告知には、有人のサポートが平日の10時から12時と13時から17時30分であること、AIのサポートが24時間365日で提供されること、対象はシステム管理者であることが書かれています。電話の窓口の終了はライトコースのみが対象で、他のコースに変更はないとも明記されています。
進捗の仕組みを組んでいる途中で詰まると、作業が止まります。ライトコースで運用していて、これまで電話で聞いていたなら、聞き方を変える準備が要ります。一方で、これまでメールやチャットで解決できていたなら、運用への影響はほとんどありません。この種の条件は料金表には出てこないので、運用の設計をするときに一度確かめておくのが安全です。
進捗が止まっている理由を、数字で切り分ける
報告でいちばん難しいのは、遅れの説明です。件数だけを出すと「遅れが多い」で終わり、次に何をするかが決まりません。
プロセス管理を使っていれば、この切り分けは自動でできます。状態ごとの件数を見れば、どの段階で滞留しているかが分かるからです。確認待ちに件数が偏っているなら、確認する人の手が足りていません。差し戻しが多いなら、前の工程の品質か、依頼の伝え方に原因があります。未着手が多いなら、そもそも着手できる人がいません。
段階ごとに原因が違うので、打ち手も変わります。件数をひとまとめに出している限り、この切り分けは会議の場で口頭でやることになり、毎回20分ほど取られます。状態ごとの件数を出すグラフを1つ用意しておけば、その20分が数秒になります。
もうひとつ効くのが、その状態にとどまっている日数です。同じ「確認待ち5件」でも、全部が昨日から待っているのと、1件が40日待っているのとでは、意味がまったく違います。更新日時を使って経過日数で並べ替えた一覧を作っておくと、どこから手を付けるかがその場で決まります。
更新され続けるかどうかで決まる
最後に、設定より重い話をします。どれだけ丁寧に一覧とグラフを組んでも、作業者が状態を進めなければ、出てくる数字は実態と合いません。
状態を進める人が一部にとどまると、集計した数字はその時点で意味を失います。状態を進めてもらうための条件は3つです。自分の番が来たことが分かること。操作が数回で終わること。進めた結果が本人にも役に立つこと。
kintoneの場合、1つめはポータルの件数と通知で担保されています。2つめは、アクションのボタンを押すだけなので短い操作です。問題になりやすいのは3つめです。状態を進めても本人には何も起きず、ただ上への報告が楽になるだけだと、優先度が下がります。
ここに効くのは、作業者向けの一覧を用意することです。自分の担当分だけが出て、期日の近い順に並ぶ一覧を作り、それを既定の表示にしておく。作業する人にとって開く価値のある画面になれば、状態を進めるついでに次の作業も確認することになり、更新が習慣として定着します。報告のための仕組みと、作業のための仕組みを同じ場所に置く意味は、ここにあります。
寄せられる相談から見えていること
進捗の見せ方について届く相談で多いのは、「作れるものが多すぎて、どれを使えばよいか分からない」という戸惑いです。一覧もグラフも1,000件まで作れて、表示の形式も3つあり、通知の種類も複数ある。自由度が高い道具ほど、最初に設計を決める負担が大きくなります。
もうひとつ多いのが、作り込んだ人が異動したあとの相談です。誰が何のために作った一覧なのか分からず、消すに消せない。この状態になると、新しく入った人は既存の仕組みを避けて自分用の一覧を作り、さらに増えます。
道具の作りとしては、業務に合わせて自由に組める方向のほかに、機能で絞らず、区切るのは人数とボードの数だけという形もあります。作れるものを絞るかわりに、最初に決めることが少なく、引き継ぎの説明も短く済みます。どちらが合うかは、業務システムとして作り込みたいのか、進行を見る板が欲しいのかで変わります。できることと料金を並べて見ると、性格の違いが見えます。
他の道具と見比べる段階にいるなら、軸を絞ってから並べます。板で進行を見せる形と比べたいならTrelloとの比較が、案件ごとの進行と担当を扱う形と比べたいならAsanaとの比較が、国内の開発現場でよく使われる作りと比べたいならBacklogとの比較が、それぞれ近い論点を扱っています。国産の板型の道具と並べたいならJootoとの比較も参考になります。複数の候補をまとめて眺めたいときは比較の一覧から入ると全体像がつかめます。
判断の前に確かめておきたいのは3点です。報告に必要な数字はいくつか。状態を進めるのは誰の仕事として決まっているか。そして、社外の人を何人入れる必要があるか。この3つに答えが出れば、いまの仕組みのどこを直せばよいかが見えてきます。移行を検討する段階ならTrelloからの移行に手順の考え方が、判断に迷う点があればよくある質問に近い相談が並んでいます。
Q1. kintoneで進捗を管理するには、何から設定すればよいですか？
プロセス管理からです。公式ヘルプでは、プロセス管理を設定すると、どの状態で、誰が、何をするかがアプリに追加されると説明されています。状態があるから段階ごとの件数が数えられ、作業者がいるから誰のところで止まっているかが分かります。状態の数は4つから6つに収め、報告で使う言葉と名前を揃えておくと、後の集計が楽になります。
Q2. カレンダー形式の一覧で、レコードが表示されないことがあるのはなぜですか？
1ページにつき500件までという上限があるためです。公式ヘルプには、500件を超える場合は第一週の日曜から先頭の500件が表示されると書かれています。省略されたことは画面上に表示されないので、空いているように見えます。担当や状態で絞り込んだカレンダーを作ることで回避できます。
Q3. グラフの色や文字の大きさを変えることはできますか？
できません。公式ヘルプには、グラフの色や文字サイズなどの書式は自動で設定され、各要素の書式を個別に設定することはできないと明記されています。社内の体裁に合わせた資料が必要な場合は、集計結果をファイルに書き出して別のソフトで作ることになります。まずはその体裁が本当に必要かどうかを確かめるほうが、作業時間の削減につながります。
Q4. 一覧が開けなくなったときは、何を見直せばよいですか？
表示している列の数を減らしてください。公式の制限値では、取得するフィールドの数が200万個を超える場合や、レコードの合計サイズが数十MBを超える場合に取得に失敗すると書かれています。フィールドの数は件数と列数を掛けた数なので、5万件のアプリで40列を表示すると届きます。進捗を見る一覧なら、案件名、担当、状態、期日の4列で足ります。