技術だけでは、選ばれない時代へエンジニアとして成長するために必要なものは何でしょうか。 新しいプログラミング言語でしょうか。 クラウドの知識でしょうか。 AIの活用スキルでしょうか。 もちろん、それらはすべて重要です。 しかし、私がロンドンで学んだ最も大きなことは、技術ではありませんでした。 「お客様が変わっている」という現実でした。 https://aontechblog.blogspot.com/2026/06/it.html ロンドンで感じた違和感社会人8年目。 私は日本のお客様が導入する海外製パッケージシステムのプロジェクトに参加し、2週間の研修のためロンドン・ウォータールーを訪れました。 当時の私は、アプリケーション開発を中心に経験を積み、システムのプロとしてお客様へ価値を提供することが自分の役割だと考えていました。 ところが、プロジェクトが始まるとすぐに違和感を覚えます。 お客

技術だけではない。考え方を学ぶ仕事エンジニアとして成長する。 多くの人は、新しいプログラミング言語を覚えたり、新しいフレームワークを学んだりすることを想像するかもしれません。 もちろんそれも重要です。 しかし、本当に大きな成長は「システムの考え方」が変わったときに訪れます。 私自身、その経験をロンドンでの研修で味わいました。 当時、私は海外製パッケージシステムの導入プロジェクトに携わっていました。 Javaを中心としたシステム開発経験も積み、プロジェクトをコントロールする立場として複数の案件を担当していました。 システム開発については、それなりに理解しているつもりでした。 しかし、その自信は良い意味で覆されることになります。 https://aontechblog.blogspot.com/2026/06/blog-post_10.html ロンドンで出会った世界のシステム思想お客様向けシ

はじめに私たちはよく、 「システムを開発する」 という言葉を使います。 しかし最近、ロンドンでのある経験を通じて、 「システムを育てる」 という全く違う視点に出会いました。 そして、その考え方こそが、これからのエンジニア組織に必要な価値観ではないかと感じています。 https://aontechblog.blogspot.com/2026/06/blog-post_06.html 私たちはシステムを作るプロ集団だった私はこれまで約8年間、システム開発の現場で仕事をしてきました。 バッチシステム。 Webシステム。 メール連携システム。 さまざまな業界の案件にベンダーとして関わり、多くのシステムを作ってきました。 顧客から要望を受ける。 設計する。 開発する。 テストする。 リリースする。 多くのエンジニアが経験してきた流れだと思います。 特にアプリケーション開発部門では、大規模改修案件が中

エンジニアとして順調だったはずだった入社8年目。 私はお客様が導入した大規模金融システムの研修のため、ロンドンへ向かいました。 サーバ担当。 ネットワーク担当。 オペレーション担当。 そしてアプリケーション担当の私。 アプリ担当は私一人でした。 これまで数多くのシステムを開発してきました。 Javaを中心とした3層構造。 Webシステム。 データベース設計。 インターフェース設計。 顧客向けシステム開発。 アプリケーション開発には自信がありました。 「このシステム全体を理解し、将来的には開発も運用も支援できる存在になる。」 そんな想いでロンドンへ向かったのです。 しかし、そこで待っていたのは予想外の現実でした。 https://aontechblog.blogspot.com/2026/06/blog-post.html 理解できない。しかも英語が原因ではない。研修初日。 講師が説明を始め

システムは、完成した瞬間から価値が下がる？「システム開発」と聞くと、 要件定義 ↓ 設計 ↓ 開発 ↓ テスト ↓ 納品 という流れを思い浮かべる人は多いと思います。 https://aontechblog.blogspot.com/2026/05/blog-post_25.html もちろん、それは重要です。 しかし私たちは今、もう一つの視点が必要な時代に入っていると感じています。 それは、 “システムを育て続ける” という視点です。 ロンドンで見た衝撃以前、ロンドンの金融システムを日本へ導入するプロジェクトに参加しました。 私はアプリケーション観点からシステムを理解する役割として、2週間ロンドンへ行きました。 そこで見たのは、単なるITシステムではありませんでした。 金融会社自身が、 自ら育てた金融基幹システムを、 海外へ販売していたのです。 しかも、そのシステムは完成品ではありません

