問題対策に強いエンジニアを作る方法
私ももう既に、最前線から離れて10年近くになりますが、でも単純な最新プログラミングなんかで競われない限り、通常のソフトウェア開発程度ならまだまだ負けるつもりはありません。
まぁ、開発チームが問題を起こすたびに多様な様式の設計書を読んで、多様なソースコードを解析して、いろいろな業界の仕様をおさえて、ユーザーに説明して…と言うのは今でも普通にして（させられて）いますしね。開発をしないってだけで、すべてに触れる機会はやたらと多いものです。
けれども、いつも思うのは
「なぜ、こんなに数多くの問題を起こしておいて、
自ら解決することができないのだろう？」
です。自分で作成したプロダクトに、作成した本人として責任を持つ…と言うのは、私の中では当たり前のことだと思うんですけど、なぜかできないエンジニアが多いように見受けられます。
そして、なぜかどーにもこーにもならなくなってから呼び出されて、途中参加させられています。本当はそうなる前に呼んでくれると被害を最小限に抑えられるのですが…。
足りないのは決断
さて、
エンジニアは、往々にして決断をすることが"苦手"
と言われています。特にＢ２Ｂのシステム開発現場などでは、顧客が仕様を出してくれて、提示された仕様（希望？）通りに開発さえすればいいと思っているエンジニアが多いですし、仮に「こんなのが欲しかったわけじゃない」と揉めても、「こういうのが欲しいって言ったじゃないか。ほら議事録にも」などと言って、責任逃れをすればいいと思っている人が多いからです。
果たしてそれがプロフェッショナルのすることか？
と言われると、甚だ疑問が残りますが、それが中小ベンダーであっても大手ベンダーであっても、責任逃れの方法や落としどころの模索方法について、各社独自にバイブル化される傾向が強いため、エンジニアにとって『自分で考え、自分で決める』と言う領域が非常に狭いのは確かです。
エンジニアの中には物事を自分で決めずに「どうしましょうか」とすぐ先輩やマネージャーに相談する人も少なくありません。しかし、いついかなる時でもそれしかできない、というのでは困ります。エンジニアが自分の意見を言うことは極めて重要なことなのです。
たとえば、ユーザーとの会議などでは「自分はこう思う」と、根拠をもって自分の意見やポジションを明確に言う必要があります。ユーザーから何か言われたときでも「それは上司に相談して返事します」などあいまいな返事をするのではなく、自分の意見をその場ではっきり言うことが大切です。
ですが、そうした発言ができるようになるためには、日頃エンジニア自身が自分の意見を「明確にする」という訓練をしていないと、なかなか実行に移せるものではありません。
実行に移せるようになるためには、"問題が起きたとき"こそがエンジニアに「自分で考え、自分で決断する」習慣をつけさせる絶好のチャンスであり、そのチャンスを活かせる必要があります。そうでない限り、エンジニアに決断力を身につけさせることは難しいでしょう。
決断力に欲しいのは一粒の責任感
エンジニアは、起こった問題を何とかしなければならないという、逃げられない環境の中でユーザーや、上司から突き放されると自分で決断をせざるを得なくなります。
そうなるシチュエーションと言うのは、決して少なくありません。
第一線のエンジニアは、目の前のシステムをしっかり開発するのにも、問題が起こったときにしっかり対応をするのにも、自分で考え、自分で決め、自分で行動するという心構えと姿勢が重要です。それに乏しいエンジニアは、いかに技術力が優れていても『プロフェッショナル』とは言えないのです。
考えてみてください。
誰かの決断に頼ることなく、自分自身で決めるって…なんか心細くないですか？自信がなくなりますよね？それでも、自ら決めるって勇気がいると思います。この時、何が背中を押してくれるのかというと、それは
責任感
です。何かあったときに責任が持てないから、自信がないのです。自信がないから決められないのです。逆に、自分で決める、自分が責任を持つという意識こそが『プロフェッショナル』の証とは言えませんか？責任意識の低い人って、どんなに優れていても『プロフェッショナル』とは呼びにくいですよね。
「仮説思考」と「閉じた質問」
確かに、システム開発の過程では様々な問題にぶつかります。
すべてをあらかじめテンプレート化しておくことは現実的ではありません。事実、起きた問題に対してどう対応するか、それを考える際にあらかじめ考慮しておくべき事項は実に多いものです。
たとえば、その問題にかかわる
・諸々の物事の状況
・その問題に起因する様々な影響とその度合い
・手が打てる現実的可能性
などいろんなことを考えてどう対応するかを決めるのは、必須事項です。具体的には、仮にバグにぶつかったとすると、その対応を考えるときには、
・トラブルの状況やその難易度
・再現性の有無
・同様のトラブルの有無
・業務への影響の度合い
・顧客との関係の良さ悪さ
・顧客のビジネスへの影響およびその損害
・エンジニアの技術力や勤務時間
・追加要員の可能性
・他部署との関係
など諸々の事柄を考えた上で、どう対応するか判断しなければなりません。ユーザーからクレームをもらったときや、外注メンバーと揉めたときなども同様に、いろんなことを考えて判断しなければならなくなるでしょう。
そんな時、現場のエンジニアがどうするべきかを自分自身で判断できないままでは、ただでさえ緊急性の高い状況なのに、より対応が遅延し、多くの関係者に迷惑をかけることになってしまいます。
この時、海水注入の決定に対する東京電力経営層の決断力のなさは、海水注入することによって「廃炉」を確定させてしまうことに対する責任感のなさが引き起こしたものでしたよね。
彼らにとって、最優先だったのは…あるいは決められないほどに優先順位が高かったのは「営利」だったのでしょう。人の命よりも、国際的な責任よりも、企業の営利と自らの保身を優先させたかったのです。
もしもこの時、「重要度×緊急性マトリクス」で客観的に思考を整理していれば、そんなちっぽけなことで悩む必要はなかったのかもしれませんけどね。
では、どうやって訓練するべきか？と言うと、１つの例として、以下のような方法があります。
問題が起こったとき、課題ができたときに
1）エンジニア自身が「これはどう対応すれば良いか」を考える。
2）エンジニア自身が「この対応はこうする/こうしたい」と仮決めする。
間違っていても良いからとにかく決める。
3）それをマネージャーや先輩に「自分はこの問題にこう対処したいと思い ます、これでよいでしょうか」と相談する。
4）そのやり方は正しいと言われたら「自分の考えは合っていた！良かった 」と自信をもってそれを行なう。
5）違っていれば「なぜそうなのか、自分の考えのどこがおかしいのか」と 質問しマネージャーや先輩の意見を聞く。
6）「なるほど、そうなんだ」と納得できたら、マネージャーや先輩の意見 を取り入れてそれを行なう。
7）納得がいかなければ業務命令でない限り、自分が考えたやり方で行なう 。ただし、責任感を常に意識する。
といった手順を徹底させることです。そして、ここで重要となってくるのは、項3で行う
"クローズド・クエスチョン"
（回答者に「Yes/No」で答えさせる質問）
です。当然、新人教育などでも説明する程度の質問スキルなので、手順自体に技術的な難しさは一切ありません。やや難しいのは対応策を考えることと、考えた策にきちんと根拠を添えることだけです。
「Yes/No」で回答してもらうためには、自ら考え、仮説を立てる必要性があります。この"考える"機会を多く作ることは、非常に本人の成長に役立ちます。もちろんこの手順を踏まなくても解決はできますが、実務において、新人～若手層を「訓練」するには、このクローズド・クエスチョンはとても有用なのです。
１つ目のポイントは「エンジニア自身が対応の仕方を考え、その意思を表現する」という点です。それは問題が起きたとき、その問題の状況、顧客やプロジェクトの状況、その問題が与える業務などへの影響度などを一番よく知っている人間こそが適切な対応策を考えられますが、それを一番よく知っているのは現場のエンジニアです。
そこでマネージャーは、現場のエンジニアに「皆さんしか正しい対応の仕方は決められない。問題にぶつかったときは自分でどう対応するか考えて決めてください。相談には乗るから」と話し、彼らに任せるようにします。
２つ目のポイントは「エンジニアに対応の仕方の考え方と考える癖を身に付けさせる」という点です。エンジニアが問題対応に強くなるには、「こんな状況はこう考えてこう対応するんだ」と言う考え方を身に付けることが重要です。
たとえば、要件が大きくなりそうなときに、顧客と交渉するにしても顧客の業務にどれくらいの影響があるか、ビジネスにどんな影響があるか、顧客との関係への影響はどうか、稼働開始に間に合うか、技術的実現可能性はどうか、自分たちの技術力はどうか、応援を頼めるか、コストは大丈夫か、契約内容はどうか、などいろんなことを優先度も含めて考え、どう対応するかを決めなければなりません。
問題が起ったときに「それをどう考えればよいか」をエンジニアに身に付けさせたいと思うならば、そういう機会を作って育むしかないのです。
決断する経験を積ませよう
第一線のエンジニアが、この(1)～(7)のやり方をして「何をどう考えてどう対応するんだ」という“考え方“を身に付けると、次に同様な問題が起ったときには適切に対応できるようになってきます。
また、色々なケースの”考え方”を身に付ければ、いずれは応用も利きだしますし、ほかのエンジニアの事例を聞いてもそれが頭に入ってくるようになります。すると、だんだんと問題対応に強い骨太なエンジニアとなっていくわけです。
ですが、エンジニアが自分自身で考えることなく、マネージャーや先輩に相談して指示を仰いでばかりいては、その考え方はなかなか身に付きません。まして、マネージャーや先輩の指示通りにしてうまくいかなかったときには、マネージャーや先輩の責任にしてしまうかもしれません。
しかし、自分が考えたことや自分が納得したことであれば、成功しようが失敗しようがそれが自ずと身に付きます。
エンジニア一人ひとりのなかで、もしも"プロジェクト運用の責任の一端を担っている一員"と言う意識が今まで薄かった方は、今後、この点は特に注意した方がよいと思います。
いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。