COLUMN
「作れる人」から「課題を解決できる人」へ|エンジニア採用の変化
この記事の結論
採用で見られる軸は「何が作れるか」から「どんな課題を、どう解決したか」へ。技術の一覧より、課題・判断・結果を語れる材料を先に整えます。
求人は動いているのに、書類や面接で思ったほど手応えがない。スキルシートに書ける言語やフレームワークは増えたのに、評価が変わった実感がない。そういう相談は珍しくありません。
理由のひとつは、採用する側が見ているところと、応募する側が力を入れているところがずれていることです。採用する側が聞きたいのはその技術で何を解決したかなのに、使える技術の数を増やすことに力を入れてしまう。解決したことを先に書き、技術はそのあとに書くだけでも、伝わり方はかなり変わります。
採用で見られるものは、なぜ「作れる」から変わってきたのか
作ること自体が道具の進化で速くなり、差がつく場所が「何のために、何を選んで作ったか」に移ってきたからです。
米田は、検討タスクを出したときにアウトプットの本質がずっとズレたままの人がいる、と話します。なぜその検討をするのか、どうなったら嬉しいのかというゴール像が共有できていない。指示する側にも責任はある、と前置きしたうえで、1から10まで指示しないと動けないのではなく、常に仕事の本質を理解しようとする姿勢が大事だと考えています。
コードを書く速さは、AIという道具で底上げされました。米田はAIをドーピングのようなものだと表現します。扱えるエンジニアが強くなるだけで、仕事がなくなるわけではありません。ただ、底上げされた分だけ、「何を作るか決める側」の力が見えやすくなったのは確かです。
「課題を解決できる人」と見られる人の共通点
課題の設定、選んだ手段とその理由、結果と振り返りを、自分の言葉で説明できることです。そのうえで、一方的に話し終えるだけでなく、質問されたときに会話を続けられることです。
代表・米田の視点 面接で「この人は課題を解決できるな」と感じるのは、ひとつの質問から会話のラリーが何往復か続く人です。もちろん、そのラリーの中でしっかり話せることが前提ですが。正直、その辺は書類だけではわかりません。
会話が続くかどうかは、自分の経験を、判断した理由まで含めて理解できているかで決まります。人から渡された説明をそのまま言っているだけだと、二問目で止まってしまう。逆に、自分で判断した部分があれば、角度を変えて聞かれても答えられます。
今の経験を「課題解決」の言葉で言い直す
担当作業を並べるのではなく、「困っていたこと→自分がしたこと→変わったこと」の順に書き直します。新しい経験を増やす前に、今ある経験をこの順に書き直すほうが早いことが多いんです。
| 作業として書くと | 課題解決として書き直すと |
|---|---|
| 〇〇システムの改修を担当 | どんな不具合や要望が起点だったか、複数案からなぜその改修方法を選んだか、直したあと何が減ったか |
| テスト工程を担当 | どこで漏れが起きていたか、観点や手順をどう変えたか、変えた結果チームの何が変わったか |
ENFIのBE-DO-HAVE棚卸しには、実績・成果として「誇れる成果、乗り越えた課題、チームへの貢献」を書く欄があります。職務経験・技術スキルの欄とは別に用意しているのは、ここが薄いまま職務経歴書を書く人が多いからです。書き出してみると、意外と埋まります。
保守・運用・テストの経験も材料になる
作る仕事が中心でなくても、語れる材料はあります。米田は、ソフトウェアの保守でも、ただバージョンアップ対応をするのではなく、それを属人化させない仕組みにできるか、プロセスを作るところまで踏み込めるかだと言います。
ここには面白い葛藤もあって、仕組みを作ってしまうと自分の仕事を奪うことになるので、わざと避ける人もいる、とも話しています。避けずに踏み込んだ経験があるなら、それはそのまま課題解決の話になります。
足りないと感じたら、何から積むか
今の仕事の中で小さな改善をひとつ選び、課題から結果までを記録するところから始めます。転職しないと材料が作れない、ということはありません。
米田が挙げるのは、課題をブレークダウンして「〇〇と△△と□□の方法があるな、でもこのケースでは△△がベストかもしれない」という思考を即座にでき、すぐにPoC(実現できるかを小さく試す検証)を回せる力です。極小範囲でテストして、うまくいきそうならスコープを広げる。この進め方自体が、そのまま面接で話せる中身になります。
記録の残し方としては、GitHubに作品だけでなくプロセスと運用まで残しておくと、あとから語れる幅が広がります。何を作ったかに加えて、課題をどう分けたか、レビューで何を直したか、どう運用して止めたか。これらは転職活動の有無に関係なく、自分の判断の履歴として残ります。
ENFIは転職ありきで考えません。材料が足りないと感じたとき、選べるのは転職だけではなく、今の部署で改善提案をする、別チームへの異動を希望する、学び直す時間を作る、といった手も並びます。どれを選ぶかは、自分が将来どんな課題を解きたいか(Be)がはっきりしてからのほうが決めやすい。スキルの一覧を増やす前に、将来どんな課題を解きたいかを言葉にしておくと、面接でどの経験を話すかも選びやすくなります。
あなたが直近1年で「これは自分が考えて動かした」と言える仕事は、どれでしょうか。
今日からできる次の一歩
- 直近の仕事をひとつ選び、課題・判断・結果を3行で書く。1行ずつ、短くて構いません
- BE-DO-HAVEの実績・成果の欄(誇れる成果、乗り越えた課題、チームへの貢献)に、その3行を書き足す
書いてみて書けることが少ないと感じても、経験が足りないとは限りません。まだ課題・判断・結果の形に書き直していないだけのことが多いです。3行が埋まるようになると、面接の会話は続けやすくなります。
よくある質問
課題解決力はどうやって証明すればいいですか
証明書のようなものはありません。担当した仕事について、何に困っていて、なぜその手段を選び、結果どう変わったかを自分の言葉で説明できることが材料になります。面接では、そこから追加の質問が来たときに会話が続くかどうかが見られます。
実務経験が浅くても、課題解決の話はできますか
できます。規模の大小より、課題を自分で切り分けて手を打った過程があるかどうかです。手順書の整理や小さな自動化でも、困りごとと結果をセットで話せれば材料になります。
技術スキルはもう重視されないのですか
そんなことはありません。技術は前提として必要です。そのうえで、同じくらいの技術力の人が並んだときに、課題の設定や判断の理由を語れるかで差がつきやすくなっている、という話です。