ミスが少ないweb制作会社を目指して～実践している16の取り組み

web制作の仕事は、ミスとの戦いでもあります。

ベイジは数あるweb制作会社の中でも、比較的ミスが少ない方だとは思います。しかしそれでもゼロにはなりません。プロジェクトによっては、単純なミスを多く発生させてしまうことも未だにあります。

便利なツールは沢山存在しますが、人が手を動かし、目視で確認する部分はまだまだ多く残っています。機械化できないそうした箇所で、ヒューマンエラーが起こります。

やっかいなのは、自覚症状がないミスが多いことです。認識違いに起因する場合、本人では正誤の判断ができません。見れば分かる単純ミスも、根底にあるのは認知バイアスであり、それを自ら検出することは難しいものです。

だからといって、「チェックを増やす」「管理シートを作る」と確認工程を増やしていくと、労働生産性はどんどん悪化します。それはやがてコストパフォーマンスの低さ、競争力の低下に繋がっていきます。

「ミスを絶対に起こしてはならない」と一辺倒に考えるのではなく、ミスは必ず発生するという前提に立ち、品質、コスト、スピードのバランスを見極めながら、発生確率を下げる、迅速に対処できる仕組みを作るべきです。

本記事では、web制作の過程で発生しがちなミスを減らすために、特に有効だと私が実感している、ベイジの16の取り組みをまとめてみました。

1. マルチタスクを避ける

基本的に人間の脳はマルチタスクに向いていません。そのため性質の異なる作業を同時並行で行うと、ミスを起こしやすくなります。

このようなマルチタスクに起因するミスというのは、マネジメントの問題です。特にミスが許されない作業を行うときは、マルチタスクを避け、一つの作業に集中できる環境を作るべきです。マネージャーであれば、マルチタスクを極力避ける仕事の依頼の仕方をすべきでしょう。

実際ベイジでも、メンバーのスケジュールを立てる際に以下のことに配慮するなど、マルチタスク化を極力避けるマネジメントをしています。

• 一日に一案件を原則とする
• それが難しい場合、数時間単位でできるだけまとめる
• 突発タスクが発生して無理が生じる場合、計画自体を見直す

2. 午前と午後で仕事を変える

脳の司令塔となり、論理的な思考や自我を司る前頭前野がもっとも働くのは午前中といわれています。午後になると思考力が低下する、集中力が続かない、といったことは、努力不足でも意識が低いからでもなく、人の生理現象といえます。

このような脳の仕組みを考えると、午前と午後で仕事内容を変えた方がいいでしょう。

例えば、以下のような仕事は午前中にやるべきといえます。

• ミスが許されない集中力を要する仕事
• 認識違いを避けたい大事な議論
• 細かな配慮を必要とする作業

一方、午後は以下のような仕事をするといいでしょう。

• ある程度ツールで自動化できる仕事
• 報告や共有を目的とした会議
• 細かな精度を求められない仕事

チームやクライアントと仕事をしていると、このように都合よく予定を組めないこともあるでしょうが、可能な範囲で実践するだけでも、ミスの発生確率は変わってくるのではないでしょうか。

3. 突発的に話さない

「ちょっといいですか？」と突然話しかけると、相手の作業を止め、保っていた集中力が途切れてしまいます。当然、ミスの発生確率を高めます。

突発的な会話が長く続くと、今考えるべきではないことにワーキングメモリを使い、それまで集中していたタスクの細部を忘れてしまい、抜け漏れなどのミスは発生します。

気軽に話しかけられる環境を作ることは大事ですが、一方でデスクワークが多い私たちの会社では、無制限に話しかけることができる環境は、仕事の質を下げかねません。

そこでベイジでは、以下のようなルールを設けています。

• 相談事が発生した場合、まずチャットで用件を伝えてから会話する
• 突発的な会話は、結論から話すなど、できるだけ短時間で済ませる
• 会話が5分以上になる場合は、改めてミーティングを設定する

4. 口頭は避けてテキスト化する

口頭で伝えられると、認識違いや失念の可能性を高めます。ミスが起こった時に、「言った」「言わない」の問題に発展する可能性もあります。特に技術的なことや複雑なことを口頭で伝えるのは危険です。

会話から生まれた内容があれば、それはメールやチャットなどのテキストで共有しましょう。テキスト化しておけば、後から検索して確認でき、記憶違いを防ぐこともできます。電話で話した際も、電話の後に要点をメールで送るといいでしょう。

