#174 施工スケジュール（工程表）

本書について

これは 「UI診断」（¥100,000・税別）で実際にお渡しする報告書の見本です。題材は私たち自身が作った画面（GUNJO コールドテスト #174）で、他社の画面ではありません。

開示の範囲は、次のとおりです。

---

0. 検品の記録（メタデータ）

---

1. 判定

1-1. 総合判定

要再構築

判断点（修正コスト）＝「構造からやり直す方が安い」

確定Issue 18件（＋候補2件）／引用のないNo 0件／パネルの集約への上書き なし

1-2. 6観点のスコアと3段階判定

スコアはレビュアーに付けさせず、レビュアーが付けた Severity から機械が導出します（Severity→スコアの導出規則は 2026-08-05 に確定済み。規則そのものは完全版には収録しています）。

3段階判定＝要再構築。判定は3段階（出してよし／要修正／要再構築）で、スコアの平均からではなく Severity から機械的に導出されます（→ 1-3節）。

スコアの読み方（0〜5スケールの定義）：5＝問題なし・この観点で出して良い／4＝軽微・出せるが改善余地あり／3＝要改善・出す前に手を入れたい箇所がある／2＝重い・この観点が事業目的の妨げになっている／1＝破綻・この観点でユーザーが目的を達成できない。

この画面は、Trust（2.00）だけが「事業目的の妨げ」の水準にあり、他の4観点は「出す前に手を入れたい」水準です。判定が要再構築になったのは平均が低いからではなく、Critical が1つあり、その修正コストが構造だったからです。

Feasibility が N/A である理由：静止画検品では実装の壊れやすさを判定できないからです。※ ただし静止画でも分かる範囲の実装所見は取れました＝D-2「テーブルの列幅に余裕があるか」＝No 12/12（工種名という主キーが既定データで既に「…」に省略されている）・D-3「長い文字列で崩れないか」＝No 11/12。採点しないことと、見なかったことは別です。

1-3. 判定はどう出たか（機械の担当と、人の担当）

① 12体のレビュアーが、観点ごとに「最も重い問題の Severity」だけを付ける（スコアは付けない）
② 書記が集約規則で束ねる → Trust ＝ Critical（2.00・Criticalを立てたのは 6/12）
③ 確定済みの導出規則で観点スコアへ（Trust 2.00／他4観点 3.00）　※集約と導出の規則は完全版には収録
④ 判定フォーマット 第2章 → Critical観点1件 → 「要修正／要再構築の判断点」で停止
────────── ここまでが機械。ここから先が人 ──────────
⑤ 審査担当が修正コストを判断 →「構造からやり直す方が安い」→ 要再構築

1-4. 所見（署名＝審査担当）

この画面の目的は「現場監督が工種ごとの進捗と遅れを掴み、今日どこに手を打つかを決める」ことである。しかし画面は、工程表・遅延一覧・作業行・人数といったセクションを並べているだけで、その判断を支える構造になっていない。

当日の稼働人数が画面内で3通りに食い違う（26名／内訳20名／基礎工事8名／同作業行6名）、打設前に立上り型枠が解体されている、工程表が工期の約1/6しか映していない——これらは個別の不具合ではなく、「誰が、いつ、何を判断するために見る画面か」が設計されていないことの現れである。

したがって数値の整合を取るだけでは目的を満たせない。修正コストは局所ではなく構造であり、判定は要再構築とする。

1-5. 「作れたか」と「出せるか」は別の物差しです

この画面は、私たちのコールドテストで 4/5 の評点が付いていました。その評点は「デザインシステムのコンポーネントが業種をまたいで嵌まったか」を測ったもので、画面としての品質を測ったものではありません。

この2つが同じ画面で並ぶことが、検品という仕事の存在理由です。tsc が緑であることも、コンポーネントが嵌まったことも、「出していい画面か」の答えにはなりません。

---

2. ピンマップ（どこを、何体が、何と言ったか）

画面のキャプチャの上に、指摘の位置をピンで置いた地図です。 ピンをクリックすると「どのレビュアーが・どの設問で・何と言ったか」が全件出ます。生成は機械化されていて、書記が手で決めるのはピンの座標だけです（文面はレビュアーの回答から直接引くため、本文と食い違いません）。

緑（良い点）も同じ地図に載せています。批判だけの地図にしないためです。この画面で全員一致だった良い点は5件あります（→ 第5章）。

---

ピンマップ（画面の上で、どこを・何体が・何と言ったか）

パイロット第2巡／12体のレビュアー・二段階・盲検／質問票 v0.4.0（toB業務画面 53項目）／最終判定＝要再構築（審査担当・2026-08-04）

