創業ベンチャーでの新規サービス開発も、大企業でのレガシー刷新も、求められることは変わらない
この記事は、丸井グループ・マルイユナイト・Mutureの有志メンバーによるアドベントカレンダーに参加しています。 https://note.com/muture/m/m5efe45c5812e
マルイユナイトとの出会い
2024年10月から、新しく設立したマルイユナイトという会社に関わっています。マルイユナイトは、下記のPRタイムズの記事の通り、丸井グループの中でもテックを担う会社です。
では、ここが具体的に何をやる（やっている）会社なのかと言うと…同じく記事内で言及されていますが、エポスカード関連のシステムに手を入れています。
第一歩として、フィンテックの顧客接点である「エポスアプリ」や会員サイト「エポスネット」に着手し、今後は段階的に小売やグループ全体のプロダクトへ範囲を拡げ、新しいビジネスについても模索していく予定です
クレジットカードの大規模決済基盤というと聞こえは良いのですが、実体はかなりのレガシーで…このレガシーをどうにか刷新したいということで、お声がけいただいた次第です。
求められている役割の共通点： アーキテクティング
私自身は、ここしばらく（創業かどうかを問わず）ベンチャーCTOとして新規サービスの開発をする機会ばかりだったので、「いまはレガシー刷新を担っている」と言うとけっこう知人には驚かれたりします。
…が、実際に書き出してみると、実は双方で求められるスキルはそんなに変わらなかったりします。
例えばベンチャーで新規サービス開発を牽引する場合、下記が期待される動きの代表例となるでしょう。
サービスのアーキテクチャを決める
リリース後もアーキテクチャを最適に保つ
アプリケーションの設計をキレイに保つ
チームの技術力を底上げする
事業領域の知識をキャッチアップする
レガシー刷新でもこれらが必要になってくるのは容易に想像が付くと思います。
新規サービス開発も、レガシー刷新も、求められることは変わりません。
レガシー「刷新」という文脈ではありますが、敬遠されがちなレガシーも範疇に入ることで、スキル・キャリアパスも広がるのではないかと思います。
では、エンジニアとしてもっと具体的に何を習得すればいいの？という問いに対しては、「ソフトウェアアーキテクト」を目指そう、と答えるようにしています。
「ソフトウェアアーキテクト」に何が求められるかをイメージするには、書籍「ソフトウェアアーキテクチャの基礎」が非常に参考になります。
ソフトウェアアーキテクトという単語だけ見ると、何か「ソフトウェアを設計する人」という解釈になってしまいますが、実際に求められることはもっと多岐に渡ります。
書籍の中では「アーキテクトへの期待」として求められる事項が8つ書かれています。
アーキテクチャ決定を下す
アーキテクチャを継続的に分析する
最新のトレンドを把握し続ける
決定の順守を徹底する
多様なものに触れ、経験している
事業ドメインの知識を持っている
対人スキルを持っている
政治を理解し、かじ取りする
前述した例と言葉は違えど、言っていることに大きく変わりはありません。
最後の「政治を理解し、かじ取りする」に関しては前述の例にはないものですが、こちらは新規サービス開発かレガシー刷新かというよりかは、組織やシステム規模の問題になってくるかと思います。
組織やシステムが大規模になるほど関係する部署も多くなり、ステークホルダーも必然的に多くなります。ここでソフトウェアアーキテクトに求められるのは、そうしたステークホルダーの調整をしつつ、システムが最適な形になるように設計し、執行までもっていくという力。こればかりはエンジニアリングスキルとは言えないですが、大きな組織・サービスで技術を牽引する立場を担うならば避けては通れないものでしょう。
実際、創業ベンチャー時代はエンジニアが自分だけ、というフェーズもあったので、自身の技術選定・アーキテクチャ決定が全てであり、ステークホルダーも何もありません。
一方、マルイユナイトではすでに大きなサービスが動いており、複数の部署が関わっている状態からのスタートだったので、いきなりアーキテクチャを考える・開発をはじめるといったことはせず、グループ内各部署の部長クラスの方々や役員へのヒアリングからはじめることになりました。
これは必ずしもネガティブなことではなく、事業ドメイン（クレジットカード関連）の知識を深めるうえでも大変役に立ったので、アーキテクチャ決定のプロセスで必要不可欠と言えるかもしれません。
いずれにせよ、アーキテクトとして技術的な部分で求められる役割に関しては、両者に違いはないと言えるでしょう。
新規サービス開発も、レガシー刷新も、求められることは変わりません。
求められている役割の違い： アーキテクティングとコーディング
アーキテクトとして求められる役割に変わりはないのですが、実際にエンジニアとしてサービスに関わるうえでは、コーディングもしなくてはなりません。
アーキテクチャだけ決定してコードは全く書かない（あるいはコードレビューをしない）なんてケースは無いと言えるでしょう。
ここが、どんなソフトウェアアーキテクトになるかの違いが出てくるところであると言えます。
こちらも「ソフトウェアアーキテクチャの基礎」に書かれていますが、アーキテクトは技術の「幅」が求められ、実際にコードを書く開発者は技術の「深さ」が求められます。
もちろん「幅」も「深さ」も極められればいいのですが、どちらも網羅することは余程のスーパーマンでない限り無理なため、基本的には「幅」と「深さ」のトレードオフを選択することになります。
その文脈で言うと、個人的には新規サービス開発では技術の深さ、レガシー刷新では技術の幅がより大事になると考えており、ここは両者の違いと言ってもいいかもしれません。逆に「ソフトウェアアーキテクトになりたい」という明確な目標がある場合は、より技術の幅が大事になるレガシー刷新のプロジェクトに積極的に関わっていくのが良いでしょう。いずれにせよ、双方に大きな違いはなく、あくまでもトレードオフの問題です。
マルイユナイトではまだまだアーキテクティングのフェーズでコーディングはほとんどできていないですが、ストラングラーパターンに則り徐々にレガシーから移行できてきているため、今後はコーディングの機会も増えていきそうです。
おまけ
大規模な組織・サービスに関わると、必然的にソフトウェアアーキテクトの役割を意識する機会が増えたので、今回はこちらの切り口で記事を書いてみました。
書き始めてみるとエンジニアのキャリアやら、システムと組織の構造やら、色々書きたくなってしまったのですが…膨大な量になってしまいそうだったので今回は触りだけにしています。
もう少し具体的な取り組みや詳細についてはデブサミ2025で話す予定ですので、そちらでもぜひ！
アーキテクトには、過去の時代から残されている前提や公理を疑うという重要な責任がある。