日報アプリの作り方｜入力項目と集計単位を先に決める

日報アプリの入力項目は、管理者が翌日に何を判断するかから逆算して選びます。今の紙をそのまま写し、長文の「業務内容」を入力欄へ置き換えただけでは、現場の報告を電子化できても、管理者は結局、一件ずつ読んで分類しなければなりません。

先に決めるのは、判断する人、判断内容、そのための最小項目、集計単位です。集計に使う分類は選択式にし、補足だけを自由記述にします。あわせて、日報を提出したかと、各作業の実績が確定したかを分けます。報告がない人と、作業量ゼロを報告した人では、翌日に必要な確認が違うためです。

外部サービスの機能に関する記述は2026年9月25日時点で確認しています。判断表と状態設計は、日報アプリ検討用の架空の条件例です。製品固有の仕様や導入実績としては扱いません。

日報アプリの入力項目は「翌日の判断」から選ぶ

紙の日報には、長い自由記述欄が残りがちです。書く側は一度に報告できますが、読む側が「支援の必要な作業だけを抽出したい」と思った瞬間、文章の読み直しが発生します。では、自由記述を細かく分割すればよいのでしょうか。

項目数を増やすこと自体は答えになりません。「誰が」「いつ」「何を決めるために使うか」を先に固定すると、その判断に使わない項目を入力画面から外せます。

kintone公式情報では、日報・報告書アプリに「日付」「作成者」「業務内容」など、業務に応じた必要項目を設定でき、形式や粒度が異なる報告を統一フォーマットで一元管理できると説明されています（日報・報告書にkintone）。つまり、長文を項目へ分ける土台はあります。難しいのは、何を分け、どの単位で見るかです。

判断から逆算する入力項目表

現場責任者と部門管理者が翌日に行う判断を起点に、入力項目と集計単位を対応させると、次の表になります。

同じ日報でも、判断する人が変われば必要な粒度も変わります。現場責任者には案件と作業区分の組み合わせが必要ですが、部門管理者が未提出を確認する場面では、部門と報告者の組み合わせが軸になります。すべてを一つの集計表に押し込まず、判断ごとに一覧を切り替えられる設計が合います。

kintoneでも、作成者、日付、所属部署などの条件で日報一覧を絞り込めます（日報・報告書にkintone）。対象日・報告者・所属部門を別々の項目として持たせると、判断表に沿った一覧を作りやすくなります。

長文入力を、集計する項目と補足へ分ける

判断表の項目を入力画面へ移すときは、集計する値と、人が読む補足を分けます。

• 対象日、報告者、所属部門、現場または案件は、報告の所属先を決める項目にする
• 作業区分、実績状態、支援要否は、あらかじめ定義した選択肢から選ぶ
• 進捗や作業量は、翌日の判断と集計に必要な形で独立させる
• 阻害要因の詳しい事情など、定型化できない内容だけを自由記述に残す

この分け方なら、主要な日次集計の分類を選択式の項目でそろえ、作業量などの実績値は独立した項目から集計できます。自由記述は対象を絞った後に読み、個別事情を確かめる補足として扱います。

kintone公式ガイドでも、あらかじめ決めた選択肢から入力させることで、入力負担と入力・変換ミスを抑え、後から集計しやすくなると説明されています（アプリを便利にする機能）。同じ分類で集計したい項目が、選択式にする対象です。

選択肢を決める際には、現場の言い回しを集めるだけで終わらせず、選択した値がどの判断へつながるかを確認します。たとえば「支援要」を集計しても、その後に対象レコードを開けなければ現場責任者の判断には届きません。入力値、集計結果、確認する明細までを一続きで設計します。

未提出・作業なし・未確定を空欄で兼用しない

空欄を見て、「作業がなかった」と判断してよいでしょうか。提出そのものがなければ、作業がなかったのか、報告を忘れたのかは分かりません。日報が提出されていても、実績値の確定待ちという場合があります。

架空の設計例では、一部の実績が未確定でも日報の提出を認める運用とします。提出状態は「対象日×報告者」、実績状態はその日報に属する作業明細ごとに持たせます。別の単位なので、同じ選択欄へまとめません。