また、発生したタスクはToDoリストのような形でテキスト化しておけば、対応漏れの発生確率を減らすことができます。

5. 伝達方法をフォーマット化する

報告・連絡といった伝達漏れに起因するミスを減らすには、伝達方法をフォーマット化してしまう、というのも一つの手です。

例えばベイジでは、チャットでの進捗報告時は、「進捗率」「対応ページ」「残画面」「確認事項」などを記載したフォーマットを使っています。こうすることで報告精度の違いがなくなり、報告の負荷も減り、結果的に抜け漏れを減らすことができます。

他にも、報告は結論から伝える、詳細な要因や経緯はその後に説明するなど、報告しやすく、受け取り側の時間短縮にもなるルールをある程度決めておくと、情報伝達に起因するトラブルを防ぐことができるでしょう。

6. 表記方法を定義し、日常的に使う

web制作では、表記の揺れもエラーの対象になってしまいます。そこで表記統一シートを作成して、人によって表記の揺れが起きそうなものをあらかじめ定義しておくと、ミスの発生をある程度防ぐことができます。

プロジェクトによって内容はカスタマイズして使用しますが、以下のようなものです。

使い方としては、文章を一つずつ目視で確認するのだと、ミスの検出精度は高くならないので、検索＆一括置換の機能を用い、よく間違える言葉は効率よく置き換えていきます。

また、日常的な文章にも適応して社内で習慣化しておくと、表記の揺れに関するエラーの発生率はより低く抑えられるようになるでしょう。

7. ファイルの管理方法を統一する

チームで仕事をする場合、ファイル名やフォルダ名のつけ方は重要です。作業ファイルの取り間違いがあるとミスに繋がるため、誰が見ても「どこに何があるか」「最新ファイルはどれか」が分かるようにしましょう。

私たちの場合、プロジェクトに関するファイルは以下のフォルダ構成を基本としており、担当者が勝手にこの構造を変えることは原則禁止にしています。

また、複数人で頻繁に更新するようなファイルについては、バージョン管理ツールを導入するのが良いでしょう。最近のオンラインストレージ系のサービスは、数世代前のファイルには遡れることが多いので、このようなツールを活用するのも手です。

8. 更新箇所を明確にする

ドキュメント化するというのは、ミスを防ぐうえで有効な対策です。しかしそのドキュメントの運用方法がマズいと、ミスの温床にもなりかねません。

特に、要件定義書のような数十～数百ページにもなる資料が更新された際、どこが変更になったかが分かりにくいと、更新された情報を読み飛ばしてしまう恐れがあり、これがミスやシステムの不具合にも繋がる可能性を高めます。

資料の冒頭には更新履歴を入れる、修正が入ったページの右上には一目で分かるマークを入れる、修正箇所には赤い囲みをして文字の色を変えるなど、誰が見ても変更箇所や内容がひと目で分かるような工夫をしましょう。

9. 自動化ツールを活用する

そもそも人間は、正確性を求められる同じ作業の繰り返しや大量のデータ処理に向いていません。途中で集中力が途切れたり、疎かになったりして、ミスを起こすのが人間というものです。このような仕事は、どんどんツールに任せていくべきでしょう。

例えば、Excelに記載された大量の商品情報をCMSに投入していく作業なら、手作業でコピペを繰り返すより、マクロやアドオンツールを作成してデータを成形し、自動的にデータベースに流し込めるようにした方がいいでしょう。

作業の手順が決まっているルーチンワークは、多くの場合で自動化できます。初回の準備に手間がかかりますが、ミスを減らすと同時に作業時間も大幅に短縮できます。

ベイジでは、一部の業務についてはエンジニアがアドオンを自作し、単純作業におけるミスの発生を最小化するような取り組みをしています。エンジニアが在籍している制作会社であれば、ほしいツールが世の中にないなら、自分たちで作ってもいいかもしれません。

10. 複数人でチェックする

自動化できない仕事は、人が確認するしかないのですが、いかに十分に注意を払い、意識を高めて確認をしても、確認者が一人である限り、必ず一定の確率でヒューマンエラーが起こります。そのため、どうしてもミスを予防する必要がある場合は、一人ではなく複数で確認する体制を作るべきです。

品質管理に定評があるトヨタにおいても、厳しい品質を求められる最終工程では、ダブルチェック、トリプルチェックが行われているとのことですが、複数人で確認するというのは、単純ですが非常に効果があるミス回避法です。

