株式会社日本教育クリエイト IT人材サービス事業部

エンジニアに求められるのは“聞き取り力”より“汲み取り力”

要件定義の現場でよくあるのが、ユーザーからのヒアリング。多くのエンジニアが「しっかり聞き取ること」を意識します。しかし、本当に重要なのは 「聞き取り力」ではなく「汲み取り力」 です聞き取れた“言葉”だけでは足りないユーザーは必ずしも自分の課題を正確に言葉にできるわけではありません。「問題は特にないです」と言っていたのに、実際には裏で膨大な手作業をしていた――そんな経験はありませんか？言葉にされた内容だけを要件として捉えると、本当の課題は見過ごされてしまう のです沈黙や曖昧さにこそヒントがある短い「はい」に隠された不安説明を避ける場面に潜む非効率言葉にできなかったモヤモヤこれらを察知し、掘...

『一人でできる』から『任せられる』へ 。信頼されるエンジニアの条件

「一人でできる」から「任せられる」へ─ 信頼されるエンジニアの条件エンジニアとしてキャリアを積んでいくと、必ずぶつかる壁があります。それは「技術力がある＝信頼される」とは限らない、という現実です「一人でできる」スキルは確かに大事です。しかし現場で本当に求められるのは、“任せられる人” になること。ということで、今回は、その違いはどこにあるのかまとめてみました🐈1. 技術力は前提、信頼は「見える化」から生まれるどれだけ優れたコードを書けても、その過程や意図をチームが理解できなければ、安心して任せることはできません。進捗の共有、設計の背景の説明、課題の早めの相談。これらが「任せても大丈夫」と...

【社員インタビュー】“締切を守る”ことから始まった、現場で信頼を築く私の成長ストーリー

石阪さん2024年5月に入社し、同年8月には早くもプロジェクト先へ。現場に立つにはまだ早いと思っていたタイミングでの配属に、不安とプレッシャーを抱えながらも、石阪さんは「まずは締切を守ること」を自分の武器にして、お客様の信頼を積み重ねていきました💡目の前の課題に食らいつきながら、少しずつ、でも確実に成長を実感していく日々。今回は、経験が浅いからこそ見える景色や、チームの中で居場所をつくるまでの軌跡をお届けします✨◼️プロフィール石阪　友紀さん現在、松井さんがプロジェクトマネージャーとして参画しているお客様案件にメンバーとして参画してもらっています。◯趣味アニメ、漫画、一人カラオケ◯好きな...

「知識がある」だけでは足りない「理解している」人の違い― 技術の先にある“文脈を読む力”

「知識がある」だけじゃ届かない“理解している人”は、なぜ信頼されるのか？「この技術、知ってます」だけでは、現場で評価されづらい――そんなもどかしさを感じたことはありませんか？エンジニアとして勉強し、知識を身につけてきた。でも、実務になると、何かが足りないような気がする。そう思う瞬間は、誰にでもあると思います💡私たちが現場で何度も見てきたのは、「知っている人」と「理解している人」の間にある、決定的な差です。たとえば、仕様レビューの場で「この技術の使い方は合っている」とだけ答える人と、「この処理が、実際の業務のどの場面で活きるか」「将来的にどんな影響が出そうか」まで読み取って提案できる人。知...

“わかりやすい説明”ができる人ほど、設計がうまい

― 伝える力と技術力は、切り離せない。「設計って、どうやってうまくなるんですか？」そんな問いに対して、ベテランエンジニア👩‍🔧が静かにこう答えたことがあります。「説明して伝わるようになったとき、設計は自然とうまくなるよ」その言葉の意味は、実はとても深いんです💡たとえば、設計書を作るとき。そこに書かれているのは仕様や構造ですが、本当に大事なのはその“背景”です。・なぜこの構成にしたのか・なぜ別の案を選ばなかったのか・将来的に何を見据えているのかこれらを誰かに説明するとき、自分の思考の道筋が曖昧なままだと、たちまち伝わらなくなります。逆に、伝える過程で「そもそも自分、ここちゃんと理解してなか...

