仕事にトラブルは付きものです。でも人間は楽観的なので、トラブルが起きない前提で考えてしまいがちです。

そうして楽観的に進めた結果、トラブルが起きて慌てたり、残業でカバーしたりします。

今回は次のような方のために、トラブルを未然に防ぐ方法を解説します。いずれも私が長年のマネジメント経験で実践してきたことや、よその失敗プロジェクトを見て気付いたことを基にしています。

• トラブルで悩むことがよくある
• トラブルに追われたくない
• 仕事を上手くできるようになりたい
• 新人や若手の教育を担当しており、トラブルを防ぐ仕事術を教えたい

なぜ仕事が後手に回るのか？

トラブルが起きてから慌てることのデメリット

多くの職場やプロジェクトにおいて、トラブルが起きてから慌てることはよくあります。そして犯人探しがお約束のように行われます。

トラブルの発生によってスケジュールもみるみる遅れ、残業も増えます。トラブル対応に追われ、残業もして、働く人みんなが心身ともに疲弊していきます。

失敗プロジェクトから学んだ予防の重要性

私は失敗プロジェクトをいくつも見てきました。その数は軽く10を超えています。

そしてそれらのプロジェクトに共通していることは、楽観的すぎる、すなわちトラブルが起きない前提で計画を立てているということでした。

しかし仕事にトラブルは付きものです。そしてトラブルは時間とともに、坂道を転がる雪だるまのようにドンドン大きくなります。

つまりトラブルを予測して対策を打った計画を立てること、すなわち予防が重要なのです。これが私が失敗プロジェクトを見て学び、自分自身で長年マネジメントをして実感している重要なことです。

トラブルの予兆

トラブルの予兆の例

以下のようなことでトラブルが発生しがちです。計画を立てる時点でこれらを洗い出し、起こりうるリスクを検討してください。そして影響が大きいと考えられる場合は予防策を検討してください。

認識違いが発生しうること

仕事において、認識違いが発生しうることは多々あります。認識違いがあると、後でやり直しが発生して、残業でカバーすることになります。

また間違って部品や材料を調達したり、間違って違う施設を予約してしまったりすると、損失が小さくないです。

その他にもシステムの改修でありがちなことが、対象環境（検証環境と本番環境など）を間違える、対象機能を間違える、開発者に仕様が正しく伝わっていないなどです。

これは私もやってしまったことがあります。これらもやり直しに週単位で時間を取られます。

後でひっくり返される危険性があること

聞いていなかった、認識が違った、イメージしてたのと違うなどは後でひっくり返される要因としてよくあります。

影響が多い人物に伝えていなかったために、作った成果物が承認されないということもあります。

ルールを事前に確認していなかったために、ルール違反で修正が発生することもあります。

言った言わない論争はありがちです。それゆえ会議では議事録を作って関係者に承認を得ることが慣習になっています。

システム開発ではシステムが出来上がってから受入テストが行われます。この段階で当初のイメージと違うというトラブルがよく発生し、大きな修正につながります。特に画面設計のやり直しが多いです。

不確定要素があること

不確定要素すなわちやってみないと解らないこともトラブルの元です。典型的な後で痛い目を見ることは下記です。

• やってみないと工数がいくらかかるか読めない（例えば誰もやったことがない、会社として初挑戦など）
• 技術的に実現可能かどうかが試してみないと解らない
• 交渉が上手く行かないと実現できない
• 協力を得られないとできない

これらは事前に所要工数を予測することが困難です。ザックリこれくらいといったところであまり当たりません。

よってできるだけ早く着手しておく方が良いです。後になってからでは期限まで時間が足りないということになりかねません。

グレーゾーンにあること

一般的に仕事は関係者が複数人参加して役割分担して進めます。ということは担当が誰なのか曖昧な仕事は誰もやらないということになります。

ここで業務が3種類あるとします。業務1の担当はAさん、業務2の担当はBさん、業務3の担当はCさんとしましょう。

ここで業務1と2の間に1.5みたいなグレーゾーンの仕事が発生したとします。AさんもBさんも自分の担当外だから勝手に手を出せません。