受付で記録した画面の目的（1行） 「現場監督が工種ごとの進捗と遅れを掴み、今日どこに手を打つかを決める」この1行が、問題の重さ（Severity）を判定する基準です。

この画面の最終判定は「要再構築」です（審査担当・2026-08-04提出／判断点＝修正コストは局所ではなく構造）。ここに出ているピンは判定の材料になったレビュアーの声であって、判定そのものではありません。

ピン29箇所

評価の総数（延べ）251件 / レビュアー12体

No（問題あり）20箇所 / 154件判断できない3箇所 / 27件良い点6箇所 / 70件

ピンの一覧（体数の多い順）

3. Top 1 Issue（この1件だけ、直し方まで書きます）

3-0. なぜこの1件を選んだか（選定：書記）

確定Issue 18件から選んだのは「当日の稼働人数が画面内で食い違う」です。理由は5つあります。

1. 12/12 の全員一致。盲検の12体のレビュアーが例外なく指摘しました（18件中、最も強い信号のひとつ）。
2. 唯一の Critical 観点（Trust）の最重量です。 Critical を立てた6体すべてが、その根拠欄にこの食い違いを書いています＝判定の導出に直結した事実です。
3. 審査担当の所見が最初に挙げた事実＝人の判定の核でもあります。
4. 静止画だけで第三者が追試できます。4つの数字はすべて同じ1枚のキャプチャに写っており、操作も実機も要りません。
5. 提案が「表示の手直し」ではなく「構造の設計」になります。 この1件を正しく直すと、別の確定Issue 1件（基礎工事の人数が2箇所で食い違う・12/12）と、別の全員一致No 2件（T3-5 語の統一／T1-2 数字の基準時刻）が同時に閉じます。「UI診断」（¥100,000）で何を設計するのかが、この1件で伝わります。

採らなかった候補（参考）

• 「工程の前後が成立していない（打設前に立上り型枠を解体）」——事実としては最も重い部類ですが、質問票にこれを書ける設問が無く、質問票上の体数は 3/12 に留まりました（Severity の根拠欄と自由記述まで含めれば 9/12 が触れています）。見本に載せるには「なぜ体数が少ないのか」の説明が要り、主役には向きません。※ これは画面の問題ではなく私たちの質問票の穴で、次巡で軸を新設します。
• 「ガントが工期全体を映していない（半年の工期に対し約4週分）」——11/12 と強い指摘ですが、提案が「期間の切替を付ける」で収束しやすく、設計の中身を見せる材料としては薄いと判断しました。

このあとの記述には「基礎工事 8名 対 6名」の食い違いも出てきます。これは確定Issue一覧では別の1件（→ 4-1節 の #2）で、Top 1 とは別に数えています。同じ原因（人数の出所が管理されていない）から出ているため、事実の説明と修正計画の中では切り離せません。

---

3-1. ISSUE #1 — 当日の稼働人数が、画面内で3通りに食い違う

① 事実（画面から）

26名・20名・8名・6名。同じ日・同じ現場の人数が、1画面の中で噛み合っていません。さらに、差の理由（管理者を含むのか、協力会社の内訳か、予定と実績の違いか）は画面のどこにも書かれていません。

さらにラベルも揺れています——上部は「本日稼働予定」、右カードは「本日稼働」。予定なのか実績なのかを、読み手が語から判断できません。

② なぜ問題か

これは「数字が1つ間違っている」問題ではありません。同じ事実についての集計が、画面の中に3つ独立して存在していることが問題です。

3つが一致していたとしても、読み手にはそれぞれが何を数えた数字なのかが分かりません（26は管理者を含むのか／作業予定リストは当日の全作業を網羅しているのか／工種カードの8名は作業行の6名と同じ母集団か）。合計と内訳が同じ画面に並んでいるのに、その関係が示されていない——ここが構造の欠陥です。

この画面の目的は「今日どこに手を打つかを決める」ことです。手を打つとは、人を動かすことです。その人数が読めない時点で、目的の達成が止まります。

③ ユーザー影響（レビュアーの声・引用そのまま）

#1 現場監督（Trust＝Critical の根拠欄）

「当日の人数が画面内で食い違う。上段『本日稼働予定 26名』に対し当日作業の合計は20名、基礎工事は『本日稼働 8名』なのに当日の基礎作業は『6名』。人数は明日の手配と出面・請求の根拠なので、この状態では数字を外に出せない」

#7 疑い深いユーザー（同）

「今日の人員という、まさに手を打つ対象の数字が画面内で食い違う。（略）当日の手配判断を直接誤らせる」

#9 事業責任者（同）

