【開催レポート】DX成否の鍵を握る「内製開発」、その成功の秘訣を先進企業から学ぶ（2025/6/3開催）

2025年6月3日、アシスト主催のウェビナー「先進企業対談で学ぶ！内製化とアジャイルで加速するDX推進と企業価値向上」が開催されました。近年、DX推進の施策としてシステム開発の内製化に取り組む事業会社が増加しており、それに伴い開発手法としてアジャイル開発への注目が再燃しています。

このウェビナーでは、実際に内製化やアジャイル開発で大きな成果を上げている企業のキーパーソンを招いたパネルディスカッションを通じてその取り組みを紹介しました。また、アシスト社内で実践されている内製開発の実態についても詳しく解説し、内製開発の未来を占う上で不可欠な「生成AIを活用したシステム開発」の最前線についても紹介しました。

ウェビナー冒頭では、アシスト 経営企画部 ITサービス企画部 部長 石川俊朗が登壇し、アシスト社内におけるシステム開発の内製化への取り組みを紹介しました。

現在、アシストの情報システム部門（ITサービス企画部）は、約40名体制で社内システムの企画・構築・運用、および社内ヘルプデスク業務を担当しています。この中で、一部の開発・運用業務を内製化しており、具体的には営業活動や顧客対応を支えるSFA・CRMシステムであるSalesforceの開発・運用、これらを周囲のシステムと連携させるデータ連携基盤、さらには帳票システムやBIツールを活用したデータ活用基盤などです。

これらのシステム内製化に踏み切った理由について、石川は「これらのシステムは弊社のビジネスに直結しており、社内ユーザーからの要求や問い合わせに迅速に対応する必要があるため」と説明しました。さらに、「システムをリリースして終わりではなく継続的なシステム改修が必要なため、外部委託よりも内製の方がスピード感やコスト面で有利であると判断しました」と述べています。

内製化の具体的な手段としては、「Scrum（スクラム）」をベースとしたアジャイル開発手法を全面的に採用し、2週間単位のスプリントで、システム改修の影響分析から設計、開発、テスト、リリースまでを実施しています。Scrumの導入により、タスクを個人だけでなくチームで共有する意識が芽生え、2週間サイクルで業務を計画する習慣ができたことで仕事全体にリズムが生まれるなどといった様々な効果が現れています。

一方で、プロダクトオーナーへの負荷集中や、複数のScrumチーム間でのコミュニケーション不足といった課題も顕在化しており、現在、これらの課題解決を目指し、Scrumの体制・プロセスの改善に努めています。

社内実践を通じて得られた内製化のポイントについて、石川は次のように述べています。

「内製化は開発チームとユーザーとの距離が近いため、ユーザーの要求を断りにくい側面もありますが、要求を採用する基準やルールを定めて適切に取捨選択することが重要です。また、内製化したものが複雑化するとその後のコントロールが難しくなるため、ユーザーと密接にコミュニケーションを取りながら仕様をシンプルに保ち、定期的にリファクタリングを実施してシステムのコントロール性を維持し続けることも極めて重要です」。

続いて、システム開発の内製化で大きな成果を上げている企業のキーパーソンを招き、それぞれの取り組み内容、成果、課題などに関するパネルディスカッションが行われました。

まずは狩野氏と高岡氏から、SBI生命保険とセブン銀行が現在進めている内製化の取り組みについて紹介がありました。

「システムの全面クラウド化」など大胆なDX施策を推進しているSBI生命保険では、システム開発のスピードと柔軟性向上によるDXのさらなる加速を目指し、内製化に積極的に取り組んでいます。しかし、一足飛びに全てのシステム開発の内製化を目指すのではなく、まずは既存システムの保守領域の内製化から着手し、次に開発プロジェクトの上流フェーズのみ、そして最終的には全てのフェーズの内製化と、3段階に分けて内製化の範囲を広げています。

これにより多くの成果を得ましたが、同時に「ナレッジがなかなか蓄積できない」「内部リソースだけでは不十分」「システムがブラックボックス化されていて最適化されていない」といった課題にも直面しました。これらの課題を克服するため、スピード感を意識したシステム開発方針の確立、ノウハウが共有できる開発体制の構築、既存システムの見直しによる開発コスト削減といった施策に取り組んでいます。

セブン銀行では、イノベーションを通じてお客さまに新たな価値を提供することを目指し、その実現手段として内製開発に積極的に取り組んでいます。この取り組みは、「当社らしいサービスをビジネス部門と一体でつくる」「市場投入までのスピードで優位性を発揮する」「素早く反応し、長期的な競争力を確保する」という目標を掲げ推進をしています。

2016年から内製化への挑戦を開始し、その後「Myセブン銀行アプリ」の内製化成功を機に一気に内製化の範囲を拡大し、様々なサービスの開発を社内で内製するようになりました。そして2023年以降はさらにその範囲を拡大し、「コンビニ証明書受取サービス」をはじめとする様々な主要サービスを内製開発するまでに至っています。

