フールプルーフとは？ミスを防ぐ設計の考え方

フールプルーフ（foolproof） とは、人が操作を間違えることを前提に、間違った操作をできなくするか、間違いにすぐ気づけるようにする設計の考え方です。品質管理でいう「ポカヨケ」や mistake proofing と近い考え方です。

「担当者が注意する」「手順書をよく読む」だけでは、忙しさや経験の差によってミスが起きます。そこで、正しい操作を選びやすい形を作り、間違いが起きても次の工程へ流さないようにします。

身近な例で考える

場面	注意だけに頼る場合	フールプルーフを取り入れた場合
左右を間違えやすい部品	「向きを確認」と貼り紙をする	正しい向きでしか差し込めない形にする
入力フォームの日付	「未来の日付を入れないで」と説明する	選択可能な日付を制限し、送信時にも確認する
注文の確定	担当者が明細の有無を目視で確認する	明細がない注文は確定操作を受け付けない

共通しているのは、利用者の記憶や注意力を唯一の防波堤にしないことです。ミスをする人を責めるのではなく、ミスが起きる場所を設計で扱います。

「防ぐ」と「すぐ検出する」の二段階

最も強い方法は、間違った操作自体をできなくすることです。部品の形を変える、入力できる値を絞る、プログラムの公開操作を限定する、といった方法があります。

それが難しい場合は、間違いが起きた場所で検出し、次の工程へ進めないようにします。たとえば、注文確定時に明細がなければその場で理由を示して処理を止めます。後日、請求処理で気づくよりも原因を特定しやすくなります。

flowchart LR
    A["間違いが起きそうな操作"] --> B{"操作を防げる？"}
    B -->|はい| C["誤操作できない形にする"]
    B -->|難しい| D["その場で検出して止める"]
    C --> E["正しい結果へ"]
    D --> E

警告を表示するだけでは、警告を見落としたり無視したりできます。重要なルールでは、警告の後も誤った状態へ進めてしまわないかまで確認しましょう。

フェイルセーフとの違い

二つは組み合わせて使える考え方ですが、ここでは「人の誤操作」と「故障時の安全な停止」という着目点で整理します。分野によって用語の使い方が重なる場合もあります。

考え方	主に考える問い	例
フールプルーフ	操作する人が間違えても、誤操作を防ぐ・早く見つけられるか	明細がない注文を確定できない
フェイルセーフ	故障や異常が起きたとき、安全側の状態に移れるか	異常を検知した機械を停止する

たとえば、誤った条件で処理を開始できないようにするのがフールプルーフです。それでも機器が故障したときに危険な動作を続けないようにするのがフェイルセーフです。

ソフトウェアで取り入れる手順

1. ミスが起きる場所を特定する — どの操作で、何を取り違えたり、どの確認を忘れたりするかを具体的に書きます。
2. 守るべきルールを決める — 「数量は1以上」「確定後は変更できない」など、成立してほしい条件を明確にします。
3. できれば誤操作を不可能にする — 入力の選択肢や型、操作の入口を設計し直します。
4. 残るミスは直近で検出する — 操作を受け付ける場所で検証し、処理を止めて理由を伝えます。
5. 別の入口も確認する — 画面だけで防いでも、API、バッチ、データ移行が同じルールを迂回できるなら不十分です。

ただし、すべてのミスを一つの仕組みで防げるわけではありません。入力画面での案内、業務ルールを持つコード、データベース制約、テストなどを、ルールに応じて組み合わせます。

まとめ

フールプルーフは、人の注意を前提にした運用を、間違いにくく、間違えてもその場で止まる構造へ変える考え方です。最初に「どのミスを防ぎたいか」を特定し、誤操作をできなくする方法から検討します。

DDDのドメインモデルにこの考え方を当てはめる方法は、次の記事で解説します。

DDDで考えるフールプルーフ設計 値オブジェクトと集約ルートで、ルールの迂回を防ぐ

参考資料

• ASQ: What is Mistake Proofing? — ポカヨケの定義と、予防・即時検出の考え方
• NIST: fail safe — 故障が起きたときの安全側への動作に関する定義