エンジニアのソフトスキル (1) 問題解決力
（この記事は「エンジニアに求められるソフトスキル」のPart 1です）
ソフトウェアのエンジニアは、ソフトウェアの力で何らかの問題を解決するのが仕事です。そのため問題解決力は欠かせません。
何が問題かを定義する力
よい問題解決をするには、まず何が問題か、何を解決すべきかを特定できることが大切です。解決しても価値が薄いことを解決しても成果とは見なされません。書籍「ISSUE DRIVEN」では、「今、この局面で本当に白黒をはっきりさせるべき問題は、（100個中で）せいぜい2つか3つ」とまで断じています。
また、問題を言語化できることも大切です。「なんかうまくいかない」のままでは前進できません。困りごとがあって上位者に相談したとき、「問題が何かが分からない」って返されたりしませんか？このあたりはコミュニケーション力とも関連してきます。
問題を定義する力の一部として、あるべき姿を描く力が挙げられそうです。よく「問題とは、あるべき姿と現状のギャップ」って言いますよね。
そして、あるべき姿を描くためには、目的と手段の連鎖を把握する力も必要です。何事も、目的と手段はずーっと繋がっていて、ある目的はまた、更に上位目的のための手段だったりします。この連鎖をより多段に視野に入れられる人は、枝葉末節にとらわれず、より大きな問題に取り組めます。
これらの力を伸ばすためには、自分のタスク、担当するプロダクト、所属する組織（ひいては会社）が何のためにあるのかを意識することが一端になります。また、問題を言語化したり説明したりするための語彙力も土台として必要になるでしょう。
問題の原因を分析する力
問題が特定できたら、次は原因分析がセオリーですよね。
ここは、事実を粛々と収集する力が必要になります。思い込みで判断せず、事実を見る。ソフトウェア開発でいうと、ログを見るとか、デバッガで変数の中身を調べるとか、そういったことの積み重ねです。ただし効率も重要で、熟練者は知識や経験で見当をつけて、しかし予想だけでは判断せずに事実をチェックします。
問題を切り分ける力もここに含まれます。上手な人は容疑者を素早く絞り込みます。「ここまでは合ってるな。ここからおかしいな」と。いっぺんに色々な要素を変えると、容疑者が増えてしまいます。上手な人は日頃から、コミットやプルリクの粒度を細かくしたり、テストやリリースの頻度を小刻みにしています。
物事を論理的に考える力も必要です。因果関係を整理する力とも言えるでしょうか。これができる人は、「現象Xの原因AとBを見つけたけど、これで全部かな。逆に、AとBを潰せば現象Xが解消すると言い切れるだろうか」という幅の思考ができたり、「この原因の更に根本の原因はなんだろう」という深さの思考ができます。
解決策を選定する力
原因が分かったら、解決策を考えましょう。
できれば、複数の候補を挙げてから、その中の一つを選定できることが望ましいです。ここは、問題の対象分野に関するハードスキルも前提として必要になってきます。ハードスキルが未熟な場合、解決策を1個見つけるだけで精一杯になり、そこで満足してしまいがちです。例えば、ググって最初に見つけたStack Overflowの回答をコピペ、みたいな。
複数挙げて、そこから選ぶという所作が身についていないと、最適解を発掘し損ねる可能性が高まります。また、上位者に提案しても納得を得られないことがあります。ここはコミュニケーション力にも関わりますね。
複数の候補を挙げると、しばしばトレードオフが生じることに気づきます。効果、コスト、実現可能性などの面で。どんなプロジェクトもリソースは有限ですから、こうしたトレードオフを踏まえて、今の自分達にできる現実解を見出す力も大切です。このあたりは推進力とも関わってきます。
解決策を実行する力
解決策が決まったら、当たり前ですが実行しなければ意味がありません。案を出すだけよりも、実行できる方がより価値があります。また、"Doing"でなく"Done"に価値があります。
ここでは、計画を立てる力も必要になります。大タスクを小タスクに分解して、段階を踏んで一つずつDoneにする攻め方が役立つ場合も多いです。このあたりも推進力と一部重複します。
実行結果を検証する力
実行してもまだ終わりではありません。結果や効果を検証します。バグを修正しておいて、その後の動作確認をしていなかったらまずいですよね。
検証すると、より良くするために原因分析や解決策選定に立ち戻ったり、得られた経験を個人やチームのノウハウとして蓄積したりできます。
結果や効果が直ちに簡単に分かれば苦労しませんが、現実はそうとも限りません。どうやって検証したり測定したりするのか、事前に考えておく必要があったりもしますので、要注意です。
最後に
関連する素敵なnote記事を紹介します。問題指摘どまりよりも、解決策提示できること、そして解決策提示よりも解決策実行までできることを目指したいですね。また、横軸の「課題のスコープ」も意識したいです。
この記事が気に入ったらサポートをしてみませんか？