するとこの業務1.5という中途半端な仕事は放置されてしまいます。気付かないうちに仕事が放置されていたということが起きるのです。

特にこういうグレーゾーンの問題は大企業で起こりがちです。大企業ではルールや役割分担が明確だからです。

トラブルの予兆の見抜き方

上記のような典型的なトラブルの予兆が見つかったら、できるだけ早めにトラブルになったときの影響度や影響範囲、対策を検討しましょう。

また、もしかしたら○○（不都合なことやトラブルなど）が起きる可能性があることを放っておくのは止めましょう。

今対処すればすぐにできるけど、後になると問題が大きくなるということも少なくないです。

トラブルというものは時間や工程が進むとともに雪だるま式に大きくなっていくものです。火は小さなうちに消しておく方が安心です。後で火事になってからでは遅いのです。

具体的には下記のようなことは要注意です。後で大きな問題や厄介な問題にならないかよく考え、早めに対処しておいた方がよいです。

• この表現（絵でも文言でも）だと顧客は誤解しないか？
• 今合意を取っておかないと、後でひっくり返されないか？
• こういう事象が発生したら、このマニュアルで対応できるのか？
• こんなデータが入ってきたら、システムのこの機能はどう処理する？

2番目と4番目はありがちです。2番目は事前にやっておかないととても痛い目に遭います。

4番目は影響が大きいなら検討しておきましょう。システムは考慮することが多いですし、考慮が甘いと後から残業地獄を味わうケースがとても多いです（IT業界では炎上とかデスマーチと呼んでいます）。

私が失敗プロジェクトを沢山見て、自分自身が毎日定時帰りするマネジメントをやってきた体験から言うと、マネジメントは先手を取って動くことが大事です。

後で問題が大きくなる例

ここでは後で問題が大きくなる例として、システム開発でありがちな例を紹介します。

Aさんはシステム開発プロジェクトのリーダーです。システムを開発し、テストも終わりました。次は顧客による受入テストです。

しかしAさんには懸念事項があります。画面のデザイン、レイアウトについて顧客がどんな反応をするか不安がありました。

とはいえスケジュールにあまり余裕がないため、画面の実物を見せずにテスト完了を優先させました。顧客が持っている画面イメージは設計フェイズにExcelで見せた図です。実物の画面とはだいぶイメージが違います。

受入テストが始まって、いざ顧客に画面を見せてみると、イメージと違う、解りづらい、この文言だと誤解があるなどと言われてしまいました。

Aさんは前もってHTMLのデモページでいいから見せて意見をもらっておけばよかったと後悔しました。

実際にシステム開発ではウォーターフォール型開発の場合にこのようなことが起こりがちです。私は設計フェイズでサンプル画面による認識合わせを行うようにしています。

トラブルを未然に防ぐ「プロの仕事術」

認識違いを防ぐ

認識違いによるやり直しの損失は大きいため、認識違いを防ぐことが重要です。

認識違いを防ぐためには、認識違いが発生しやすい箇所や重要な個所について具体的に細かいところまで話すことが重要です。

認識違いを防ぐコツについて、こちらの記事に詳細を書いています。認識違いに悩む方は是非読んでください。

また図解によってイメージをつかみやすくすることも、認識違いを防ぐ上で有効です。

図解についてはこちらに詳細な記事を書いています。とても有効な方法ですので、是非身に付けてください。

先手を打ってトラブルの芽を潰す

マネジメントで重要なことは常に先手を打っていくことだと私は考えています。

「これくらい大丈夫だろう」という油断はトラブルの元です。「これを放置すると問題になるかな？」と考えてみましょう。

トラブルの芽が見つかり次第、すぐに対処することが重要です。そうすればトラブルに追われて残業三昧ということも減ります。

念には念を入れて確認する

「多分大丈夫だろう」という油断はトラブルの元です。不明確なことは念には念を入れて確認し、明確にしましょう。

後で問題が起きてから何とかするという考えでは、トラブルに追われてしまいます。

