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

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

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

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

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

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

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

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

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

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

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

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

「評価されない職務経歴書あるある７選」まとめてみました🐈

評価されない職務経歴書、実は“よくある型”があります採用に関わっていると「経験はあるはずなのに、判断材料が足りない」そんな職務経歴書に出会うことが少なくありません。書き方で損をしているケースがほとんどです。ここでは、採用側から見て「これは評価しづらい…」となりがちな職務経歴書あるあるを整理してみます✨あるある① 工程名だけが並んでいる要件定義基本設計詳細設計実装テスト一見、幅広く経験していそうです。でも、中身が一切見えません。採用側が知りたいのは、「その工程で、あなたは何を担っていたのか」同じ“実装”でも言われた通りに書いたのか実装方針を考えたのかで、評価は大きく変わります✨あるある② ...

「仕様どおり作ったのに怒られる」現象の正体─ 仕様遵守と価値提供は、まったく別の話

開発現場で、こんなやり取りを見たことはないでしょうか。「仕様書どおりに実装しました」「……うん、でもこれ、使いにくいよね」エンジニア側からすると、理不尽に聞こえるかもしれません。書いてある通りに作った。テストも通した。それなのに、なぜダメ出しをされるのか。このズレの正体は、とてもシンプルです。仕様を守ったかどうかと、価値を届けられたかどうかは、別の軸だからです。仕様書は「決まった内容」を書いたものですが、本来その裏には必ず「なぜこの仕様になったのか」「誰の、どんな課題を解決したいのか」という背景があります。ところが、実装が進むにつれて、目的よりも「作業」が前に出てしまう瞬間があります。・...

“コードを書く”より“問題を定義する”力がエンジニアを成長させる

エンジニアの価値は、書けるコードの量だけで決まるわけではありません。むしろ、キャリアが進めば進むほど問われるのは 「技術そのもの」よりも前段階にある能力──それが “問題を定義する力” 多くの開発現場で、こんな光景があります。仕様は一応ある。タスクも割り振られている。にもかかわらず、なぜか実装フェーズに入ると手戻りが続く。方向性がブレる。認識のズレが起きる。レビューで「これじゃない」「想定と違う」が頻発する。原因は、技術力の不足ではないと思うんです。“問題そのものを正しく定義できていない” 「目的」から考える優れたエンジニアは、目的から考えています。まず 「この機能は何のために存在するの...

“動くもの”ではなく“仕組み”を描ける人が必要なんですー「システム構造」を考えられるエンジニアを求めている理由

私たちのチームに、ただコードを書くだけではなく、“プロダクト全体の構造”を見渡し、どの部分がどうつながり、どんな未来の拡張に備えるべきかを描ける人を必要としています✨なぜ「システム構造」を考えられるエンジニアを求めているのか。現場で起きている多くの問題は、実は“構造の歪み”から生まれています。レスポンスが遅い、バグが連発する、機能追加のたびに影響範囲が広すぎる──これらは表面的な現象であり、本当の原因は“設計思想”や“アーキテクチャの選択”にあります。良いアーキテクチャは、後から効きます。悪いアーキテクチャも、後から効きます。違いは、未来に払うコストが天と地ほど変わるということ――。仕様...

部分ではなく全体を見る力──「システム思考とは？」

仕事をしていると「この作業にどんな意味があるのか」「なぜ自分の担当が詰まると全体に影響するのか」そんな疑問やモヤモヤを感じたことが、誰にでもあるはずです。その感覚こそ、実は“システムとして物事を見る”ための入口です。システム思考とはものごとを“点”ではなく“つながり”として捉える考え方です。作業単体を見るのではなく「どこから始まり、どこに流れ、何に影響し、最終的にどんな結果を生むか」という“全体の流れ”に視点を広げることを意味します。多くの現場で起きる課題は、実は“部分最適”によるものです。例えば、ある担当者が自分のタスクだけを早く終わらせても、前後の工程が詰まっていれば全体のスピードは...

「伝えたつもり」と「伝わった」は、まったく別の現象─ 認知科学でひもとく“理解のズレ”の正体

「何回説明しても伝わらないんです。」そう感じたこと、誰にでもあるはずです。でもそれは、説明する側の伝え方が悪いとも、聞く側の理解力が低いとも限りません。実はそこには、“人間の認知の仕組み”による、避けがたいギャップが存在します。認知科学では、人が何かを理解する際、頭の中で「既に持っている知識の枠組み（スキーマ）」に新しい情報をあてはめながら理解すると言われます。つまり、人は「聞いたこと」ではなく「自分の知っている範囲で理解できたこと」しか実際には頭に残らないことが多いとのことです。たとえば、あるエンジニアが「APIのレスポンスが遅い」と報告を受けたとします。しかし“遅い”という言葉ひとつ...

“動く”だけでは終わらない──エンジニアの真価が現れる

WEBシステムの開発において「ちゃんと動くものをつくる」ことは大前提です✨しかし、そこから先にあるのが、レスポンスの速さや拡張性といった“質”の部分。ここにこそ、エンジニアの知識と技術が顕著に発揮される瞬間があります💡システムが完成した当初は、利用者が少ない場合があったり、問題も見えにくい。けれど、ユーザー数が増えるにつれて、処理の遅延やメモリ負荷、DBアクセスの集中など「動くけれど遅い」「スケールできない」という問題が必ず顔を出します。ここで問われるのは、どのように設計すれば、成長するサービスの可用性を担保できるかという視点。たとえば、ユーザー体験をいっさい損なわず、負荷を最小限に抑え...

「つくりたいシステム」を言語化するのは、とても難しい

クライアントと話していると「こういうシステムをつくりたい」と言葉にしてくれる瞬間があります。しかし、その言葉の中には、漠然とした期待や、日々の課題、組織の事情など、多くの“曖昧さ”が潜んでいます。「使いやすくしたい」「もっと早く処理したい」その一言の裏には、現場の業務フロー、システムの制約、そして「こうありたい」という想いが、複雑に絡み合っているのです。この“想い”を丁寧に解きほぐし「本当に実現すべきこと」を明確にしていくのが、要件定義の仕事✨どんなに技術力があっても、言葉の意図を正しく読み解けなければ、クライアントが求める価値は形になりません。非エンジニアとしてクライアントと向き合って...

要件定義って、こんなにすごいことなんだ！

現行システムを使っているクライアントに「どんなことでお困りですか？」とヒヤリングする。採用業務をやりながら、クライアント営業も行っています💦これ、やってみると本当に難しい。クライアント自身も「なにが課題なのか」を明確に言葉にできていないことが多い。業務の流れ、システムの使われ方、部門間の関係性──すべてを理解していないと、本質的な課題にはたどり着けない。ましてや、相手が使っているのは「パッケージシステム」自社開発ではなく、既存機能に業務を合わせて使っているケースも多い。「カスタマイズすればいいのか」「運用を変えた方がいいのか」その判断すら、簡単ではない。そんな中で、クライアントの話を丁寧...