今回は炎上小話です！
今回の小話は「コミュニケーション」の歪みにより起きる炎上の小話です。
これは私独自の解釈ですが、コミュニケーションが原因の火種って、プロジェクトのあちこちに潜んでいる地雷みたいなもんです。
そして、この地雷は些細な部分に隠れていて、これを踏んでしまうと、火種が発生して大きなトラブルに繋がったりします。
一体どんな風に地雷を踏んでしまうんでしょう？私が実際に体験したノンフィクショントップ５を元に原因を考えてみたいと思います。
解らないけど「はい」と言ってしまう
これシンプルな話ですけど、意外とやっちゃう人も多くて、トラブルの火種になりやすかった原因の１つです。
理解をしていないのに「はい」と言ってしまうと、問題がある内容の話でも、相手は問題ないだろうと捉え、そのまま進めてしまいます。
この様な「はい」のやり取りから、ボタンの掛け違いが少しづつ発生して「齟齬」が発生するケースって非常に多かったんです。
プロジェクトは、お互いの認識合わせを繰り返し、齟齬がないように話を進める事が、最重要ポイントです。
理解ができていないまま話を進めると、お互いの認識にズレが生じて、混乱が発生します。
これを防ぐ方法としては、会話の後に「今の話ってこういう事ですよね？」みたいに、内容を抽象化し、確認を取るクセを付けると、雰囲気にながされなくなるのでお勧めです！
この方法を使うと、その場にいた関係者の齟齬も同時に防ぐ事ができますので効果的です！
もちろん議事録をとる方法も、読んでもらえるような工夫をすれば効果的です！
この項目をまとめるとこんな感じ！
- 解んないのに「はい」は危険かも？
- 内容を抽象化して確認してみよう！
- 議事録を取るのも有効な方法！
解らないので誰かに丸投げ
これは地味で結構ありがちな話ですが、割と危険な地雷です。
例えば問い合わせが来ました。お客側はこちらが状況を理解していると思い、端折って詳しい背景を書かずに質問をしてきました。
想像してみましょう。
こんなとき、内容を理解をせず、背景を解らない人に丸投げ（例：お願いします＆メールの転送）したらどうなるでしょう？
もしくは、実は齟齬が発生していて「意図がよく解らない質問」になっているのに、丸投げしたらどうなるでしょう？
質問の意図が解らないものをそのまま転送したところで、他の人も解らないです。
それに丸投げされてる事は、内容を見れば解るので、相手に普通にバレてます。
これが引き金となり、社内・社外両方の信頼を失い、プロジェクトを混乱させてしまうケースは本当によく見かけます。
問い合わせを受けて、誰かに相談するときは、せめて質問の意図は理解できる状態にしないと、上記の様なトラブルの原因になるので注意しましょう。
この問題のやっかいなところは「そんなの当たり前ですよね？」って人でも、相手に追い詰められると、結構やってしまう事です。
別な記事にも書きましたが、両者で意思の疎通ができてないと感じたら、電話で話したり関係者集めてミーティングを開いて話を整理するのがお勧めです。
この項目をまとめるとこんな感じだ！
- ただの丸投げは混乱を招く！
- 丸投げやると板挟みにあう！
- 質問の意図は理解する様にしよう！
- 混乱しそうなときは集まって話そう！
すぐあやまってしまいがち
明らかに悪いのに謝らないのは問題ですが、逆に謝りすぎて起きる問題もあります。
我々は日本人は、礼儀礼節の教育を受けているんで、これは仕方ない事なんですけどね・・。
では「すぐあやまってしまいがち」だと、どんな事が問題になるか考えてみましょう。
例えば謝るときって、自分に非があったり、忙しい相手にめんどくさい依頼をする場合だったりとか様々です。
しかし謝る事は、同時に「こちらに責任があります」という認識を相手に与えてしまいがちなので、必要以上の責任を請け負ってしまいます。
そして、いつのまにか追い込まれる形になってしまい、じわじわ大きなトラブルに繋がっていく訳です。
また、謝る事が習慣化していると、問題の所在が不透明になり、解決を遠ざけてしまう場合もあるので注意しましょう。
謝る事は立派な事ですし、物事を進めるために必要な大人の手段です。
しかしながら、状況がクリアになっていない状態での「謝罪」は、この様にトラブルに発展しやすいので注意しましょう。
課題管理がされていない
関係者がそれぞれ「聞いてない」「本当にそれ大丈夫？」ばっかりで、まったく作業に着手できない。
これ私がエンジニアだった頃にすごくよく見かけた光景です。
これは、想定外の話が沢山出てきて、必要以上に関係者が心配して疑心暗鬼になり、話が進まなくなってるケースなんです。
きっと想定外な事がちょこちょこ起きると、大きな会社だと部署間の調整が大変なんだろうなー
振り返ってみると、この様になってしまうプロジェクトには共通点がありました。
それは課題管理とその共有がまったくされてないという事だったんです。
何でもそうなんですけど、実際やってみないと解らない事って結構多いんですよね。
何もかも予測するのは不可能なんで、見つかった時点で解決するしかありません。
ただ、この対応を個別にやってしまうと、「聞いてないぞ」とか「どうしてそんな事になってるんだ？」みたいな話になりやすいんです。
ですので、これを「想定外」という認識から「課題管理」という認識に変換します。
こうする事で「課題」として対応中ですよって安心させる事ができますし、問題となってる部分を全体に共通認識として周知する事で、相談もしやすくなるんです。
課題管理の方法は、全然難しく考える必要ありません。
最低限、以下の項目をエクセルで更新して→共有するを繰り返すだけの話です。たったこれだけで多くの問題が回避できるならやった方がいいですよね。
・課題や問題内容
・担当者
・期限
・解決策
・優先度
・対応状況
（未着手・対応中・保留・完了）
これは逆に難しくしちゃダメ！できるだけ簡単で短い表現をチョイスしよう。
課題管理は内容が「書いてある・書いてない」よりも「多くの人が理解できる・できない」のが重要なんです！
責任範囲の認識がズレていた
お客様の目線で考えると、多くの方が導入作業は、全て業者に頼めばやってくれるだろう。って考えるのはごく自然な事だと思います。
しかし、案件によってはコストを安く見積もったなどの関係で「ここまではやるけど、ここからは御社で」みたいなケースも出てきます。
また、サービスを提供するベンダーにも、請け負える責任範囲というものもありますんで、この話はどこかで認識合わせをする必要があります。
この認識がずれていると「お金は払わない、ちゃんと説明受けてないから、とにかやって」みたいな話に発展してしまうんです。
この認識合わせは、プロジェクトが進んでからでは遅いので、キックオフのタイミングで説明するのが一般的な流れです。
契約内容などのエビデンスを提示する方法も、手としてはあるんですが、この方法は火に油をそそぐ事になる場合があるので、進め方は注意が必要です。
認識合わせをする方法の1つでWBS（Work Breakdown Structure）という方法があります。
いつか別の記事で説明しますが、ここのサイトが解りやすく書かれてたのでよかったら見てみて下さい。
https://www.jooto.com/contents/wbs/
最後に
前に別な記事で、私こんな事、書いたんですね。
|
林先生がなんかの番組で、歴史上で負けた人物には共通点があると言ってました。 それは【情報不足・慢心・思い込み】だそうです |
あ、前と同じ事いっちゃいますけど、私、林先生リスペクトとか、歴史から学ぶとか、何かに勝ちたいって事を言ってるんじゃないんです。
何が言いたいかと言うと、この共通点を「失敗や炎上の火種の原因」って置き換えると、私この話にすごく共感できるんですね。
今回紹介させていただいた、ノンフィクショントップ５も、やっぱりこれに当てはまってる気がします。
もしかしたら、駆け出しエンジニアの皆様から見たら、コミュニケーションの話よりも、もっと技術情報が欲しいのかもしれません。
でもね、現場に出たら技術だけではなく、こういった事に結構巻き込まれます。
もしかしたら、プロジェクトを仕切りながら開発をするなんて事もやらされるかもしれません。
そんなときに備えて、コミュニケーションの情報収集をするのは・・
いまでしょ！
