顧客に向き合う開発組織へ リアーキテクチャとフィーチャーチーム化で挑む組織改⾰ 技術的負債に向き合うConference 2026 2026.09.16 セーフィー株式会社 中村 俊成 

⾃⼰紹介 中村 俊成 Toshinari Nakamura セーフィー株式会社 開発本部 システム基盤開発部 Safie Manager 開発G / Safie Entrance 開発G グループリーダー Career 本取り組みとの関わり 性格診断 ⼤⼿メーカーにて組み込み系ソフトウェア開 発に従事。 開発本部が推進するプロジェクトの⼀員とし て、組成されたフィーチャーチームの運営に 責任を持つ。 擁護者型 ISFJ-A その後、スタートアップやメガベンチャー、 事業会社にて、Web‧モバイルアプリから バックエンド、IoTデバイス連携など幅広い開 発を経験。 誰かの役に⽴てると嬉しいタイプです。 セーフィーでは、エンタープライズ向けのプ ロダクト開発を担当。 システムのリアーキテクチャと開発組織の再設計を、ひとつのプロジェクトとして進めています © Safie Inc. 2 

本⽇の内容 1 なぜ失敗したか 組織だけを変えて、何が起きたのか 2 何を⽬指すか システムと組織の「2つのリアーキ」 3 どう始めたか システムはアプリ分離から、組織はバーチャルチームから 4 どう定着させたか 正式組織化と、評価‧専⾨性⽀援の設計 5 どこまで来たか 2つのリアーキの⽬標に対する現在地 © Safie Inc.｜ 3 

セーフィー Safieについて © Safie Inc.｜4 

クラウド録画サービス「Safie（セーフィー）」の概要 会社概要 製品‧サービスの概要 設⽴年⽉ 2014年10⽉ データ 連携 API 従業員数（2026年7⽉）*1 644⼈ 年間売上⾼（FY2025） 19,029百万円 ARR（2026年6⽉末）*2 15,791百万円 課⾦カメラ台数（2026年6⽉末）*3 38.5万台 クラウド プラットフォーム データ 分析 画像 解析 映像 解析データ ソリューション 映像 入口/出口の インターフェースは 問わない クラウドとオンプレミスのハイブリッドなカメラOS 強固なセキュリティ 誰もが使える高品質なUI･UX *1 各⽉初の⼈数 *2 ARRはAnnual Recurring Revenue。各四半期末時点のMRR（Monthly Recurring Revenue）を12倍して算出。 MRRは対象⽉末時点における継続課⾦となる契約に基づく当⽉分の料⾦の合計額（販売代理店経由の売上を含む） *3 各四半期に販売したカメラ台数ではなく、各四半期末時点で稼働‧課⾦しているカメラ台数 拡張性の高いプラットフォーム © Safie Inc.｜ 5 

沿⾰及びマーケットシェア 課⾦カメラ台数及び主な提携実績 マーケットシェア 課⾦カメラ台数 クラウドモニタリング‧録画サービスシェア*1 資本業務提携 業務提携 業務提携 業務提携 資本業務提携 *1 テクノ‧システム‧リサーチ社調べ「ネットワークカメラのクラウド録画サービス市場調査（2025）」より、エンジン別カメラ登録台数ベースのシェア（54.3％） © Safie Inc.｜ 6 

あらゆる業界での顧客基盤 小売 /サービス 飲食 建設 インフラ / 公共 物流 製造・プラント オフィスビル 警備 © Safie Inc.｜ 7 

たとえば、小売/サービス業界だと 既設カメラのクラウド化を含むカメラの多台数設置 × 映像 × AIで省人化を実現 多台数設置 × ソリューション 2 1 既設カメラも クラウド化 セキュリティ対策 1 ・店舗の危機管理を 遠隔化 ・再来店を自動検知 7 遠隔で防犯 /警備 在宅からの 遠隔接客 3 レジ待ち対策 4 ・混雑緩和による 顧客体験改善 3 4 遠隔接客 ・専門スタッフ不足解消 ・インバウンド対応 6 6 5 マーケティング ・来店者数カウント 販売促進 ・棚割りや商品補充 タイミングの最適化 5 2 7 本社(遠隔)からの 多店舗管理 コミュニケーション支援 ・業務を遠隔から インカムで指示 © Safie Inc.｜ 8 