また同社では、システム開発プロジェクトを「対象領域が予測しやすいか、もしくは不確実性が高いか」「顧客への提供価値が高いか、もしくは社内の業務高度化に主眼を置いているか」の2軸に分類し、その中でも「不確実性が高く、かつ顧客への提供価値が高い」新サービスの開発において優先的に内製化を適用しています。

以降では、SBI生命保険とセブン銀行それぞれの取り組みを踏まえ、斎藤氏のファシリテーションのもとに行われたパネルディスカッションの模様をダイジェストでお届けします。

斎藤氏：セブン銀行さんは業務システムの特性を4象限に分類して、内製化を適用する開発プロジェクトを取捨選択されているとのことでしたが、これはやはり人的リソースの制約があるからでしょうか？

高岡氏：そのとおりです。内製化は社員が直接関わってこそメリットを引き出せると思っていますので、社内リソースが限られている中でも内製化を可能にするために、対象システムに優先度を設けて取捨選択しています。ただしそれでも社内リソースだけで全ての開発作業をまかなうことは難しいので、事業と密接に関わる部分や設計のコア部分は社員が直接行いつつも、足りない部分については外部パートナーの手を借りています。

狩野氏：社員数を増やすことが必ずしも最善の解決策とは限りません。社員一人ひとりのスキルや経験は多様であり、単純に人手不足を補うためだけに人員を増やすのではなく、必要に応じて外部パートナーの力を積極的に活用することも有効だと考えます。 ただし、外部に依頼する範囲については慎重に見極める必要があります。場合によっては「自社で対応できるのはここまで」と線引きされてしまうこともあるため、そうならないよう、まずはパートナーとの信頼関係を築くことが重要です。

高岡氏：そのために弊社では、社員とパートナーの間に格差を付けずに、「一緒に開発する仲間」と感じてもらえるような環境づくりを心掛けています。また弊社の内製化プロジェクトに参画してもらうことで、パートナーのエンジニアが自身の市場価値を高めてもらえるようなインセンティブを提供することも重要だと考えています。

斎藤氏：ちなみに古田さんは、かつてウォーターフォール型の開発プロジェクトに従事していた際に感じた違和感を払拭すべく、アジャイル開発の専門家の道を志すようになったとお聞きしました。

古田氏：はい。私は過去にいくつかのウォーターフォールプロジェクトに携わっていましたが、顧客価値に繋がらない作業や手続きが非常に多いなと感じていました。顧客に価値を届けるよりも、予測可能なプロセスであることとQCDを守ることが優先されている印象でした。対してアジャイルは、最小のコストで最大の学習をしながら不確実性を低減し、顧客にとっての価値を最大化していくというマインドセットです。不確実性が高い状況においては、非常に有効なアプローチだと感じています。

高岡氏：確かに内製開発とアジャイルは高い親和性を持っていますが、一方で要件や期限が最初から厳密に決まっているシステムに関しては逆にウォーターフォールの方が適していると思いますし、ウォーターフォールで内製化することも決して不可能ではありません。

狩野氏：特に金融業界では、こうした特性を持つシステムが多く見られます。そのため、内製化を軌道に乗せるためには、アジャイル開発の導入だけでなく、CI/CDやDevOpsといったプラットフォームやインフラの整備が不可欠です。これらの環境が整っていなければ、実際の運用は困難であるため、技術基盤の構築にも十分な配慮が求められます。

古田氏：前提として、アジャイルや内製化は目的達成のひとつの手段にしかすぎません。重要なのは、本来の目的達成から逆算して、最適な手段を自分たちで選択していくことだと考えています。そうした考え方が根本にあれば、CI/CDやDevOps、クラウドといった技術的な要素をどう活用すべきかも自律的に判断できるはずです。

斎藤氏：ちなみに最近では、システム開発の現場に生成AIを導入する動きが加速していて、「近い将来、エンジニアは不要になるのでは？」といった極論も聞かれるようになってきました。

狩野氏：弊社でも、GitHub CopilotをはじめとするAIツールを導入し、一部の開発業務の自動化に取り組んでいます。現場では導入が進みつつあるものの、現時点では目に見える数値としての効果はまだ明確に表れていません。ただ、現場の感覚としては一定の生産性向上が実感されつつあります。とはいえ、こうしたツールの活用がエンジニアの役割を不要にするということではありません。今後、システムに求められる機能や取り組みがますます多様化・高度化していく中で、これまで以上に多くのエンジニアの力が必要とされると考えています。

高岡氏：そうですね。単にプログラムコードを書くだけの需要は確かに減少するかもしれませんが、AIにコードを書かせるために適切なインプットができるエンジニアや、AIが書いたコードを検証するためのエンジニアは新たに必要になります。狩野さんもおっしゃるとおり、今後システム案件が増えるにつれ、必要とされるエンジニアの数は逆に増えていくのではないでしょうか。

