エンジニアとしてのキャリアを考えるうえで、「働きやすさ」を重視されている方も多いと思います。 日本教育クリエイトでも、ライフステージに応じて柔軟に働ける環境づくりに力を入れてきました。 ですが、「制度があるから安心」だけではなく、一人ひとりの人生を本気で尊重するカルチャーそのものが、私たちの職場の魅力です。 小...
スキルシートでよく見かける「基本設計経験あり」の言葉 しかし、実際に話を聞いてみると「それ、基本設計というより詳細設計では?」と思うケースが少なくありません💦 たとえば、ある教育業界のプロジェクトでの話 学生の情報管理、授業の出欠登録、保護者向け通知の仕組みを構築する案件でした あるエンジニアは「画面の入力項目を...
開発の現場では、こんな場面によく出会います。 あるエンジニアは専門用語を次々と並べ、もう一方は「何を言っているのかよくわからない…」と戸惑う。結果として会話が空回りし、仕様の確認や設計の議論が前に進まなくなる。 これ、実は“誰が悪い”わけでもないんです。 知識レベルの差があるから、同じ言葉を使っても頭に浮かんでい...
プロジェクトにおける認識のズレの多くは「同じ言葉を使っていても、違う意味で理解している」ことから生まれます 「設計できています」って、どこまでの粒度? 「テストしました」って、単体?結合?手動?自動? 「対応済みです」って、修正完了?レビュー完了?リリース済み? このように、使っている言葉が同じでも、人によって...
あるメンバーがこんなことを言っていました 「昔は、なんでもやりますって言ってた。必要とされることに応えるのがプロだと思ってたんです。でもあるとき、気づいたんです。“自分がどうなりたいか”がずっと置き去りだったなって」 一方で、別の若手メンバーはこんな悩みを抱えていました 「自分はこれがやりたいんですって話すと、...
「この機能、どうやって作ろう?」 エンジニアであれば誰もが考える問いです。 でも本当に大切なのは、「なぜ作るのか?」 という問いを持つこと。 つまり ドメイン(業務領域や課題の本質)を理解することです🐈 ドメインを軽視すると何が起きるか 作ったものが実際の業務フローにフィットしない ユーザーが本当に解決したかっ...
「一人でできる」から「任せられる」へ ─ 信頼されるエンジニアの条件 エンジニアとしてキャリアを積んでいくと、必ずぶつかる壁があります。それは「技術力がある=信頼される」とは限らない、という現実です 「一人でできる」スキルは確かに大事です。しかし現場で本当に求められるのは、“任せられる人” になること。ということ...
― 伝える力と技術力は、切り離せない。 「設計って、どうやってうまくなるんですか?」 そんな問いに対して、ベテランエンジニア👩🔧が静かにこう答えたことがあります。 「説明して伝わるようになったとき、設計は自然とうまくなるよ」 その言葉の意味は、実はとても深いんです💡 たとえば、設計書を作るとき。 そこに書かれ...
── ドキュメントよりも対話を重視する理由 「これ、仕様書に書いてなかったんですけど…」 「どういう意図でこの処理なんですか?」 「この仕様、もう少し柔軟に考えられませんか?」 ――開発現場で、こうしたやりとりはよくあります。 なぜか? ”完璧な仕様書なんて、存在しない”からです。 いくら綿密に書いても、すべての...
─ コード量じゃない。周囲にどれだけ“安心”を与えているか。 「自分、そんなにコード書いてないけど、チームに貢献できてるのかな?」 あるエンジニアが、1on1でそんな不安を口にしました。 でも、チームのメンバーに聞くと、彼の名前は必ず「頼れる存在」として挙がります。 それはなぜか? 彼は、コードレビューで“動くけ...
「技術は面接じゃわからないから、ポートフォリオで判断しますよね?」 応募いただく方から、そう言われることもありますが、私たちが面接で見ているのは、 実は“技術力”そのものよりも、“技術に向き合う姿勢”や“仕事の進め方”だったりします。 ■ 面接で見ているのは「コード」ではなく「向き合い方」 確かに、実務経験が何...
あるエンジニアがこう言いました。 「業務理解が進まないんです。だって、うちの会社の事業内容がよくわからないんですよね」 その言葉を聞いたとき、正直少し引っかかりました。 確かに、業界知識や業務フローが複雑な会社もある。 でも、それだけが“業務理解が進まない理由”とは限らないんじゃないかと思ったのです。 たとえば...
―― 設計書や仕様書の「書かれていない前提」まで理解できるリーダーであってほしい。 仕様書や設計書は読んでいる。 指示もしているし、タスクも回っている。 でも、なぜかチーム内でズレが出る。 「想定と動きが違う」 「目的と実装が合っていない」 「修正や手戻りがやたら多い」 こうした状況の原因は、設計書や仕様書に“書...
評価シートに書いてあることが、何を意味するのかわからない? ―― “目の前の仕事”と“評価される力”をつなぐヒント 「業務はちゃんとやってるつもり」 「でも、等級や評価で何を見られてるのかがよくわからない」 「レビューもしてるし、技術も身につけてる。それで何が足りないの?」 モヤモヤするときありますよね 評価内容...
「開発経験10年以上」「設計から保守までやってきた」 それなのに、書類が通らない。面接で落ちる。手応えがない。 もしかすると、スキルではなく伝え方や向き合いかたに、つまずきの原因があるのかもしれません 【落とし穴①】ただの“経験の羅列”になっていないか? 「何をやったか」だけじゃ、伝わらない。大事なのは“どう関...
コードレビュー、設計レビュー、ドキュメントレビュー…… 「間違いを見つけられるのが嫌だ」 「面倒くさい」「時間がかかる」 そんなふうに感じている人も、少なくないかもしれません。 でも本来、レビューは「成長のチャンス」です。 特に、自分のスキルを本気で高めたい人にとっては、最強の教材になり得ます 他人の目は“気づ...
「開発経験10年以上」「基本設計やレビューも経験あり」 それだけ見れば“経験豊富”なはず。 でも、なぜか一次選考で落ちてしまう。面接にすら進まない。 そんなケース、実は少なくありません。 現場目線で見ると「なぜ選ばれなかったのか」の理由は案外明確だったりします。 今日は、“経験豊富なのに残れない人”の共通点を整理...
― 上流ポジションを目指すあなたへ 「設計や要件定義に関わっていきたい」 「上流工程にキャリアをシフトしたい」 そう思っていても、実際に上流ポジションで求められる人物像は、 “技術力”だけでは語れません。 上流を任される人には、共通する“信頼される力"があります。 今日は、採用担当として実際の現場から見えてきた ...
近年の中途採用市場では、かつての「できることが多い=即戦力」という価値観から、大きな変化が起きています。 それは―― 「できること」より「任せられること」で選ばれる時代が来ている、ということです なぜ「できること」だけでは評価されないのか? 面接で「こんな技術が使えます」「こういう開発をやっていました」と語られ...