“要件定義経験あり”が、要件定義とは限らない

採用をさせていただいている中で「要件定義経験あります」という職務経歴書をよく見ます。面談や面接で詳しくお話を聞いていくと、実態はかなり違うことがあります。 例えば、・既存仕様の修正・項目追加・画面文言変更・API項目定義・設計書更新 これらも、現場によっては「要件定義」と表現されることがあります。もちろん、それ自体が悪いわけではありません。 ただ、本来の要件定義とは、“もっと曖昧なところ”から始まるものだと感じています。 現実の現場では、ユーザーから最初に出てくるのは、「業務を効率化したい」「入力ミスを減らしたい」「確認工数を減らしたい」といった“目的”です。 しかし、何をどう変えればど...

エンジニアの仕事で、本当に難しいのは、仕様把握

「Java出来ます」「Reactやってます」「AWS触れます」もちろん、それらは大切です。ですが、実際のシステム開発現場で、本当に難しく、本当に価値が出るのは、そこではありません。私たちが最も重要だと考えているのは、“仕様を理解する力”です。システム開発とは、「仕様書通りに作る仕事」だと思われがちです。ですが現実は違います。そもそも、“仕様書が存在しない”ことの方が圧倒的に多いです。もっと言えば、ユーザー自身が、自分たちの業務を整理できていない。これが現場のリアルです。例えば現場では、こんな会話が普通にあります。「今どういう流れで業務やってますか？」すると返ってくるのは、「えっと…まずE...

いま参画すると何ができる？内製化フェーズの技術と設計のリアル

今回は、わたしたちの開発チームが“何をやっているか”というより、“どういう考え方で開発しているか”を中心にお話ししたいと思います。おたくの開発チームって、結局どういう特徴なの？一言で言うと、「業務起点で、長期運用前提の基幹システムを、内製で再構築しているチーム」です。① 前提：扱っているシステムの特性まず、わたしたちのチームの前提です。教育領域の基幹システム（学生・講師・学納金など）年間3万人以上の個人情報を扱う複数システムに分断された既存ERPを段階的に再構築中業務依存度が高く「止められないシステム」つまり、💡 「壊れてはいけない」領域です。この前提が、すべての設計・技術判断に影響して...

API設計の中身、どこまで言えますか？

「API設計を担当しました」この表現もよく見かけます。ただ、ここも基本設計と同じで、👉 中身の解像度で伝わり方が変わる領域です今回は、API設計の実務をできるだけ具体的に分解してみます。API設計で考えていること① エンドポイント設計URL構造（/users, /orders など）リソースの切り方② リクエスト設計パラメータの定義必須/任意の整理バリデーション③ レスポンス設計データ構造（JSONなど）ステータスコードエラー時の返却内容④ 認証・認可トークンの扱いアクセス制御⑤ エラーハンドリングエラーコード設計メッセージの粒度⑥ 非機能の考慮パフォーマンススケーラビリティ冪等性まとめ...

「基本設計やりました」の解像度を分解してみました

職務経歴書でよく見る一文。「基本設計を担当しました」一見、上流工程に見えます。この言葉、間違いではないのですが、これだけだと少しもったいないです。なぜなら、👉 中身の解像度で伝わり方が大きく変わるから今回は「基本設計って実際に何をやっているのか」を実務ベースで分解してみました。そもそも基本設計とは何かシンプルに言うと、👉 “ユーザーや業務から見たシステムの仕様を決める工程”よくあるズレ画面設計をした仕様書を作成したもちろんこれも一部です。ただ、それだけだと少し情報が足りない。👉 「何を決めたのか」が見えない💦基本設計で考えていること① 画面・UI仕様どんな画面が必要か入力項目・表示内容エ...

人は、環境でここまで変わる。この環境ならエンジニアは伸びる。

前回は「伸びない理由」を解説しました。では逆に、エンジニアが伸びる環境とは何か？結論から言うと、“思考を強制される環境”です💡① レビュー文化があるなぜこの実装なのか他に選択肢はないのかここまで突っ込まれる環境。👉 レビュー＝品質チェックではない👉 レビュー＝思考のトレーニングこの環境にいると、自然と思考の解像度が上がります。② 設計に触れる機会があるAPI設計DB設計アーキテクチャ検討👉 実装だけでは、必ず頭打ちになる設計に触れることで、全体構造の理解技術選定の意図が見えるようになります✨③ 「なぜ」を問われるなぜこの技術を選んだのかなぜこの設計にしたのか👉 答えられないと通らない環境...

同じ年数、同じ現場。それでも、伸びる人と止まる人がいる。

同じ年数、同じ現場。それでも、伸びる人と止まる人がいる。その差は、才能ではありません。“思考と行動のクセ”です。今回は、採用・現場の両視点から「伸びないエンジニアの共通点」を整理します。① 「環境のせい」にしている案件が悪い技術が古い教えてもらえない気持ちはわかります。ただ、ここで止まる人は伸びません。👉環境は選べないが、解釈と行動は選べる同じ環境でも、自分で調べる人仮説を立てる人周囲を巻き込む人は確実に伸びています✨② 「作業」で終わっている言われた通りに実装手順書通りに対応これ自体は悪くない。問題は、その先がないことです。👉 “なぜこの実装なのか”を考えていないなぜこの設計なのか他に...

「この人、できる」と感じる職務経歴書。“できる人”はここが違う

