問題対応に強いエンジニアを作る方法

『エンジニアは往々に決断をすることが"弱い"』

と世間ではよく言われています。

特にＢ２Ｂでは顧客が仕様を出してくれて、提示された仕様（希望？）通りに開発さえすればいいと思っているエンジニアはとても多いですし、仮に「こんなのが欲しかったわけじゃない」と揉めても、「こういうのが欲しいって言ったじゃないか。ほら議事録にも」などと言って、責任逃れをすればいいと思っている人が多いのも確かです。

「果たしてそれがプロフェッショナルのすることか？」

というと甚だ疑問が残りますが、それが中小SIerであっても大手SIerであっても企業内でバイブル化される傾向が強いため、自分で考え、自分で決める領域が非常に狭いのは確かです。エンジニアの中には物事を自分で決めずに「どうしましょうか」とすぐ先輩やマネージャーに相談する人も少なくありません。

しかし、いつもそれでは困ります。

自分で意見を持たない、自分で決断をしないというのは、役割上『無責任』となってしまうこともあるからです。エンジニアに限った話ではありませんが、意見を言わなければならない場で自分の意見を言うことは極めて重要なことなのです。

たとえば、会議などでは「自分はこう思う」と、根拠をもって自分の意見やポジションを明確に言う必要があります。顧客から何か言われたときでも「それは上司に相談して返事します」などあいまいな返事をするのではなく、自分の意見をその場ではっきり言うことが重要です。

「失敗の最大の原因は決断力の欠如にある。決断は素早くし、変更が必要になるときまで一度下した決定は変えないことだ。優柔不断は誰もが克服しなければならない大敵である。」

といいます。

ですが、それには日頃エンジニアが自分の意見を明確に言う訓練をしていないとなかなかできるものではありません。その解決のためには、日頃の"些細な問題が起きたとき"こそが「自分で考え自分で決断する」習慣をつけさせる絶好のチャンスです。エンジニアは起こった問題を何とかしなければならないという、逃げられない環境の中で上司から突き放されると自分で決断をせざるを得ないためです。

第一線のエンジニアは仕事をしっかりするのにも、問題が起こったときにしっかり対応をするのにも、自分で考えて自分で決めて自分で行動するという心構えと姿勢が重要です。いかに技術力があっても、それに乏しいエンジニアはプロとは言えません。

確かに、システム開発の過程では様々な問題にぶつかります。
すべてをテンプレ化することは現実的ではないでしょう。

事実、起きた問題に対してどう対応するかそれを考える際に考慮すべき事項は実に多いものです。

たとえば、その問題にかかわる

　・諸々の物事の状況
　・その問題に起因する様々な影響とその度合い
　・手が打てる現実的可能性

などいろんなことを考えてどう対応するかを決めるのは、必須事項です。
具体的には、仮にバグにぶつかったとすると、その対応を考えるときには

　・トラブルの状況やその難易度
　・再現性の有無
　・同様のトラブルの有無
　・業務への影響の度合い
　・顧客との関係の良さ悪さ
　・顧客のビジネスへの影響およびその損害
　・エンジニアの技術力や勤務時間
　・追加要員の可能性
　・他部署との関係

など諸々の事柄を考えた上で、どう対応するか判断しなければなりません。お客さまからクレームをもらったときや協力会社と揉めたときなども同様に、いろんなことを考えて判断しなければならなくなるでしょう。

そんな時、現場のエンジニアがどうするべきかを自身で判断できないままではより対応が遅延し、お客さまに迷惑をかけることになってしまいます。

では、どうやって訓練するべきか？というと、１つの例として以下のような方法があります。

①問題が起こったときに「これはどう対応すれば良いか」を考える。
②「自分はこの対応はこうする/こうしたい」と決める。間違っていても良いからとにかく決める。
③それをマネージャーや先輩に「自分はこの問題にこう対処したいと思います、これでよいでしょうか」と相談する。
④そのやり方は正しいと言われたら「自分の考えは合っていた！良かった」と自信をもってそれを行なう。
⑤違っていれば「なぜそうなのか、自分の考えのどこがおかしいのか」と質問しマネージャーや先輩の意見を聞く。
⑥「なるほど、そうなんだ」と納得できたら、マネージャーや先輩の意見を取り入れてそれを行なう。
⑦納得がいかなければ業務命令でない限り、自分が考えたやり方で行なう。ただし、責任感を常に意識する。

これは、報連相スキルの１つ、

　"クローズド・クエスチョン"

の応用です。

当然、新人にも説明する程度のスキルなので、手順自体は技術的に難しいことではありません。難しいのは対応策を考えることと、考えた策にきちんと根拠を添えることです。

もちろんこの手順を踏まなくても解決はできます。しかしこれには「訓練」という意図も含んでいるため、非常に有用なのです。

１つ目のポイントは「自身が対応の仕方を決める」という点です。

それは問題が起きたとき、その問題の状況、顧客やプロジェクトの状況、その問題が与える業務などへの影響度などを一番よく知っている人間こそが適切な対応策を考えられますが、それを一番よく知っているのは現場のエンジニアです。そこでマネージャーは、メンバーに「皆さんしか正しい対応の仕方は決められない。問題にぶつかったときは自分でどう対応するか考えて決めろ。相談には乗る」と話し、彼らに任せるようにします。

２つ目のポイントは「エンジニアに対応の仕方の考え方と考える癖を身に付けさせる」という点です。

エンジニアが問題対応に強くなるには「こんな状況はこう考えてこう対応するんだ」という考え方を身に付けることが重要です。たとえば、要件が大きくなりそうなときに、

　・顧客と交渉するにしても顧客の業務にどれくらいの影響があるか
　・ビジネスにどんな影響があるか
　・顧客との関係への影響はどうか
　・稼働開始に間に合うか
　・技術的実現可能性はどうか
　・自分たちの技術力はどうか
　・応援を頼めるか
　・コストは大丈夫か
　・契約内容はどうか

などいろんなことを優先度も含めて考え、どう対応するかを決めなければなりません。問題が起ったときに「それをどう考えればよいか」をエンジニアに身に付けさせたいと思うならば、そういう"考えなければ先に進めない"機会を作って経験を積ませて育むしかないのです。

第一線のエンジニアが先述の①～⑦のやり方を実施して「何をどう考えてどう対応するのか」という“考え方“を身に付けると、次に同様な問題が起ったときには適切に対応できるようになってきます。

また、色々なケースの”考え方”を身に付ければ、いずれは応用も利きだしますし、ほかのエンジニアの事例を聞いてもそれがスッと頭に入ってくるようになります。すると、だんだんと問題対応に強い骨太なエンジニアとなっていくわけです。

ですが自分自身で考えず、マネージャーや先輩に相談して指示を仰いでばかり、挙句の果てに答えを欲するばかりでは、その考え方はなかなか身に付きません。まして、マネージャーや先輩の指示通りにしてうまくいかなかったときには、彼ら/彼女らの責任にするでしょう。

しかし、自分が考えたことや自分が納得したことであれば、成功しようが失敗しようがそれが自ずと身に付きます。常に

　"プロジェクト運用の責任の一端を担っている"

という意識が今まで薄かった方は、この点は特に注意した方がよいでしょう。