進捗管理アプリ 評価入力画面 壁打ち記録 (2026-09-25)
本日の修正点一覧(当初設計との相違点)
| # | 項目 | 変更前(当初) | 変更後(本日確定) | 理由 |
| 1 | ②正確性の 入力方式 | 1回目・2回目それぞれ単 一のプルダウン選択(精度 判定1つ+コメント採用有 無) | 不備区分(文章修正あ り-1点/見落とし・軽 微-3点/誤指摘-5点/見
落とし・重大-10点) ごとに件数を入力す る方式 |
1案件に不備が複数 (10件等)発生する現 実に、単一選択では 対応できなかったた め |
| 2 | ファインプ レー加点の 扱い | 案件スコアに+5点として 合算 | 案件スコアから完全 に除外し、「貢献度」 という別枠の参考情 報に格下げ | 不備の多い案件を担 当した人が統計的に 有利になる不公平を 避けるため |
| 3 | ファインプ レーの集計 方法 | 発見数からの自動集計を 想定 | 2次が「うちファイン プレー件数」を任意 で手入力する方式に 確定 | 発見自体は1回目・2 回目チェックの通常 業務であり、優れた 発見かどうかの判定 には人の主観判断が 必要で、自動検知は できないと判明した ため |
| 4 | 2次担当者
自身の正確 性評価 |
未定義 | 数値評価はしない方 針で確定。審査目線 の統一はマニュアル 整備・情報共有等の 運用面で担保 | 2次より後工程のチ ェック役が制度上存 在せず、データで測 定できないため |
| # | 項目 | 変更前(当初) | 変更後(本日確定) | 理由 |
| 5 | 費目以外の 審査項目 | ①は費目(8項目)のみを対 象 | 費目外項目(概要説明 文評価・経常経費の 税込税抜整合性・取 得財産の計上確認 等)の存在が判明。案 件により作業量が変 動するものは①、ほ ぼ一定のものは②の 不備区分に仕分ける 方針 | ①が実際の審査全量 をカバーできていな かったため |
| 6 | 同一費目内 の負荷差 | 費目ごとの固定重み
(2.0/1.2/0.5)のみで計算 |
特に負荷の重い個別 案件への補正方式(A 案:案件単位フラグ/B 案:費目ごと補正列)
を検討開始(未確定) |
同じ費目でも案件に より実際の負荷が大 きく異なる実態があ るため |
| 7 | 役職による 評価基準 | 未定義 | 繁忙期にAD・ディレ クターが1回目/2回 目/2次を担当した場 合も、スタッフと同 じ基準・同じ計算式 で集計する方針を確 認 | 本制度はスタッフ評 価が主目的だが、担 当した工程には役職 に関わらず同じ物差 しを適用するため |
| 8 | 賃上げ特例 案件の位置 づけ | ①②③の設計に賃上げ審 査は未反映 | 案件数カウント方
法・特例書類確認負 荷の扱い等、検討が 必要な論点として認 識(未確定、ToDo化) |
現行モックアップ・ 設計メモのどちらに も賃上げ審査の評価 ロジックが存在しな いことが判明したた め |
ToDo一覧(会社で検討)
- 費目外審査項目の全量リストアップ:概要説明文評価・経常経費の税込税抜整合性・取得財 産計上確認 等を全て洗い出し、各項目が①(負荷量)行きか②(正確性の不備区分)行きか を、案件による作業量の変動有無で仕分ける
- 特例(賃上げ・インボイス・卒業 等)の添付書類確認負荷:①への算入要否を事務局と協議す る(制度改正が多い分野なのでノイズ化リスクも検討)
- 特例全体の制度への組み込み方の包括的整理:上記2の負荷算入だけでなく、案件数カウン トや担当者評価の要否も含めて検討
- 賃上げ案件の案件数カウント方法:通常審査と合算して1件とするか、別案件として+1件カウ ントするかを決定(②の分母定義に影響)
- 繁忙期に賃上げ審査だけを専任で担当するスタッフがいる場合、その人専用の評価が必要 かを検討
- 同一費目内で特に負荷が重い案件の補正方式(A案:案件単位フラグ+固定加点/B案:費目ごと の補正列)のどちらにするか決定。、2次の入力負担を増やさないシンプルな方式を優先
ク側で未解決・曖昧な論点
- ①の費目外項目の性質未確認:件数もの(複数回発生しうる)か、単発チェック(有無)かでテ ーブル設計(件数入力 or チェックボックス)が変わるため、リスト確定後に要判断
- 「貢献度(ファインプレー)」の運用ガバナンス未設計:2次の主観判断による手入力数値であ り、乱用防止や表彰・記録としての具体的な使い道(ランキング算出方法等)が未整理
- 「特に重い案件」補正の乱用防止:A案(主観フラグ)を採用する場合、②で一度封じた「判 断のブレ」の問題が①に逆流するリスクがあり、AD等によるスポットチェックの要否は未 検討
- 賃上げ審査ブロックの評価軸としての構造:通常審査の①②③とどう統合するか(共通軸に合 算するか、独立軸を新設するか)は未着手
- 現行Excelテーブル設計(設計メモ第4章)の反映漏れの可能性:①の8費目列化が第4章の移行 テーブルに反映されているか未確認。②の件数入力方式(1回目4区分+2回目4区分+ファイ ンプレー手入力2件=最大10列相当)も、現行Excelでの実装可否(列数・運用負荷)を精査し ていない
クロードが追加で把握したい情報(実データ不要・項目・構造・集計値の共有で可)
以下はすべて、個別申請者の実データは不要です。列名・項目名・大まかな集計値だけで十分です。
- 現行進捗管理表(Excel)の全列構成:列名・入力者・目的の一覧(列見出しのリストだけで十分)。既存と重複しない列設計にするため。
- 審査チェックシートの全審査項目一覧:費目審査以外に何を確認しているか(概要説明文評価・経常経費の税込税抜整合性・取得財産計上確認以外の項目名)。各項目について「1案件で複数回発生しうるか、、1回限りの確認か」も併記いただけると、①/②のどちらに寄せるかの判断に直結します。
- 過去の不備コメントの分類集計(件数の分布。個別コメント内容は不要):文章修正あり/見落とし軽微/誤指摘/見落とし重大 の実際の発生比率が分かれば、-1/-3/-5/-10という点数配分が実態に見合っているかを検証できます(現状はあくまで暫定値)。
- 賃上げ特例・インボイス特例・卒業特例等の具体的な確認項目一覧:それぞれ何を追加でチェックするか(書類名・確認内容の一覧)。
- 案件数・母数の運用ルール:再申請は何回でも同一申請IDとして扱うのか、賃上げ審査は通常審査と何案件としてカウントされているか、という現行の数え方の実態。
- AD・ディレクターが1回目/2回目/2次を兵務する頻度感(繁忙期にどの程度の割合で発生するか、大まかな比率で可)。
- 「特に重い案件」として現場で語られる具体的な特徴・実例(点数や件数ではなく、どういう性質の案件が該当するかの記述)。
- SharePoint移行の想定時期・予算感:今のExcel/Power Apps設計にどこまで投資すべきかの判断材料になります。
※特に③(不備コメントの分類集計)は、今-1〜-10で暫定的に置いている点数配分の妥当性を検証するのに直結するので、優先度が高いと思います。②(費目外審査項目それぞれが件数ものか単発チェックか)も、①②のテーブル設計そのものを左右するので早めに知りたいところです。
————————————–
＜評価を加えた画面での懸案事項＞
————————————–
保留中・未決定事項(要:会社で確認)
・再申請時の「2回目スキップ」:1回目のみ行い2回目を飛ばして2次に進む運用の可否、および誰が・いつスキップと決めるかは棚上げ。現状のラジオボタン方式では2回目を選ばずに2次だけを選ぶことは可能だが、それを正式に許可するかは未確定。
・通常審査/賃上げ審査の取り違え防止:本来別チームが担当すべき方を誤って選んでしまった場合のエラー表示は棚上げ。
・再申請の複数回対応:現行Excelでは列を増やせないため「再申請」は1つの状態としてのみ管理。SharePoint移行後は再申請が複数回(周回)発生する前提で、可変レコードとして管理する方針だが、具体的なテーブル設計は未着手。
・修正権限:入力ミスをスタッフ本人が直せるか、ADのみが直せるかは保留中。変更ログを残す方向性のみ決定済み。
・②正確性・貢献度の入力粒度:現行Excel上は暫定簡易方式(1回目/2回目それぞれ「精度判定」+「コメント採用有無」の計4列相当)で表示しているが、不備単位での完全な粒度管理(最大10列相当)はSharePoint移行後に再検討する方針。本パネルの②入力欄は暫定方式に基づく。
————————————–
人物評価制度 検討中の論点(ディレクターが事務局と相談中・要フォローアップ)
————————————–
・費目外の審査項目の全量リストアップ:概要説明文評価・経常経費の税込税抜整合性・取得財産の計上確認 等、費目に紐付かない審査項目を洗い出し中。各項目が①(負荷量。案件により作業量が変動するもの)行きか、②(正確性。作業量がほぼ一定でチェック項目として扱えるもの)行きかを、洗い出し後に仕分ける。
・賃上げ特例/インボイス特例/卒業特例等の添付書類確認負荷:通常審査より負荷が増える可能性があるが、頻繁な制度改正でノイズ化するリスクもあるため、①への算入要否を事務局と協議中。
・同一費目内でも案件により負荷が大きく異なるケースの補正方式:A案(案件単位で「特に重い案件」フラグ+固定加点)かB案(費目ごとに補正列を追加)かは未定。2次の入力負担を増やさないシンプルな方式を優先する方針。
・賃上げ特例案件の案件数カウント:通常審査と合算して1件とするか、別案件として+1件カウントするかは未定(②の分母定義に影響)。
＜最初の画面での懸案事項＞
————————————–
裏側の制御ロジック(見えない部分)
————————————–
・自己申告方式(ラジオボタン):案件の担当割り振りは引き続きSalesforce側で行い、Teams等で本人に連絡する現行運用を維持する。新システム側は割り振りを持たず、各審査工程(1回目/2回目/2次)の行頭にラジオボタンを置き、スタッフが自分の担当する工程を自分で選んでから開始/終了ボタンを押す方式にする。
・順序チェック:1回目が完了していない状態で2回目を選択した場合はエラーとする。このルールは初回審査・再申請ともに共通の絶対ルール。
・完了済み工程は選択不可:ステータスが「完了」等になっている工程のラジオボタンはグレーアウトして選べないようにする。
・二重着手の防止:「審査開始」を押す直前に、そのステータスが本当に「未審査」かを再確認する。未審査以外なら上書きせずにエラー表示し、既存の担当者名と現在のステータスを表示する。
・入力漏れの防止:「審査終了」を押すと終了日時は自動記録されるが、ステータス(不備あり/完了)を選択するまで保存ボタンは押せない状態のまま。
・自動打刻:開始・終了ともに日時と担当者名(ログインアカウント)は手入力不要。ボタンを押した瞬間に自動で記録される。
・経過時間の注意喚起:着手から2時間経過すると、審査員本人の画面に控えめな警告バナーを表示する(ADが声かけをしやすくするための、見られている感を意識づけるナッジ)。
・業務終了ボタン:押すと、自分が担当中で「一時審査中」のまま残っている案件がないか自動チェック。日をまたいで作業を続ける場合は「持ち越し」ステータスを選べる。
・状態遷移:未審査 → 一時審査中 → (持ち越し) → 不備あり/完了 の順に進み、逆戻りや飛び越しは通常操作では発生しない設計。
・初回審査/再申請ラベル:検索した案件が初回審査か再申請かを、会社名の横にバッジ表示する。現時点では表示のみで、それ以外の制御ロジックは持たない。
・賃上げ審査ブロック:賃上げ特例を申請した事業者のみ、通常審査とは別に1回目・2回目・2次のトリプルチェックの表示ブロックが現れる。対象外の事業者ではこのブロック自体が表示されない想定。
・2次評価入力パネルの表示条件:ログイン中ユーザーの担当ロールが「2次」であり、かつ行頭ラジオボタンで「2次」工程が選択されている場合にのみ、作業パネル内に人物評価入力パネル(①対応負荷量・②正確性)を表示する。1回目・2回目担当者がログインした場合はこのパネル自体が表示されない。③対応速度は新規入力なし(既存の開始/終了日時タイムスタンプから自動算出)。評価入力値は「審査終了・保存」ボタン押下時に案件データと一括保存され、専用の保存ボタンは設けない(1画面完結の原則を踏襲)。評価対象は初回審査のみで、再申請案件ではこのパネルを表示しない。
・②正確性の入力方式(確定):1回目・2回目それぞれについて、不備区分(文章修正あり-1点/見落とし・軽微-3点/誤指摘-5点/見落とし・重大-10点)ごとに「件数」を入力する方式とする(単一のプルダウン選択ではない。1案件内に複数の不備が発生するケースに対応するため)。案件スコア=100−(区分別件数×点数の合計)を1回目・2回目それぞれで自動計算する。
・ファインプレー加点はスコアに含めない(確定):正確性スコア自体には加点しない(荒れた案件を担当した人が統計的に有利になる不公平を避けるため)。ファインプレーは自動検知できない ー 不備を発見すること自体は1回目/2回目チェックの通常業務であり、「発見した」件数と「特に優れた発見だった」ことは別物で、後者の判定には2次の主観的判断が必須となるため、件数入力欄とは別に「うちファインプレー件数」の手入力欄を設ける(2回目の功績分・2次自身の功績分の2つ)。参考として通常の自動集計(総発見数)もあわせて表示し、2次が判断する際の目安とする。
・2次担当者自身の正確性は数値評価しない(確定):2次は最終ゲートであり、この制度内に2次の不備を発見する後工程が存在しないため、2次の正確性はデータでは測定しない。審査目線の統一はマニュアル整備・担当者間の情報共有など運用面で担保する方針とする。なお繁忙期はAD・ディレクターも1回目/2回目/2次を担当することがあり、その場合も同じ基準・同じ計算式で集計する(本制度は主にスタッフ評価が目的だが、担当した工程には役職に関わらず同じ物差しを適用する)。