日経TECHで現在以下のような記事が連載されている。
[clink url=”https://tech.nikkeibp.co.jp/atcl/nxt/column/18/00614/030100001/”]要はトラブル時にどことなく他人事にしてしまい、トラブルの収束の仕方を知らないエンジニアについて書かれている。
トラブル収束するための謝り方について書かれている記事だ。
この記事を読んだITエンジニアは
「ありがちな話だな」
「こんな事は当たり前だ」
「ふーん、そうか」
「これは役立つから早速やってみよう」
といった様々な反応をしていると思う。
私自身も10年以上エンジニアとして大手ベンダーにいたことも、小規模なシステム開発会社にいたことも、ユーザー企業にいた事もあるが、この記事はそれぞれの立場によって見え方が違うのではないかと感じた。
確かに謝る技術というのは必要だし、武器になりうる。
確かに役に立つ記事だと思う。
しかしそもそも、
「簡単に謝らない」と考える原因となった出来事があったとしたら、それは仕方ないのではないか？
とも思う。
よって本記事では日経TECHの謝り方の技術に関する記事を読んだ上で、そもそも欠けているエンジニアの視点を語っていきたいと思う。
そもそも謝る前に関係が崩壊している場合がある
この記事では「謝り方の技術」と題し、エンジニアの謝り方が下手である事を題材に、エンジニアは「安易に謝らないのが得策だ」と考えているように記載している。
しかし、そもそも「安易に謝らないのが得策だ」と考えているわけではなく、
「謝った結果、無茶な要求をしてくるだろう」
と思っている現場のSEは結構多い。
もっと極端に言えば、
「またこちらが頭下げないといけないの？あれだけ無茶な要求を叶えたのに、ちょっとダメだったらこれだ。」
と思っているエンジニアも結構多くいる。
そもそも無茶な要求を既に呑んでいて、トラブルにあう可能性が高まる事も説明したのに、いざ起こったらこれだ。。。
というパターンである。
こうなっていたは謝るも何も既に関係は崩壊している。
また、関係は保たれていたとしても、謝った結果、以下のような要求が来る事は目に見えている場合もある。
・なるべく早くトラブル収束に向けて行動する為、連日連夜での対応をお願いしたい
・夜間対応するのでよろしく
・トラブルなのだから当然費用は発生しないよね？
日経TECHの記事では誤った結果で損害賠償が来る事は日本の場合はほとんどない。
とあるが、現場のエンジニアからしてみれば損害賠償を恐れているわけではなく、
謝罪した結果、上記のような要望が来る事を恐れているエンジニアは結構多い。
この記事中のシステム開発会社というのはたぶん大手SIerから発注を受けた下請けシステム開発会社の事を指しているだろう。
謝った結果、トラブル収束の為の対応で無茶な要望に対応させられた挙句、結局対応費用ももらえない
なんていう状況も危惧されるし、結局対応するのは大手SIerではなくシステム開発会社の人間だったりするわけで、
単純に謝った事から責任をとらされる一連の行動のほとんどがシステム開発会社にまわってくる事が多いためだ。
よって、簡単に謝ってしまっては取り返しのつかない事になると思っているエンジニアは多くいるだろうし、謝った結果、割を食いたくないと思っているエンジニアも一定数いるという事だ。
エンジニアは謝り方を知らないのではなく、そもそも状況がわかっていない場合も多い
記事を読んでみると、冒頭でどこか他人事のように聞こえる言葉を発言してしまったシステム開発会社の担当者が
火に油を注いだという例をとっているが、そもそもエンジニアは状況をわかっていない事が多い。
ユーザー企業の中でトラブルが発生した事は何となくわかっていたとしても、いざその場に呼ばれた時には
そもそも何故呼ばれたのだろう？
と思っているパターンも少なからずあるわけだ。
これはシステム開発会社で働く人たちの中で下流工程のみ実施するエンジニアやバックエンド側に立つエンジニアに多い傾向がある。
要は普段お客様側、つまりはフロントに立っていないがために
お客様の業務にどれぐらいの影響が発生しているのか？
お客様のどんな業務ができなくて困っているのか？
といったユーザー企業側の業務に与える影響が全くイメージできていないパターンに陥るわけだ。
これを回避するには、
普段から自分たちが作っているシステムがお客様のどんな業務に使われているか？
を明確にイメージしておく必要がある。
例えプログラムの一部分だったとしても、日本中のインフラを支えていたり、通信を支えていたりする場合もあるわけなので、普段からユーザーの使い方や世間への役立ち方を明確にイメージしておくと仕事にも身が入って相乗効果を生むのでおすすめだ。
ユーザー企業、大手Sier、システム開発会社の3社間での信頼感の確立
3つ目に話すこの内容が正直一番大事だと思うが、ユーザー企業、大手SIer、システム開発会社の普段からの信頼度合いがトラブル発生した時の温度感につながるのは間違いない。
だからいざという時の為にも普段から密なコミュニケーションを行うと共に、３者の役割を各々がしっかりと果たす事が重要だ。
例えばシステム開発会社であれば、普段から正確な仕様書やプログラムを作って納品する確かな技術力をつけておく。ちゃんと費用に見合った仕事をする。
大手SIerであればユーザー企業の課題や動向を常に把握し、システム開発に対する評価を聞いておくと共に、システム開発会社の人間にも状況を伝えたり、フィードバックを行う。そしてシステム開発をしっかりとしているならそれ相応の対価を払う。
ユーザー企業はユーザー企業側の業務に携わる人間と密な人間関係を築くと共に、要望や困っている事がないか聞き出す。それらの要望や課題を大手SIerや開発会社に伝える。無茶な要望だとわかっているなら、見合った報酬を用意したり、ちゃんと対価を用意する。
普段から３社間がしっかりと連携をとり、お互いに要望を満たす状況を作っていれば、いざと言う時にも素早い対応がとれるし、謝らないなんてこともない。
謝る技術
とはいうものの、結局は普段からのお互いの信頼関係がものを言うので、ちゃんとお互いの状況をフォローしあえるかどうかで結果は変わってくるわけだ。
まとめ
エンジニアは簡単に謝らない。
確かにその側面もあるとは思う。
しかし、実際にはいざという場面で謝る前に既に関係が崩壊している事も多々あるし、そもそもそう思わせる原因がどこかにあるという事を念頭に置く必要があるし、普段からの関係性が崩壊している場合があるということを忘れてはならない。
謝る技術というのも確かに必要。
だがそれ以上にもっと必要なのは、普段から密な関係を築き、いざという時には
ユーザー企業、大手SIer、システム開発会社
が一丸となってトラブルを迅速に解決する事なのだから。