たとえば、建設/インフラ業界だと 多台数カメラ設置と複数ソリューションにより利便性の高い建設業界の現場DXを実現 多台数設置 × ソリューション 1 1 工事進捗の把握 2 ・多台数のカメラを 活用し進捗確認 3 遠隔で防犯 /警備 2 4 5 交通量調査 ・映像×AIで人手を かけず自動計測 現場NW環境 屋内監視用の メッシュ環境 不安全行動の 自動検知 ・危険エリアへの 侵入抑止 ・資材盗難防止 5 6 ・管理コストの削減 4 3 遠隔臨場 / 検査 6 コミュニケーション 支援 ・トラブルをセンサー で検知しインカムと 「窓」で即時指示 7 7 本社(遠隔)での 多現場管理 高速道路の維持管理 ・映像にキロポスト 表示で位置情報を 即座に把握 © Safie Inc.｜ 9 

勝ち筋を伸ばすとともに多⽅⾯での探索的なアプローチも必要 プロダクトをどんどん世に出して 「各業界のDX課題の解像度をあげる -> デファクトな仕組みを構築していく」をより スピーディに、かつ多⾓的に⾏うことが求められている © Safie Inc.｜10 

1 なぜ失敗したか 組織だけを変えて、何が起きたのか © Safie Inc.｜ 11 

開発組織の歩み：組織を変えれば、顧客に向き合えるのか 2014〜2021 2022 → 2023 主要サービスひとつを全 員で開発 IPOを経て、業界軸の BU制へ BU制をやめ、職能型へ 戻す システム刷新と組織再設 計を⼀体で進める ⼈数は増えたが、結果として 職能で分かれた組織へ 組織だけを分けたが、システ ムは分かれておらず、チーム は⾃律できなかった 採⽤‧育成‧オンボーディン グを整備し、まず組織の安定 を取り戻す 本⽇の本題。現在進⾏形の取 り組み ⼀度⽬の組織改⾰：失敗 2024〜 再挑戦 技術的負債は、コードを変えにくくするだけではない 「チームが⾃律できない」という形で、組織改⾰の⾜かせにもなる © Safie Inc.｜ 12 

「ひとつの巨⼤なシステム × 職能別組織」の成り⽴ち 創業〜 2018年ごろ〜 組織という概念がなく、全員でバグ修正‧改善‧新 機能開発 カメラ販売台数が急増。エンジニアもプロジェクト も増え、PM‧PdMを専任化 リポジトリはアプリケーション、バックエンド/イ ンフラ、デバイスに分離。それぞれ単⼀ エンジニア総数が少なく、結果として職能で分かれ る組織に。リポジトリ構成はそのまま その規模ではいちばん速く、合理的な判断 主要サービスがひとつの時代は、この構造で⼗分に回っていた 誰かの設計ミスではなく、各成⻑段階での合理的な判断の積み重ねとして⽣まれた © Safie Inc.｜ 13 

前提が変わり、2022年に業界軸のBU制へ移⾏ 前提を変えたもの 2022年：業界軸の BU制 各BUにPM‧PdMとエンジニアを配置し、⾃律的なプロダクト開 発を⽬指す IPOを経て事業が成⻑ 業界ごとにお客様の課題が⼤きく異 なる BU ⼩売 BU 建設 BU … PM‧PdM＋Eng PM‧PdM＋Eng PM‧PdM＋Eng 画⼀的な対応では厳しい 横串組織：共通基盤 認証‧デバイス管理‧録画配信 前提の変化 ひとつのサービスをみんなで開発する ひとつのモノリシックなシステム‧リポジトリ → 業界‧⽤途別に複数のプロダクト を並⾏で開発する プロダクトごとの境界は分離されず、複数の組織が同時に⼿を⼊れる エンジニア数 30名 → 100名へ 組織は分けたが、システムは独⽴して開発‧リリースできる構造では なかった 職能型のまま増員しても、受け渡しと調整が 増え、⼈数に⽐例して速くはならない © Safie Inc.｜ 14 

組織だけを変えて露呈した、3つの課題 01 02 03 改修時の影響範囲が広い 学習難度が⾼い オーナーシップが不明瞭 障害リスクと影響確認‧検証のコストが 増加。同じリポジトリを触る組織が増 え、リリース調整のコストはむしろ上 がった 即戦⼒しか採⽤できず、各組織に必要な エンジニアを配置できない。キャッチ アップにも多⼤な時間 コードベースの分割は進めたが、各コン ポーネントの持ち主が決まらず、改善や リファクタが進まない 業界軸で組織を分けても、チームは⾃律できなかった → 2023年、いったん職能型へ戻す 組織を変えるには、システムはどうなっているべきか。順序と進め⽅をセットで考える必要があった © Safie Inc.｜ 15 