私たちは、単に「システムを作る会社」ではありません。 技術だけでなく、 ビジネス構造、顧客価値、組織、DXまで含めて考える。 https://aontechblog.blogspot.com/2026/05/it.html そんな“構造を理解するエンジニア”を目指しています。 今回は、ロンドンでの金融システム研修を通じて感じた、IT業界のリアルな構造についてお話します。 ロンドンで感じた、小さな違和感入社8年目。 私は金融システム導入プロジェクトの一員として、ロンドンへ向かっていました。 海外金融システム。 グローバルプロジェクト。 若手だった自分にとって、それだけで刺激的な世界でした。 そして、飛行機。 当時、私たちベンダー側メンバーはプレミアムエコノミー。 正直、それだけでも感動していました。 一方、お客様側はビジネスクラス。 ラウンジ利用。 別導線。 別空間。 その時、少し考えたので

“海外案件”は、技術力だけでは突破できないAONTechでは、単なるシステム開発ではなく、 「業務」「IT」「運用」「グローバル構造」を繋ぐ視点を大切にしています。 https://aontechblog.blogspot.com/2026/05/8.html 今回お話しするのは、入社8年目で挑んだロンドンでのシステム研修の話です。 当時の私は、既に複数のシステム開発を経験していました。 しかも単なる開発担当ではなく、マネジメント側としてプロジェクト全体を見る立場にもなっていた。 「システムはこう作るものだ」 そんな感覚も、少しずつ持ち始めていた時期でした。 だからこそ、ロンドン研修も“確認作業”の延長線上だと思っていました。 しかし、現地で見たものは、想像以上に大きな価値観の違いでした。 ロンドンで感じた、“設計思想”の違い現地で最初に驚いたのは、技術ではありません。 “資料の作り方”で

「ロンドン出張、2週間ね」 プロジェクト開始から、まだ1ヵ月。 突然そう言われた時、正直かなり驚きました。 https://aontechblog.blogspot.com/2026/05/82.html しかも目的は、“理解できない金融システム”を理解すること。 でも今振り返ると、この経験こそが、グローバルIT人材として成長する最初の大きな転機だったと思っています。 AONTechでは、こうした「未知に飛び込む経験」を大切にしています。 グローバル案件のリアルは、“キラキラ”だけではないグローバル案件というと、 ・英語が飛び交う ・海外メンバーと働く ・最先端技術を扱う そんなイメージを持つ方も多いと思います。 もちろん、それも間違いではありません。 しかし実際の現場は、もっと泥臭い。 大量の英語ドキュメント。 理解できない業務知識。 複雑なシステム構造。 文化の違い。 そして、「分から

「英語ができればグローバル案件に行ける」と思っていた。実際に必要だったのは、“異なる世界をつなぐ力”だった。 グローバル案件への憧れから始まった社会人8年目。 私はずっと「グローバルプロジェクトに入りたい」と言い続けていました。 https://aontechblog.blogspot.com/2026/05/blog-post_14.html TOEICは750点。 英語が得意と言えるほどではない。 でも、海外案件に挑戦したい気持ちは強かった。 海外の人と仕事をしたい。 日本だけでは見えない世界を見たい。 そう考えながら、少しずつ英語を勉強していました。 そして、ついにロンドン金融システム導入プロジェクトへ参画する機会がやってきます。 華やかな“海外案件”のイメージと、現実プロジェクトの中心はロンドン。 金融会社のシステム部門が持つシステムを、日本へ導入する案件でした。 日本側は導入支援

A on Techでは、“国内だけで完結しないIT”に挑戦しています。 今回紹介するのは、ロンドンを中心に使われる世界的金融システムを、日本市場へ導入した大型プロジェクト。 Blog：AONTech Blog記事URL 英語。 金融業務。 グローバルシステム。 そして、組織を超えた連携。 現場で求められたのは、単なる開発力ではありませんでした。 「逃げずに踏み込める力」 そんなリアルな現場についてお話します。 ■ “英語できる人いない？”で始まった入社8年目。 突然、ある大型案件への参加を命じられました。 理由はシンプルでした。 「英語できる人、他にいないから」 当時、私は開発部隊から唯一の参加者。 アプリチームからも一人だけ。 プロジェクトは、日本にまだ存在しない金融サービスを立ち上げるため、海外システムを丸ごと導入する案件でした。 つまり、 システム業務オペレーション管理思想これらをす

