メガだからしびれる ── 三井住友カード・CTOが語る、「手の内化」への挑戦

自分のスキルや経験を生かし、これからのキャリアではサービスに共感できる事業会社で働きたい——。エンジニアとして経験を積む中で、そう考える方も多いのではないでしょうか。しかし、求人票を読むだけでは、組織のカルチャーや企業・グループ全体における役割は、なかなか見えてきません。

新連載「未知↔既知 意外と知らない大企業の開発組織」では、募集ポジションの業務内容（What）だけでなく、その背景にある事業戦略や組織の役割（Why）を、現場の方々への取材を通してひも解きます。

連載第1回は、内製化を推進する 三井住友カード株式会社。同社は、カード会社からキャッシュレスカンパニーへの変革に向けて、個人向け総合金融サービス「Olive」、法人向けデジタル総合金融サービス「Trunk」、加盟店向け決済プラットフォーム「stera」などを展開しています。

同社の変革と挑戦を支えるのが、CTO直下の「デジタルイノベーションオフィス」（DIO）です。2025年9月の発足後、急拡大のフェーズにあり、2026年度中に100名規模の採用を予定。開発では、複数のAIツールを組み合わせ、AI駆動開発を前提としています。

常務執行役員 CTO デジタルイノベーションオフィス 本部長の中川 陽介さんに、自社の内製化を「手の内化」と表現する意図、SMBCグループにおけるDIOの役割、求める人物像などを伺いました。

内製化ではなく「手の内化」。そこに込めた意図

——貴社で内製化（手の内化）を進める意義について教えてください

もともとは開発・運用のほとんどを外部に委託し、要件を伝えて形にしてもらう、という体制でした。しかし、「もっとこうしたらいいんじゃないか」という素早いアイデアの反映が難しかったり、アイデアが世に出るまでのリードタイムが長期化したりすることが、経営課題として挙がっていました。

ビジネスを伸ばすには、「ソフトウェアデリバリー能力」（組織がソフトウェアを速く、安全に、安定してユーザーへ届ける力）を上げることが必須です。そのためには、自社で技術主権を持ち、お客さまの声を自分たちで反映しなければいけません。こうした背景から「手の内化」の必要性を感じ、DIOが立ち上がりました。

——中川さんは、自社の内製化について「手の内化」という言葉をよく用いている印象です。その言葉に込めた意図があれば教えてください

内製化と言うと、「すべてを自社の社員が行う」というイメージを持たれがちです。社内の人も、社外の人もそう捉えてしまう。

僕らが内製化で重視するのは、すべてを自分たちで行うことではなく、技術主権を持つことです。例えば、自分たちで技術選定を行う、アーキテクチャに責任を持つ、なぜその技術を使うのかの説明責任を果たす、といったことがあります。特に金融業界では長いスパンで物事を考えなければならない部分もあるので、「10年後にこの技術で本当にいいのか」といったことは、自分たちで決めなければいけません。

そのうえで、僕らの環境（プラットフォーム）やプロセスでプロダクト開発を進める。これは、自分たちのパフォーマンスや生産性、貢献度を計り、客観的・科学的な事実に基づいて改善していくために、とても大事なことだと思っています。

この前提で、優れた技術力を持ち、僕らの考えに共感してくださる外部の企業さんとは、単発のプロジェクトではなく、長期的に連携することが多いです。

「手の内化」の範囲は、2つの軸で決める

——「手の内化」を進める範囲とそうではない範囲は、どのような基準で決めていますか

「変化のスピード」「差別化要素になるかどうか」の2軸でプロダクトを4つに分類する4象限マトリクスを用いています。これにより、自社で取り組む優先順位が見えてきます。

まず、変化が速く、差別化要素にもなる「戦略コア」。ここは、絶対に自社の手に取り戻さなければいけない領域です 。例えば、お客さまとのタッチポイントになるアプリやそれを支えるプラットフォームなどがあります。

次に、変化は速いけれど、まだ差別化要素になるかわからない「進化フロンティア」。思いついたばかりのサービスなどがこれに当たり、できる限り自分たちでやったほうがいいです。変化が速い領域なので、外部に委託するとどうしても完全性を求めてしまい、提供までに時間がかかるので、他社に先を越されてしまうかもしれません。