2 何を⽬指すか 「2つのリアーキ」を共通⽬標にする © Safie Inc.｜ 16 

システムと組織の「2つのリアーキテクチャ」 システムのリアーキテクチャ 組織のリアーキテクチャ チームが担当するプロダクトを、⾃分たち で変更し、リリースできる境界をつくる プロダクトに必要な職能が⼀つのチームと なり、顧客価値に共同で責任を持つ チームに責任を渡すことと、その責任を果たせるシステムを整えること。この2つを⼀体で進める © Safie Inc.｜ 17 

3つの課題を、顧客価値への影響として関係部署に説明する リアーキにエンジニアのリソースを割く以上、 プロダクト開発の⼿を⼀部⽌めることになる → 「開発を⼀部遅らせてでも、いま構造を変える」ことに 納得し、体制変更を⼀緒に進めてもらう必要があった 開発部⾨の⾔葉 業務‧顧客価値への影響 改修時の影響範囲が広い 確認‧検証‧切り戻しのコスト。API待ちや複数チームの⽇程調整で、顧客に価値を届けるま での時間が延びる 学習難度が⾼い 採⽤と育成の問題。同時に、チームの開発⼒が伸びない問題 オーナーシップが不明瞭 職能ごとに情報と優先順位が分かれ、兼務も多い。個々の判断は合理的でも、プロダクト全 体で何を優先すべきかを考えにくい 顧客に価値を届ける速さと質に関わる共通の課題として共有し、組織案‧サービス境界‧ロードマップを叩き台 に、TL‧GL‧関係部署と⼀緒に具体化 © Safie Inc.｜ 18 

3 どう始めたか システムも組織も、可逆性の⾼い⼀歩から © Safie Inc.｜ 19 

システム：アプリレイヤーの分離から、2ステップで進める 体制 第⼀歩 横断のリアーキ推進グループ 計画とサポート 主要な分離は完了 アプリレイヤーの分離 効果がすぐ出る：独⽴リリース、影響範囲の限定、CI/CDの⾼速化。移⾏難度が⽐較的低 く、1チーム1プロダクトの境界ができ、フィーチャーチーム化に踏み出せた × 各プロダクトチームの有識者 サービス境界‧データ構造‧移⾏⽅ 法をリードまたは協業 第⼆歩 着⼿済み DB分離も含めた疎結合化 推進グループだけで決めず、関連チーム が当事者として関与する 移⾏難度が⾼く、可逆性が下がる。境界の解像度が低い状態から始めるため、100％の正 解を⽬指さず、まずざっくり分けるところからスタート © Safie Inc.｜ 20 

第⼆歩：論点単位で、検討と分離を回す STEP 01‧論点を設定 STEP 02‧有識者と議論 STEP 03‧段階的に移⾏ STEP 04‧現在地 サービス境界ごとに データ構造の⾒直し 論点ごとに step by step 検討中の論点と分離作業 中の論点が並⾏ 例：契約とデバイス機能の分 離 → ユースケースごとのサービス 間IF → 固まった論点から分離作業へ → 全体計画を固めて⼀気に移⾏するのではなく、論点単位で検討と分離を回す。早い段階で効果が⾒えることが、チームを分ける判断を ⽀える 最初から100％正しい境界を決めるのではなく、可逆性の⾼い変更から始め、学習しながら境界を育てる © Safie Inc.｜2121 

組織：2つのプロダクト開発チーム セーフィー マネージャー セーフィー エントランス Safie Manager Safie Entrance Safieのクラウドカメラやユーザーアカウントを安全に ⼀括管理できるWebアプリケーション クラウド型の顔認証⼊退室管理システム エンタープライズユースにも対応した⾼いセキュリティと、 クラウドならではの導⼊の⼿軽さを実現しています。 ブラウザ上で権限設定やログ確認が完結するため、全国の拠点や 膨⼤なドアも、1つの画⾯で管理が可能です。 © Safie Inc.｜ 22 