なぜ、プロジェクトは“勝った瞬間”から崩れ始めるのか。 私たちはその現場を、何度も見てきました。 https://aontechblog.blogspot.com/2026/05/blog-post_6.html ■“勝利”の裏で壊れるもの200人規模の大型プロジェクト。 受注の瞬間、社内は歓喜に包まれる。 しかし、その裏で静かに進行しているものがあります。 それは「開発の崩壊」です。 過度な価格競争によって成立した案件は、 多くの場合、開発フェーズで歪みが表面化します。 設計は後回しになり、 現場は制約の中で“なんとか成立させる”ことを求められる。 結果として、技術的負債と疲弊が積み上がっていきます。 ■なぜ、この構造はなくならないのかそれでも、このやり方はなくなりません。 理由はシンプルです。 最終的に「利益が出てしまう」からです。 運用フェーズで回収できる構造がある限り、 短期的な受

「成果を出せば何をしても許されるのか？」 現場で起きた一つの出来事を通じて、私たちはこの問いに真正面から向き合いました。A on Techは、同じ構造を繰り返さない組織を本気で作ろうとしています。 https://aontechblog.blogspot.com/2026/05/blog-post_5.html ■ あの夜、違和感は確信に変わった深夜のオフィス。静まり返った空間に、怒号だけが響く。 一見、どこにでもある“忙しい現場”の一コマかもしれません。 しかし、その裏には明確な構造がありました。 ・上には従順、下には強圧 ・成果さえ出せば評価される ・周囲は気づいていても介入しない この構造の中で、優秀な人ほど静かに消耗していきます。 そしてある日、何も言わずに去っていく。 ■ 問題は「人」ではなく「構造」多くの企業は、問題が起きると「誰が悪いのか」を探します。 しかし本質はそこではあ

かつての現場では、“声の大きさ”が正義だった。 しかし私たちは、その延長線上に未来はないと考えています。 AONTechは、エンジニアが本来の力を発揮できる組織を、本気で設計しています。 https://aontechblog.blogspot.com/2026/05/blog-post_2.html ■ なぜ、この話をするのか多くの企業がDXを掲げる中で、技術やツール以上に重要なのが「組織文化」です。 過去のIT現場では、営業主導の強いプレッシャーの中で開発が進むことも少なくありませんでした。 短期的な成果は出る一方で、現場の疲弊や再現性の低さという課題が残る。 AONTechは、この構造に明確に向き合います。 ■ エンジニア文化：圧力ではなく、構造で勝つ私たちが重視するのは、「再現性」です。 ・属人的なスキルに依存しない設計 ・データとロジックに基づく意思決定 ・チームで成果を出す仕組

プロジェクトは最後までやり切るべきか？ AONTechでは、その前提をあえて問い直しています。 私たちは「途中で抜けること＝価値がない」とは考えません。 むしろ、価値は“どこで何を残したか”にあると定義しています。 https://aontechblog.blogspot.com/2026/05/blog-post.html プロジェクトはリレーである多くのITプロジェクトは、長期間・大規模・高コストです。 数十人、時には数百人規模で進む中で、すべてを一人が見届けることは現実的ではありません。 AONTechでは、プロジェクトを「リレー」と捉えています。 設計、開発、テスト、移行、運用。 それぞれのフェーズで最適な人材が価値を発揮し、次へつなぐ。 重要なのは、「最後までいたか」ではなく 「どれだけ再現性ある仕組みを残せたか」です。 エンジニア文化：仕組みで勝つ私たちの開発思想はシンプルです

「テストケースってどれぐらいありますか？」 その問いに対して、「1万件くらいですね」と答える現場があります。 それは決して誇張ではなく、日本の金融システムを支えるリアルです。 https://aontechblog.blogspot.com/2026/04/1.html ■プロジェクトの背景：COBOLからJavaへ私たちが取り組んでいるのは、金融基幹システムの刷新です。 長年稼働してきたCOBOLシステムを、Javaへ全面的に置き換えるプロジェクト。 一見するとモダンでスマートな挑戦に見えますが、 実際の現場は、もっと泥臭く、そして構造的です。 ■テストケースは「過去の資産」金融システムの特徴の一つは、テストケースの多さです。 それは単なるチェック項目ではありません。 ・過去の障害 ・業務上の例外 ・顧客対応の蓄積 これらすべてがテストケースとして残っています。 そして重要なのは、 プロ