【社員インタビュー】成果にこだわるチーム。SES事業初経験から始まった1年の挑戦

2024年３月入社の松井さんに、入社してから、１年経過した今、近況をインタビューしました🐈ウォンテッドリーのストーリーは、松井さんからのインタビュー記事から、スタートしました🎉いろいろ熱く語ってくれましたので、ぜひ、ご覧ください。◼️プロフィール松井　伸興さん現在も、SES事業のプロジェクトマネージャーとして、お客様の重要な案件に参画してもらっています。◯趣味野球観戦、スノーボード、釣り◯好きな言葉理論と実践の往復◯入社したきっかけ　面接時に「人を大切にして、会社への帰属意識、教育面を大事にする」という話があって、人を大事にしたり、その組織の一員として、同じ事業部の仲間と精一杯仕事をする...

「完璧な仕様書なんて存在しない」からこそ、仕様の会話が大事

── ドキュメントよりも対話を重視する理由「これ、仕様書に書いてなかったんですけど…」「どういう意図でこの処理なんですか？」「この仕様、もう少し柔軟に考えられませんか？」――開発現場で、こうしたやりとりはよくあります。なぜか？”完璧な仕様書なんて、存在しない”からです。いくら綿密に書いても、すべての要件や例外、想定される利用シーンを網羅することはできません。逆に言えば、仕様書を「完全な正解」として扱いすぎると、現場では手が止まってしまうのです。たとえば「ユーザー」と一言で言っても、立場や状況によって目的は変わります。「こうすべき」と書かれているけど、現実の業務ではうまくフィットしない。「...

チームの中での“貢献力”って、どう測る？

─ コード量じゃない。周囲にどれだけ“安心”を与えているか。「自分、そんなにコード書いてないけど、チームに貢献できてるのかな？」あるエンジニアが、1on1でそんな不安を口にしました。でも、チームのメンバーに聞くと、彼の名前は必ず「頼れる存在」として挙がります。それはなぜか？彼は、コードレビューで“動くけど危うい実装”を丁寧に指摘してくれる。ミーティングでは「本当にこの仕様で大丈夫？」と、立ち止まってくれる。困っている人がいれば、「今少し時間あるけど、見ようか？」と自然に声をかけている。そう、彼は“成果”ではなく“信頼”を積み上げていたのです。チーム開発では、ただコードを書くことだけが貢献...

面接で「技術力」より先に見ているもの― エンジニア採用担当者目線での面接ポイントとは？

「技術は面接じゃわからないから、ポートフォリオで判断しますよね？」応募いただく方から、そう言われることもありますが、私たちが面接で見ているのは、実は“技術力”そのものよりも、“技術に向き合う姿勢”や“仕事の進め方”だったりします。■ 面接で見ているのは「コード」ではなく「向き合い方」確かに、実務経験が何年ある、どんな言語が書ける、という情報も重要です。でも、面接の限られた時間で見極められるのは、その人の本質的な姿勢や思考のクセです。たとえばこんなポイントを見ています。■ 面接で私たちが大事にしている５つの視点①「なぜ」この選択をしたのか語れるか仕様をどう捉え、なぜその技術・設計を選んだの...

「業務がわからない」って言う前に、見えていないもの

あるエンジニアがこう言いました。「業務理解が進まないんです。だって、うちの会社の事業内容がよくわからないんですよね」その言葉を聞いたとき、正直少し引っかかりました。確かに、業界知識や業務フローが複雑な会社もある。でも、それだけが“業務理解が進まない理由”とは限らないんじゃないかと思ったのです。たとえば、自分が関わっているシステムの仕様書を読んで、「この機能って、誰がどんな場面で使うんだろう？」と疑問に思ったことはありませんか？でもそのまま「業務がわからないから調べられない」と止まってしまってはいませんか？業務理解とは、最初から“すべてを知っている状態”ではありません。むしろ、“わからない...

