『否』のときだけ詳しく書く

ほとんど「良」なのに、全項目に所見を書かされる。いざ異常のときは、余白が足りない。点検表のこのくせは、設計で直せます。

普段は速く、異常のときは詳しく

点検は、**ほとんどが「良」**です。毎回、全項目に所見を書かせる作りは、書く人にも読む人にも負担になります。

一方で、「否」のときは、詳しい情報が必要です。

• どこが、どのように悪いのか
• 写真はあるか
• すぐ対応が必要か、様子を見るか

この差を、点検表の設計に反映させます。

2つの作りを比べると、次のとおりです。

全項目に所見欄

「否」のときだけ詳しく

毎回、すべての項目に書く

「良」は1タップで次へ進める

異常のとき、余白が足りない

「否」で備考と写真の欄が開く

ほとんど空欄の所見が並ぶ

書かれた所見は、すべて意味がある

異常を書くのが面倒になる

入力が軽く、異常を記録しやすい

設計の考えかた

判定	画面の状態
良	何も出ない。次の項目へ進める
対象外	何も出ない。次の項目へ進める
否	備考と写真の欄が開く。理由を入れないと次へ進めない形にもできる

点検の入力画面では、たとえばこう動きます。「否」を選んだ項目だけ、下に備考の欄が開いています。

• 2番と4番が「否」で、赤く表示され、備考が開いている
• 「良」の項目には、何も開かない
• 欄の下に「6/6項目」「否2件」と出る

こうすると、次のよい点があります。

1. 普段は1タップで済み、速く終わる
2. 異常のときだけ、必要な情報が確実に集まる
3. 画面がすっきりして、迷いにくい

「否」のときに残す情報

詳しく書くといっても、長い文章は求めません。

• 備考: 症状を一言（「軸受から周期的な異音」）
• 写真: 異常の様子（全体と近く）
• 対応の種類: 「すぐ停止」「次回交換」「経過観察」などを選ぶ
• 対応期限: 必要なら、いつまでに直すか

選ぶ形を多くして、書く量を最小にします。

不具合につなげる

「否」が出たら、記録で終わらせず、次の動きにつなげます。

• 一覧で「不具合あり」の件数がすぐ見える
• 不具合がある点検は、報告書として別の様式でも出せる
• 対応する人に通知が届く（詳しくは「不具合の対応状況を追う」で説明します）

「否」から対応までの流れを、図にします。

否を選ぶ備考と写真→一覧に「不具合」が出る→報告書として出せる別の様式でも→対応する人に届く通知

「否」を付けやすい空気づくり

「否」を付けると、手間が増える、責められる、と感じると、人は「良」で済ませがちです。「否」は異常を見つけた手柄だ、という空気を現場の班長が作ることが大切です。「否」が出たら「よく見つけた」と声をかけ、そのあとの対応を一緒に考える。入力の軽さと同じくらい、この空気が点検の質を左右します。

「否」の記録は、次の点検の人にも役立ちます。前回に「否」だった項目が目に入ると、確認の注意が自然に向きます。記録が、次の点検の手がかりとして働く形にすると、点検全体の質が上がります。

まとめ

• 点検はほとんど「良」。普段は速く終われる形にする
• 「否」のときだけ、備考と写真の欄を開く
• 残す情報は、選ぶ形を中心に最小限にする
• 「否」は記録で終わらせず、対応につなげる

Formia でやるなら

Formiaの判定リストでは、判定ごとに「理由の入力を求める」「理由を書けるようにする」「出さない」を選べます。「否」を選ぶと、備考と写真の欄がその場で開きます。「問題として数える」を入れた判定は、一覧に「不具合N件」と出ます。設定は チェックリスト項目 と 必須と入力チェック の記事を見てください。

設計画面では、判定ごとに設定します。「否」には「理由の入力を求める」「問題として数える」のチェックが入っています。

設定した結果は、一覧の「点検チェックリスト」の列に出ます。

• 「問題として数える」を入れた判定が、「不具合N件」として数えられる
• 不具合のない点検は、「問題なし」と表示される

関連する記事

• 良い点検チェックリストの作りかた
• 写真を証拠として残す
• 不具合の対応状況を追う