あとは、変化は遅いけれど、差別化要素になり得る「差別化基盤」。ここが一番難しい。おそらく自社独自のサービスを支える部分になるので、時間をかけてでも自分たちでコントロールできるようにしたいと考えています。

最後に、変化が遅く、差別化要素ではない「安定資産」。例えば、クレジットカードの利用時に発生する認証処理や、利用金額の集計・明細作成といった機能です。これは競合他社も基本的には同じ仕組みなので、どこが開発しても大きな差別化にはなりません。だからこそ、安定した運用に力を入れるべきだと感じます。

安定資産の領域でも技術主権は手放さないのですが、長年SMBCグループのIT開発を担っている、日本総合研究所と連携しながら、自分たちはほかの3領域に注力することが重要だと考えています。

開発スピードとの両立の鍵は「ルールを覚えなくてもいい環境づくり」

——貴社では金融業界ならではの厳しいセキュリティ要件もあると思います。開発スピードとの両立で意識していることはありますか

実は「金融だから厳しい」というのは、誤解されがちなポイントです。どの業界にも法律や規制があり、個人情報の保護なども金融業界に限った話ではありません。ただ、経済活動に直接影響を与える社会的インフラを提供しているので、慎重にならざるを得ない部分はありますね。

そのうえで、一番意識しているのは「エンジニアの認知負荷を下げる」ということです。自社や業界のルールを毎回確認していると、開発が遅れたり、整理されていない制約に引っ張られてアイデアが出にくくなったりしてしまいます。意識しなくても自然と守られている、という状態をつくってあげることが大事だと考えています。

そのため、DIOの立ち上げで最初にやったのは、ルールをあらかじめ設定し、エンジニアが開発に集中できる社内開発基盤をつくらせてください、と経営層に説明しに行ったことです。当社の社内開発基盤「エンジニアリングプラットフォーム」は、例えるなら法定速度以上出ない車を運転するイメージです。

AIツールも、皆使いたいですよね。そのため、エンジニア一人ひとりが「これは使っていいだろうか」と毎回判断するのではなく、「この環境の中にあるAIは使っていい」という設計にしています。ライブラリやツールについても同じで、信頼できるものかを社内のプラットフォームエンジニアが確認し、問題ないものだけが使える状態にする。それ以外は、そもそも使えないようになっています。

——貴社では、ChatGPTやGeminiに加え、Claude Code、Devin、MCPなど、様々なAIツールを活用していると聞きました。それぞれ、どのような場面で使い分けられていますか

コードを書いたり、テストを実行したりする場面では、Claude Codeがメインです。Devinは、既存のコードをまとめて読み込ませてドキュメント化する用途に優れており、例えば今も残っているCOBOLのコードを読ませて操作する場面などで活用できると考えています。最近はGeminiも使い始めていて、ドキュメント周りの作業で活躍しています。

意識しているのは、特定のLLMに固定化しないことです。地政学的リスクも存在するため、「このLLMしか使えない」という状態にしてしまうと、開発やサービスが止まってしまいかねません。開発段階ならまだしも、サービスに組み込まれた状態でそれが起きると危険なので、選択肢を多く持つようにしています。

——AI駆動開発にも取り組んでいるそうですが、どんな開発手法を用いていますか

主に仕様駆動開発を用いています。ビジネスサイドの方々にまずユーザーストーリーマッピングを書いてもらい、そこからエンジニアも手伝いながら、テスト可能な単位の仕様をマークダウンで記述してもらっています。

それをClaude Codeに読み込ませることで、エンジニアがコードそのものを書く場面はかなり少なくなってきました。最近は、テストの自動化の仕組みも部分的に取り入れており、単体テストが完了するまでの工程を、AIで完結させる世界も見え始めています。

SMBCグループの新ビジョンにおけるDIOの役割とは

——SMBCグループの事業戦略の中で、DIOはどのような役割を期待されているのでしょうか

