ベイジの今西さんの「ミスが少ないweb制作会社を目指して～実践している16の取り組み」をモノづくりに当てはめ、
「ミスが少ないモノづくりを目指して：実践したい16の取り組み」
をまとめました。
Web製作の過程で発生しがちなミスを減らすための16の取り組みは、モノづくりにも参考になります。
モノづくりとヒューマンエラー
モノづくりの仕事は、要求される品質（Quality）を見たし、計画通りのコスト（Cost）で作り、出荷納期（Delivery）を守るために様々なミス（ヒューマンエラー）をなくすための取り組みを続ける仕事とも言えます。
モノづくりのミスは、会社の規模に限らず多かれ少なかれあるもので、なかなかゼロにすることができず、日々苦労しているケースが多いと思います。特に人による作業や目視で確認する部分（プロセス）に原因のあるミスはヒューマンエラーと呼ばれ、ミスをゼロに近づける努力が続けられています。
ヒューマンエラーがやっかいなのは、思い込みや勘違いなど、単純なミスでも、それを本人自ら検出することが難しいからです。
モノづくりでの目視検査であれば、センサーやパソコンなどを利用して人が判断しない検査にすることでヒューマンエラーを防ぐ方法もありますが、現実問題としてはコストがネックとなり導入が難しい場合が多いです。そして、ダブルチェックという、「ヒューマンエラーを防ぐために人がチェックする」という何ともすっきりしない対策を取ることになります。
だからといって、ダブルチェック、トリプルチェックやチェックシートを作るといった確認作業を増やしていくと、
- ミスを防ぐためのチェックをする時間（工数）が増える。
- コストパフォーマンスが落ちる（時間当たりの生産数量が減る）。
- 納期に間に合わない。
- 急ぐため、確認工程を省かないと間に合わないので手を抜く。
- ミスが起きる。
といった悪循環に陥ることになります。
以下、ミスの少ないモノづくりのための取り組みを紹介します。
ミスが少ないモノづくりの16の取り組み
始めはミスを減らすための取り組みだったのに、手間が増えているのにミスが減らず、お客様も含め誰も喜ばない結果になってしまうのでしょうか？
「ミスが起きたから今後同じミスをしない」と考えるのではなく、前提として「ヒューマンエラーによるミスは発生する」と考え、品質、コスト、納期のバランスを見ながら、ミスの発生確率を下げたり、ミスが起きた場合に速やかに対処できる仕組みを作ることが必要です。
ここでは、ベイジさんのWeb製作の過程で発生しがちなミスを減らすための16の取り組みをヒントにモノづくりについてまとめていきます。
1.マルチタスクを避ける
マルチタスク、例えばパソコンであれば複数の計算を同時並行して処理するということですが、人は同時に２つ以上のことをすることはできません。
似たような作業を並行して行う場合もありますが、これは同じ作業を並行して行う場合であり、実際に行う作業内容が異なる場合には、平衡作業はミスを起こしやすくなります。
また、国内の製造業においては多能工の例もありますし、大量生産の自動車業界でも実際には多品種の少量生産となっており、１つ１つの作業を確実に進めることがミスをなくすモノづくりのポイントなのではないかと考えています。
マルチタスクをするとミスを起こしやすくなるというのは、個人の力量の問題ではなく、マルチタスクが人には向いてないということです。
マルチタスクが得意な人の作業を詳しく見てみると、例えば複数のプロジェクトを処理する場合であれば、各々のプロジェクトのプロセス毎に優先順位をつけて次々と処理していて、１度には１つのことを行っているのに１日とかまとまった時間でみると同時並行的に処理しているように見えるだけのことが多いです。
マルチタスクが原因で担当者にミスが発生している場合、そのミスの本当の原因は、担当者にマルチタスクを要求しているマネジメントの問題となります。
マネージャーはもちろん、マネージャーではなくても、誰かに重要な仕事を頼む場合（得てして納期も厳しい場合に多いのですが）、ミスが許されない作業をする場合には、マルチタスクを避けて１つの作業（重要な仕事）に集中できる状況にあるかどうかを含めて仕事（作業）をお願いした経験がありませんか？
重要で急ぐ仕事を頼みながら、簡単に終わる作業だからと割り込みをいれていませんか？
そして割り込みを入れた結果、重要な仕事が見込みまでに終わらず、仕方なく自ら処理したことはありませんか？
特にマネージャーであれば、上司であれば、マルチタスクを極力避けるような指示（仕事の依頼方法）をするべきだと考えています。
この辺りを理解している部下であれば、重要な仕事が入りそうだとか、割り込みが入ることを前提に仕事（作業）のやり方や進め方を考えて対応しているのですが、残念ながら上司の方がそれに気づいていない場合の方が多いようです。
ベイジさんでは、メンバーのスケジュールを立てる際に以下のことに配慮して、マルチタスク化を極力避けるマネジメントをしているそうです。
- 一日に一案件を原則とする
- それが難しい場合、数時間単位でできるだけまとめる
- 突発タスクが発生して無理が生じる場合、計画自体を見直す
どの様な仕事にも共通する内容だと思いませんか？
決してできないことではないと思うのですが、続けていくことが難しいようです。
2.午前と午後で仕事を変える
１日の時間の使い方で、仕事の内容により時間帯を意識していませんか？
体調による時間帯の使い分けも同様です。
例えば、
- 頭を使って考える仕事は午前中の早い時間帯に取り組む。
- 手を動かす様なルーティン作業は、昼食後とか今一つ調子が出ない時に進める。
といったことです。人によっては、意識せずとも仕事と時間帯をうまく組み合わせているかもしれません。
この様な経験から、午後になると思考力が落ちたり、集中できる時間が短くなってくるのは人として当たり前のことだと考えています。
疲れてくれば考えはまとまりにくいですし、疲れていてもできる作業的なこともあります。したがって、効率よく仕事を処理するためには、以下の様に仕事の内容によって、時間帯を使い分けた方がよいと考えています。
例えば、次のような仕事はできるだけ午前中に取り組みます。
- ミスが許されない数字のチェック
- 考えを整理するなど集中力を要すること
- 認識違いを避けたい大事な打ち合わせ（意見交換）
- 細かいルールのある作業
午後は次の様な仕事をします。
- ある程度ルーチン作業になっている仕事
- 報告や共有を目的とした会議
- 細かな差異がない、ざっくりでよい仕事
仕事によっては、上記の様に都合よく予定を組めない場合もありますが、ミスを少なくするために、仕事の内容により時間配分を考慮することも有効な手段になると考えています。
朝型、夜型とかいうのは、起きてから頭が動き出すまでの立ち上がりが速いと朝型、なかなかエンジンがかからないのが夜型なのかと思っています。
3.突発的に話さない
上司に話しかける場合と、部下に話しかける場合とでも違いますが、これまでに本当に困った例を紹介します。
技術系の職場で主語を言わずに話し始める上司への対応は、なかなか難しかったです。上司と仕事でのコミュニケーションは取れていると思っていましたが、思い当たる案件や優先している案件が上司と自分とでは違う場合には全く話がかみ合わないので、何の話なのか探ったり、忙しいときは失礼承知で確認するようにしていました。
通常は、基本的に相手が上司でも部下でも、
- 様子見て話しかける。
- 今すぐに聞かなくてよいことは整理しておいて、話しかけてもよさそうなタイミングで２つ３つ聞くようにする。
ようにしています。
技術や情シスのマネージャーの時は、基本いつでも声をかけてOK、話しがあるなら私のスケジュールに予定を入れる（グループウェアに予定を入れておく）ように言っていました。
私の場合にはこうすることで、わずかな変化やトラブルになりそうな兆候が察知できました。
上司や部下に話しかけるタイミングをなぜ考えていたかというと、
- お互い暇ではないので集中している時は邪魔をしたくない。
- 割り込みはミスの原因になる。
- 割り込みが続くと、割り込みに対応するためにその人のパフォーマンスが落ちる。
と考えていたからです。
このため相手の様子と聞きたいことの緊急性や優先度を考えてから話しかけるようにしていましたが、結果として雑談は自分からはあまりしないことになり、見る人によっては何をしているか分からないといったマイナスの評価やイメージを持たれることもあったようです。
「ちょっといいですか？」と気軽に話しかけられる環境は大事ですが、特にデスクワークが主体の職場では、いつでも話しかけてしまうことにより仕事の質を下げることにもなるので何らかのルールは必要だと考えています。
仕事をしているアピールをする人の話は、聞いていてなかなか厳しいものがありますが、人事が絡んでいるケースも多く現場での対応が難しい問題だと考えています。
ベイジさんでは次の様なルールがあるそうです。
- 相談事が発生した場合、まずチャットで用件を伝えてから会話する。
- 突発的な会話は、結論から話すなど、できるだけ短時間で済ませる。
- 会話が5分以上になる場合は、改めてミーティングを設定する。
このようなルールを作り守る職場に巡り合ったことはありませんが、新型コロナで在宅ワークが珍しくなくなった今、改めて考えてみる価値はあると思います。
4.口頭は避けてテキスト化する
例えば、口頭で何かをお願いしたときに、
- やって欲しかったことと実際のアウトプットが違う。
- 緊急性（いつまでに）が伝わらず、すぐに取りかかって欲しいのに後回しにされた。
といった経験はありませんか？
口頭で伝えることは、コミュニケーションが取れている状態でも簡単なことではないと考えています。
「口頭は避けてテキスト化する」というのは、文書化というとちょっと大げさですが、何かを頼む側にも頼まれる側にもメリットがあります。
- 依頼側であれば、何をいつまでにということが具体的になります。
- 頼まれた方は、いつまでに何をやればいいのかが具体的に分かります。
急いでいるからこそ、いつものことであるからこそ、意外な落とし穴があるように思います。何か頼むときは、テキスト化することで思わぬミスを防ぐことができます。
口頭：顔をみながら
口頭にも直接顔を見ながら説明する場合には、相手の表情や様子からも伝わっているか分かりますし、直接、期限や内容を確認することができます。
それでも、「言った、言わない」の問題は出ますので、口頭で伝えるのは以外に難しいことなのだと考えています。
技術的なことやちょっと複雑な内容を口頭で伝えるのは、後で大変な思いをすることさえあります。悪気はなくとも自分の都合によいように、分かりやすいように受け取りがちだからです。
電話
電話の場合には直接顔を見て伝えるよりも、自分で思っている以上に「言ったつもり」が増えてしまいます。
電話で指示を受ける方も、何の話なのか状況が分かりませんし、急ぎであればなおさらのこと、電話での言葉から受け取る情報が限られてきます。聞き洩らしをなくす、全てを聞き取ろうとして頑張る努力は認めますが、肝心なことが伝わっていなかったということも珍しくありません。
指示を出す側と、受ける側とで、「分かるだろう、こういうことかな？」という推測で話が進みがちなのでなおさらです。
伝える側が内容を整理して、受け取りやすい言葉で伝えることが重要になります。
メール
日本語力の問題が出てきます。
何をいいたいのか分からないメールもあります。
分からなければ、メールで具体的に確認したいところですが、急いでいる場合には、電話で聞いた方がよいこともあります。
日本語は難しいです。
SNS、チャット
LINEなどのSNSは速報性に優れますし、写真や動画のやり取りも簡単にできますので、うまく使うと便利なツールだと考えています。
しかし、速報性があるからこそ、伝えたいことを受け取りやすい順番で知らせることが重要になっているのではないでしょうか？
会社でSNSを使う前には、セキュリティの仕組みと利用者の教育・訓練が不可欠だと考えているので、あまり気乗りしませんが、これは情報システムでの経験があるせいかもしれません。
時と場合によっては、メールや電話の方が適している場合もありますので、うまく使い分けられるようにしたいものです。
なお、口頭で指示した場合には、電話後メール等で共有することが必要です。
「言った、言わない」は、お互いに得るものがありません。
メールなどでテキスト化してあれば、内容の確認、記録として残るので後から調べたりすることもできるようになります。口頭での逐次の指示をタスクリスト化していくのも一考の価値があると考えています。
5.伝達方法をフォーマット化する
報告漏れや連絡を忘れたといったミスを減らすためには、
- 報告や連絡の伝え方、伝える内容を書式化（フォーマット化）すること
が有効です。
書式かする際には、5W1Hをもれなくというのではなく、もっと具体的に、使いやすく書式化しておくことがポイントになります。
不具合が発生し報告する場合であれば、次のような項目にしておき、すぐに埋められない部分は空欄でよしとし、まずは第一報を発信することが必要です。書式になっているということは、項目が明確になっていることでもあり、電話で伝える場合にも使えます。
- 発生日時
- 発生場所
- 不具合の報告者（誰から連絡があったか）
- 不具合の発見者（誰が不具合を見つけたか）
- 不具合の対象（製品名、型番）
- 数量（納入数量、不具合数量）
- 状況
- 現場確認結果
例えば、進捗報告であれば、次のような項目を決めて報告するようにします。
- 計画に対する進捗率
- 本日の作業内容
- 課題や問題
- 確認事項
報告する項目を決めておくことで、次の様な効果も期待できます。
- 何を報告するか考えなくて済む。
- 報告する項目ではなく、報告内容に注力できる。
- 人による報告内容の差が小さくなる。
- 報告して欲しい内容が得られる。
- 抜け漏れを減らすことができる。
これ以外にも、
- 報告はまず結論から伝える。
- 詳細な経緯などは、後で説明する。
ことで、
- 報告しやすく
- 報告を受け取りやすく（時間短縮の効果が期待できる。）
といったことが進み、情報を伝えることに起因するトラブルを防ぐことができるようになると考えています。
6.表記方法を定義し、日常的に使う
表記方法を定義するとは、表記ゆれをなくすことです。
例えば、表計算ソフトでデータを扱う場合、表記ゆれがあると別のデータになってしまうため、データ分析をする前には表記ゆれのチャックをして、修正が必要になります。
データ作成が定期的にある場合には、表記ゆれをチェックシート（表記方法の定めた一覧表）を使いデータを修正します。
表記ゆれを修正する際には、目視ではどうしても漏れが出ますので、検索と置換を使っています。
置換する場合は、ちょっとした注意（工夫）が必要な場合があります。
例えば、「マーカー」と「マーカ」が混在している場合には、まず、
「マーカーをマーカに置換」
してから、
「マーカをマーカーに置換」
します。
表記ゆれの統一対象の例を列挙します。
- 西暦か、和暦か。
- 年月日は、2020年10月10日とするか、2020.10.10とか。
- 時間は、半角数字を使う。10時10分、10:10。
- 文書の章番号、半角で統一、1 1.1 1.1.1、1 1-1 1-1-1など。
- 送り仮名、取組、取り組み、取組みなど。
- 株式会社は、株式会社、(株)。
表記ゆれをいきなりゼロにするのは、なかなか大変ですし、現実的には無理がありますので、少しづつ表記方法を決めた言葉を増やしていきます。
表記ゆれに注意することは、言葉を正確に扱うことにもつながるので、徐々に表記ゆれが少なくなっていくことも期待できます。
7.ファイルの管理方法を統一する
毎年使用するファイルは、
- 年度別にフォルダを作成する。
- 年度別のフォルダ内のフォルダ名を決める。
ことで、管理する側も、実際に使う側も便利になります。
１人で担当している仕事のファイルだからファイル管理は自分だけが分かればよいということはありません。
例えば、インフルエンザで出社できなくなることもあります。このような場合には、他の誰かがフォルダを見てある程度分からないと、サポートしようがありません。
最低限「どこに何があるのか」とリストなどのデータを追加する記録については、「最新版がどれか」が分かるようにしておく必要があります。
年度別のフォルダの例ですが、
- 予算
- 品質計画
- 教育・訓練計画
- ISO審査
- JIS規格
- クレーム
- マネジメントレビュー
- 内部監査
- 会議資料
- 外注先評価
- 外部提出文書
- 議事録
- 台帳
- 通達
ファイル名のルールとしては、
- 年月日_分類１_分類２
- 年月日：20201010、201010でもよいのですが、日付不明の場合、西暦4桁の方が見やすい？
- 分類１：文書の種類（申請書、メール）
- 分類２：ファイルの内容が分かるタイトル
最新版の管理にはバージョン管理ツールを使う手もありますが、毎日バックアップを取っていればファイルが壊れても前日分までは戻ることができます。
なお、バックアップについては、何のためにどこまで必要かだけでなく、費用対効果をよく考える必要があります。
極論ですが、安心を買うだけにいくら費やすのか、事業を再開するために不可欠な情報は何か洗い出すことが必要になります。
8.更新箇所を明確にする
品質マニュアルや関連規定の改訂では、改訂履歴に変更箇所を明記するようにしていますが、改訂履歴に詳細を入れ込むのではなく、改訂部分が分かればよいと考えています。
規定改訂で変更部分を目立つように色分けすることもあるのですが、完成前に色分けを戻す作業が必要になるのは面倒ですね。完全に電子化してしまえばよいのでしょうが。
何かのきっかけで、かつての改訂理由に想いを馳せるようなことはあっても、品質マニュアルや規定では改訂部分を遡って調べることはほとんどないように思います。
改訂履歴は見ても改定時に１度だけですし、改訂履歴を調べたい場合には背景などの情報が欲しかったりしますので、規定等の改訂履歴は改訂部分が分かればよいと考えています。
モノづくりであれば、図面や仕様書などの変更が少なくありません。
例えば、次のような運用をしていても、
- 図面では変更箇所は明記しますが、変更理由等の詳細までは分からず、関連資料などを残すようにする。
- 仕様書などの文書では、改訂履歴に加え変更箇所が分かるようにする。
今回の変更については、変更になった背景などを含めた詳細な理由を残しておきたいことがあります。この場合、どこまで何を残すかのさじ加減が難しいと思っています。
例えば、残された情報が多すぎると結局調べ直すことになりがちなので、変更理由は簡潔にまとめ、修正するための資料を見た方が分かりやすい時はとりあえず資料を残しておくこともあります。
これは、変更理由を知りたくなった時に分かればよいという考え方です。
時間の経過と共に記憶は薄れてきますし、変更理由や資料を見ても分からなくなってきますが、その時はまた検討すればよいと割り切ってしまうのも一手だと考えています。
１年、２年と時が過ぎれば状況もずいぶん変わっています。過去にこだわるより今とこれからを考えればよいと考えています。
9.自動化ツールを活用する
同じことを繰り返す作業は苦手です。
- １時間集中してやれば終わる。
- １日頑張れば先が見える（あらかた終わる）。
と判断した場合には、頑張ってやるかと思い取り掛かるのですが、
- 急ぎの仕事
- 電話
- 問い合わせや相談
などで、作業が中断すると思わぬミス（通常は起きないミス）が発生してしまいます。
ミスは人が目でチェックしてのミスなのでミスがゼロにはならないことは理解しているつもりなので、次の様なマイルールとしています。
- 単純作業の場合には、考えずに、判断することなく繰り返し作業が進むようにする。
- 中断した場合には、途中までの作業は最初からやり直す。
さて、本題の自動化ツールはとても魅力的ですが、次の様な前提があると考えています。
- 自動化ツールの前に、対象となる作業の標準化、マニュアル化が必要です。
- 初めての人でも間違えずに作業ができるやり方が決まっている。
また、作業の中に判断が必要であれば、
- 判断基準、処理手順を決めておく。
ことが必要です。
例えばマニュアル作成を始めた場合、大なり小なり判断が必要になるのですが、これを完全に盛り込もうとすると結構面倒なので、例外処理で済ませたくなります。しかし、例外処理は間違いなく手作業で属人化しがちなので、避けては通れない道になります。
シンプルな作業に分解するとかえって手間が増えそうですが、シンプルな単純作業は確実に処理できるため自動化に適しています。
自動化というほどではないのですが、私はシステム化できない定型作業をエクセルで作り込む場合、社内に専門部署や担当がいないのであれば、エクセルの標準関数（最新の関数は使わない）を使った処理にするようにしています。
私は、エクセルの関数なら頑張って何とか読みますが、マクロを分かりやすいプログラミングで作るスキルはありません。
マクロはクセがあり過ぎて中途半端なので、自動化するならコストはかかりますがツール導入がよいと考えています。
以上、自動化ツールについてまとめると、
- 作業手順が決まっているルーチンワークは、大抵自動化できる。
- 最初の準備に時間はかかりますが、ミスを減らし作業時間を大幅に短縮できる。
つまり、
- 手作業をやめて自動化していくことがミスを減らすことになる。
現在作り込んだエクセルを使った業務があるのですが、データベースとレイアウトや印刷、エクセルデータも書式情報が必要なので、代替手段がない状態です。サイボウズのメールワイズが使いやすかったので、予算の問題はありますが、kintoneはいつか使ってみたいと思っています。
10.複数人でチェックする
複数人でチェックする方法には、ダブルチェックとクロスチェックがあります。
- ダブルチェックは文字通り、複数の人で同じことをチェックする方法
- クロスチェックは、複数の人でチェックしますが、チェックする観点が違う方法
基本的に自動化できない仕事は、人が確認するしかありません。
自動化できない理由にはコスト的な問題もあります。
人が確認する以上、ミス（ヒューマンエラー）は起こります。
ヒューマンエラーを少なくすることはできますが、ゼロにはできないということです。
例えば、製品の出荷を例に、誰が何をするのか時系列で列挙してみます。
- お客様の注文
- 製品Ａを１個、12月23日18時までに、現場に届けて欲しい。
- 出荷指示者
- 出荷伝票（製品Ａ、１個、配送日時、配送場所）を作成、出荷担当者に送る。
- 出荷担当者Ａ
- 出荷伝票に基づき、製品が保管されている場所から、製品Ａを１個取り出す。
- 出荷担当者Ｂ
- 出荷伝票通りの製品、個数を確認する。
- 梱包担当者Ａ
- 梱包前に、出荷伝票通りの製品、個数、配送日時・場所（運送会社の伝票）を確認する。
- 梱包担当者Ｂ
- 出荷伝票通りの製品、個数、配送日時・場所（運送会社の伝票）を確認し、梱包する。
- 梱包担当者Ｂ
- 出荷品置場に移動する。
- 出荷（＝運送会社の引き取り）
- 配送担当者
- 出荷されたことを確認する（運送会社の伝票の控えを出荷支持者に戻す。）
この例では、
- 出荷する製品の種類、個数をダブルチェック
- 梱包前に、種類、個数、出荷先（出荷伝票）をダブルチェック
しています。
ヒューマンエラーとダブルチェックを意識させる方法の１つは、チェックリストや作業手順書を作業者自身が作ることです。
これにいより、ミスをする人がミスを少なくする対策を考えることから始まります。なぜミスをするのか、間違えないためにはどうするか、ダブルチェックをなぜやるのかを理屈ではなく、現場作業での必要性から理解するようになります。
また、対策を決めたら、それを忘れずに続けられるように、上長などが繰り返し注意喚起をしていくと、ダブルチェックが当たり前のことになり、習慣化することができます。
一言で言えば、
- ミスしない方法を作業者が考え、決めた対策を続けること
なのですが、なかなか続けられないようです。
上述の内容をもう少し詳しく説明します。
出荷作業は、出荷品ごとに毎日実施します。
出荷品の確認時間は慣れてくればある程度は短くなりますが、
- 割り込みの仕事などが入りダブルチェックを省略してしまう。
と、出荷ミスが発生します。
また、
- 担当者Ａが、ダブルチェックは担当者Ｂさんがするから大丈夫だろうとチェックを省略する。
- 担当者Ｂさんが、担当者Ａさんがチェックしたから大丈夫だろうとチェックを省略する。
と、出荷ミスが発生します。
出荷ミスなどでクレームとなった場合には、次のような主旨の話をしますが、何度でも繰り返される場合には組織的な要因もあったりして困ったものです。
- 「Ａさんだから大丈夫」という考えは、「Ａさんがチェックしたから大丈夫、ダブルチェックしなくてよい」とＢさんが個人的に（独自に）判断したことと同じですよ。
- 出荷関連のミスは、ヒューマンエラーが多く、ヒューマンエラーは、完全になくす、ゼロにすることができないものです。
- 出荷ミスはお客様からの（会社としての）信頼を一瞬で失うことにつながります。
そして、
- 「忙しいから、面倒だから」とか言い訳せずに、時間がなくてダブルチェックできないのであれば、「現場で判断せず上長に相談する」とか、「担当者間で作業分担などについて考えてみる」とかしませんか？
と言ってまとめています。
残念ながら、ミスが繰り返される現場に共通しているのは、ミスを防ぐために自分たちで決めたことさえ続けていくのが難しいようです。掲示や手順書の作成に加え、毎朝の作業指示の際、リーダーや上司などにより繰り返し注意喚起をすることが必要なのですが、どうも続けることが苦手な場合が多いようです。
ヒューマンエラーを防ぐためには、ダブルチェックやトリプルチェックなど、複数人でのチェックをしなくて済む方法（プロセス）に変えていくのが望ましいと考えています。
しかし、現場だけで進めるのは難しいという現実は受入れるしかありませんが、少しでもミスを少なくしたいといった現場の声があると、何とかしたい、手伝えることはないかなど考え始めることができます。
11.細かな工程表を作る
プロジェクトは特別なものではなく、規模の大小はあれど仕事はすべてプロジェクトと言ってもよいと考えています。
モノづくりであれば、大きなところは品質工程図、作業単位では作業手順書やチェックリストを準備すことが相当します。
新製品の開発プロジェクトの様に、実際に使うことができる細かな工程表を作れる状況であればそれを利用すればよいのですが、そうでない場合には、次の様な状況なのではないでしょうか。
- そもそも主要メンバーが兼務となっている。
- 緊急な割り込みが日常的に入る。
- 割り込みに対応できるのは、プロジェクトの成否を握る人だったりする。
この様なプロジェクトの場合には、
- プロジェクトの目標や期限（納期）に向けて同じ方向を向く
- 特に悪い情報や聞きたくないことを早目に共有する
のも大変です。
私は、プロジェクトを成功させるためには、次の様なリスク管理と察知力が重要だと考えています。
- リスク管理とはプロジェクトの人の管理、プロジェクトの成否を左右する人が誰かを見極めること
- 察知力とは、プロジェクトの進捗や成否にかかわる状況（プロジェクト成功の鍵を握る人への影響）を知ること
ここでの質問「細かな工程表を作る」の回答はタスクわけから始めることかと思っていたがさすがベイジさん、もっと先に進んでいましたので、紹介します。
ベイジさんでは、全社共通のプロジェクト管理シート（テンプレート）を準備しており、プロジェクトが始まるとこのテンプレートから必要なタスクを取捨選択して、そのプロジェクト用の管理シートを作り全員で週一のチェックをしているそうです。
モノづくりの標準的なテンプレートが必要ということなので、タスクについては別途読んでみたいと思います。
なお、この管理シートに記載されているタスクについては、以下のページをご参照ください。
12.リスクを事前に洗い出す
プロジェクト管理と聞くと大規模建造物や新製品開発など何か特別なことをイメージしますが、実は規模の差こそあれど大小様々なプロジェクトがあります。
プロジェクト管理のキーワードは「マネジメント」です。日本語の管理は「コントロール」といった意味合い（イメージ）を強く感じますが、私は以下の定義がしっくりきています。
- マネジメントとは、何とかすること
- ちなみに、経営＝manage＝やりくりして何とかすること
例えば、商品企画担当時代を振り返ると、新製品開発（プロジェクト）を成功させるために最も重要なのは、リスク管理、具体的には納期管理だと考えており、当時担当者として心がけていたのは次の２点でした。
- どんなに準備をしても想定外は起こる
- 見込みが外れた時の対応策を考えておく（決めておく）
もちろん、新商品そのものの要求、要求仕様なども重要なのですが、それだけではないのです。企画した商品が売れるまで、ネガティブな意見はなくなりませんが、それを気にしないで済む環境（上司やチーム、支えてくれる経営層）もポイントです。また、プロジェクトの主要メンバーの人選の影響は大きいので、運も実力のうちだと考えています。
プロジェクトに取り組み始めたことからリスクについて考えていたわけではありませんが、大小様々な仕事（プロジェクト）を通して、プロジェクトを成功させるためには、何のためのプロジェクトであるか目的を明確にし、具体的な目標を設定することが必要だと考えています。
しかし、これだけでは不十分なのが現実で、想定外は普通に起こりますので、プロジェクトの成功に影響するリスク要因について事前に洗い出し対策を決めておくことは、とても重要です。
ベイジさんのブログを見てから、「リスク管理は察知力」、「プロジェクト成功の可否は誰が握っているのか」と考えてしまうことは、実はプロジェクト管理を属人化して考えているからではないかと思い始めました。
以下は、ベイジさんのブログから引用しますが、属人化しないように仕組みや文書化がされているそうです。私はここまでは考えが及んでいませんでした。
以下の３文は引用符を使うこと！！！
損失を生じうるリスクを把握して、その影響を事前に回避もしくは事後に最小化する対策を検討する活動は、プロジェクト管理の根幹を成していると考えています。
そのリスクの中でも、事前に想定されるものについては、発生確率や影響度の査定、リスクの事象や要因、影響度などをリストアップして共有しておけば、トラブルを未然に防ぎ、さらには例えトラブルが発生しても、冷静に速やかに対処することができるようになります。
特に深刻なリスクについては、リスク管理表をプロジェクトごとに用意して、想定されるリスクを事前に検討しています。
余談になりますが、
「プロジェクトを成功させるにはどうしたらよいのですか？」
と聞かれることがあります。プロジェクト（新商品企画・開発）の成功経験はありますが、それでも非常に説明しにくい質問の１つです。
答えの１つとして以下の記事にまとめてみました。
また、今やプロジェクトマネジメントの手引きがJIS「JIS Q21500：2018 (ISO 21500：2012) プロジェクトマネジメントの手引」となっています。プロジェクトマネジメントと言えば、プロジェクト憲章というものがあります。難しそうですが、プロジェクトの目標達成に必要な合意事項です。
以下の記事にまとめています。
13.ミス発生時の心理ハードルを下げておく
ミスの中には対応方法を誤ると、
- 対外的にはお客様との信頼関係を失ってしまう。
- 社内的には各部署間や部署内の人間関係にも影響を与えてしまう。
ことがあります。
そもそもなぜミスは起きるのでしょうか、例えば製造不良が起きた場合、
- 作業手順からジグの作成、作業の自動化などにより再発防止を図ることができるミス
- ヒューマンエラーと呼ばれる人の判断に関わるミス
とに分けることができます。
設計、製造、出荷において人の目で確認しているプロセスでミスが発生した場合、自動化などにより対策できる場合はよいのですが、ヒューマンエラーの場合にはミスが続くと皮肉なことに人が何とかするしかないという状況になってしまいます。
ヒューマンエラーによるミスの場合、対策として「ダブルチェックをします」がありがちです。
ダブルチェックによりミスの発生を減らすことはできるのですが、ミスを無くす、ゼロにすることはできません。そもそも人は間違えるものですし、同じ作業をするにしても、忙しかった、急ぎの別の仕事が割り込んできた、電話に出た、体調が悪かったなど、ミスの理由は様々です。
ミスをするからダブルチェックにしたのに、
- ＡさんはＢさんが後でチェックするからと確認が甘くなった。
- ＢさんはＡさんなら誤りなくチェックしているだろうと考え確認が甘くなった。
といった様に、ミスが繰り返されるには、
- 「決められたことを確実に行う」という当たり前のことを繰り返し続けることができる。
ように習慣化するまで、教育し、訓練し、注意喚起を行い続けるしかありません。
一方、別の視点でミスについて考えてみます。
ミスが起きた場合に最も対応に困るのが、「ミスの報告が遅い（結果的にはミスを隠されたと思われてしまうような状況）」です。
この辺の気持ちは分からないでもないのですが、クレーム処理を担当する側からすると、起きてしまったミスを無かったことにはできないので、例えミスしたことが他の人にみつからなかったとしても、ミスをしたら直ちに同僚や上長に報告するようにして欲しいと切に願っています。
たいていのミスは、ミスが発生した直後の素早い初動により、ミスによる影響を最小限に抑えることができます。これは、お客様にとってもミスによる影響範囲を限定できるということです。
これが、例えば小さな製品トラブルだからと隠されてしまうと、問題が表に出た時には、お客様も含めて問題そのものよりも会社対会社の問題として大事（おおごと）になってしまいます。こうなると、「何とかしてください。」と泣きつかれてもどうにもできず、我ながら事務的に処理を進める形になってしまい、なんともいえない気持ちで対応したことがあります。
ミスはない方がよいのですが、ゼロにできないのもミスです。このことを社内に周知し、ミスが起きてしまったら直ちに報告するようにすることが重要です。
プロジェクトや製品開発などでもミスやトラブルは発生しますが、これは何とか少なくしたいものです。このような場合には、発生する可能性のあるミスやトラブルを事前に、関係者間で共有しておくことが対策となります。
「一言言っておいてくれればよかったのに」とか、「なぜ事前に教えてくれなかったの」といった言葉を聞いたことがあります。事前にミスやトラブルの可能性を関係者間で共有していれば、今よりはよい状況になったろうにと思うこともありました。
事前にミスやトラブルの可能性を話すと、「対策しろと言われてさらに仕事が増えてしまう」と思われる方もいるかもしれませんが、それは、ミスやトラブルとは別の問題なのではないでしょうか？
14.危機的な状況を共有する
危機的な状況というと、危機管理という言葉を思い出しますが、ここではビジネス上のピンチという意味合いで危機的な状況のことです。
天変地異や自然災害でいう危機管理とは違うということです。
私は、進行中のプロジェクトにおいて、リスク管理をしていても起きてしまった危機的な状況に対しては、プロジェクトマネージャーやリーダーが自ら判断し、その判断基準、理由を含めて危機レベルと内容を説明し、関係者間で共有すればよいと考えていました。
ベイジさんはもっと具体的で、危機的な状況を共有するだけでなく、仕組み化までしています。
危機管理の仕組み化まで考えが及びませんでした。
ここまでやらないと実際に行動はできないということだと受け止めています。
以下、ベイジさんの危機的な情報を共有する取り組みについて、私が経験した製品開発プロジェクトを例に私の理解した内容で説明します。
そもそも営業、技術、商品企画間に信頼関係のない（コミュニケーションがとれていない）状態で、営業の新製品が欲しいという声に応えるための商品を企画したことがあります。
いざ蓋を開けてみると、営業は「欲しいものはなんでもありの高級機を低価格」で、技術は「既存製品のメンテナンス開発で協力できない」というような状況でした。
幸い利益を見込めるアイディアがあったので、プロジェクトを進めて成果を残すことができたのですが、関係者間の信頼関係に問題があったため、上司は社内の人間関係（社内政治）が原因でプロジェクト中断や中止とならないように、キーマンの状況とプロジェクトの直接の担当者の状況を常に把握し、火消しをしたり、プロジェクトの責任者を励ましたりといわゆるお偉いさんや重鎮と呼ばれる方とのコミュニケーションを頑張っていました。
上司のこの動きがなければ、そもそもプロジェクトは始まらなかったのですが、「製品開発（モノづくり）は人が最も重要」と改めて認識するよい経験となりました。
ベイジさんには、「プロジェクト警報システム」という仕組みがあるそうです。上記のケースでは、商品企画の担当者や上司がその役割を果たしていたということになると考えています。
ベイジさんは受託開発をされていますので、複数のプロジェクトを並行して走らせていると思われます。プロジェクトの依頼者はお客様であり、トラブルの発生そのものは許容できても、お客様との信頼関係に影響を与えるような状態にならないようにする必要があります。
それは、プロジェクトのマネージャーやリーダーの仕事だと言えばそれまでですが、これでは危機管理のノウハウが属人化するだけで、同じような失敗を繰り返すことになってしまいます。
そこで、ベイジさんでは、プロジェクトが危機であることをメンバー間で共有するため、【注意報】や【警報】を定義した「プロジェクト警報システム」という仕組みがあるそうです。
プロジェクトで危機が近づいているような状況になった時に、【注意報】や【警報】といった定義に従いメンバー間で共有する仕組みは、プロジェクトに関係するすべての人にとってよい仕組みだと考えています。
ベイジさんの【注意報】と【警報】を以下に引用しますが、具体的で分かりやすい言葉で書かれており、形だけの警報システムではないことが伺えます。
ベイジさんのルール
- プロジェクトが【注意報】や【警報】という状況に陥った際は、プロジェクトのチャットのチャンネル名に、これらの表示を追加する。
- 例えば、「ABCプロジェクト」に注意報が発令された場合、チャットのチャンネル名が「ABCプロジェクト【注意報発令中】」となるような仕組み。
この、【注意報】【警報】の基準は、以下のように定義しています。
【注意報】の発令条件
- 誤字やリンクミスなどの軽微なミスを、2度顧客から指摘される
- 「もう少し慎重に確認してもらえますか」などの注意を受ける
- 機密情報の漏洩に繋がりかねない対応をした
- ベイジ側の要因で、納品/公開が延期になった
- 顧客がベイジの対応に満足していない（ディレクター判断）
- 修正指示の量が多く、不満を感じている（ディレクター判断）
【警報】の発令条件
- 顧客から管理体制などについて呼び出された
- クライアントから強い口調で叱責された
- ベイジ側の要因で、 納品/公開が二度延期になった
- 上長と話がしたい、と言われた
- その他、危険な状態になっている判断される場合（ディレクター判断）
幸い、このシステムを導入して以降、注意報も警報も発令されたことはありません。しかし、長く仕事をしていればいつか発令される日が来ると思っています。そうなった時は速やかに判断し、プロジェクト内の緊張感を高めるようにしたいと思います。
15.プロジェクト終了後、すぐに対策を検討する
プロジェクトをPDCAに置き換えても、同じことが言えます。
PDCAが回らない場合、そもそもPlan（計画）で止まっていることもありますが、折角Do（実行）しても、
- 結果を振り返らない。
- 前回と同じことを繰り返す。
- 失敗やミスも同じように繰り返してしまう。
という笑い話のようで笑っていられないケースは少なくないと考えています。
設計、製造、検査、出荷などで大きな問題が発生した場合でも、その場限りの対応で何とか済ませて（丸く収めて）、本質的な問題には目をつぶりフタをしてしまうことがないでしょうか？
問題やトラブルの対応中は、トラブルを収束させることを最優先にするため、本質的な問題点が分かっていても、別の対策により解決を図ることがあります。
解決の糸口が見えてきたら本質的な問題点を解決するための原因究明や対策を本格的に検討し始めるのですが、問題が解決してしまうと「とりあえず今回は収まったからこれでいいじゃない」という悪魔の囁きがどこからともなく聞こえ始め、いわゆる「なかったことにしたい」という空気が出てきます。そして、忘れる間もなく似たようなトラブルが発生し、前回同様フタをする。
どうしてこうなってしまうのでしょうか？
直接的ではなくてもミスや失敗をした個人を責めたり、精神論で何とかしろ言ったことがあったのではないでしょうか？
トラブルや問題が発生した場合には、
- 社内ルール（仕組み）として関係者間で問題点や対策を共有する。
- 必要に応じ社内ルール（ISO規定など）や業務フローを見直す。
- 対策を仕事の仕組みに反映させていく。
ことが重要です。
仕事の仕組みにまで対策を反映させないと同じ問題が再発するのは、どうやら間違いないようです。
仕事である以上、「またか」と問題の再発に慣れてしまうことだけは避けたいものです。
16.人ではなく仕組みを見直す風土を作る
失敗は繰り返さなければよいと考えています。
例えば製品クレームが発生すると、原因調査が始まります。最優先は、お客様に対する対応であることに異論はないと思います。
次は、クレームの原因調査です。何が起きてクレームとなっているのか、不具合の発生原因は、不具合品が社外に流出してしまった原因はなどを調べ始めます。
注意しなければいけないのは、ミスにより発生した不具合の場合に、ミスをした個人を責めることのないようにすること、原因を聞く際にも「ミスを繰り返さないために教えてください」といった様に、ミスをした個人を責めることのないように配慮します。
個人を責めるような組織の場合には、なかなか実際にあったこと、本当の理由を話してくれなくなります。誤った原因をもとに対策を進めるとさらに困ったことになるのですが、ミスをした当事者や部署、部署長の心理というのは分からないものです。
原因の調査方法には、定型的な対応手順があるわけでもなく、それ以前にコミュニケーションが取れていることの方が重要な場面もあります。
以下に少々長くなりますが、ベイジさんの記事から引用します。
行動指針として明確にしないとミスが発生した時に仕組みを見直すことが、なかなかできないのかもしれません。
そもそも人は完璧ではなく、誰もがミスを犯す可能性を持っています。ミスが起きたことは組織を成長させる改善点が見つかったと前向きに捉えて、一人に責任を負わせず、組織全体で改善に取り組む必要があります。
私たちは、全社員に当てはまる「プロフェッショナルの条件」という行動指針と、主に管理者やリーダー職が対象の「良い上司の条件」という2つの行動指針を持っています。行動指針は、作っただけでは、日々の業務の中で忘れてしまいがちなため、行動指針から引用して日報を書くことで、定着を図っています。
ベイジでは行動指針の中の最終項目として、以下のように失敗に関することが書かれています。
会社紹介 2つの行動指針
8.プロフェッショナルは失敗から学ぶ
8-1.失敗は根本的な原因と影響範囲を考えろ。起こった事象を把握するだけの薄っぺらい考察は無意味だ。
8-2.他人の失敗も自分の失敗と考えろ。より多くの失敗体験が成長スピードに影響するからだ。
8-3.失敗には痛みが伴うと考えろ。痛みがあるから、失敗から学べるのだ。
8-4.失敗の改善は、精神論ではなく具体的なプロセスで考えろ。精神論は思考停止を意味している。
8-5.失敗したらすぐに原因を考え、すぐに対策を実行しろ。失敗を寝かせておくほど馬鹿な行為はない。
8-6.失敗をチャンスに変える努力を怠るな。失敗した時の対応こそ、信頼を得る絶好のチャンスである。
8-7.失敗しても、再挑戦しろ。失敗のリスクから逃げていると、失敗は失敗のままで終わる。
こういった考えを日頃から浸透させることで、人ではなく仕組みで解決する、という風土を作るところから、対策を打っていこうと考えています。
まとめ
以上、ベイジさんの「ミスが少ないweb制作会社を目指して～実践している16の取り組み」の16の取り組みをモノづくり視点でまとめました。
ミスを減らしていくためには、ミスは起きるものだという前提に立ち、仕組みや組織を作り上げていくことが必要です。
ベイジさんは、すごいです。まだまだ学ばせて頂けそうです。業種問わずナレッジベイジは一度目を通されてはいかがでしょうか？おすすめです。