例えば私たちであれば、フォームが送信できない、お問い合わせにリンクされていない、計測タグが機能していない、電話番号が誤っている、非公開のデータが公開されてしまう、といった事態は絶対に避けなければなりませんが、こういう領域についてはチェックリストを作成し、複数人でチェックを実施しています。

ただし、この複数人チェックをあらゆる箇所に適応すると、人の手と時間が際限なく奪われてしまい、組織の生産性が大きく低下してしまいます。そのため、複数人チェックは品質管理の最終手段と捉え、複数人チェックをしなくても済むようなプロセスを、まず考えるべきではないかと思います。

11. 細かな工程表を作る

数ヶ月にも及ぶプロジェクトの場合、各工程でやるべきタスクをリスト化しておかないと、本来やるべき工程を飛ばしてしまい、「必要なパーツを作成していなかった」「テストに必要な工程を飛ばして品質に影響が出てしまった」といった、タスクの抜け漏れに起因するミスやトラブルが発生します。

ベイジでは、受注から納品までのタスクを、サブタスクを含めて約140項目程度に分解した、全社共通のプロジェクト管理シートというものを用意しています。プロジェクトが始まると、このテンプレートの中から必要なタスクを取捨選択し、そのプロジェクト固有のプロジェクト管理シートを作ります。

そして実際のプロジェクトが始まると、週に一回プロジェクトメンバーでこのプロジェクト管理シートを確認し、各タスクの遅延や抜け漏れ、軌道修正がないかなどを、全員でチェックしています。

プロジェクト管理シートに記載されているタスクについては、こちらのブログ記事にも詳しく書いています。

2020年はこれをアップデートした、最新のワークフローとプロジェクト管理シートを公開しようと考えています。

12. リスクを事前に洗い出す

リスクマネジメントは、プロジェクトマネジメントの手法をまとめたPMBOKの一領域にもなっています。損失を生じうるリスクを把握して、その影響を事前に回避もしくは事後に最小化する対策を検討する活動は、プロジェクト管理の根幹を成しているといえます。

そのリスクの中でも、事前に想定されるものについては、発生確率や影響度の査定、リスクの事象や要因、影響度などをリストアップして共有しておけば、トラブルを未然に防ぎ、さらには例えトラブルが発生しても、冷静に速やかに対処することができるようになります。

ベイジでは、特に深刻なリスクについては、以下のようなリスク管理表をプロジェクトごとに用意して、想定されるリスクを事前に検討しています。

13. ミス発生時の心理ハードルを下げておく

ミスを発生させることの一番の怖さは、顧客や周囲の人との信頼関係を失ってしまうことです。ミスを100%防ぐことはできませんが、「手を抜いているのでは」「馬鹿にしているのでは」と思われて怒りを買うことは、100%防ぎたいものです。

一番の対策は、ミスの可能性を事前に告げて、心理的ハードルを下げておくことです。

OSやアプリに深刻な不具合があっても、ほとんどの人はMicrosoftやAppleに対して怒りをあらわにすることはありません。なぜなら、OSやアプリケーションには、一定の不具合が含まれると皆分かっているからです。これと同じことをすればいいわけです。

例えば私たちの会社では、キックオフミーティングやテスト公開前ミーティングなど、プロジェクト進行における重要なミーティングでは、その後に起こりえるトラブルをできるだけ共有しています。心の準備があれば、いざトラブルが起こっても信頼関係を損ねるほどのことには、普通なりません。

またこれによって、顧客と共犯関係になることもできます。無責任になるのはもちろん論外ですが、ミスやトラブルに対して、共に対処する関係を作っておくことは、プロジェクト進行上、とても重要なことだと思います。

14. 危機的な状況を共有する

プロジェクト内で顧客との信頼関係にヒビが入る様なトラブルが発生しても、それを感知しているのがディレクターなどの一部メンバーだけだと、さらに油断した対応を繰り返し、状況を悪化させてしまう恐れがあります。

そこでベイジでは、プロジェクトが危機的な状況に陥った時に、それをメンバーに共有する「プロジェクト警報システム」という仕組みを作っています。

具体的には、【注意報】【警報】という状態を定義した上で、プロジェクトがこれらの状況に陥った際は、プロジェクトのチャットのチャンネル名に、これらの表示を追加する、というルールです。例えば、「ABCプロジェクト」に注意報が発令された場合、チャットのチャンネル名が「ABCプロジェクト【注意報発令中】」となるような仕組みです。

この、【注意報】【警報】の基準は、以下のように定義しています。

【注意報】の発令条件