SMBCグループは新ビジョンとして「世界をつなぐ日本発のトラステッド・パートナー」を掲げており、中期経営計画（2026〜2028年度）では基本方針の一つとして「IT基盤の抜本的強化とAI活用のさらなる加速」を挙げています。その一環として、3カ年で1兆円規模のIT投資を行い、ITインフラの刷新や専門人材の拡充、AIを前提とする業務プロセスの整備に取り組むことを予定しています。

そうしたグループ全体の方針の中で、当社は手の内化を掲げ、率先して組織をつくっている自負があります。エンジニアを採用し、自分たちで担っていくことに投資しています。

グループの中で当社やDIOは「先遣隊」の役割を担っていると僕は考えています。これがうまくいくなら、ほかのグループ会社も同じようにやればいい。うまくいかないなら、グループ会社と連携しながら、どうこの課題をクリアしていくのかを考えることになると思います。最近は、グループ各社から「どうやっているんですか」といった相談をいただく機会も増え、「手の内化」という言葉も一定浸透してきた手応えがあります。

「つくらない」選択もある。職種を越えた意思決定のリアル

——貴社では、職種横断で意思決定を行う場面も多いと聞いています。そうした環境で、DIOのエンジニアの方々が意識されていることがあれば教えてください

DIOが立ち上がる前は、事業部が要件定義書を書いて社内のシステム本部に渡し、それを基にシステム本部が外部委託先に説明する、という流れが一般的でした。社外に委託する際は確実なプロセスですが、DIOでは「アイデアを思いついた瞬間に相談してください」と伝えています。

「こういうことができたらいいよね」というアイデアが出た時点で、事業部から声をかけてもらう。本当に事業インパクトがあるのかをリサーチし、一緒にやるべきだとなれば、規模に応じて経営会議にかけたり、本部内で決めたりします。企画の背景や仮説、解決したいことを最初から理解しているので、動き出しが早くなります。

変化のスピードが速い「戦略コア」「進化フロンティア」のアイデアは、何かしらの仮説があるはずなので、まずは仮説検証の解像度を上げることを大切にしています。そのため、プロジェクトの初期段階からビジネスオーナーやリサーチャー、デザイナーと検討を共にすることが常態になりつつあります。

その結果、既存のサービスで対応したり、システムではなくオペレーションやプロセスで解決したりできると気づき、「つくらない」という結論に至るものもあります。

——仮説検証のプロセスを重視し、結果として開発以外の解決策に行き着くことも一定あるのですね

はい。「つくること」が目的になると、解決すべき問いや、実現したい戦略がぼやけてしまいます。「そこをしっかり考えましょう」とすると、ビジネスサイドの方々はしんどさを感じる場面もあるかもしれません。

これまでは、要件定義書さえ書いて渡せば、あとは仕上がりを待つだけでした。それが「達成したいことはどんなことですか？」「そのためには本当にそのシステムが必要なんですか？」「この仕様でその問いは解けますか？」などと聞かれるわけですから、負担に感じるのも当然です。

それでも、僕たちと組むと本当に必要なものだけに集中できますし、満たすべきスコープが小さくなり、かつ契約の壁がない分、開発のリードタイムも短縮される。特定のチームが担当するので、長く一緒にやる中で知識も蓄積されていきます。そうした効果を期待していただけるなら、しんどくても一緒にやりましょう、という思いで向き合っています。

求人票では書き切れない、働き方や求める人物像とは

——中川さんが採用活動に携わる中で、求人票だけでは伝えきれていないと感じる部分があれば教えてください

正直に申し上げますと、面接でお会いする方の多くが最初に気にされることと、DIOの今の姿、フィロソフィー的な部分で大事にしていることにずれがあることは少なくありません。これは僕らの説明不足が原因であることに間違いないので、申し訳なく思います。

多くの方は当然、募集職種の確固たる役割や、任されるタスク、現在進行中のプロジェクトの内容などを気にされることが多いのですが、DIOではその線引きをすることは大きな要素ではありません。

僕が見ているのは、どうすればこの会社のビジネスがうまくいって、エンジニアが楽しく働けるか、それだけなんです。そのうえで、新しく入社される方が持っているスキルや経験を生かしていただきたいと考えています。

