私たちがつくっているのは、システムだけではありませんー開発組織は、技術力だけでは強くなれない。2026.6ver

どれだけ優秀なエンジニアが集まっていても挑戦できる環境がなければ、新しい価値は生まれない。だから私たちは「何をつくるか」と同じくらい「誰と、どんな環境でつくるか」を大切にしています🍀経験年数や役職に関係なく意見を出し合い良いアイデアであれば、誰の提案でも採用する。失敗を責めるのではなく、挑戦したことを評価し困ったときは、一人で抱え込まずチーム全員で考える。そんな文化が、私たちの開発チームには根付いています。そして、私たちが向き合うのは「コード」だけではありません。その機能は、本当にユーザーの課題を解決できるのか。その設計は、数年後も成長し続けられるのか。その技術は、事業の未来に貢献できる...

「完成された環境」ではなく、「未来をつくる環境」へ。2026.6ver

多くの会社では、すでに整った開発基盤やルールの上で仕事が始まります。でも、私たちが目指しているのは少し違います🐈今まさに内製化を本格的に進めるこのタイミングですので開発プロセスも、アーキテクチャも、技術選定も、チームの文化さえもまだこれから創り上げていくフェーズです。決められたレールを走るのではなく「この設計がいい」「この技術なら将来まで運用しやすい」「もっと開発しやすい仕組みにしよう」そんな一つひとつの意思決定が、そのまま会社の標準になっていきます。あなたが設計したシステムはあなたが書いたコードは未来のエンジニアが受け継ぐ"土台"になります。これは、完成された組織ではなかなか経験できな...

自社開発なら、どこでも同じだと思ってたり・・・2026.6ver

「自社開発」という言葉だけでは、その会社の開発環境は分かりません。プロダクトを自社で持っていても、エンジニアの役割が"実装だけ"という会社は少なくありません。仕様はすべて決まっていて技術選定も設計も意思決定も他の誰かが行う。エンジニアは、決められたものを形にすることが求められます。もちろん、それも一つの開発スタイルです。ですが、私たちが目指しているのは、少し違います。私たちは、現場の課題を理解するところから始めます。「何をつくるか」「なぜ、それが必要なのか」「どう設計すれば、5年後・10年後も使い続けられるのか」そこまで含めて、エンジニアが主体となって考える開発組織です。技術選定も、アー...

システムを、自分たちの手に取り戻す　2026.6ver

システムは、会社の競争力そのものです。それなのに、「誰も全体像を理解していない。」「改修するたびに、想定以上の時間とコストがかかる。」「障害が起きても、原因が分かるのは外部ベンダーだけ。」システムを使う人と、つくる人が離れている。知識が組織に蓄積されず、技術もノウハウも外へ流れていく。その積み重ねが、変化へのスピードを鈍らせ、挑戦する力を奪ってしまいます。だから私たちは、内製開発へ舵を切りました。目指しているのは、単に開発を内製化することではありません。自分たちが使うシステムを、自分たちで理解すること。設計の意図を知り、コードを書き、運用まで責任を持つこと。そして、仕組み一つひとつを自分...

今、船出する理由　2026.6ver

私たちは今、IT組織として大きな転換期を迎えています。これまでグループのシステム開発は、多くを外部パートナーに委ねてきました。もちろん、それによって安定したシステム運用を実現できた一方で「すぐに改善したい」「もっと使いやすくしたい」そんな現場の声を迅速に形にできない場面も少なくありませんでした。"自分たちが使うシステムは、自分たちでつくる。"その実現に向けて、本格的な内製開発へと舵を切ります。これは、既に出来上がった組織に人を補充する採用ではありません。これから何年も使われるシステムの設計思想を考え開発プロセスを整え技術選定やアーキテクチャを議論し「どんな開発組織でありたいか」まで、一緒...

なぜ、エンジニア領域に挑戦するのか　2026.6ver

教育と人材の事業を続ける中で、私たちはある課題に向き合ってきました。学ぶ環境は増えている。研修もある。資格を取得する機会もある。それでも「経験を積める場」が不足していることで、成長の機会を得られないエンジニアが少なくありません。知識だけでは、技術者にはなれない。実際に考え、つくり、失敗し、改善する経験があってこそ、本当の力が身につく。人を育てるだけではなく挑戦する機会をつくること。経験を積み技術を磨き社会で価値を発揮できるエンジニアを増やしていくこと。教育で終わらせない。人材紹介で終わらせない。「成長できる環境そのものをつくる。」この想いを、事業の背景や目指す未来とともに採用ピッチ資料で...

なぜ、ITソリューション事業部を立ち上げたのか　2026.6ver

これまで、教育と人材の力で社会課題の解決に挑んできました。医療、介護、福祉、保育。人手不足や業務負荷の高まりと向き合う現場を支え続ける中で、ある課題が見えてきました。それは「人の力だけでは解決できない壁」があるということです。どれだけ優秀な人材がいても。どれだけ現場が工夫を重ねても。業務を支える仕組みそのものが変わらなければ、生産性向上には限界があります。現場には、長年積み上げられた知恵があります。利用者のために工夫された運用。担当者の経験によって磨かれた業務フロー。現場だからこそ見える課題と改善案。それらの多くは個人の経験に留まり、組織の資産として蓄積されないままになっていました。担当...

私たちは、なぜ「教育 × 人材 × IT」に挑むのか　2026.6ver

長年にわたり教育と人材サービスを通じて社会課題と向き合ってきました。医療、介護、福祉。人手不足が深刻化する現場で、人材を育成し、活躍の場をつくる。それが私たちの役割でした。しかし、現場で働く方々と向き合う中で、ある課題が見えてきました。人材不足だけでは解決できない問題が増えているということです。業務は複雑化し、現場の負担は大きくなる。経験やノウハウは属人化し、本来利用者支援に使うべき時間が事務作業に奪われる。現場には知恵も情熱もある。それでも、仕組みが追いついていない。その現実を数多く見てきました。だからこそ考えました。「教育」と「人材」に加えて、もうひとつ社会課題を解決する力が必要では...

AI時代に、本当に価値が上がるエンジニアとは？

ここ数年で、開発現場は大きく変わりました。AIによって、コード生成テストコード作成リファクタドキュメント生成まで、自動化され始めています。では今後、エンジニアに求められるものは何か。私たちは、“仕様を理解し、整理し、構造化できる力”だと考えています。なぜならAIは、「何を作るべきか」までは決めてくれないからです。現場では、業務が複雑運用が属人化例外だらけ関係部署が多い誰も全体を理解していないそんなケースが本当に多い。その中で、誰にヒアリングするべきかどこが本当の課題かどの業務を変えるべきかどこをシステム化するべきかを整理していく。ここには、“人間の理解力”が必要と考えています。さらに、D...

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

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

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

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

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

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

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

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

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

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

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

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