登壇レポート #２ | 技術の「幅」から広げるエンジニアリング — 創業ベンチャーCTOから大企業レガシー刷新へ
2025/2/14(金)、Developers Summit 2025に弊社エンジニアリング部シニアアーキテクトの巣籠さんが登壇しました。
── 技術の「幅」と「深さ」、あなたはどちらを追求しますか？
エンジニアとしてのキャリアの選択肢を考える際、避けて通ることはできないこの問いに対し、今回の登壇では巣籠さんのこれまでの経験を通じて、技術の「幅」を広げることの意味や重要性についてお伝えしました。
こちらの記事では、当日巣籠さんがお話しした内容をお届けいたします。
よろしければ登壇前に巣籠さんが書かれた以下noteもご覧ください。
▼ 当日の資料はこちら
はじめに
皆さん、こんにちは。本日はお越しくださり、ありがとうございます。どうぞよろしくお願いいたします。今日は「技術の幅から広げるエンジニアリング」というテーマでお話しします。技術の幅に着目し、技術的に深い部分についてはあまりお話ししない予定です。
まず、皆さんに質問です。今日は多くのエンジニアの方がいらっしゃると思いますが、エンジニアとして生きていく上で、技術の幅と深さ、どちらが大事だと思いますか？
結論から言うと、どちらも大事です。エンジニアとして目指すべきは、技術の領域やレベルを広げていくこと、つまり幅と深さの掛け算によって面積を増やしていくことです。
一般的に、サービスを立ち上げる際には技術の幅が重要であり、一方でサービスの運用や改善には技術の深さが求められます。フェーズによって求められるものが異なるため、今日はその中でも幅に着目してお話しできればと思います。
改めて、技術の幅と一口に言っても、実際には2種類の技術があると考えています。それは、フルスタックエンジニアリングとソフトウェアアーキテクティングです。今日はこの2つの単語をキーワードにお話ししていきます。
自己紹介
改めまして、巣籠悠輔（すごもり ゆうすけ）と申します。苗字が非常に珍しく、悪いことをしたらすぐにばれてしまいますので、悪いことはできません。（笑）SNS上ではこのアイコンでよく活動していますので、もし見かけたらリアクションなどいただけると嬉しいです。
今日はアプリケーション開発の人間としてこの場におりますが、実は約15年にわたりディープラーニング関連の仕事をしてきました。書籍もいくつか出しておりますので、ディープラーニングの文脈で私のことを知っていただいている方もいらっしゃるかもしれません。
簡単に私の経歴をお話しさせていただきます。
私は学生時代から、さまざまなサービスを作ったり手伝ったりしてきました。会社化される前のGunosy、Readyfor、マネーフォワードあたりの開発をしていたり、一人でバズを狙って色々とサイトを作っていたりしました。
一番バズったのはCSS SANS（CSSでフォントを作ったもの）で、国内外で変態呼ばわりされたのがちょっと嬉しかった思い出があります。
それ以外ですと、創業ベンチャーのCTOとして、オンライン診療アプリや医療AIの開発をしていました。現在では会社はエグジットしていますが、当時は何もかも自分でやらなければいけない状態で、メンバーが増えるまではなかなか大変な状況でした。
そして現在ではマルイユナイトの設立時からコミットしています。この会社は昨年の10月に設立され、まだ4か月ほどになりますが、現在私自身は丸井グループの大規模システムのあたりを中心に今見ています。
マルイユナイトについては、後ほど改めてお話しいたします。
ここでそれぞれのキャリアの中で求められてきたスキルを整理してみますと、共通する部分もありながら、より強く求められたのは、サービスや事業を作るフェーズではフルスタックエンジニアリングのスキル、今やっている大規模なシステムに関わる立場としてはアーキテクティングのスキルが求められてきたように感じています。
サービスの立ち上げと「フルスタック」
サービスを作るフェーズでは、フルスタックエンジニアリングのスキルが特に求められます。エンジニアメンバーが少ないため、幅広いスキルが必要です。時には1人しかエンジニアがいない状況もあり、フロントエンド、バックエンド、インフラも全て自分で行う必要があります。
そのため必然的に全領域のスキルが必要になってくるわけですが、全てを完璧にこなすことは難しいため、サービス立ち上げ時には、幅広いスキルを持ちつつ、深さについては割り切って考えることが重要です。
自分よりも優れたエンジニアは多く存在するので、まずは幅広くさまざまなことができるようになっておき、サービスを立ち上げてから、優れたエンジニアに来てもらい、改良していくのが一般的には良いのかなと思います。
一方、最近の10年、特にここ1年で状況が変わってきたと感じています。現在はCursorやRoo Code（旧 Roo-Cline）などを活用して開発時に生成AIのバフをかけることができ、文字通り幅を利かせやすい環境になってきています。これらのツールを使うことで、自分が書かなければならないコードの量を大幅に圧縮することができるだけでなく、自分のスキルレベルを上乗せしてもらえるため、最初からそれなりのクオリティのプロダクトを作りやすい環境にあります。
実際、CursorやRoo Codeが出てきたことにより、一人で起業するようなプレイヤーもかなり増えており、今後もこのトレンドは続いていくと考えます。
生成AIの活用において、APIのコストが高いという意見も見受けられますが、足元ではDeepSeek-V3等の登場により価格破壊が起きています。
そのため、生成AIを活用したエンジニアリングはより手軽にできるようになっていきますし、活用が前提の環境になっていくと思いますので、試したことがない方はぜひ試していただきたいと思います。
レガシーシステムとアーキテクティング
次にアーキテクティングについて具体的にお話しします。
ます前提として、なぜ今私が大企業にいるのかという疑問もあるかと思いますが、大規模なシステムの開発に関わりたいという思いから参画しています。
大規模システムに関わろうと思っても、ゼロイチから自分でスタートする場合では成功してもそれなりに時間がかかるため、効率的に大規模なシステムに関わることができるルートとして、マルイユナイトに参画することを決めました。
マルイユナイトは丸井グループが設立したテックカンパニーで、2024年10月1日に設立されたばかりです。マルイというと、皆さんはどのようなイメージを持つでしょうか。多くの方が店舗のイメージを持つかもしれませんが、実は収益の大半はクレジットカードから来ています。
現在カード会員数750万人、アプリの会員も400万人の規模感になっており、個人的には小売とフィンテックという組み合わせがとてもユニークで楽しく感じています。
丸井のクレジットカードは1960年に日本で初めて発行され、2006年から現在のシステムが運用されています。そのため、長い歴史を持つシステムであり、ご想像通り技術的な負債が多く存在、いわゆるレガシーシステムとなっています。
丸井グループとしては小売とフィンテックというユニークなアセットの組み合わせで今後も色々とプロダクトを作っていこうという意気込みはあるものの、このレガシーシステムをどうにかしないことには良いサービスをすぐ作ることはできないため、技術負債を解消しに行っているという現在地です。
（一応中身はJavaで、COBOLじゃなくて安心しました（笑））
レガシーシステムは敬遠されがちですが、実際には新しく作り直す際に求められることはさほど変わらない側面があります。フルスタックエンジニアリングのスキルが必要であり、レガシーシステムの文脈ではそれに加えて既存のシステムを理解し、変更する力も求められます。
レガシーシステムの改善手法の一つに、ストラングラーパターンがあります。これは、現在のレガシーシステムから移行できる部分を徐々に新システムに移行していく戦略です。システム全体のアーキテクチャを考える必要があり、これをアーキテクティングと呼びます。
少し古い2006年頃のJ2EEベースの設計思想で書かれたアプリケーションの例になりますが、クライアント層、プレセンテーション層、ビジネスロジック層に分かれています。設計思想自体はある程度しっかりしているのですが、課題としては使用されているフレームワークの古さや多すぎるコードに存在しています。
これをモダナイズしていく方針として、一般的には先ほどお伝えしたストラングラーパターンではなく、ビッグバンというゼロから作り替える手法も存在しますが、今回のケースではシステムが巨大すぎて一気に移行することが難しかったため、徐々に移行させていくストラングラーパターンを選択しました。
現行のシステムはリポジトリで複数に分かれてはいるものの、プレゼンテーション層とビジネスロジック層が1つのアプリケーションサーバーで動かす巨大なモノリシック前提になっているため、新しく何かをやろうとしてもシステム全体を見なければいけないと言うことで非常に時間がかかります。
DevOpsのサイクルが回らないため、作り変えるにあたってはマイクロサービス化もしくはモジュラーモノリス化が必須となります。
いずれにしても、これはモダナイズにおける方針と考えます。
現在はその方針に基づきコードを読み進めていっている最中ですが、レイヤーの依存関係が双方向になっているため、一部を改修するとシステム全体を見直さなくてはならない状態になっています。
ここを分離のしやすさや影響度の大きさを鑑みながら、どのドメイン、どのビジネスロジックから着手をするかを判断してくことになります。
加えてユニークなのは、業界独自の制約としてクレジットカードの会員情報を扱う場合、そのシステムはPCI DSSというセキュリティ基準に準拠しなければならず、その要件を満たしていく必要があります。
その際、このモノリシックのシステムではカードの会員情報が含まれていない、PCI DSSに準拠する必要がない部分も、同じサーバーでホストされているため、本来は準拠する必要がないのにPCI DSS要件に引きずられ時間がかかっていることがわかりました。
そのため、まずはその部分を切り出すことが事業効率への貢献度も高いため第一段階として取り組み、その後にPCI DSSの範囲へ着手を進めていこうと考えています。
このようにレガシー刷新に関しては、実にさまざまな観点からアプローチを考える必要があります。
まさしく、技術の幅によってアーキテクティングが活きてくるわけです。
ただし、その技術力だけが必要というわけではないことにも注意が必要です。着手の優先順位は組織構造などにも大きく影響しますし、PCI DSSのような業界、業種の要件のように、技術以外の視点もアーキテクトには求められます。
生成AIの活用についても、今後はレガシー刷新においても活用していきたいと考えていますが、現時点では大規模システムでコードの行数が多すぎてコンテキスト長が溢れてしまい、なかなかうまくできないという実態があります。
ただ、こちらも技術の幅を活かして生成AIフレンドリーな単位でリアーキテクチャ（コンテキスト長が溢れない単位でシステム分割）していき、その範囲で生成AIバフをかけていくことで開発効率も上げられると考えており、取り組みを進めています。
アーキテクチャは動的なものです。
新しい技術も次々と出てきますし、ビジネスも変化していくため、最適なアーキテクチャも変化していきます。新しい概念が次々に出てくるため、常にキャッチアップしていく姿勢も求められます。
さいごに
技術の幅を広げることで、ゼロイチでも大規模システムでも活躍の場が広がります。キーワードとしては、フルスタックとアーキテクティングです。これを意識することで、何をすべきかが見えやすくなると思います。技術の幅を持つことが強みとなりますので、深さも大事ですが、幅に着目することをお勧めします。
以上で、私の話を終わります。ありがとうございました。
最後までお読みいただきありがとうございました！
株式会社マルイユナイトでは、一緒に働くエンジニアの積極的な採用活動を行っています。
ご興味のある方は、以下をご確認ください。
●募集要項・カジュアル面談はこちらから
●コーポレートサイト
●SNS
Ｘ：@marui_unite
note：https://note.com/marui_unite/