たとえば、提出済みの日報で作業Aの数量が確定し、作業Bの数量だけ確認中なら、Aは集計し、Bは未確定として残します。日報全体を未提出へ戻したり、Bをゼロとして合計したりしません。作業がなかった日は、その旨を明示して提出する運用にします。作業を実施して成果数量がゼロだった場合は、作業なしと混同せず、確定した実績として残します。

未提出者の抽出には、日報とは別に、その日の提出対象者一覧が必要です。対象日、担当者、所属、提出対象かどうか、対象外理由を先に決め、提出済みの日報と照合します。休日などで提出不要な人は対象外とし、日報レコードがない人も確認できるようにします。報告が届いた人だけの一覧からは、未提出者を見つけられません。

日報アプリの公式機能ページは、メンバーごとの提出・未提出状況を自動集計し、部門別・個人別に可視化できると説明しています（日報アプリの機能）。提出状況を本文中の値とは別に持つことは、未提出者とゼロ実績の提出者を分ける前提になります。

集計単位は、一覧を開いた後の行動まで決める

「日別に集計する」だけでは、集計単位が足りません。現場責任者が支援対象を選ぶなら「対象日 × 現場または案件 × 作業区分」、部門管理者が提出状況を確認するなら「対象日 × 所属部門 × 報告者」が必要です。

ここで粒度を粗くすると、合計の内訳を確認するために日報本文へ戻ることになります。反対に細かくしすぎると、翌日の判断に使わない分類まで入力が必要になります。判断表の「判断に使う出力」から逆向きにたどり、対象レコードへ到達できる最小の組み合わせを採用します。

システムの方式選びは、その後です。既製サービス、kintone、個別開発のどれが合うかは、SaaS・kintone・カスタム開発の比較で整理できます。現在の管理がExcel中心で、データ整理や切り替えの進め方から確認したい場合は、Excelから業務システムへ移行する手順も参考になります。日報では、移行方法より先に日々の報告粒度を確定させておくと、方式を比較するときの条件がぶれません。

日報アプリを作る前の確認手順

設計案は、次の順で確認できます。

1. 翌日に判断する人と、実際に決める内容を書き出す
2. 判断ごとに、参照する最小の入力項目を対応させる
3. 集計結果から対象レコードを確認できる集計単位を決める
4. 集計する分類を選択式にし、補足だけを自由記述へ残す
5. 日ごとの提出対象者を定め、日報の提出状態と作業明細の実績状態を別々に保存する
6. 判断、入力項目、集計単位、確認後の行動が一対一で追えるかを試す

この順序なら、使う判断を起点に、紙の日報にある不要な入力を落とせます。特に、主要な日次集計のために自由記述を読み直す箇所が残っていないかは、実装前に確認すべき点です。

設計案の合格条件

実装へ進める前に、次の条件を満たすかを確認します。

• 管理者が翌日に行う各判断から、参照する入力項目と集計単位を追跡できる
• 提出対象者一覧から未提出者を抽出でき、提出不要の人と区別できる
• 日報の提出状態と作業明細の実績状態が別項目になり、確定・作業なし・未確定が混ざらない
• 未提出や未確定を、作業なしのゼロ実績として集計しない
• 提出済みの日報に未確定の明細があっても、提出催促をせず、その明細だけを実績の確認対象にできる
• 選択式の分類項目と作業量などの実績値で主要な日次集計ができ、分類のために自由記述を読まなくてよい

現在の日報を判断表に当てはめ、管理者が翌日に使わない項目と、自由記述を読み直さないと集計できない項目を確認します。未提出者への確認、ゼロ実績の把握、未確定値の確認を別々に行えることが、入力項目を絞る際の基準です。

Cotomuでは、困っている業務一つからWebアプリを設計できます。日報の初期開発と運用保守は個別見積もりです。連携、移行、権限、データ出力の範囲を含め、業務アプリの相談で現在の日報と判断表をもとに整理できます。