大規模商用開発PMからInsightEdgeへ　何が同じで何が違う？

こんにちは。InsightEdge（以下、IE）でPMをしている川島です。この記事ではSIerで基幹系システムのPMを実施していた私が、InsightEdgeに転職して感じたことを書かせて頂きます。大規模SIの経験しかないのにAI・事業会社に踏み出せるか不安なら、この記事を読んで欲しいです。

どうしてこのブログを書くか
なぜSIerを離れたか ― 30代中半で感じた違和感
InsightEdgeとはどんな組織か
同じこと ― 環境が変わっても通用したもの
違うこと ― 想像以上のカルチャーギャップ
大規模PMの経験が意外と活きた場面
おわりに

1. どうしてこのブログを書くか

前職はインフラ系SIerで大規模システム構築のPMをやっていました。電力・通信などの基幹系システムの構築を行ってきました。数十社のベンダーと調整しながら、ひとつの障害が社会インフラの停止に直結するような仕事をしてきました。そこからAIを活用した内製開発組織に転職しました。「なんでまた？」とよく聞かれます。この記事はその問いへの、今の自分なりの答えです。

2. なぜsierを離れたか―30代中半で感じた違和感

SIerの中で立場が上がるにつれて、ある矛盾をじわじわと感じるようになりました。組織の目標が「人を抱え続けること」になるほど、クライアントへの提案が「本当に必要なシステム改善」ではなく「次の案件を生むための提案」になっていきます。最初はそれに気づかないふりをしていました。でも30代半ばを過ぎたあたりから、「自分はいったい誰のために仕事をしているんだろう」という問いが、頭から離れなくなってしまいました。SIerという業態を否定したいわけではありません。ただ、立場が上がるほどその構造から抜け出せなくなります。「事業会社のIT組織として、ビジネス起点でシステムを考える側に行きたい」という気持ちが固まっていきました。問題は「じゃあどの事業会社へ？」です。ここが正直、一番悩みました。特定の業界を選ぶと、前職の経験が活きる場面が偏ります。かといって明確な「やりたい業界」があるわけでもありませんでした。そこで行き着いたのが「総合商社の内製化組織」という選択肢でした。住友商事は金融・流通・エネルギー・メディアなど、幅広い商流とグループ企業を持っています。その内製開発組織であるInsightEdgeなら、特定の業界に縛られることなく、分野を横断して価値を提供できるんじゃないか ――「業界を選ばなかった」結果として、これまで触れてこなかった業務ドメインに次々と関われています。「業界を選ばなくていい事業会社」という逆転の発想が、転職先を決めた理由でした。

3. InsightEdgeとはどんな組織か

InsightEdgeは、住友商事グループのDX・内製開発を担う組織です。AIや機械学習・データ分析を使って、グループ各社の業務課題を解くPoC（概念実証）を高速で回し続けることが主な仕事になります。外部SIerへの発注ではなく、内製であることの意味は大きいです。プロジェクトの動機が「次の案件を取る」ではなく「グループ事業の価値を上げる」であること。これが、前職で感じていた矛盾をそのまま解消してくれました。

4. 同じこと ― 環境が変わっても通用したもの

転職して最初に驚いたのは、PMの仕事の骨格が思ったより変わらないことです。ステークホルダー管理の本質はどこでも同じでした。相手が電力会社の設備部門長でも、製造業の経営企画部長でも、「相手が何を求めているか」を正確に把握して、「届けられるもの」との乖離を早期に埋める ―― これはPMの核心として変わりません。数十社を同時調整した経験は、そのまま活きました。リスクを早めに言語化して共有する習慣も変わりませんでした。インフラ系では「リスクを見落とすことが社会的インシデントに直結する」という文化の中にいたので、潜在リスクを早期に共有することが骨まで染みついています。 PoC環境でも「このモデルの精度が出なかった場合、どこまで巻き戻るか」を事前に言語化しておくのは全く同じPMの仕事です。「やらないことを決める」スコープ管理も普遍でした。どちらの世界でも、スコープを守る力が最重要PMスキルのひとつであることは変わりません。

5. 違うこと ― 想像以上のカルチャーギャップ

環境は変わらないと思いきや、文脈の違いは想像を超えていました。【成功の定義】前職での成功は「リリース日を守ること」「止まらないこと」でした。 InsightEdgeでは「学びを最大化すること」「次のフェーズに繋げること」が成功です。モデルの精度が出なかった＝失敗ではなく、「精度が出ないと分かった＝重要な学び」として扱われます。

【失敗の許容】ここが最もカルチャーショックでした。インフラ系では「失敗は許されない」が全ての行動原理です。 PoC環境では「失敗から学ぶ」が前提で、失敗を恐れて実験を遅らせる方が問題とされます。頭では分かっていても、長年染みついた「失敗回避」の反射はそう簡単に書き換えられませんでした。

【計画の粒度】 InsightEdgeでは短期間で仮説を回し続けることが基本です。最初のプロジェクトで丁寧な計画書を持参したら、データサイエンティストに「試してみないと何も言えませんよ」と静かに返されました。緻密に計画を立てることに価値を感じていた自分の価値観を変えるまで、時間がかかりました。

【業務知識の役割】前職では、ドメイン知識は自分が主体的に深めるべきものでした。 PoC環境では、業務知識はクライアント側が持つものであり、こちらは「引き出す問い」と「データから示唆を出す技術」を持ち込む側です。「知っている自分」から「引き出す自分」への転換も必要になってきます。

6. 大規模PMの経験が意外と活きた場面

前職の経験が武器になった場面も多くあります。 PoC→本番移行の「谷」を渡れることが、今の自分の最大の強みだと思っています。 PoCが成功して「では本番に組み込もう」となった瞬間、セキュリティ・運用体制・既存システムとの連携という、まさに前職の世界が戻ってきます。この「谷」を渡り切れずにPoC成果が塩漬けになるケースを、入社後何度も目撃しました。「PoC段階から本番を見据えて設計する」視点は、今では自分のPoC PMとしてのアイデンティティになっています。複雑なステークホルダー折衝も強みになっています。グループ企業の経営層から現場部門まで利害が複雑に絡み合う構造は、前職の「数十社ベンダー＋複数の発注者部門」に構造が似ています。「誰に何を・いつ・どう伝えるか」のコミュニケーション設計は、そのまま通用しました。

7. おわりに

正直に言うと、転職は「完璧な答えを見つけてから動いた」わけではありません。「このままSIerにいていいのか」という違和感と、「事業会社に行きたいけどどこへ？」という迷いを抱えたまま、えいやっと決めた部分が大きいです。その選択は間違っていなかったと思っています。「業界を選ばなかった」結果として、これまで触れてこなかった業務ドメインに次々と関われており、成長を感じさせてくれています。 PMという仕事の本質は「人と目標をつなぎ、不確実性を前に進む力に変える」ことです。スピードが速くなっても、確実性が下がっても、それは変わりません。大規模SIの経験しかないのにAI・事業会社に踏み出せるか不安なら、この記事を読んでほしいです。