システム開発はロジックの世界。 でも、本当に強いチームは“人”でできている。 AONTechでは、日常の中にある「ランチ」という時間を通じて、チームをデザインしています。 https://aontechblog.blogspot.com/2026/04/blog-post_26.html ■ エンジニア文化：静かな職種の中のダイナミズムエンジニアという職種は、一見すると個人作業の集合に見えます。 実際、日中の多くはパソコンと向き合い、コードを書く時間です。 しかし、AONTechでは明確に考えています。 システム開発は「チーム戦」であると。 だからこそ、意図的に“人と話す場”を設計しています。 その象徴が「ランチ」です。 ■ ITプロジェクト：ランチが変える現場社会人7年目、後輩が増え、チームを持つ。 これは多くのエンジニアが経験する転換点です。 技術だけではチームは動かない。 その壁に直

システム開発は、きれいなオフィスでコードを書く仕事——そう思っていませんか？ 私たちは、そのイメージとは真逆の現場を経験してきました。 だからこそ、“本質的に強いエンジニア”を目指せる環境があります。 https://aontechblog.blogspot.com/2026/04/blog-post_22.html ■私たちの開発現場私たちは、単なる開発チームではありません。 システム全体を動かすために、 アプリケーションだけでなく、サーバ、データベース、ネットワークまでを一気通貫で扱います。 200人規模のプロジェクトでは、 ネットワーク設計から現場構築まで自ら手を動かすこともあります。 時にはLANケーブルが足りなくなり、 現場でケーブルを加工しながら環境を作り上げる。 それが、私たちのリアルです。 ■エンジニア文化私たちが大切にしているのは、 「現場で理解する力」です。 ・コードだ

システムは動けばいい？ 私たちは、その考えに“NO”を突きつけます。 200人規模のプロジェクトで見えたのは、技術力以上に重要な“メンタリティ”でした。 https://aontechblog.blogspot.com/2026/04/ok.html ■「200人が同じ部屋」から始まる現場かつて、200人以上が関わる大規模プロジェクトに参画しました。 しかも、物理的には非常に狭い空間。 「この人数、どうやって座る？」 そんな議論が最初に出るような現場です。 ですが、本質は座席ではありません。 人が増えるほど、システムは複雑になる。 そして、複雑さをどう扱うかが、エンジニアの価値を決めるのです。 ■役割は違えど、全員が“システム屋”プロジェクトには、プログラマーだけでなく、サーバ管理、ネットワーク担当など、多様な専門家が存在します。 私は構成管理を担当し、開発そのものではなく、環境の安定性を

エンジニア＝コードを書く人。 そう思っていませんか？ 私たちA on Techは、その常識に疑問を持っています。 システムを“作る人”だけでなく、“動かす人”にこそ価値がある。 今回は、200人規模のプロジェクトでの実体験から見えた、新しいエンジニア像についてお話しします。 https://aontechblog.blogspot.com/2026/04/200_20.html 200人プロジェクトで見えた現実社会人7年目、私は5社が関わる200人規模の大規模プロジェクトに、構成管理リーダーとして参画しました。 役割は、基準書を整備し、複雑なチームを“ルール”で動かすこと。 その中で、最も密に連携していたのがサーバ管理担当でした。 ある日、私は彼に聞きました。 「Javaって、どれくらい書きます？」 返ってきた答えは、 「書いたことないですね」 しかし彼は続けます。 「でも、スクリプトは書

エンジニア＝プログラミング、そう思っていませんか？ 私たちは、その前提を少しだけ疑っています。 200人規模の金融系プロジェクトで見えたのは、“違う入口”から価値を出すエンジニアの存在でした。 https://aontechblog.blogspot.com/2026/04/200_19.html ■巨大プロジェクトのリアル私たちが関わっていたのは、日本の金融インフラを支える企業の基幹システム刷新プロジェクト。 COBOLからJavaへの変換という、大規模かつ高難易度の取り組みでした。 200人以上が関わる中で重要だったのは、単なる開発力ではありません。 “全体を成立させる力”でした。 ■構成管理という役割私は構成管理担当として、プロジェクトに参画していました。 ソースコード、バージョン、リリースの整合性を維持する。 いわば「秩序を守る」ポジションです。 一部Javaの開発も行っていました