嫌な予感を放置しない

嫌な予感が的中することはあります。そして的中してからではトラブルに追われて残業三昧になり、疲弊するだけです。

よって嫌な予感がしたら早めに確認し、問題につながりそうならすぐに対処しましょう。

私も嫌な予感を様子見して痛い目を見たことがあります。

グレーゾーンにあることを放置しない

グレーゾーンにあること、すなわち担当者が不明瞭なことが見つかったら、誰がどうやって解決するのか早めに決めましょう。

誰しも自分の担当の範囲はしっかりやりますが、担当外の仕事は手を出しにくいものです。それゆえグレーゾーンにある仕事は放置されがちです。

誰もやってない仕事がいつまでも残り続けたら、後でトラブルになることは明確です。

特にシステム間連携でこのようなことが起こりがちです。システム内の開発や改修などはそのシステムを担当している人の仕事です。

しかしシステムの外の仕事は誰の仕事でもないグレーゾーンです。そこに最近増えているシステム間連携が登場すると、やる人がいない仕事が増えます。

こういう仕事を放置すると、プロジェクトの後半で気付き、慌てて対応することになります。よって早めに余裕をもって対応しましょう。

不確定要素は先に対処する

やってみないと解らないこと、自分たちのチームの都合だけで決まらないこと（顧客や他部署、他社の都合が絡むこと）、難易度が高いことは先に対処します。

これらは所要工数や所要期間が読めないため、後回しにすると期限に間に合わないということが起こりがちです。よって先に対処するのです。

リスクを見える化する

以上を踏まえた上で、計画時点でリスクを洗い出して一覧化しましょう。そして影響度、緊急度、影響範囲、事前に打てる対策を検討しましょう。

仕事を上手く進めるコツはリスクマネジメントをしっかりやることです。

リスクに応じたバッファーをスケジュールに入れる

スケジュールを作成する際、私はタスクの工数にリスク係数をかけるようにしています。

つまりリスクが高いタスクは見積工数が大きくなり、リスクが低いタスクは見積工数があまり大きくならないのです。

もちろん全てのタスクに高いリスク係数をかけたら、ぼったくりみたいな見積になってしまうのでダメですよ。

想定外に備えたバッファーがスケジュールには必要です。

リスクマネジメントについては別途詳細な記事を書いています。トラブルを未然に防ぐ上で重要ですので、リスクマネジメントを積極的に身に付けていきましょう。

プロが実践しているトラブルに強いマネジメント

仕事の進め方で実践していること

私は常に先を読んで、トラブルの芽になりそうなものが見つかったら先手を打つようにしています。

トラブルの芽を未然に防ぐためには、先ほど解説したことが役立ちます。

こうすることで残業は大きく減ります。もちろん完全にトラブルを防ぐことはできず、ときには1時間くらいの残業をしてしまうこともあります。

しかし1ヶ月のトータルで見れば、10年近くに渡って残業時間を5時間以内にできています。

リスクは常にあり、トラブルが常に起きるのが仕事です。だから先手を打っていくことが重要だと私は考えています。

チームマネジメントで実践していること

先手を打つことはもちろんとして、それだけで全てを防げるわけではないです。そこで他人の視点からもトラブルの芽を教えてもらうことが効果的になります。

チームに心理的安全性を作ることで、チームのメンバーがトラブルの芽を報告しやすく、そして対処方法を提案しやすくできます。

心理的安全性はチームのメンバーに意見をもらう上で有効ですので、是非知っておいてください。こちらの記事で詳細を解説しています。

そしてチームのメンバーにも、先手を打つことの大切さを伝えていく必要があります。人間は楽観的なので、トラブルを起きない想定で考えてしまいがちだからです。

おわりに

今回はトラブルを未然に防ぐ方法について、私の考えと実践していることを解説しました。

トラブルに追われると心身ともに疲弊しますし、残業も増えます。そんな残念なことにならないよう、未然に防いでいきましょう。

あなたがトラブルを上手く未然に防げるようになることにこの記事が貢献できれば幸いです。