記事に関する注釈
・本記事は、エンジニア採用担当の私がこれまでに拝見した職務経歴書の中から、「実務未経験・微経験ながら面談オファーを出した事例」を分析・抽象化したものです。
・記載されている内容はあくまで「弊社の採用基準（カルチャー）」において魅力的だと感じたポイントですが、エンジニアを目指す多くの方にとってヒントになれば幸いです。
株式会社ナハトでエンジニア採用をしているものです。
エンジニア採用担当をしていると、毎日多くの履歴書や職務経歴書、GitHubを拝見します。
特に実務未経験〜微経験の方の場合、どうしても「技術スタックの羅列（React使えます、AWS触れます）」だけのアピールに終始してしまいがちです。
もちろん技術への関心は大切ですが、それだけでは「その他大勢」に埋もれてしまいます。
一方で、スクール卒や独学、あるいは実務経験が浅い方であっても、「この人は絶対に優秀だ、すぐに会って話したい！」と即決する書類が、稀に存在します。
今回は、私が惹かれたポイントを4つに分けて紹介します。
1. 技術選定に「ユーザー」と「コスト」の視点がある
実務経験が浅い方の職務経歴書（スキル詳細や自己PR）でよく見かけるのが、「流行っているから触ってみました」と思わせるような技術スタックの羅列です。
しかし、私たちが惹かれた候補者は、学習や個人開発の段階であっても「なぜその技術でなければならなかったのか」をビジネス視点で語っていました。
例えば、過去に高い評価をした書類には、以下のような記述がありました。
-
運用コストを極限まで下げた設計
「自分一人で運用するため、サーバー管理コストがかからないサーバーレス構成（BaaSやAWS Lambda等）を採用しました」
技術そのものへの興味だけでなく、「運用コスト（金銭的・時間的コスト）」というビジネス感覚を持っていることに惹かれました。
-
開発スピードを優先した技術選定
「最新のフレームワークも検討しましたが、今回はアイデアを最短で形にすることを最優先し、ライブラリが充実しているRails（PHP/Laravel等）を採用しました」
「新しい技術を使いたい欲」を抑え、プロダクトのゴール（MVPリリース）のために手段を選べる判断力は、スタートアップの現場で非常に重宝されます。
-
ユーザー体験（UX）を優先したピボット
「当初はUnityでアプリを作っていましたが、現場の端末スペックでは動作が重く、ブラウザで動くWebアプリへ全面的に作り直しました」
これは非常に高評価です。「自分が書きたいコード」よりも「ユーザーの使いやすさ」を優先して、苦労して作ったものを捨てる決断ができる。これは、プロの現場でも求められる重要な資質です。
2. 「企画→開発→運用」のフルサイクル経験がある
学習段階では「コードを書いて動けばOK」かもしれませんが、仕事としては不十分です。
たとえ実務での開発経験が浅くても、私たちが「即戦力に近い」と魅力を感じる方は、開発の「前後」にある泥臭いプロセスを経験しています。
-
「使ってもらう」ための泥臭い工夫
要件定義や実装だけでなく、「操作マニュアルの作成」「現場スタッフへのレクチャー」「問い合わせ対応」まで行っているケースです。
システムは作って終わりではなく、誰かに使われて初めて価値が出ることを理解している点に惹かれます。
-
定量的なデータに基づく改善
「リリース後、Google Analyticsでユーザーの動きを計測したところ、〇〇機能が使われていないことが判明しました。そこでUIを××に変更した結果、クリック率が20%改善しました」
「なんとなく修正しました」ではなく、仮説と検証のサイクルを回した経験は、エンジニアとしての強い武器になります。
-
信頼の証としての「継続契約」
中には、前職を退職した後も、個人的に「業務委託契約」を結んでシステムの保守開発を続けている方もいました。
これは、技術力以前に「人間として信頼されている」ことの何よりの証明であり、会ってみたいと思わせる強力なフックになります。
3. 「学習の密度」と「基礎体力」が可視化されている
実務経験が少ない分、「入社後にどれくらいのスピードで成長できるか（ポテンシャル）」は最重要項目です。
「新しい技術へのキャッチアップには自信があります」、「知的好奇心が旺盛で、継続力があります」といった定型的なアピールだけでなく、職務経歴書内でそれを客観的な事実として証明している方に惹かれます。
-
短期間での集中的な資格取得
例えば、1年〜2年の間に「ITの基礎知識を問う試験」から「専門的なベンダー資格」までを体系的に取得している例です。
知識そのものも評価しますが、それ以上に「目標を決めてやり切る学習習慣（基礎体力）」があることを評価します。
-
エラーとの戦い方を記録している
「開発中に発生したエラーと、その解決プロセスをQiita（Zenn）に50記事以上投稿しています」
単なる技術解説ではなく、「どこで詰まり、どう公式ドキュメントを読み、どう解決したか」という思考のログが見えると、入社後のトラブルシューティング能力への信頼感が高まります。
-
論理的思考力のバックグラウンド
理数系の学部出身であったり、複雑な業務フローを整理した経験があったりと、「論理的思考力」の素地が見えると、新しい技術の習得も早いと判断できます。
4. エンジニア組織に必要な「調整力」を持っている
エンジニアの仕事は、PCに向かっているだけではありません。
ビジネスサイドやデザイナー、あるいは異なる背景を持つメンバーと協働する必要があります。
技術スキル以外の強み（ソフトスキル）が明確な方は、チームの潤滑油として期待できます。
-
ビジネスサイドとの折衝経験
「前職の営業時代、顧客のふわっとした要望を具体的な要件に落とし込むヒアリングを行っていました」
前職で顧客や他部署とタフな交渉をしてきた経験は、エンジニアになってからも「要件定義」や「仕様調整」の場面で必ず活きます。
異業種の経験こそ、エンジニアとしての差別化要因になり得ます。
私たちが探しているのは「課題解決者」
私が面談オファーを出す候補者に共通して言えること。
それは、「コードを書くこと」を目的にせず、「技術という手段を使って、現実の課題を解決しようとしている」点です。
「実務経験が浅いから書くことがない」と悩んでいる方は、ぜひ一度視点を変えてみてください。
あなたが書いたそのコード、あるいは前職での仕事は、「誰の、どんな悩みを解決するために」行われたものでしょうか？
そのストーリーこそがあなたのエンジニアとしての資質を語ってくれるはずです。
📢 採用に関するお知らせ
株式会社ナハトでは、急成長ベンチャーならではの「スピード感」ある環境で、事業をグロースさせたいエンジニアを募集しています。
ご興味のある方は、ぜひ採用ページをご覧ください。