注目のストーリー
All posts
“経験豊富”なはずなのに、選考で残らないのは、なんで？
「開発経験10年以上」「基本設計やレビューも経験あり」それだけ見れば“経験豊富”なはず。でも、なぜか一次選考で落ちてしまう。面接にすら進まない。そんなケース、実は少なくありません。現場目線で見ると「なぜ選ばれなかったのか」の理由は案外明確だったりします。今日は、“経験豊富なのに残れない人”の共通点を整理してお伝えします1. 「何をやってきたか」は書かれているでも「どう関わっていたか」が見えない。職務経歴書にありがちなのが、「基本設計、詳細設計、実装、テスト、保守を担当」という表現の羅列。確かに一通り経験しているように見えます。でも「何を考え、どう判断して進めたのか」が書かれていないと、実...
あなたに任せたい。そう思わせる人の共通点とは？
― 上流ポジションを目指すあなたへ「設計や要件定義に関わっていきたい」「上流工程にキャリアをシフトしたい」そう思っていても、実際に上流ポジションで求められる人物像は、“技術力”だけでは語れません。上流を任される人には、共通する“信頼される力"があります。今日は、採用担当として実際の現場から見えてきた「この人なら任せたい」と思われるエンジニアの共通点をお伝えします。1.「設計できます」ではなく「設計を導けます」「基本設計経験あり」「画面設計やAPI設計に携わりました」といった経験はよく見かけます。ですが、それだけでは「任せたい」とは思われません。上流で任される人は、“設計ができる”こと以上...
技術力だけでは測れない、今の採用基準とは？
近年の中途採用市場では、かつての「できることが多い＝即戦力」という価値観から、大きな変化が起きています。それは――「できること」より「任せられること」で選ばれる時代が来ている、ということですなぜ「できること」だけでは評価されないのか？面接で「こんな技術が使えます」「こういう開発をやっていました」と語られる方は多くいます。けれど、現場が本当に知りたいのは、「その技術をどう使って、どんな判断をしてきたか」ということ。たとえば、Javaでの開発経験があっても…サービス層やドメイン層の設計は自ら主導していたか？フレームワーク（Springなど）の構成方針にどの程度関与していたか？ビジネス要件をど...
「関わった」と「設計した」はまったく違う―職務経歴書における“主語”の重み
――職務経歴書における“主語”の重み、見直してみませんか？日々、たくさんの職務経歴書を拝見する中で感じることがありますそれは――「やっていた」と書かれている業務が、実は“やっていた風”のことが多いということたとえば「基本設計経験あり」と書かれている方でも、よくよく話を聞くと「先輩が作った資料をもとに入力フォームの画面を作っていました」といったケースは少なくありませんここで大事になるのが「主語の重み」です「設計した」のか、「設計に“関わった”」のかで、評価は大きく変わる採用側は、職務経歴書から「この方にどこまで任せられるか」を見ています。たとえば「画面設計を担当」と書かれていた場合、ユーザ...
採用担当者が“よくある違和感”を感じるケースと、どうすれば伝わる職務経歴書になるか？
――ギャップのある応募がもったいない理由と、伝えるべきポイントをまとめてました。選考をしていると、こんな応募に出会うことがあります。「要件定義からリリースまで一貫して担当しました」「基本設計もやっていました」「上流工程の経験があります」一見、頼もしい経験のように見えます。しかし、実際に面接で深掘りしてみると、「設計書のレビューに同席しただけ」「誰が使うか・何のためかは聞かされておらず、仕様通りに作っただけ」といった実態が見えてくることも少なくありません。ここに、現場との“ギャップ”があります。なぜギャップが起きるのか？最大の原因は、職務経歴書に書かれている“言葉”と、その“中身”が一致し...
“生成AIに任せられない仕事”って何だろう？
ChatGPTをはじめとした生成AIの登場で、エンジニアの仕事はどう変わるのか？コードを書くこと、UIを整えること、ドキュメントを作ること、これらの多くはすでにAIで代替可能な領域に入り始めています。では、そんな時代に「エンジニアが担うべき仕事」とは何なのか。言い換えるなら「生成AIに任せられない仕事」とは、どんなものなのかを考えてみました✨それ、誰のための機能ですか？システム開発においてもっとも人間らしい判断が求められるのが、“目的の設定”です例えば、学生管理システムで「成績レポートをPDFで出力したい」という要望が出たとします。AIに頼めば、レポートのPDF出力部分のコードは即座に生...
同じような環境、同じような経験年数。成長できる人と、止まる人の差はどこにある？
同じような環境、同じような経験年数。なのに、なぜか“成長が続く人”と“そこ止まりの人”がいらっしゃいます。それは、才能の差ではなく、ほとんどの場合「姿勢」と「言語化力」の差かと思っています。成長し続ける人は、自分のやっていることに「意味づけ」をしています。たとえば設計書をつくるときも「なぜこの構成なのか？」「誰のために、どんな意図で書いているか？」を考えて取り組まれている傾向です。一方で、成長が止まりがちな人は「与えられた作業」として“やること”にしか意識が向いていないように見えます。この差は、日々の会話にも表れていて、成長する人は、質問の仕方が具体的です。「この仕様だと、データ量が増え...
「要件定義や設計」経験のあるスキルシート。採用担当が見ているのは「関与度」
職務経歴書によく書かれている「要件定義を担当」。採用の現場では「どのレベルまで関与していたのか」「どんな情報を整理して、誰とすり合わせたのか」といった“中身”まで見ています🐈要件定義という言葉には幅があります。ビジネス要件のヒアリング、業務フローの整理、機能要件の抽出、非機能要件の取りまとめ、そしてそれらを関係者と合意形成していくまで――。これらのどこにどの程度関わったのかで、経験値もスキルも大きく異なりますたとえば、営業担当がまとめた要望リストを受け取り、要件定義書のテンプレートに落とし込んだだけ、というケースもあります。一方で、エンドユーザーと直接会話し、業務上の課題をヒアリングし、...
制度じゃ伝わらない“雰囲気”を、、1日のスケジュールをご紹介します！
「どんな会社なのか気になるけど、求人票だけじゃ雰囲気が分からない…」そんな声にお応えして（？）、今回は**“社内案件に参画しているメンバーの1日”**を少しだけご紹介します！■ 基本の勤務時間：8:45〜17:45現在はリモートワークと出社のハイブリッドを取り入れており、勤務スタイルはプロジェクトや職種によって柔軟に調整可能です。※入社してしばらくは基本出社をお願いしております。フレックスタイム制も導入しているため、業務状況に応じて早め・遅めの出社もOK！■ 9:00 全体朝礼（＠Web）毎朝9時から、エンジニア、営業、事務も含めて全員参加で朝礼を行います。内容は以下の2つがメインです：...
あなたの“仕様理解力”は現場で通用するか？「読み取り＋問い返し」ができる人材こそ、仕様理解力が高い
システム開発において「仕様を理解しています」という言葉はよく使われますが、果たしてその“理解”は、現場で求められるレベルに達しているか、振り返って確認してみても良いかもしれません😊採用の現場でも「仕様書をもとに開発していました」「要件定義をもとに設計していました」といった経歴が並びます。しかし、いざ面談で詳細を聞いてみると「仕様書のどこをどう解釈したのか？」「不明点があったとき、どう対処したのか？」「顧客との認識齟齬をどう防いだのか？」といった具体的なエピソードが出てこない方もいらっしゃいます実際の現場では、仕様書は必ずしも“完璧”ではありません。曖昧な表現、過不足のある要件、矛盾した記...
条件を減らすには「業務の本質」から考える
条件分岐が多い業務フローは、やがて破綻する業務フローを整理する際、よく目にするのが「この場合はAだけど、こういうときはB」「ただし、この条件なら例外的にC」という分岐の連続です。一見すると柔軟で丁寧な対応のように見えますが、条件分岐が多い業務フローは、属人化・ミス・混乱の温床になりがちです特にシステム化や自動化を見据えたとき、条件が多ければ多いほど、処理の複雑さが爆発的に増します。これは現場でも、開発でも、運用でも、大きな負担となって跳ね返ってくるのですなぜ条件分岐が少ない方がよいのか？1. 運用ミスのリスクを減らせる条件が多ければ、担当者は「どのケースに当てはまるか」をその都度判断する...
「職務経歴書」は“工程名”ではなく“中身”で評価される～採用担当が見ているポイント7選～
採用側は「工程における思考・判断・実行の中身」を見ています。今回、選考通過率を上げるために必要な書くべき各ポイント7つを、実務ベースでまとめてみました✨① 工程ごとに 「何をしたか」ではなく「何を考えたか」 を書くただ「要件定義しました」「基本設計やりました」では、具体的内容が把握しにくいので、どういう情報を元に、どんな判断・整理を行ったかを書く必要があります🔸悪い例：要件定義を担当🔸良い例：顧客からの要望ヒアリング内容を業務フローに落とし込み、実現可否を検討。費用対効果を加味し、優先度づけして提案。② 成果物・アウトプットを具体的に記載する上流工程では、考えたことの“証拠”＝成果物が重...
品質保証も“人の目”が大事
テストの自動化、CI/CDパイプラインの高度化、AIによるバグ検出──近年、開発現場における品質保証の仕組みは飛躍的に進化しています。再現性のある検証を、正確かつ高速に回し続ける。これらは、機械の得意分野。ですが、品質を「担保する」ことと「保証する」ことは、似て非なるものと思っていますどんなにテストが通っていても、「この仕様、本当にこれでいいの？」「ユーザーがこの操作で迷わない？」「エラー文言が冷たくない？」といった、人の感覚による確認は、どうしても最後に必要になりますなぜ人間による品質保証が欠かせないのか？1. ユーザー体験はスペックでは測れないたとえば、業務支援系の管理システム。機能...
仕様決定は、AIより人間がまさる気がしています──
AIの進化によって、設計やコード生成の精度は飛躍的に向上しました。プロンプト一つで複雑なシステムのコードをアウトプットし、テストコードすら自動生成できる時代です。AIがいずれ仕様決定も担うようになってくるのか。考えてみました少なくとも現時点では「No」な気が個人的にはします。そして、今後もしばらくは「人間にしかできない仕事」であり続けるんじゃないかと思っています。その理由を、いくつかの視点から整理してみます1. 「仕様」はビジネス戦略と密接に結びついている仕様決定とは単なる機能一覧の作成ではありません。顧客の課題、ビジネスモデル、現場の業務プロセス、競合との差別化要因など、あらゆる要素を...
AIでコードが書ける時代でも「人間のレビュー」は不可欠な理由
生成AIやコード補完ツールの進化により、コードを書くスピードは飛躍的に向上しました。特に、定型処理やAPI連携など、パターン化された業務は自動生成でも高精度でカバーできます。ですが――生成されたコードをそのまま信用してはいけません。なぜなら、AIは「動くコード」は出せても、「適切なコード」かどうかの判断はできないからですコードレビューで人間が担う3つの役割1. 業務背景と目的との整合性を確認するAIは仕様の文脈を深くは理解していません。「この処理、本当にこのビジネスロジックで正しいのか？」という視点は、人間にしか持てません。2. 設計思想・アーキテクチャへの適合を見極めるいくら動くコード...
