強いエンジニアを作る方法

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

と言われています。

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

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

と言うと、甚だ疑問が残りますが、そうした対応の仕方が中小であっても大手であっても、バイブル化される傾向が強く、自分で考え、自分で決める領域が非常に狭いのは確かです。

エンジニアの中には物事を自分で決めずに「どうしましょうか」とすぐ先輩やマネージャーに相談する人も少なくありません。

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

エンジニアが必要な時に、必要に応じて「自分の意見を言う」ということは極めて重要なことなのです。

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

個人レベルにおける「失敗」の最大の原因は
決断力や判断力の欠如にあります。

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

第一線で活躍しているエンジニアは仕事をしっかりするのにも、問題が起こったときにしっかり対応をするのにも、自分で考えて、自分で決めて、自分で行動するという心構えと姿勢を持っています。

いかに技術力があっても、それに乏しいエンジニアはプロとは言えません。

確かに、システム開発の過程では様々な問題にぶつかります。
すべてをテンプレ化することは現実的ではないでしょう。事実、起きた問題に対してどう対応するか、それを考える際に考慮すべき事項は実に多いものです。

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

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

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

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

など諸々の事柄を考えた上で、どう対応するか判断しなければなりません。お客さまからクレームをもらったときや協力会社と揉めたときなども同様に、いろんなことを考えて判断しなければならなくなるでしょう。そんな時、現場のエンジニアがどうするべきかを自身で判断できないままでは、より対応が遅延し、お客さまに迷惑をかけることになってしまいます。

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

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

これは、新入社員教育などでもよく説明されるコミュニケーションスキルの１つ、

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

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

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

１つ目のポイントは「エンジニア本人が対応の仕方を決める」点です。

それは問題が起きたとき、その問題の状況、顧客やプロジェクトの状況、その問題が与える業務などへの影響度などを一番よく知っている人間こそが適切な対応策を考えられるからです。そして、それを一番よく知っているのは現場のエンジニアです。マネージャーは、メンバーのエンジニアに

「皆さんしか正しい対応の仕方は決められない。
　問題にぶつかったときは自分でどう対応するか考えて決めろ。
　相談には乗る」

と話し、彼らに任せるようにします。

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

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

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

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

第一線級のエンジニアがこの(1)～(7)のやり方をして「何をどう考えてどう対応するんだ」という“考え方“を身に付けると、次に同様な問題が起ったときには適切に対応できるようになってきます。また、色々なケースの”考え方”を身に付ければ、いずれは応用も利きだしますし、ほかのエンジニアの事例を聞いてもそれが頭に入ってくるようになります。

すると、だんだんと目の前の問題対応に強い骨太なエンジニアとなっていくわけです。

ですが、エンジニア自身が自分で考えず、マネージャーや先輩に相談して指示を仰いでばかりいては、その考え方はなかなか身に付きません。まして、マネージャーや先輩の指示通りにしてうまくいかなかったときには、他責しかできなくなっていることでしょう。

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

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

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