「Java出来ます」 「Reactやってます」 「AWS触れます」 もちろん、それらは大切です。 ですが、実際のシステム開発現場で、本当に難しく、本当に価値が出るのは、そこではありません。 私たちが最も重要だと考えているのは、 “仕様を理解する力” です。 システム開発とは、 「仕様書通りに作る仕事」 だと思わ...
採用をさせていただいている中で「要件定義経験あります」 という職務経歴書をよく見ます。 面談や面接で詳しくお話を聞いていくと、実態はかなり違うことがあります。 例えば、 ・既存仕様の修正 ・項目追加 ・画面文言変更 ・API項目定義 ・設計書更新 これらも、現場によっては「要件定義」と表現されることがあり...
ここ数年で、開発現場は大きく変わりました。 AIによって、 コード生成 テストコード作成 リファクタ ドキュメント生成 まで、自動化され始めています。 では今後、エンジニアに求められるものは何か。 私たちは、 “仕様を理解し、整理し、構造化できる力” だと考えています。 なぜならAIは、 「何を作るべきか」...
当社では現在、教育・人材領域を支える複数の基幹システムを 外注中心の開発体制から、段階的に内製へ切り替えるフェーズ に入っています。 これまではスピード優先で外部ベンダーと協業してきましたが、 事業拡大に伴う要件の複雑化 長期運用を前提とした堅牢性・保守性の重要性 業務理解を前提とした設計判断の必要性 といった...
前回は「伸びない理由」を解説しました。 では逆に、 エンジニアが伸びる環境とは何か? 結論から言うと、 “思考を強制される環境”です💡 ① レビュー文化がある なぜこの実装なのか 他に選択肢はないのか ここまで突っ込まれる環境。 👉 レビュー=品質チェックではない 👉 レビュー=思考のトレーニング この環境に...
「API設計を担当しました」 この表現もよく見かけます。 ただ、ここも基本設計と同じで、 👉 中身の解像度で伝わり方が変わる領域です 今回は、API設計の実務を できるだけ具体的に分解してみます。 API設計で考えていること ① エンドポイント設計 URL構造(/users, /orders など) リソースの...
職務経歴書でよく見る一文。 「基本設計を担当しました」 一見、上流工程に見えます。 この言葉、間違いではないのですが、 これだけだと少しもったいないです。 なぜなら、 👉 中身の解像度で伝わり方が大きく変わるから 今回は「基本設計って実際に何をやっているのか」を 実務ベースで分解してみました。 そもそも基本設計...
同じ年数、同じ現場。 それでも、伸びる人と止まる人がいる。 その差は、才能ではありません。 “思考と行動のクセ”です。 今回は、採用・現場の両視点から 「伸びないエンジニアの共通点」を整理します。 ① 「環境のせい」にしている 案件が悪い 技術が古い 教えてもらえない 気持ちはわかります。 ただ、ここで止まる...
今回は、採用側が思わず前のめりになる「この人、できる」と感じる職務経歴書の特徴を整理します。 ① 「役割」と「意思決定」が明確 できる人の職務経歴書は、単なる作業報告ではありません。 API設計において、認証方式をJWTに統一 DB設計でインデックス設計を見直し、性能改善 “何を任され、何を判断したのか”が書か...
評価されない職務経歴書あるある エンジニア採用をしていると、毎日のように職務経歴書を見ます。その中で正直に言うと「もったいない」と感じるケースがかなり多いです。 スキルがないわけではない。でも、“伝わっていない”。 今回は、採用側の視点で「評価されない職務経歴書あるある」を整理します。 ① 「要件定義やりました」...
転職活動をしているエンジニアの方と話していると、よくこんな声を聞きます。 「この技術、5年後も使われていますか?」 「年齢を重ねてもエンジニアとして通用しますか?」 「AIに仕事を奪われませんか?」 とても健全な不安だと思います。 その一方で、多くのエンジニアがまだ価値に気づいていない、しかし今後も確実になくな...
評価されない職務経歴書、実は“よくある型”があります 採用に関わっていると「経験はあるはずなのに、判断材料が足りない」 そんな職務経歴書に出会うことが少なくありません。 書き方で損をしているケースがほとんどです。 ここでは、採用側から見て「これは評価しづらい…」となりがちな 職務経歴書あるあるを整理してみます✨ ...
開発現場で、こんなやり取りを見たことはないでしょうか。 「仕様書どおりに実装しました」 「……うん、でもこれ、使いにくいよね」 エンジニア側からすると、理不尽に聞こえるかもしれません。 書いてある通りに作った。テストも通した。 それなのに、なぜダメ出しをされるのか。 このズレの正体は、とてもシンプルです。 仕様を...
エンジニアの価値は、書けるコードの量だけで決まるわけではありません。 むしろ、キャリアが進めば進むほど問われるのは 「技術そのもの」よりも前段階にある能力──それが “問題を定義する力” 多くの開発現場で、こんな光景があります。 仕様は一応ある。タスクも割り振られている。 にもかかわらず、なぜか実装フェーズに入...
私たちのチームに、ただコードを書くだけではなく、“プロダクト全体の構造”を見渡し、どの部分がどうつながり、どんな未来の拡張に備えるべきかを描ける人を必要としています✨ なぜ「システム構造」を考えられるエンジニアを求めているのか。 現場で起きている多くの問題は、実は“構造の歪み”から生まれています。 レスポンスが遅...