今回は、採用側が思わず前のめりになる「この人、できる」と感じる職務経歴書の特徴を整理します。① 「役割」と「意思決定」が明確できる人の職務経歴書は、単なる作業報告ではありません。API設計において、認証方式をJWTに統一DB設計でインデックス設計を見直し、性能改善“何を任され、何を判断したのか”が書かれているここが見えると、単なる実装者ではなく設計・思考できる人材だと判断されます。② 技術スタックに“深さ”があるSpring BootでREST APIを設計・実装トランザクション管理や例外設計まで担当「使った」ではなく「どう使ったか」採用側は、ツール名ではなく理解度と再現性を見ています。...

スキルあるのに、もったいないです🐕

評価されない職務経歴書あるあるエンジニア採用をしていると、毎日のように職務経歴書を見ます。その中で正直に言うと「もったいない」と感じるケースがかなり多いです。スキルがないわけではない。でも、“伝わっていない”。今回は、採用側の視点で「評価されない職務経歴書あるある」を整理します。① 「要件定義やりました」の正体が不明よくあるのがこれです。「要件定義を担当」「基本設計を担当」一見、上流工程に見えますが、実態がわからない。実際に多いのは、画面仕様書の修正だけ既存資料の転記顧客との調整なし何を決めたのか／どこまで関与したのかが書かれていないと採用側は、判断できないことがあります。② 「開発経験...

実装はできる。でも、それだけで満足ですか？未来のチームに責任を持てる設計を、今。

実装よりも先に、必ず立ち止まる問い開発を始める前に、私たちは必ず問いを揃えます。この機能は、誰のどんな業務を支えるのか３年後、業務及び仕様の変化があっても対応できるか仕様策定に関わらなかったエンジニアへ、意図が伝わるか「作らない」という判断肢はないか後から取り返せない“構造の負債”を残さないためです。なぜ、構造にここまでこだわるのか私たちが向き合っているのは、教育・医療・人材といった止められない業務を支えるシステムです。一度リリースした仕組みは、「後で作り直す」ことが簡単にはできません。だから私たちは、見た目の派手さ一時的な開発効率流行りの実装パターンよりも、・ 長期運用に耐える構造・チ...

自社開発＝どこも同じ、ではありません。完成後では、もう手に入らないキャリアがある

「自社内開発」 「内製チーム」最近は、どの会社の求人にも並ぶ言葉になりました。でも実は、この二つの言葉の裏側には、 まったく違うキャリア体験 が隠れています。それが、完成された内製チーム立ち上げ期の内製チームという違いです。私たち日本教育クリエイトが、 いま“立ち上げ期”にこだわっている理由を、正直にお話しします。完成された内製チームの現実完成された内製チームは、 率直に言って、とても働きやすいです。役割は明確設計方針も技術選定も決まっているレビュー基準や開発プロセスも整っている迷うことは少なく、 求められるのは「正しく作る力」。これは、安定したキャリアを築くうえで とても価値のある環境...

【社員インタビュー】内製立ち上げ期に入社した、あるエンジニアのキャリアストーリー

「あとから入る人」ではなく「最初に決める人」へプロローグ｜転職理由は「これ以上、決まった仕様を作り続けるのか？」という違和感Aさんは、30代後半のWebエンジニア。 受託・SES・自社開発を一通り経験し、技術的な引き出しも増えてきた頃でした。ただ、どの現場でも感じていたのは、こんな違和感です。「設計はもう決まっている」 「技術選定は上で決まっている」 「自分は、正しく作る役割でしかない」コードを書くこと自体は嫌いじゃない。 でも――“この構造で本当にいいのか？”を考える余地がないそんな思いが、少しずつ積み重なっていました。出会い｜「内製立ち上げ初期」という言葉に引っかかった日本教育クリエ...

内製初期フェーズ“最初の意思決定”に関われる、非常に希少なタイミング

当社では現在、教育・人材領域を支える複数の基幹システムを 外注中心の開発体制から、段階的に内製へ切り替えるフェーズ に入っています。これまではスピード優先で外部ベンダーと協業してきましたが、事業拡大に伴う要件の複雑化長期運用を前提とした堅牢性・保守性の重要性業務理解を前提とした設計判断の必要性といった背景から、「自分たちで設計思想を持ち、構造から考える内製開発」への転換が不可欠 となりました。ただし現状は、案件そのものは十分にある一方で、要件定義・設計レベルから意思決定できる人材技術と業務の両方を理解し、全体構造を描ける人材が不足しており、本来進めたいプロジェクトを“待たせている”状態 ...

ベンダー依存から脱却し、システムを“自分たちの手”に取り戻す

当社ではこれまで、事業を支える基幹システムを100％ベンダーに依存してきました。しかも単一ベンダーではなく、複数ベンダーにまたがる構成です。その結果、システム全体の構造が把握しづらい改修や改善に時間とコストがかかる業務の変化に、システムが追いつかないという課題を抱えるようになりました。今、私たちは「内製化」に本気で向き合っています現在、「どこから内製化に着手するか」「どのシステムを、どの思想で再設計するか」を検討しているフェーズです。つまり、すでに決まった設計を作る人を探しているわけではありません。要求整理・構想段階から、一緒に考えるエンジニアを求めています。対象となるのは、教育事業の“...

コードを書かなくなっても、価値が上がり続けるエンジニア職がある

転職活動をしているエンジニアの方と話していると、よくこんな声を聞きます。「この技術、5年後も使われていますか？」「年齢を重ねてもエンジニアとして通用しますか？」「AIに仕事を奪われませんか？」とても健全な不安だと思います。その一方で、多くのエンジニアがまだ価値に気づいていない、しかし今後も確実になくならない仕事があります。それが、医療機器セキュリティ（IEC規格）におけるアセスメントコンサルです。医療機器の世界では、セキュリティ対策は「やらなければ売れない」 「対応し続けなければ市場から退場させられる」完全に事業継続の前提条件です。新製品を出すときソフトウェアを改修するとき機能追加・アッ...