• 誤字やリンクミスなどの軽微なミスを、2度顧客から指摘される
• 「もう少し慎重に確認してもらえますか」などの注意を受ける
• 機密情報の漏洩に繋がりかねない対応をした
• ベイジ側の要因で、納品/公開が延期になった
• 顧客がベイジの対応に満足していない（ディレクター判断）
• 修正指示の量が多く、不満を感じている（ディレクター判断）

【警報】の発令条件

• 顧客から管理体制などについて呼び出された
• クライアントから強い口調で叱責された
• ベイジ側の要因で、 納品/公開が二度延期になった
• 上長と話がしたい、と言われた
• その他、危険な状態になっている判断される場合（ディレクター判断）

幸い、このシステムを導入して以降、注意報も警報も発令されたことはありません。しかし、長く仕事をしていればいつか発令される日が来ると思っています。そうなった時は速やかに判断し、プロジェクト内の緊張感を高めるようにしたいと思います。

15. プロジェクト終了後、すぐに対策を検討する

プロジェクトで問題が発生したときに、その場限りの対処だけで済ませてしまい、根本的な問題を解決しないままでいると、以降も社内で同じような問題が起きてしまいます。

そこでベイジでは、プロジェクト終了後の1週間以内にはディレクターが主導して「クロージングミーティング」という場を開催し、記憶が生々しく残っているうちに議論するようにしています。

クロージングミーティングでは、明らかになった問題を解決するためのtodoを必ず決め、仕事の仕方やルールに改善が必要な場合には、社内のワークフローやドキュメント類に反映していくなど、精神論ではない、具体的な仕組みに反映していくことで、ミスを再発させないようにしています。

16. 人ではなく仕組みを見直す風土を作る

ミスが起きたときに特定の個人を責めてしまうと、さらに萎縮して別のミスを引き起こす悪循環を生みかねません。また、人を責める組織では、ミスへの恐怖心が高まり、新しいチャレンジをしなくなります。

そもそも人は完璧ではなく、誰もがミスを犯す可能性を持っています。ミスが起きたことは組織を成長させる改善点が見つかったと前向きに捉えて、一人に責任を負わせず、組織全体で改善に取り組む必要があります。

ベイジでは行動指針の中の最終項目として、以下のように失敗に関することが書かれています。

行動指針8：プロフェッショナルは失敗から学ぶ

1. 失敗は根本的な原因と影響範囲を考えろ。起こった事象を把握するだけの薄っぺらい考察は無意味だ。
2. 他人の失敗も自分の失敗と考えろ。より多くの失敗体験が成長スピードに影響するからだ。
3. 失敗には痛みが伴うと考えろ。痛みがあるから、失敗から学べるのだ。
4. 失敗の改善は、精神論ではなく具体的なプロセスで考えろ。精神論は思考停止を意味している。
5. 失敗したらすぐに原因を考え、すぐに対策を実行しろ。失敗を寝かせておくほど馬鹿な行為はない。
6. 失敗をチャンスに変える努力を怠るな。失敗した時の対応こそ、信頼を得る絶好のチャンスである。
7. 失敗しても、再挑戦しろ。失敗のリスクから逃げていると、失敗は失敗のままで終わる。

こういった考えを日頃から浸透させることで、人ではなく仕組みで解決する、という風土を作るところから、対策を打っていこうと考えています。

まとめ

冒頭でもお伝えしたように、「ミスを絶対に起こしてはならない」と完璧主義を目指すのではなく、ミスが発生することを前提とした仕組み作り・組織作りが必要です。その再発防止のためには、個人の努力に依存しない、仕組みや文化といった対処が不可欠です。

私もディレクターとして数多くのプロジェクトを経験するなかで、大きなものから小さなもの、仕方ないものから、自分でも理解しがたい馬鹿馬鹿しいものまで、様々なミスを起こしてきました。

その経験から感じたのは、ミスを100%なくすことは難しいが、コミュニケーションの取り方に注意を払ったり、ミスを起こした後に適切な改善策を考えたりと、振り返りと再発防止策の実行を地道に繰り返していけば、ミスの発生率は減らせるということです。

避けなければいけないのは、ミスを起こしたまま改善策を講じず放置したり、精神論で終わらせたり、個人のせいにしたりすることです。組織全体で考え、仕組みで解決していかなくてはなりません。完璧主義でいることは現実的ではありません。ミスが起きても許容される環境作りも重要です。

こういったことを根気よく追及していけば、私たちが理想とする「極めてミスが少ないweb制作会社」に近付いていけるのではないかと考えています。