斎藤氏：視聴者の方から、「システムの開発効率だけでなく、保守効率も向上させる必要があると思いますが、そのために社内システム開発・運用の標準化は行っていますか？」という質問をいただきました。アジャイル開発はどちらかというとスピードや柔軟性を重視する分、標準化は犠牲にされがちだという見方もありますが、いかがでしょうか？

狩野氏：まず大前提として、ガバナンスに関わる領域については、標準化が不可欠であると考えています。ただし、開発の細かな手順まで厳格に定めてしまうと、アジャイル開発の柔軟性やスピード感が損なわれる可能性があります。そのため、どこまでを標準化し、どこからを現場の裁量に委ねるかについては、関係者全員で議論を重ねながら、最適なバランスを見つけていくことが重要です。

高岡氏：弊社でも同じく、ガバナンスやセキュリティに関わる部分については標準化は絶対に必要だと考えています。また具体的な開発手順についても、開発スピードや生産効率、品質の向上が見込めるような標準化であれば積極的に行うべきだと思います。ただしあまりに細かく作業の手順や内容を縛ってしまうと、開発者にとっては足かせにしかなりませんし、せっかくアジャイルを導入した効果が十分に発揮されなくなってしまいます。

古田氏：アジャイルな考え方が組織に浸透してくると、さまざまなレイヤーでプロセス改善が自立的に行われるようになっていきます。そのとき、過度な標準化がアジリティの向上を妨げてしまう可能性は少なくありません。大事なのは、狩野さんや高岡さんがおっしゃったとおり、ガバナンスとアジリティのバランスを組織として考えていくことなのかなと感じます。

斎藤氏：「内製化の初期段階ではどうしても学習コストが掛かると思いますが、そこはどのように乗り越えましたか？」という質問も寄せられています。

狩野氏：アジャイル開発は、単にコストをかけて教育すればすぐに習得できるというものではありません。基本的には、実際のプロジェクトを進めながら、試行錯誤を通じて少しずつ理解を深めていくアプローチが求められると考えています。

高岡氏：そういう意味では確かに学習コストは掛かるのですが、それでも内製化やアジャイルに今取り組むことで将来得られる価値の本質をきちんと理解して、キーパーソンやマネジャー層が現場をしっかりリードしていくことが重要だと思いますし、現に弊社ではそのようにして内製化を現場に定着させることができました。

ウェビナーの最後には、アシスト DX事業本部 DX技術統括部 部長 佐藤彰広が登壇し、「AIエージェント時代のシステム開発とは？」と題した講演を行いました。

生成AIはその登場初期からプログラムのソースコード生成が得意領域だと言われており、現に今では多くのLLMがソースコード生成の精度向上に注力しています。また、サードパーティーベンダーからはソースコード生成だけでなくデバッグやリファクタリングまでをAIエージェントが自動実行するツールが提供されるようになっています。

こうした状況を受けて、マイクロソフトのサティア・ナディラCEOは「SaaS is Dead」と発言し、大きな話題を呼びました。

佐藤は、「SaaSはこれまで、人間による利用を前提に人間向けのUIを実装してきました。しかしこれからAIエージェントが人に代わって多くのタスクを自律的に実行するようになると、もはや人間向けのUIは不要になり、SaaSはAIエージェントから標準API経由で呼び出される『MCPサーバー』としての役割がメインになります」と説明します。

ERPのようなシステムも、今後はAIエージェントから呼び出されるMCPサーバーとしての役割が求められるようになり、「徐々にヘッドレスアーキテクチャー化していくのではないか？」と佐藤は予想しています。

「その点、欧米型の業務システムはパッケージやSaaSの疎結合により構成されているため、こうしたアーキテクチャーにスムーズに移行できるでしょう。一方、日本型の業務システムはスクラッチ開発で機能をモノシリックに実装してきたので、そのままの形ではMCPサーバーになかなか移行できません。そのため大きなハンデがありますが、一足飛びにヘッドレスアーキテクチャーへと大胆に移行することでハンデを克服できるかもしれません」。

ただし、AIエージェントを無計画に導入すると、システム内で多数のエージェントやLLM、外部アプリケーション、ツールなどが無秩序につながることになり、システム全体のガバナンスが効きづらくなってしまいます。そこでアシストでは、データ分析・AI開発プラットフォーム製品「dataiku 」やビジネスルール管理製品「Progress Corticon 」などを用いて、「AIエージェントの効率的な開発」と「強固なガバナンスの管理」を両立できるソリューションを提供しています。

「今後はdataikuのように、エージェント開発やデータ分析などの機能と、エージェント管理やセキュリティ対策をはじめとするガバナンス機能を単一のプラットフォーム上で提供できる仕組みが求められてくるでしょう」と佐藤は締めくくりました。