内製開発組織の立ち上げと推進のポイント：三菱商事グループのデジタルカンパニーの歩み【11/26開催・内製化をスケールさせるAI時代のアジャイル開発イベントレポート】
内製開発組織の立ち上げと推進のポイント：三菱商事グループのデジタルカンパニーの歩み【11/26開催・内製化をスケールさせるAI時代のアジャイル開発イベントレポート】
目次
目次を読み込み中...
2025年11月26日、ファインディ株式会社が主催するイベント「内製化をスケールさせるAI時代のアジャイル開発」がハイブリッドで開催されました。
内製開発に取り組むエムシーディースリー株式会社では、内製化の推進および開発効率の可視化を目的としてファインディ株式会社が開発・運営している「Findy Team+」を導入。
客観的なデータに基づく現状分析を行い、チーム全体の効率性、生産性向上の状況、チーム単位でのパフォーマンスなどを一目で把握し、内製化をさらに推進していくために活用をしています。
本記事では、三菱商事100%子会社のデジタルカンパニー・エムシーディースリー株式会社の佐藤 勝路氏によるセッション「内製開発組織の立ち上げと推進のポイント」の模様をお届けします。
◾️登壇者プロフィール
エムシーディースリー株式会社
デジタルプロダクトカンパニー 建設クラウド事業本部/開発副統括
佐藤 勝路
【略歴】
卒業研究の作業効率を高めるために独学でプログラミングを学び、その楽しさに魅了されたことをきっかけに独立系SIerへ入社。その後、合同会社を設立して独立。続いて、大手グルメサイト運営会社に転職し、品質管理からメインサービスの担当まで幅広く歴任。最大250名規模の組織マネジメントを担う一方で、テクニカルプロダクトマネージャーとしてプロダクトの技術面を統括。その後、ＭＣデータプラス（2025年7月1日付で会社統合により社名をエムシーディースリーへと変更）へ転職し、開発組織のマネジメントおよびメインサービスの開発マネージャーを務め、現職に至る。
改めまして、皆さんこんにちは。エムシーディースリーの佐藤勝路と申します。
エムシーディースリーの建設業界向けのVertical SaaSのプロダクトにおいて開発マネージャーをしている者です。
1.会社・事業について：280万人以上のデータ基盤をもつ大規模プロダクトの開発
まず前提となる会社と事業の文脈を簡単にご紹介します。エムシーディースリーは三菱商事100%子会社のデジタルカンパニーで、2015年4月設立ですが、ちょうど2025年7月に兄弟会社と合併し社名が変更になりました。
デジタルプロダクトカンパニー（旧・ＭＣデータプラス）による建設リテール向けVertical SaaSの展開、事業共創カンパニー（旧・Industry One）による新規事業の共創、AI事業カンパニー（旧・MCデジタル）によるAIデータ活用支援まで含めたデジタル・AI領域全般での事業推進を行っております。
私が所属するデジタルプロダクトカンパニーでは、建設クラウド事業として施工管理や安全書類の作成など建設現場の業務を支えるVertical SaaSの提供と、リテールクラウド事業として購買データを活用したマーケティングプラットフォームの提供を行っています。
今回私の方は建設クラウド事業をメインに話すのですが、建設作業員270万人以上のデータを持つ大規模なサービスを運営しております。
建設クラウド事業のサービスについては、SaaSモデルかつ大規模プロダクトであり、継続的な機能追加や運用改善がそのまま事業成長につながるような形となっております。
そのため、プロダクトを支える内製開発組織のあり方自体が事業インパクトに直結しやすいというのが今日お話ししたい背景となります。
2.内製化の歩み： 外部パートナー100名超の体制からなぜ内製化が必要だったのか？
ここから本題となります。私が参画した2022年7月当時のお話なのですが、開発組織は正社員が1名、出向社員が2名、そこに外部パートナーの業務委託さんが100名以上という体制になっていました。
このような状態でしたので、業務やシステムの多くが外部のパートナーの力量に大きく依存しているような形になっており、自社組織のメンバーでは意思決定できるだけの解像度がまだない状態でした。
一方で、市場環境の変化や新規サービスの立ち上げが増えている背景で、もっと早く柔軟に開発したいというニーズ自体は高まっていました。これが内製化を本格的に進めようとしたきっかけとなります。
内製化の目的について、大きく5つに整理しています。
1. 顧客価値を最速で届けるため
2. 開発QCDと生産性を高めるため
3. 技術基盤とガバナンスを強化するため
4. 事業戦略と一体で開発するため
5. 知見を組織に蓄積し続けるため
特にマネージャー目線で重要だと感じているのは、事業戦略と開発の意思決定、こちらを社内で一貫してコントロールできる状態を作ることが大事だと思っております。
これを実現するための手段として、内製化を位置付けております。
3. 組織を強くする4つのステップ：意思決定権を確保するための内製化の進め方
ここからは内製化を進める上で意識した4つのポイントについて紹介させていただきます。
これから話すこと一つ一つはシンプルなのですが、順番だったり期待値の置き方というところがかなり重要だったと思っております。
1. 上流工程から取り組む
当時、業務やシステム仕様の全体像が社内からはまだ見えにくい状態でしたので、いきなり開発チームを作るのではなく、まず新規機能の要件定義や開発プロセスの改善のところから入ることにしました。
具体的には、要件定義の場に自社メンバーとして私も入っていきました。
私が初めに直接的に関わった機能追加の案件は、工事現場の中に掲示が必要な施工体系図と呼ばれる帳票をデジタルサイネージでも投映可能にするための対応でした。
デジタルサイネージを提供している各社の端末情報などをプロダクトマネージャーと一緒に収集し、投影に最適なファイル形式が何なのか、企業の方の利用負担が最小限になるようなUXの検討など、要求レベルから携わった上で、システム設計まで関与させていただいておりました。
採用についても、まずはマネージャーやテックリードクラスを優先しました。
ただ当時の反省点としては、人が少ないこともあり、何でもできる人を欲しいというような形になった結果、ロールの切り分けや、入社される方の支援構造というところはもっと早く整えていければよかったなと反省しております。
ポイントとしては、手を動かす人より先に、意思決定のための検討やプロセスを設計できる人を先に入れることを意識しておりました。
2. インフラ領域から取り組む
ビジネスドメイン側に強く依存するアプリケーションのレイヤーよりも、まずビジネスドメインとの関連が比較的浅いインフラ領域の部分を社員が担当するようにしました。
各プロダクトに専任のインフラ担当がいないシステムも多々ございましたので、インフラ担当不在のプロダクトから、内製の社員メンバーが関わってインフラを横串で見ていくことで、システム構成の標準化や、プロダクト横断でセキュリティガードレールを整備するといったことを進めてまいりました。
まだ全てのプロダクトのインフラ領域を社員チームで持てているわけではないのですが、自社プロダクトのインフラ領域の標準化が一定進み、全体最適につながったと思っています。
3. 優先プロダクトを決める
我々のプロダクトは、大小を合わせると2桁単位のプロダクトを持っております。全てのプロダクトを一気に内製化するということは難しいので、採用やオンボーディングに関しても薄くやってしまうと中途半端になってしまいます。
システム観点での重要度（例えば複雑さや依存関係、リスクの大きさ）と、ビジネス観点での重要度（売上や戦略的な位置付け）の2つの軸でプロダクトを整理して優先順位を決めてまいりました。
私たちのなかでは、プロダクトマーケットフィットがまだできていなくて、かつ新規開発が多いと予想していた「ワークサイト」というプロダクトを優先対象にしまして、ここに内製エンジニアと採用リソースを集中的に投下するという方式を取っておりました。
どのプロダクトで勝ち筋を作るかというのを経営や開発の組織運営の中で合意しておくと、採用のメッセージや評価・投資判断がぶれにくくなると思います。
4. 外部の力も借りる
内製化というと、全てを社員化するみたいなイメージもあるのかもしれないですが、全て社員化するのではなく、兄弟会社のメンバーやパートナー企業からの出向や協力も積極的に行いました。
2025年に合併したと申し上げたのですが、その合併前から、旧MCデジタルや旧IndustryOneのメンバーにも、我々の建設クラウド事業領域に関わっていただいていました。
合わせて、開発パートナーも含めて、チームアップイベントや改善活動を一緒に行うことで、社員と外部のパートナーさんという分け方ではなく、一つの開発チームとして動いてもらうことも意識付けを行いました。
結果として、内製比率を高める以外の方法でも、当初の内製化の目的である事業戦略と開発の意思決定を社内で一貫してコントロールできる状態というところに近づくことができました。
4. 内製化の具体事例のご紹介：グリーンサイトとワークサイトでの成果と影響
ここから、グリーンサイトとワークサイトでの具体的な活動事例をお伝えできればと思います。プロセスや組織の話をできるだけ現場の変化に落とした形でお伝えします。
事例①グリーンサイトでの要求定義フェーズへの参画
とあるプロジェクトにおいて、要求通りに手段を採用していくと、開発規模がまず非常に大きくなっていくこと、そして今後の保守性に関しても悪影響が出そうだということが分かりました。
具体的なイメージとしては、その機能に対して仕様変更が入るたびに、複数の画面、複数のテーブルに必ず影響が起きるということが、作る前から見えているような状態です。
そのため、社内メンバーが、このプロジェクトに入り、「そもそもビジネス上の目的はなんなのか」「そのために最適な解決手段となるUXはどのようなものなのか」というところから検討を進めました。
従来ですとプロダクトマネージャーの要求に対して開発チームがそのままシステム要件に落とし込んでいましたが、要求をただ実装するのではなく、目的から一緒に設計し実現することに社内メンバーが寄与できました。
ちなみに今回の検討時には、60万行以上も既存コードがある大規模なものに対し、現行仕様や設計の調査を行ったり、実際の改善案を策定する際観点不足がないかといったレビューに対して壁打ちを行ったりという形で、AIエージェントの活用も行っております。
事例②グリーンサイトでの部分的なスクラムチーム導入
グリーンサイトでは、UIの改修など小さめの案件に対して、部分的にスクラムチームを導入しております。
目的としては、①従来型のウォーターフォールだと長くなりがちだったリードタイムを短くすることと、②システム以外のプロセスも含めて、どこにボトルネックがあるのかを把握すること、の2点でした。
こちらは導入から1ヶ月ちょっとではありますが、プロダクトマネージャーの受け入れが完了するまでのリードタイムについては改善が見られました。
特にコミュニケーション面での待ち時間が、大きく減ったという示唆が得られております。
さらに、プロダクトオーナーの方も1人で裁量しきれないような事象もあるのですが、裁量の範囲をちゃんと定義することを今後やっていくとプロジェクトのアジリティも高められるのではないかといった手応えも見えてきております。
事例③ワークサイトでの組織体制の変化
2024年8月頃の体制からご説明させていただきます。この頃は、社内メンバーが1チームに配属されていて、それ以外の複数の開発チームは業務委託のリーダーが開発を進めているという状態になっていました。
業務委託のチームの方が、参画時期自体も長く、ドメインへの理解やシステムの理解といったところも彼らの方に優位性がありましたので、重要な機能開発に関しては業務委託メンバーを中心に進む状態になっていました。
社内メンバーに関しても、改善意欲はあったのですが、活動がどうしても自チームの範囲に閉じてしまい、全体に効く改善提案がしづらいという状態になっておりました。
直近は、システム仕様の理解や業務理解が進んできたことによって、社員をリーダーポジションにアサインすることができるようになってまいりました。
見えてきた定性的な効果としては、社員主導で、開発生産性や品質、開発者体験を改善する活動が行えるようになったり、それぞれの生産性や品質の把握ができるようになってきたと思います。
また、特定のお客様向けの機能改善の部分に関しては、お客様とのミーティングにも社員が入っていきました。
それにより、ビジネス上の要求事項に対してのキャッチアップも進んだと思っていますし、こうした活動を通じて、社員の当事者意識が高まったのではないかと思っております。
経営や開発マネージャーの目線で申し上げると、どこを外部に任せて、どこを自社で握っていくかといった線引きを、現場レベルでちゃんと設計できるようになったと思っております。
定量的な改善指標の導入
定量的な改善指標の導入も行っております。ユーザーへの価値提供のスピードを上げて、かつ持続させるために、Findy Team+を使ってレビュー分析とサイクルタイム分析を行っています。
定量化したレビュー関連のリードタイムに着目し、レビューアーを増やしたり、一つのプルリクエストの粒度を小さくするといった改善施策を進めた結果、実際にリードタイムの改善が見えてまいりました。
数字で良くなったというところはあるのですが、一方で大事にしたのは、こういう生産性指標に関しては、あくまでチームの改善のための情報として使うことと、個人の評価だったりチーム同士の単純な比較には使わないことということを意識しておりました。
いわゆるグッドハートの法則を意識しておりまして、数字に振り回されず、でもちゃんと数字を見ましょうというような文化作りを進めております。
5. 今後の展望：技術面でも魅力のあるサービス・プロダクトへ
ここから最後に、今後の展望についても一言触れて締めていきたいと思います。これからのテーマとして意識しているところは、技術面でも魅力のあるプロダクトにしていこうと思っております。
プロダクト自体の価値が重要なのはもちろんですが、同時にその利用している技術要素がモダナイズされているか、横断領域でSaaSが適切に導入できているかなど、開発者にとって技術面でも学びの多い魅力的な環境にしていきたいと考えております。
その際に心がけているキーワードとして、「挑戦領域で引きつける」、「見える化で強くする」、「共通基盤を磨き上げる」の3つを掲げております。
こちらの3つを回しながら、事業としても開発組織としても持続的に強くなっていくことを目指しています。あくまで一例ではあるのですが、AIネイティブで開発して、かつ仕様駆動型の開発を導入するといったところも現在取り組んでいます。
最後に、少しだけお知らせさせてください。エムシーディースリーは、今回私の方では建設SaaSの領域に関してのご説明をさせていただいたのですが、他の事業でもエンジニアを募集しております。
詳細についてはサイトの方にまとまっておりますので、ご興味持っていただいた方は、QRコードの方からご覧になっていただければと思います。
最後に、本日の話が皆さんの組織で内製開発を進める際の何らかのヒントになれば幸いです。ご清聴いただきありがとうございました。
2025年11月26日、ファインディ株式会社が主催するイベント「内製化をスケールさせるAI時代のアジャイル開発」がハイブリッドで開催されました。
内製開発に取り組むエムシーディースリー株式会社では、内製化の推進および開発効率の可視化を目的としてファインディ株式会社が開発・運営している「Findy Team+」を導入。
客観的なデータに基づく現状分析を行い、チーム全体の効率性、生産性向上の状況、チーム単位でのパフォーマンスなどを一目で把握し、内製化をさらに推進していくために活用をしています。
本記事では、三菱商事100%子会社のデジタルカンパニー・エムシーディースリー株式会社の佐藤 勝路氏によるセッション「内製開発組織の立ち上げと推進のポイント」の模様をお届けします。
◾️登壇者プロフィール
エムシーディースリー株式会社
デジタルプロダクトカンパニー 建設クラウド事業本部/開発副統括
佐藤 勝路
【略歴】
卒業研究の作業効率を高めるために独学でプログラミングを学び、その楽しさに魅了されたことをきっかけに独立系SIerへ入社。その後、合同会社を設立して独立。続いて、大手グルメサイト運営会社に転職し、品質管理からメインサービスの担当まで幅広く歴任。最大250名規模の組織マネジメントを担う一方で、テクニカルプロダクトマネージャーとしてプロダクトの技術面を統括。その後、ＭＣデータプラス（2025年7月1日付で会社統合により社名をエムシーディースリーへと変更）へ転職し、開発組織のマネジメントおよびメインサービスの開発マネージャーを務め、現職に至る。
改めまして、皆さんこんにちは。エムシーディースリーの佐藤勝路と申します。
エムシーディースリーの建設業界向けのVertical SaaSのプロダクトにおいて開発マネージャーをしている者です。
1.会社・事業について：280万人以上のデータ基盤をもつ大規模プロダクトの開発
まず前提となる会社と事業の文脈を簡単にご紹介します。エムシーディースリーは三菱商事100%子会社のデジタルカンパニーで、2015年4月設立ですが、ちょうど2025年7月に兄弟会社と合併し社名が変更になりました。
デジタルプロダクトカンパニー（旧・ＭＣデータプラス）による建設リテール向けVertical SaaSの展開、事業共創カンパニー（旧・Industry One）による新規事業の共創、AI事業カンパニー（旧・MCデジタル）によるAIデータ活用支援まで含めたデジタル・AI領域全般での事業推進を行っております。
私が所属するデジタルプロダクトカンパニーでは、建設クラウド事業として施工管理や安全書類の作成など建設現場の業務を支えるVertical SaaSの提供と、リテールクラウド事業として購買データを活用したマーケティングプラットフォームの提供を行っています。
今回私の方は建設クラウド事業をメインに話すのですが、建設作業員270万人以上のデータを持つ大規模なサービスを運営しております。
建設クラウド事業のサービスについては、SaaSモデルかつ大規模プロダクトであり、継続的な機能追加や運用改善がそのまま事業成長につながるような形となっております。
そのため、プロダクトを支える内製開発組織のあり方自体が事業インパクトに直結しやすいというのが今日お話ししたい背景となります。
2.内製化の歩み： 外部パートナー100名超の体制からなぜ内製化が必要だったのか？
ここから本題となります。私が参画した2022年7月当時のお話なのですが、開発組織は正社員が1名、出向社員が2名、そこに外部パートナーの業務委託さんが100名以上という体制になっていました。
このような状態でしたので、業務やシステムの多くが外部のパートナーの力量に大きく依存しているような形になっており、自社組織のメンバーでは意思決定できるだけの解像度がまだない状態でした。
一方で、市場環境の変化や新規サービスの立ち上げが増えている背景で、もっと早く柔軟に開発したいというニーズ自体は高まっていました。これが内製化を本格的に進めようとしたきっかけとなります。
内製化の目的について、大きく5つに整理しています。
1. 顧客価値を最速で届けるため
2. 開発QCDと生産性を高めるため
3. 技術基盤とガバナンスを強化するため
4. 事業戦略と一体で開発するため
5. 知見を組織に蓄積し続けるため
特にマネージャー目線で重要だと感じているのは、事業戦略と開発の意思決定、こちらを社内で一貫してコントロールできる状態を作ることが大事だと思っております。
これを実現するための手段として、内製化を位置付けております。
3. 組織を強くする4つのステップ：意思決定権を確保するための内製化の進め方
ここからは内製化を進める上で意識した4つのポイントについて紹介させていただきます。
これから話すこと一つ一つはシンプルなのですが、順番だったり期待値の置き方というところがかなり重要だったと思っております。
1. 上流工程から取り組む
当時、業務やシステム仕様の全体像が社内からはまだ見えにくい状態でしたので、いきなり開発チームを作るのではなく、まず新規機能の要件定義や開発プロセスの改善のところから入ることにしました。
具体的には、要件定義の場に自社メンバーとして私も入っていきました。
私が初めに直接的に関わった機能追加の案件は、工事現場の中に掲示が必要な施工体系図と呼ばれる帳票をデジタルサイネージでも投映可能にするための対応でした。
デジタルサイネージを提供している各社の端末情報などをプロダクトマネージャーと一緒に収集し、投影に最適なファイル形式が何なのか、企業の方の利用負担が最小限になるようなUXの検討など、要求レベルから携わった上で、システム設計まで関与させていただいておりました。
採用についても、まずはマネージャーやテックリードクラスを優先しました。
ただ当時の反省点としては、人が少ないこともあり、何でもできる人を欲しいというような形になった結果、ロールの切り分けや、入社される方の支援構造というところはもっと早く整えていければよかったなと反省しております。
ポイントとしては、手を動かす人より先に、意思決定のための検討やプロセスを設計できる人を先に入れることを意識しておりました。
2. インフラ領域から取り組む
ビジネスドメイン側に強く依存するアプリケーションのレイヤーよりも、まずビジネスドメインとの関連が比較的浅いインフラ領域の部分を社員が担当するようにしました。
各プロダクトに専任のインフラ担当がいないシステムも多々ございましたので、インフラ担当不在のプロダクトから、内製の社員メンバーが関わってインフラを横串で見ていくことで、システム構成の標準化や、プロダクト横断でセキュリティガードレールを整備するといったことを進めてまいりました。
まだ全てのプロダクトのインフラ領域を社員チームで持てているわけではないのですが、自社プロダクトのインフラ領域の標準化が一定進み、全体最適につながったと思っています。
3. 優先プロダクトを決める
我々のプロダクトは、大小を合わせると2桁単位のプロダクトを持っております。全てのプロダクトを一気に内製化するということは難しいので、採用やオンボーディングに関しても薄くやってしまうと中途半端になってしまいます。
システム観点での重要度（例えば複雑さや依存関係、リスクの大きさ）と、ビジネス観点での重要度（売上や戦略的な位置付け）の2つの軸でプロダクトを整理して優先順位を決めてまいりました。
私たちのなかでは、プロダクトマーケットフィットがまだできていなくて、かつ新規開発が多いと予想していた「ワークサイト」というプロダクトを優先対象にしまして、ここに内製エンジニアと採用リソースを集中的に投下するという方式を取っておりました。
どのプロダクトで勝ち筋を作るかというのを経営や開発の組織運営の中で合意しておくと、採用のメッセージや評価・投資判断がぶれにくくなると思います。
4. 外部の力も借りる
内製化というと、全てを社員化するみたいなイメージもあるのかもしれないですが、全て社員化するのではなく、兄弟会社のメンバーやパートナー企業からの出向や協力も積極的に行いました。
2025年に合併したと申し上げたのですが、その合併前から、旧MCデジタルや旧IndustryOneのメンバーにも、我々の建設クラウド事業領域に関わっていただいていました。
合わせて、開発パートナーも含めて、チームアップイベントや改善活動を一緒に行うことで、社員と外部のパートナーさんという分け方ではなく、一つの開発チームとして動いてもらうことも意識付けを行いました。
結果として、内製比率を高める以外の方法でも、当初の内製化の目的である事業戦略と開発の意思決定を社内で一貫してコントロールできる状態というところに近づくことができました。
4. 内製化の具体事例のご紹介：グリーンサイトとワークサイトでの成果と影響
ここから、グリーンサイトとワークサイトでの具体的な活動事例をお伝えできればと思います。プロセスや組織の話をできるだけ現場の変化に落とした形でお伝えします。
事例①グリーンサイトでの要求定義フェーズへの参画
とあるプロジェクトにおいて、要求通りに手段を採用していくと、開発規模がまず非常に大きくなっていくこと、そして今後の保守性に関しても悪影響が出そうだということが分かりました。
具体的なイメージとしては、その機能に対して仕様変更が入るたびに、複数の画面、複数のテーブルに必ず影響が起きるということが、作る前から見えているような状態です。
そのため、社内メンバーが、このプロジェクトに入り、「そもそもビジネス上の目的はなんなのか」「そのために最適な解決手段となるUXはどのようなものなのか」というところから検討を進めました。
従来ですとプロダクトマネージャーの要求に対して開発チームがそのままシステム要件に落とし込んでいましたが、要求をただ実装するのではなく、目的から一緒に設計し実現することに社内メンバーが寄与できました。
ちなみに今回の検討時には、60万行以上も既存コードがある大規模なものに対し、現行仕様や設計の調査を行ったり、実際の改善案を策定する際観点不足がないかといったレビューに対して壁打ちを行ったりという形で、AIエージェントの活用も行っております。
事例②グリーンサイトでの部分的なスクラムチーム導入
グリーンサイトでは、UIの改修など小さめの案件に対して、部分的にスクラムチームを導入しております。
目的としては、①従来型のウォーターフォールだと長くなりがちだったリードタイムを短くすることと、②システム以外のプロセスも含めて、どこにボトルネックがあるのかを把握すること、の2点でした。
こちらは導入から1ヶ月ちょっとではありますが、プロダクトマネージャーの受け入れが完了するまでのリードタイムについては改善が見られました。
特にコミュニケーション面での待ち時間が、大きく減ったという示唆が得られております。
さらに、プロダクトオーナーの方も1人で裁量しきれないような事象もあるのですが、裁量の範囲をちゃんと定義することを今後やっていくとプロジェクトのアジリティも高められるのではないかといった手応えも見えてきております。
事例③ワークサイトでの組織体制の変化
2024年8月頃の体制からご説明させていただきます。この頃は、社内メンバーが1チームに配属されていて、それ以外の複数の開発チームは業務委託のリーダーが開発を進めているという状態になっていました。
業務委託のチームの方が、参画時期自体も長く、ドメインへの理解やシステムの理解といったところも彼らの方に優位性がありましたので、重要な機能開発に関しては業務委託メンバーを中心に進む状態になっていました。
社内メンバーに関しても、改善意欲はあったのですが、活動がどうしても自チームの範囲に閉じてしまい、全体に効く改善提案がしづらいという状態になっておりました。
直近は、システム仕様の理解や業務理解が進んできたことによって、社員をリーダーポジションにアサインすることができるようになってまいりました。
見えてきた定性的な効果としては、社員主導で、開発生産性や品質、開発者体験を改善する活動が行えるようになったり、それぞれの生産性や品質の把握ができるようになってきたと思います。
また、特定のお客様向けの機能改善の部分に関しては、お客様とのミーティングにも社員が入っていきました。
それにより、ビジネス上の要求事項に対してのキャッチアップも進んだと思っていますし、こうした活動を通じて、社員の当事者意識が高まったのではないかと思っております。
経営や開発マネージャーの目線で申し上げると、どこを外部に任せて、どこを自社で握っていくかといった線引きを、現場レベルでちゃんと設計できるようになったと思っております。
定量的な改善指標の導入
定量的な改善指標の導入も行っております。ユーザーへの価値提供のスピードを上げて、かつ持続させるために、Findy Team+を使ってレビュー分析とサイクルタイム分析を行っています。
定量化したレビュー関連のリードタイムに着目し、レビューアーを増やしたり、一つのプルリクエストの粒度を小さくするといった改善施策を進めた結果、実際にリードタイムの改善が見えてまいりました。
数字で良くなったというところはあるのですが、一方で大事にしたのは、こういう生産性指標に関しては、あくまでチームの改善のための情報として使うことと、個人の評価だったりチーム同士の単純な比較には使わないことということを意識しておりました。
いわゆるグッドハートの法則を意識しておりまして、数字に振り回されず、でもちゃんと数字を見ましょうというような文化作りを進めております。
5. 今後の展望：技術面でも魅力のあるサービス・プロダクトへ
ここから最後に、今後の展望についても一言触れて締めていきたいと思います。これからのテーマとして意識しているところは、技術面でも魅力のあるプロダクトにしていこうと思っております。
プロダクト自体の価値が重要なのはもちろんですが、同時にその利用している技術要素がモダナイズされているか、横断領域でSaaSが適切に導入できているかなど、開発者にとって技術面でも学びの多い魅力的な環境にしていきたいと考えております。
その際に心がけているキーワードとして、「挑戦領域で引きつける」、「見える化で強くする」、「共通基盤を磨き上げる」の3つを掲げております。
こちらの3つを回しながら、事業としても開発組織としても持続的に強くなっていくことを目指しています。あくまで一例ではあるのですが、AIネイティブで開発して、かつ仕様駆動型の開発を導入するといったところも現在取り組んでいます。
最後に、少しだけお知らせさせてください。エムシーディースリーは、今回私の方では建設SaaSの領域に関してのご説明をさせていただいたのですが、他の事業でもエンジニアを募集しております。
詳細についてはサイトの方にまとまっておりますので、ご興味持っていただいた方は、QRコードの方からご覧になっていただければと思います。
最後に、本日の話が皆さんの組織で内製開発を進める際の何らかのヒントになれば幸いです。ご清聴いただきありがとうございました。
内製開発組織の立ち上げと推進のポイント：三菱商事グループのデジタルカンパニーの歩み【11/26開催・内製化をスケールさせるAI時代のアジャイル開発イベントレポート】
2025年11月26日、ファインディ株式会社が主催するイベント「内製化をスケールさせるAI時代のアジャイル開発」がハイブリッドで開催されました。
内製開発に取り組むエムシーディースリー株式会社では、内製化の推進および開発効率の可視化を目的としてファインディ株式会社が開発・運営している「Findy Team+」を導入。
客観的なデータに基づく現状分析を行い、チーム全体の効率性、生産性向上の状況、チーム単位でのパフォーマンスなどを一目で把握し、内製化をさらに推進していくために活用をしています。
本記事では、三菱商事100%子会社のデジタルカンパニー・エムシーディースリー株式会社の佐藤 勝路氏によるセッション「内製開発組織の立ち上げと推進のポイント」の模様をお届けします。
◾️登壇者プロフィール
エムシーディースリー株式会社
デジタルプロダクトカンパニー 建設クラウド事業本部/開発副統括
佐藤 勝路
【略歴】
卒業研究の作業効率を高めるために独学でプログラミングを学び、その楽しさに魅了されたことをきっかけに独立系SIerへ入社。その後、合同会社を設立して独立。続いて、大手グルメサイト運営会社に転職し、品質管理からメインサービスの担当まで幅広く歴任。最大250名規模の組織マネジメントを担う一方で、テクニカルプロダクトマネージャーとしてプロダクトの技術面を統括。その後、ＭＣデータプラス（2025年7月1日付で会社統合により社名をエムシーディースリーへと変更）へ転職し、開発組織のマネジメントおよびメインサービスの開発マネージャーを務め、現職に至る。
改めまして、皆さんこんにちは。エムシーディースリーの佐藤勝路と申します。
エムシーディースリーの建設業界向けのVertical SaaSのプロダクトにおいて開発マネージャーをしている者です。
1.会社・事業について：280万人以上のデータ基盤をもつ大規模プロダクトの開発
まず前提となる会社と事業の文脈を簡単にご紹介します。エムシーディースリーは三菱商事100%子会社のデジタルカンパニーで、2015年4月設立ですが、ちょうど2025年7月に兄弟会社と合併し社名が変更になりました。
デジタルプロダクトカンパニー（旧・ＭＣデータプラス）による建設リテール向けVertical SaaSの展開、事業共創カンパニー（旧・Industry One）による新規事業の共創、AI事業カンパニー（旧・MCデジタル）によるAIデータ活用支援まで含めたデジタル・AI領域全般での事業推進を行っております。
私が所属するデジタルプロダクトカンパニーでは、建設クラウド事業として施工管理や安全書類の作成など建設現場の業務を支えるVertical SaaSの提供と、リテールクラウド事業として購買データを活用したマーケティングプラットフォームの提供を行っています。
今回私の方は建設クラウド事業をメインに話すのですが、建設作業員270万人以上のデータを持つ大規模なサービスを運営しております。
建設クラウド事業のサービスについては、SaaSモデルかつ大規模プロダクトであり、継続的な機能追加や運用改善がそのまま事業成長につながるような形となっております。
そのため、プロダクトを支える内製開発組織のあり方自体が事業インパクトに直結しやすいというのが今日お話ししたい背景となります。
2.内製化の歩み： 外部パートナー100名超の体制からなぜ内製化が必要だったのか？
ここから本題となります。私が参画した2022年7月当時のお話なのですが、開発組織は正社員が1名、出向社員が2名、そこに外部パートナーの業務委託さんが100名以上という体制になっていました。
このような状態でしたので、業務やシステムの多くが外部のパートナーの力量に大きく依存しているような形になっており、自社組織のメンバーでは意思決定できるだけの解像度がまだない状態でした。
一方で、市場環境の変化や新規サービスの立ち上げが増えている背景で、もっと早く柔軟に開発したいというニーズ自体は高まっていました。これが内製化を本格的に進めようとしたきっかけとなります。
内製化の目的について、大きく5つに整理しています。
1. 顧客価値を最速で届けるため
2. 開発QCDと生産性を高めるため
3. 技術基盤とガバナンスを強化するため
4. 事業戦略と一体で開発するため
5. 知見を組織に蓄積し続けるため
特にマネージャー目線で重要だと感じているのは、事業戦略と開発の意思決定、こちらを社内で一貫してコントロールできる状態を作ることが大事だと思っております。
これを実現するための手段として、内製化を位置付けております。
3. 組織を強くする4つのステップ：意思決定権を確保するための内製化の進め方
ここからは内製化を進める上で意識した4つのポイントについて紹介させていただきます。
これから話すこと一つ一つはシンプルなのですが、順番だったり期待値の置き方というところがかなり重要だったと思っております。
1. 上流工程から取り組む
当時、業務やシステム仕様の全体像が社内からはまだ見えにくい状態でしたので、いきなり開発チームを作るのではなく、まず新規機能の要件定義や開発プロセスの改善のところから入ることにしました。
具体的には、要件定義の場に自社メンバーとして私も入っていきました。
私が初めに直接的に関わった機能追加の案件は、工事現場の中に掲示が必要な施工体系図と呼ばれる帳票をデジタルサイネージでも投映可能にするための対応でした。
デジタルサイネージを提供している各社の端末情報などをプロダクトマネージャーと一緒に収集し、投影に最適なファイル形式が何なのか、企業の方の利用負担が最小限になるようなUXの検討など、要求レベルから携わった上で、システム設計まで関与させていただいておりました。
採用についても、まずはマネージャーやテックリードクラスを優先しました。
ただ当時の反省点としては、人が少ないこともあり、何でもできる人を欲しいというような形になった結果、ロールの切り分けや、入社される方の支援構造というところはもっと早く整えていければよかったなと反省しております。
ポイントとしては、手を動かす人より先に、意思決定のための検討やプロセスを設計できる人を先に入れることを意識しておりました。
2. インフラ領域から取り組む
ビジネスドメイン側に強く依存するアプリケーションのレイヤーよりも、まずビジネスドメインとの関連が比較的浅いインフラ領域の部分を社員が担当するようにしました。
各プロダクトに専任のインフラ担当がいないシステムも多々ございましたので、インフラ担当不在のプロダクトから、内製の社員メンバーが関わってインフラを横串で見ていくことで、システム構成の標準化や、プロダクト横断でセキュリティガードレールを整備するといったことを進めてまいりました。
まだ全てのプロダクトのインフラ領域を社員チームで持てているわけではないのですが、自社プロダクトのインフラ領域の標準化が一定進み、全体最適につながったと思っています。
3. 優先プロダクトを決める
我々のプロダクトは、大小を合わせると2桁単位のプロダクトを持っております。全てのプロダクトを一気に内製化するということは難しいので、採用やオンボーディングに関しても薄くやってしまうと中途半端になってしまいます。
システム観点での重要度（例えば複雑さや依存関係、リスクの大きさ）と、ビジネス観点での重要度（売上や戦略的な位置付け）の2つの軸でプロダクトを整理して優先順位を決めてまいりました。
私たちのなかでは、プロダクトマーケットフィットがまだできていなくて、かつ新規開発が多いと予想していた「ワークサイト」というプロダクトを優先対象にしまして、ここに内製エンジニアと採用リソースを集中的に投下するという方式を取っておりました。
どのプロダクトで勝ち筋を作るかというのを経営や開発の組織運営の中で合意しておくと、採用のメッセージや評価・投資判断がぶれにくくなると思います。
4. 外部の力も借りる
内製化というと、全てを社員化するみたいなイメージもあるのかもしれないですが、全て社員化するのではなく、兄弟会社のメンバーやパートナー企業からの出向や協力も積極的に行いました。
2025年に合併したと申し上げたのですが、その合併前から、旧MCデジタルや旧IndustryOneのメンバーにも、我々の建設クラウド事業領域に関わっていただいていました。
合わせて、開発パートナーも含めて、チームアップイベントや改善活動を一緒に行うことで、社員と外部のパートナーさんという分け方ではなく、一つの開発チームとして動いてもらうことも意識付けを行いました。
結果として、内製比率を高める以外の方法でも、当初の内製化の目的である事業戦略と開発の意思決定を社内で一貫してコントロールできる状態というところに近づくことができました。
4. 内製化の具体事例のご紹介：グリーンサイトとワークサイトでの成果と影響
ここから、グリーンサイトとワークサイトでの具体的な活動事例をお伝えできればと思います。プロセスや組織の話をできるだけ現場の変化に落とした形でお伝えします。
事例①グリーンサイトでの要求定義フェーズへの参画
とあるプロジェクトにおいて、要求通りに手段を採用していくと、開発規模がまず非常に大きくなっていくこと、そして今後の保守性に関しても悪影響が出そうだということが分かりました。
具体的なイメージとしては、その機能に対して仕様変更が入るたびに、複数の画面、複数のテーブルに必ず影響が起きるということが、作る前から見えているような状態です。
そのため、社内メンバーが、このプロジェクトに入り、「そもそもビジネス上の目的はなんなのか」「そのために最適な解決手段となるUXはどのようなものなのか」というところから検討を進めました。
従来ですとプロダクトマネージャーの要求に対して開発チームがそのままシステム要件に落とし込んでいましたが、要求をただ実装するのではなく、目的から一緒に設計し実現することに社内メンバーが寄与できました。
ちなみに今回の検討時には、60万行以上も既存コードがある大規模なものに対し、現行仕様や設計の調査を行ったり、実際の改善案を策定する際観点不足がないかといったレビューに対して壁打ちを行ったりという形で、AIエージェントの活用も行っております。
事例②グリーンサイトでの部分的なスクラムチーム導入
グリーンサイトでは、UIの改修など小さめの案件に対して、部分的にスクラムチームを導入しております。
目的としては、①従来型のウォーターフォールだと長くなりがちだったリードタイムを短くすることと、②システム以外のプロセスも含めて、どこにボトルネックがあるのかを把握すること、の2点でした。
こちらは導入から1ヶ月ちょっとではありますが、プロダクトマネージャーの受け入れが完了するまでのリードタイムについては改善が見られました。
特にコミュニケーション面での待ち時間が、大きく減ったという示唆が得られております。
さらに、プロダクトオーナーの方も1人で裁量しきれないような事象もあるのですが、裁量の範囲をちゃんと定義することを今後やっていくとプロジェクトのアジリティも高められるのではないかといった手応えも見えてきております。
事例③ワークサイトでの組織体制の変化
2024年8月頃の体制からご説明させていただきます。この頃は、社内メンバーが1チームに配属されていて、それ以外の複数の開発チームは業務委託のリーダーが開発を進めているという状態になっていました。
業務委託のチームの方が、参画時期自体も長く、ドメインへの理解やシステムの理解といったところも彼らの方に優位性がありましたので、重要な機能開発に関しては業務委託メンバーを中心に進む状態になっていました。
社内メンバーに関しても、改善意欲はあったのですが、活動がどうしても自チームの範囲に閉じてしまい、全体に効く改善提案がしづらいという状態になっておりました。
直近は、システム仕様の理解や業務理解が進んできたことによって、社員をリーダーポジションにアサインすることができるようになってまいりました。
見えてきた定性的な効果としては、社員主導で、開発生産性や品質、開発者体験を改善する活動が行えるようになったり、それぞれの生産性や品質の把握ができるようになってきたと思います。
また、特定のお客様向けの機能改善の部分に関しては、お客様とのミーティングにも社員が入っていきました。
それにより、ビジネス上の要求事項に対してのキャッチアップも進んだと思っていますし、こうした活動を通じて、社員の当事者意識が高まったのではないかと思っております。
経営や開発マネージャーの目線で申し上げると、どこを外部に任せて、どこを自社で握っていくかといった線引きを、現場レベルでちゃんと設計できるようになったと思っております。
定量的な改善指標の導入
定量的な改善指標の導入も行っております。ユーザーへの価値提供のスピードを上げて、かつ持続させるために、Findy Team+を使ってレビュー分析とサイクルタイム分析を行っています。
定量化したレビュー関連のリードタイムに着目し、レビューアーを増やしたり、一つのプルリクエストの粒度を小さくするといった改善施策を進めた結果、実際にリードタイムの改善が見えてまいりました。
数字で良くなったというところはあるのですが、一方で大事にしたのは、こういう生産性指標に関しては、あくまでチームの改善のための情報として使うことと、個人の評価だったりチーム同士の単純な比較には使わないことということを意識しておりました。
いわゆるグッドハートの法則を意識しておりまして、数字に振り回されず、でもちゃんと数字を見ましょうというような文化作りを進めております。
5. 今後の展望：技術面でも魅力のあるサービス・プロダクトへ
ここから最後に、今後の展望についても一言触れて締めていきたいと思います。これからのテーマとして意識しているところは、技術面でも魅力のあるプロダクトにしていこうと思っております。
プロダクト自体の価値が重要なのはもちろんですが、同時にその利用している技術要素がモダナイズされているか、横断領域でSaaSが適切に導入できているかなど、開発者にとって技術面でも学びの多い魅力的な環境にしていきたいと考えております。
その際に心がけているキーワードとして、「挑戦領域で引きつける」、「見える化で強くする」、「共通基盤を磨き上げる」の3つを掲げております。
こちらの3つを回しながら、事業としても開発組織としても持続的に強くなっていくことを目指しています。あくまで一例ではあるのですが、AIネイティブで開発して、かつ仕様駆動型の開発を導入するといったところも現在取り組んでいます。
最後に、少しだけお知らせさせてください。エムシーディースリーは、今回私の方では建設SaaSの領域に関してのご説明をさせていただいたのですが、他の事業でもエンジニアを募集しております。
詳細についてはサイトの方にまとまっておりますので、ご興味持っていただいた方は、QRコードの方からご覧になっていただければと思います。
最後に、本日の話が皆さんの組織で内製開発を進める際の何らかのヒントになれば幸いです。ご清聴いただきありがとうございました。