もちろん特定の業務をお願いする場面もありますし、専門性は大いに発揮していただきたいと思っています。しかしながら、まだ顕在化していない課題も多い中で、DIOのメンバーには「何をしていくかは自分たちで決めていく」というマインドセットを持ってほしいと考えています。

だから面接の冒頭ではいつも、「ジョブディスクリプションには特定の職種が書いてあるけれど、実はあまり気にしていません」と伝えるようにしています。

——「“落ちているボール”を拾い、自ら動ける人」という、貴社のエンジニアに求める人物像にも通じますね

そうですね。「ここまでが自分の仕事」と線引きしてしまうと、今のフェーズではうまくいかないと感じます。また、「これはこうすべきだ」という“べき論”が強すぎる人も、慣れるまでに苦労してしまうかもしれません。単なる批評家にならずに越境する姿勢を持ちつつ、柔軟なマインドセットでいてほしいと常に感じていますね。僕らは不完全であるからこそ、自ら考え、自ら動く、というところもあります。

「メガ」でしびれる。DIOのエンジニアだからできること

——中川さんから見て、DIOのエンジニアとして得られる経験にはどういったものがありますか

「エンジニア組織を拡大していく」「技術主権を取り戻していく」という経験は、ほかの環境でも得られるかもしれません。それでも、僕がこの会社でやろうと思った理由の一つは、「メガ」だからです。大手金融グループの中でこれをやるのは、"なかなかしびれる挑戦"です。

今まで誰もやってこなかったことに対して仲間を集める、上層部に理解してもらえるよう、「なぜこれをやる必要があるのか」を説明しに行く——。本当に文明開化をしていくような醍醐味があります。

テックカンパニーでは当たり前とされている、「なぜ社内開発基盤が必要なのか」「どうしてテクノロジービジョンを決めたほうがいいのか」を改めて言語化しようとすると、意外と悩みます。だからこそ、チームで膝を突き合わせて議論できることが、僕は面白いなと思うんです。

いつまでも“不満”を言っている部署でありたい

——貴社に限らず、組織を急拡大する中ではカルチャーギャップが生まれることもあると思います。そうした難しさを感じる場面はありますか

正直ありますね。2025年9月にDIOを立ち上げ、約一年が経ちましたが、この差が大きくて。初期メンバーの中では「自分たちがつくってきた」という自負があり、最近入ってきたメンバーとの間には、ギャップが生まれることもあります。

だからこそ、オンボーディングを仕組み化したり、初期メンバーだけで意思決定が偏らないようにしたりすることを意識しています。人数が増えてきたので、プロダクト単位のテックリードに権限をきちんと委譲する、という取り組みも進めているところです。

ほかにも、管理職以外のエンジニアが集まって思っていることを話し合う「エンジニアデイ」を開いたり、僕自身に意見を伝える場をつくったりと、地道な取り組みを積み重ねています。誰の意見かはほぼ関係なく、良いものは良い、悪いものは悪い、という価値観も大切にしています。

——開発スピードもチーム内のコミュニケーションも、精神論ではなく仕組みをつくって解決しようとしているのが伝わってきます。最後に、応募を検討しているエンジニアに向けて、メッセージをお願いします

楽な仕事ではありませんが、楽しく仕事ができる環境を追求しているので、「エンジニアがハッピーでいられる組織って何だろう？」ということを一緒に考えながら走っていただける方であれば大歓迎です。

一番怖いのは、誰も不満を言わなくなることです。だから僕は「愚痴はどうにもできないけど、不満は言ってください」と伝えています。不満はある意味宝物で、伸びしろがある証拠です。解決すれば前進しますし、放置すると組織の崩壊にまでつながりかねません。

DIOは全社単位で見ると少ない人数で社内の変革を進めている立場です。また、バックグラウンドが多岐にわたるキャリア採用が多い組織でもあります。だからこそ、自分たちの風通しが悪くなってしまってはいけない。そういう意味では、いつまでも“不満”を言っている部署でありたいですね。