組織：組織図を変える前に、バーチャルな2チームで成功体験をつくる バーチャルチームで取り組んだ3つのこと 正式な⼈事異動を伴わない、可逆性 の⾼い⼀歩 2つのバーチャルなフィーチャーチーム で、職能を越えて⼀つのチームとして開発 できることを確かめる 1 技術スタックの壁を低くする 2 開発プロセスを⼀つにする 3 成功体験を正式組織化の根拠にする © Safie Inc.｜ 23 

① 技術スタックの壁を低くする：スキルマップで道筋を⽰す FE‧BE双⽅のスキルマップで可視化 学ぶべき技術 希望するエンジニアが段階的に進む 教材 隣接領域の課題 ↓ 課題 期待するアウトプット 実際の開発タスク 「隣の領域もやってみて」と⾔うだけでは動きにくい。何をどこ までできればよいかを先に⽰す ↓ レビューと協働で定着 全員を同じスキルセットにすることが⽬的ではない 専⾨性は持ったまま、隣接領域を理解し、チーム内で協⼒できる状態を⽬指す © Safie Inc.｜ 24 

② 開発プロセスを⼀つにする：ひとつのバックログとPO バーチャルチーム これまで ひとつのプロダクトバックログ 企画 FE BE 課題‧優先順位 課題‧優先順位 課題‧優先順位 職能ごとに分かれた課題管理。情報と優先順位に偏り → PdM＝PO FE BE QA スクラム∕カンバンで計画‧開発‧レビュー‧改善を回す。QAは 別部署所属のまま参加 狙い 結果 顧客と事業の優先順位が、開発チームの意思決定と 直接つながる 情報の⾮対称性が減り、⼿戻りとコミュニケーショ ンコストが下がった © Safie Inc.｜ 25 

③ 成功体験を正式組織化の根拠にする：2022年との違い 2022年 今回 組織図から変えた アプリレイヤーの分離で、1チーム1プロダクトの 境界を先につくる システムとリポジトリは分かれていなかった チームは⾃律できず、翌年に職能型へ戻す バーチャルチームで、働き⽅‧相互理解‧バック ログ‧意思決定の接続を整える うまくいくことを確かめてから、組織図を変える 成功体験を踏まえ、責任範囲を明確にした正式なフィーチャーチームへ移⾏ © Safie Inc.｜ 26 

4 どう定着させたか 正式組織化に合わせ、評価と専⾨性⽀援を 設計する © Safie Inc.｜ 27 

評価軸は、技術⼒と影響範囲：既存のランクテーブルをそのまま使う 論点 専⾨領域の異なるメンバーの技 術⼒を、どう適切に評価するか バックエンド出⾝のGLと部⻑が、フロントエ ンドエンジニアの評価も担う 技術⼒ 影響範囲 要件定義から実装‧テストまで の、どこまでを、どれだけ⾃律 して担えるか その⼒を、⾃分の担当 → チー ム → チーム外 → 社外まで、ど こまで及ぼせるか 職能に依存しない。また、例えばFE, BE両⽅の技術を扱えること⾃体が⾼ 評価になるわけではなく、その⼒で出した成果と周囲への貢献を⾒る © Safie Inc.｜ 28 

専⾨領域の⽬標設定と評価を、知⾒を持つ⼈と協⼒して⽀える フィーチャーチームで レポートライン BE出⾝のGL‧部⻑ 評価の責任、共通の評価軸で⾒る → フロントエンド領域を担 うメンバー ⽀援 ← FE出⾝の別グループGL‧TL FE技術⾯の⽬標設定と評価 同じ「設計ができる」でも、FEでどの難しさの設計を担い妥当だったかを⾒るには、FEの知⾒が必要。評価 全体を職能組織に預けるのではなく、マネージャーだけでは判断できない専⾨領域だけを⽀援してもらう 評価軸は職能を越えて共通にし、技術⾯の⽬標設定と評価は、その領域に知⾒を持つ⼈を巻き込み、協⼒して 進める © Safie Inc.｜ 29 

5 どこまで来たか 2つのリアーキの⽬標に対する現在地 © Safie Inc.｜ 30 