“チームにとっての最適”と“自分にとっての最適”がズレた瞬間。技術的こだわりとチーム開発のバランスを考える

「自分にとっての最適」だけで進めていなかったか？開発チームのとあるエンジニアのお話。―― チーム開発と、技術的こだわりのあいだで気づいたことエンジニアとしてある程度経験を積むと、「自分なりのベストプラクティス」が自然と増えていきます。あのときのバグ、このときの失敗、成功体験。知識と経験が重なって、自分の中に「こうすればいい」が蓄積されていくのです。そしてそれは、時に“独善的な正しさ”として立ちはだかることがあります。そういう瞬間がありました。ある日、プロジェクトでAPIの設計方針についてチームで議論になりました。私は「RESTの原則に則った設計にすべきだ」と強く主張。中途半端なRESTは...

「仕様を理解する力」はリーダーの土台

―― 設計書や仕様書の「書かれていない前提」まで理解できるリーダーであってほしい。仕様書や設計書は読んでいる。指示もしているし、タスクも回っている。でも、なぜかチーム内でズレが出る。「想定と動きが違う」「目的と実装が合っていない」「修正や手戻りがやたら多い」こうした状況の原因は、設計書や仕様書に“書いてあること”しか見えていないことかもしれません設計書や仕様書は、あくまで「最低限の情報」設計書や仕様書には必要な情報が書かれています。でも、そこに書かれていないけれど重要な“前提”や“意図”が必ず存在します。たとえば──バリデーションの順番があえて指定されている理由なぜ非同期ではなく同期処理...

“目の前の仕事”と“評価される力”をつなぐヒント

評価シートに書いてあることが、何を意味するのかわからない？―― “目の前の仕事”と“評価される力”をつなぐヒント「業務はちゃんとやってるつもり」「でも、等級や評価で何を見られてるのかがよくわからない」「レビューもしてるし、技術も身につけてる。それで何が足りないの？」モヤモヤするときありますよね評価内容は“未来の役割”から決まっている等級制度に書かれている項目は、抽象的なものが多く見えます。たとえばこんな言葉、目にしたことがありませんか？「主体的に業務を推進できる」「チーム全体の生産性に寄与する」「上位の視座で設計・実装を進められる」これらは「この等級なら、こういう役割を担っていてほしい」...

設計だけ、実装だけ、じゃない。仕様の背景を、みんなが知っているー開発チームの特徴ー

設計だけ、実装だけ、じゃない。“みんなでつくる”が、日本教育クリエイトの開発スタイルです。設計担当、実装担当。分業すれば効率的。そう言われることもあります。私たちの開発チームは、設計も、実装も、全員が関わる。仕様の意図も、技術的な制約も、みんなで共有し、みんなで考える。そこにこそ私たちが大事にしている「納得感」と「連携」があります。仕様の背景を、みんなが知っている「なぜこの設計になったのか」「どんな業務上の制約があるのか」「何を守るためのバリデーションなのか」設計と実装を分けないことで、実装する人が“設計の背景”をちゃんと理解しています。逆に、設計に関わるメンバーも、「この設計は本当に現...

仕様をそのままコードにするのではなく、「本質」を噛み砕く

フレームワークに書かされたコードじゃない“ビジネスロジックに命を吹き込む”ことが、私たちの開発です。Javaでも、C#でも。SpringやASP.NETでも。どんなフレームワークを使っても、私たちが一番大切にしていることがあります。それは、ビジネスロジックをどう設計し、どう実装するか。「このチェック、なぜここで入れてるの？」「この処理って、ユーザーにとって何を守ってる？」「このデータの整合性、どこまでを責任範囲とすべき？」コードレビューのたびに、そんな会話が飛び交います。私たちは、仕様書に書かれた“やるべきこと”だけで開発を進めません。その背後にある意図や業務の流れを理解した上で、「何を...