「出来高と人員をもとに手を打つ画面で数字が信用できないため、判断の土台が崩れる」

現場では「26名で段取りを組む」判断と「20名で段取りを組む」判断が別物です。どちらが正しいか画面から判断できない以上、利用者は画面を閉じ、別の手段（電話・台帳）で確かめ直すことになります。確かめ直しが必要な画面は、判断のための画面として機能していません。

④ 事業影響

#12 発注者・監理者（Trust＝Critical の根拠欄）

「同じ『本日の人数』を指す数字が画面内で3通りに食い違い、かつ全ての数値に基準時刻と算定根拠が無い。進捗と遅れを掴んで当日の手を決めるという目的そのものが成立せず、この画面の数字は報告にも判断にも使えない」

3つの層で効きます。

1. 業務：人数は手配・出面（作業員の出勤記録）・請求の根拠です。画面の数字が請求の根拠にならないなら、二重管理が発生します（＝この画面を導入した意味が消えます）。
2. 対外：発注者・監理者に出す資料の元データがこの画面です。数字が食い違う書類は、内容の正否以前に受け取られません。
3. プロダクト：ここが崩れると、画面全体の数字（出来高42%・遅延-4pt・工期）に対する信頼も同時に落ちます。信頼は項目ごとではなく画面ごとに失われます。

⑤ SUGGESTED ACTION（修正計画）

方針＝「表示を揃える」のではなく、「人数の出所を1つにする」。表示だけ揃えると、次のデータで再発します。

Step 1｜定義を決める（これが本体・画面の作業ではありません）

決めることは2つだけです。

• 「稼働」の定義：作業に就く実働者だけを数えるのか、管理・間接・搬入立会いまで含めるのか
• 集計の単位：現場全体／工種／業者のどれを一次データとするか

推奨＝「作業行の人員割当」を唯一の一次データにする（現場で実際に割り当てるのはこの単位だからです）。定義が2種類必要ならフィールドを分けて両方出す——たとえば「実働20名＋管理・間接6名＝計26名」と書けた瞬間、26と20は矛盾ではなく内訳になります。※ 差の6名が何を指すかは、この画面からは判断できません。それを決めるのが Step 1 です（画面の作業ではありません）。

Step 2｜画面を、一次データからの導出に組み替える

Step 3｜再発を止める（実装・同時にやると安い）

• 集計はデータ層で一度だけ行い、UIは表示に徹する（画面内に同じ事実の独立フィールドを作らない）
• 基準時刻を出す——「7/17 9:12 時点」。この画面には「最新に更新」ボタンがあるのに、いつ時点のデータかが書かれていません（T1-2＝No 12/12）。人数の出所を1つにする作業のついでに閉じられます
• チェック（実施状況の更新）が人数に影響するなら、反映のタイミングも同じ場所に書く

この1件を直すと、同時に閉じる全員一致No が2件あります＝T3-5（同じものを2つの語で呼んでいる・No 12/12）とT1-2（数字にいつ測ったかが添えられていない・No 12/12）。3つは別々の不具合ではなく、「数字の出所を管理していない」という1つの原因の3つの現れ方です。

工数の目安：表示側の実装は小さい（半日〜1日）。重いのは Step 1 で、これは画面の作業ではなく業務側の合意です（誰を稼働に数えるか）。ここを飛ばして表示だけ揃えると、次のデータで必ず再発します。先に決めるべきは、どこに何を出すかではなく、何を数えているかです。

⑥ 確信度：High

---

4. 残りのIssue

確定Issue の基準＝「2体以上が同一箇所を引用した指摘」（体数だけを基準にします。少数の視点が見つけた実害を消さないためです）。引用の無い指摘は集計から捨てています（この画面では引用のないNoは0件でした）。

4-1. 確定Issue（Top 1 の1件を除く 17件）

4-2. 候補（1体のみの指摘・確定にはしていません）

「N」丸バッジは画面の欠陥ではありません。開発ツールのボタンが撮影時に写り込んだもので、既知の事象として別に管理しています。審査対象から分離し、判定には算入していません。

---

5. OK項目（良かったところ）

批判だけの報告書にはしません。全員一致で「良い」と判定された箇所を、同じ地図に緑のピンで載せています。

この画面は雑に作られたものではありません。むしろ丁寧に作られており、上表のとおり評価された点が複数あります。それでも要再構築になる——それが、部品の完成度と画面としての成立が別物であることの実例です。

---

6. この判定はどこから出ているか

---

7. あなたの画面で、同じことをします

本書は、私たち自身の画面を検品した記録です。同じ物差し・同じ12体・同じ手順を、あなたの画面に当てます。