システム側：1章の3つの問題は、チームの中で解けるようになった ⽬標 チームが担当するプロダクトを、⾃分たちで変更し、リリースできる境界 1 改修時の影響範囲が広い 2 学習難度が⾼い 3 オーナーシップが不明瞭 ⾃チームの判断でリリースでき る 新メンバーのキャッチアップが 速くなった 担当プロダクトのコードの持ち 主が明確になった 担当プロダクトは他チームとのリリー ス調整なし。FEとBEが同じチームにい るのでAPI提供待ちも減少 担当プロダクトの境界が明確になり、 ⾒るべきコードベースが絞られた プロダクト開発や改善の優先順位を チーム内で議論できる 正式組織化後に加わったメンバーは、 最初からFEとBEの両⽅を前提にオン ボーディングを実施 APIのパフォーマンス改善、リンターの 導⼊、ディレクトリ構造の整理といっ た改善やリファクタを、他チームの合 意を待たずに⾃チームの判断で進めら れる 想定以上だったのが開発リソースの柔 軟さ。FE作業が少なければBE開発に回 る配分がチーム内で完結 © Safie Inc.｜ 31 

組織側：2チームとも、専⾨領域の外側で⼿を動かしている ⽬標 プロダクトに必要な職能が⼀つのチームとなり、顧客価値に共同で責任を持つ 正式組織化の前からいる 12名のうち 9 名 もともとの専⾨領域の外側で、実際に⼿ を動かしている 特別なメンバーがいたからではなく、スキル マップと共通バックログを整えたことで可能に なった Safie Manager 開発グループ Safie Entrance 開発グループ FE出⾝ 2名 → DB設計‧API設計など BE側の設計と実装 FE出⾝ 2名 → BE側の設計と実装 BE出⾝ 4名のうち 2名 → UI‧画⾯設 計と実装 各チーム 7名 FE出⾝ 2 BE出⾝ 4 BE出⾝ 4名のうち 3名 → FE側の設計 と実装 正式組織化後に加⼊ 1 うち1名は技術寄りのプロダクトマネジメントも担う © Safie Inc.｜ 32 

考え⽅の変化と、要件定義の上流への関わり 設計の場での会話が変わった 職能別チームのころ BEはAPIがフロントでどう使われるかまで、FEは APIのあるべき姿まで、考えきれない いま、出⾝職能に関係なく 「この機能はこう使われるから、フロントはこうな る。だからAPIにはこれが必要だ」 要件定義の上流へ、⼀つのチームとして踏み込む 技術寄りのプロダクトマネジメントを担うメンバーが リードし、FEとBEが領域をまたいで会話しながら、顧客 理解を要件‧仕様に落とす Safie Manager Safie Entrance ドメインモデリングに着⼿。 ドメインエキスパートへのヒ アリング機会を設ける 設置⼯事を伴うプロダクト。 メンバーが実際の設置⼯事に ⽴ち会い、現場での取り付け と使われ⽅を⾒る 実装の全体像を描けると、次に出てくるのは 「何を作るか」を決める仕事をPdMだけに預けず、 「そもそもこの機能はどうあるべきか」という問い 「開発チームが上流から関わる」 © Safie Inc.｜ 33 

2つのリアーキの⽬標に対する到達点 到達 到達 いま踏み出している システム 組織‧前半 組織‧後半 ⾃チームの判断で変更し、リ リースできる境界 必要な職能が⼀つのチームにな る。12名のうち9名が領域を越 え、要件定義の上流にも関わり 始めた 顧客価値に共同で責任を持つ。 上流に関わりドメインを理解す る動きが出てきたいま、プロダ クトの成果指標をチームの⽬標 として持つ段階へ 「⼀つのチームになる」は実現した。次は、何に責任を持つのかを顧客価値の⾔葉で定義し、顧客に価値をより速く、 ⾼い品質で届けるチームへ © Safie Inc.｜ 34 

まとめ：組織を変えれば、顧客に向き合えるのか 1 なぜ失敗したか 組織だけ変えても、チームは⾃律できない。システムと組織を、順序を設計 して⼀緒に変える 2 何を⽬指すか 「2つのリアーキ」。負債の返済を、顧客価値への影響として関係部署と合意 する 3 どう始めたか 可逆性の⾼い⼀歩から。システムはアプリ層分離、組織はバーチャルチーム 4 どう定着させたか 評価軸は職能を越えて共通に。専⾨領域の評価は、知⾒を持つ⼈と協⼒する どこまで来たか 「⼀つのチームになる」は実現した。次は、顧客に価値をより速く、⾼い品 質で届けるチームへ 5 組織を変えるだけでは、顧客に向き合えない。システムと組織を、順序を設計して⼀緒に変える。 © Safie Inc.｜ 35 

ご清聴ありがとうございました Thank you! © Safie Inc.｜ 36