注目のストーリー
All posts
“チームにとっての最適”と“自分にとっての最適”がズレた瞬間。技術的こだわりとチーム開発のバランスを考える
「自分にとっての最適」だけで進めていなかったか？開発チームのとあるエンジニアのお話。―― チーム開発と、技術的こだわりのあいだで気づいたことエンジニアとしてある程度経験を積むと、「自分なりのベストプラクティス」が自然と増えていきます。あのときのバグ、このときの失敗、成功体験。知識と経験が重なって、自分の中に「こうすればいい」が蓄積されていくのです。そしてそれは、時に“独善的な正しさ”として立ちはだかることがあります。そういう瞬間がありました。ある日、プロジェクトでAPIの設計方針についてチームで議論になりました。私は「RESTの原則に則った設計にすべきだ」と強く主張。中途半端なRESTは...
「仕様を理解する力」はリーダーの土台
―― 設計書や仕様書の「書かれていない前提」まで理解できるリーダーであってほしい。仕様書や設計書は読んでいる。指示もしているし、タスクも回っている。でも、なぜかチーム内でズレが出る。「想定と動きが違う」「目的と実装が合っていない」「修正や手戻りがやたら多い」こうした状況の原因は、設計書や仕様書に“書いてあること”しか見えていないことかもしれません設計書や仕様書は、あくまで「最低限の情報」設計書や仕様書には必要な情報が書かれています。でも、そこに書かれていないけれど重要な“前提”や“意図”が必ず存在します。たとえば──バリデーションの順番があえて指定されている理由なぜ非同期ではなく同期処理...
“目の前の仕事”と“評価される力”をつなぐヒント
評価シートに書いてあることが、何を意味するのかわからない？―― “目の前の仕事”と“評価される力”をつなぐヒント「業務はちゃんとやってるつもり」「でも、等級や評価で何を見られてるのかがよくわからない」「レビューもしてるし、技術も身につけてる。それで何が足りないの？」モヤモヤするときありますよね評価内容は“未来の役割”から決まっている等級制度に書かれている項目は、抽象的なものが多く見えます。たとえばこんな言葉、目にしたことがありませんか？「主体的に業務を推進できる」「チーム全体の生産性に寄与する」「上位の視座で設計・実装を進められる」これらは「この等級なら、こういう役割を担っていてほしい」...
設計だけ、実装だけ、じゃない。仕様の背景を、みんなが知っているー開発チームの特徴ー
設計だけ、実装だけ、じゃない。“みんなでつくる”が、日本教育クリエイトの開発スタイルです。設計担当、実装担当。分業すれば効率的。そう言われることもあります。私たちの開発チームは、設計も、実装も、全員が関わる。仕様の意図も、技術的な制約も、みんなで共有し、みんなで考える。そこにこそ私たちが大事にしている「納得感」と「連携」があります。仕様の背景を、みんなが知っている「なぜこの設計になったのか」「どんな業務上の制約があるのか」「何を守るためのバリデーションなのか」設計と実装を分けないことで、実装する人が“設計の背景”をちゃんと理解しています。逆に、設計に関わるメンバーも、「この設計は本当に現...
仕様をそのままコードにするのではなく、「本質」を噛み砕く
フレームワークに書かされたコードじゃない“ビジネスロジックに命を吹き込む”ことが、私たちの開発です。Javaでも、C#でも。SpringやASP.NETでも。どんなフレームワークを使っても、私たちが一番大切にしていることがあります。それは、ビジネスロジックをどう設計し、どう実装するか。「このチェック、なぜここで入れてるの？」「この処理って、ユーザーにとって何を守ってる？」「このデータの整合性、どこまでを責任範囲とすべき？」コードレビューのたびに、そんな会話が飛び交います。私たちは、仕様書に書かれた“やるべきこと”だけで開発を進めません。その背後にある意図や業務の流れを理解した上で、「何を...
スキルがあるのに選ばれない？“なぜか採用されないエンジニア”に共通する3つの落とし穴とは？
「開発経験10年以上」「設計から保守までやってきた」それなのに、書類が通らない。面接で落ちる。手応えがない。もしかすると、スキルではなく伝え方や向き合いかたに、つまずきの原因があるのかもしれません【落とし穴①】ただの“経験の羅列”になっていないか？「何をやったか」だけじゃ、伝わらない。大事なのは“どう関わったか”よくある表現：「要件定義〜テストまで一貫して対応」→ それだけでは、“深さ”も“価値”も伝わりません。✅ 改善ポイント「自分の立場」「判断したこと」「工夫したこと」を明記数字や影響範囲があれば具体的に（例：3名チームのリーダーとして…）【落とし穴②】ポートフォリオやアウトプットが...
レビューは「指摘される場」じゃない。自分のスキルが一番伸びる“学びのチャンス”だ
コードレビュー、設計レビュー、ドキュメントレビュー……「間違いを見つけられるのが嫌だ」「面倒くさい」「時間がかかる」そんなふうに感じている人も、少なくないかもしれません。でも本来、レビューは「成長のチャンス」です。特に、自分のスキルを本気で高めたい人にとっては、最強の教材になり得ます他人の目は“気づきの宝庫”ひとりでコードを書いていると、どうしても自分の思考のクセに気づけません。でもレビューで指摘されると、そこには「他者視点での“気づき”」がある。「その変数名、抽象的すぎて意図が伝わらないね」「この処理、1件ずつループするよりSQLでまとめた方が効率いいかも」「その例外処理、ユーザーにと...
“経験豊富”なはずなのに、選考で残らないのは、なんで？
「開発経験10年以上」「基本設計やレビューも経験あり」それだけ見れば“経験豊富”なはず。でも、なぜか一次選考で落ちてしまう。面接にすら進まない。そんなケース、実は少なくありません。現場目線で見ると「なぜ選ばれなかったのか」の理由は案外明確だったりします。今日は、“経験豊富なのに残れない人”の共通点を整理してお伝えします1. 「何をやってきたか」は書かれているでも「どう関わっていたか」が見えない。職務経歴書にありがちなのが、「基本設計、詳細設計、実装、テスト、保守を担当」という表現の羅列。確かに一通り経験しているように見えます。でも「何を考え、どう判断して進めたのか」が書かれていないと、実...
あなたに任せたい。そう思わせる人の共通点とは？
― 上流ポジションを目指すあなたへ「設計や要件定義に関わっていきたい」「上流工程にキャリアをシフトしたい」そう思っていても、実際に上流ポジションで求められる人物像は、“技術力”だけでは語れません。上流を任される人には、共通する“信頼される力"があります。今日は、採用担当として実際の現場から見えてきた「この人なら任せたい」と思われるエンジニアの共通点をお伝えします。1.「設計できます」ではなく「設計を導けます」「基本設計経験あり」「画面設計やAPI設計に携わりました」といった経験はよく見かけます。ですが、それだけでは「任せたい」とは思われません。上流で任される人は、“設計ができる”こと以上...
技術力だけでは測れない、今の採用基準とは？
近年の中途採用市場では、かつての「できることが多い＝即戦力」という価値観から、大きな変化が起きています。それは――「できること」より「任せられること」で選ばれる時代が来ている、ということですなぜ「できること」だけでは評価されないのか？面接で「こんな技術が使えます」「こういう開発をやっていました」と語られる方は多くいます。けれど、現場が本当に知りたいのは、「その技術をどう使って、どんな判断をしてきたか」ということ。たとえば、Javaでの開発経験があっても…サービス層やドメイン層の設計は自ら主導していたか？フレームワーク（Springなど）の構成方針にどの程度関与していたか？ビジネス要件をど...
「関わった」と「設計した」はまったく違う―職務経歴書における“主語”の重み
――職務経歴書における“主語”の重み、見直してみませんか？日々、たくさんの職務経歴書を拝見する中で感じることがありますそれは――「やっていた」と書かれている業務が、実は“やっていた風”のことが多いということたとえば「基本設計経験あり」と書かれている方でも、よくよく話を聞くと「先輩が作った資料をもとに入力フォームの画面を作っていました」といったケースは少なくありませんここで大事になるのが「主語の重み」です「設計した」のか、「設計に“関わった”」のかで、評価は大きく変わる採用側は、職務経歴書から「この方にどこまで任せられるか」を見ています。たとえば「画面設計を担当」と書かれていた場合、ユーザ...
採用担当者が“よくある違和感”を感じるケースと、どうすれば伝わる職務経歴書になるか？
――ギャップのある応募がもったいない理由と、伝えるべきポイントをまとめてました。選考をしていると、こんな応募に出会うことがあります。「要件定義からリリースまで一貫して担当しました」「基本設計もやっていました」「上流工程の経験があります」一見、頼もしい経験のように見えます。しかし、実際に面接で深掘りしてみると、「設計書のレビューに同席しただけ」「誰が使うか・何のためかは聞かされておらず、仕様通りに作っただけ」といった実態が見えてくることも少なくありません。ここに、現場との“ギャップ”があります。なぜギャップが起きるのか？最大の原因は、職務経歴書に書かれている“言葉”と、その“中身”が一致し...
“生成AIに任せられない仕事”って何だろう？
ChatGPTをはじめとした生成AIの登場で、エンジニアの仕事はどう変わるのか？コードを書くこと、UIを整えること、ドキュメントを作ること、これらの多くはすでにAIで代替可能な領域に入り始めています。では、そんな時代に「エンジニアが担うべき仕事」とは何なのか。言い換えるなら「生成AIに任せられない仕事」とは、どんなものなのかを考えてみました✨それ、誰のための機能ですか？システム開発においてもっとも人間らしい判断が求められるのが、“目的の設定”です例えば、学生管理システムで「成績レポートをPDFで出力したい」という要望が出たとします。AIに頼めば、レポートのPDF出力部分のコードは即座に生...
同じような環境、同じような経験年数。成長できる人と、止まる人の差はどこにある？
同じような環境、同じような経験年数。なのに、なぜか“成長が続く人”と“そこ止まりの人”がいらっしゃいます。それは、才能の差ではなく、ほとんどの場合「姿勢」と「言語化力」の差かと思っています。成長し続ける人は、自分のやっていることに「意味づけ」をしています。たとえば設計書をつくるときも「なぜこの構成なのか？」「誰のために、どんな意図で書いているか？」を考えて取り組まれている傾向です。一方で、成長が止まりがちな人は「与えられた作業」として“やること”にしか意識が向いていないように見えます。この差は、日々の会話にも表れていて、成長する人は、質問の仕方が具体的です。「この仕様だと、データ量が増え...
「要件定義や設計」経験のあるスキルシート。採用担当が見ているのは「関与度」
職務経歴書によく書かれている「要件定義を担当」。採用の現場では「どのレベルまで関与していたのか」「どんな情報を整理して、誰とすり合わせたのか」といった“中身”まで見ています🐈要件定義という言葉には幅があります。ビジネス要件のヒアリング、業務フローの整理、機能要件の抽出、非機能要件の取りまとめ、そしてそれらを関係者と合意形成していくまで――。これらのどこにどの程度関わったのかで、経験値もスキルも大きく異なりますたとえば、営業担当がまとめた要望リストを受け取り、要件定義書のテンプレートに落とし込んだだけ、というケースもあります。一方で、エンドユーザーと直接会話し、業務上の課題をヒアリングし、...
