はじめに

はじめまして。株式会社スイッチメディアでVPoEをやっている白鳥です。
今回はスイッチメディアの技術組織の全体像と、これからどこを目指していくのかを書いていければと思います。

なぜ今、技術組織の話をするかといえば理由はシンプルで、生成AIの進化によってソフトウェア開発の前提が変わってしまったからです。

これまでのソフトウェア開発は人が仕様を書き、人が設計し、人がコードを書くという人間中心のある種の労働集約的な生産モデルでした。

しかし、Codex や Claude Code をはじめとするコード生成に特化した生成AIの進化によって、実装はAIが高速にでき、ドキュメントのメンテナンスまでもAIに任せられるようになってきました。

SNSなどでもIT業界の著名人が言っている通り、今後は

• 何を作るべきか決めること
• 複雑な事業ドメインを理解し構造化すること
• 技術・プロダクト・ビジネスを横断して設計すること

が、人間の仕事として残っていくと思っています。

弊社の事業ドメイン

スイッチメディアのプロダクト領域は、正直に言ってドメインが非常に複雑です。

まず、地上波テレビCMの視聴率の計測。国内で地上波テレビの視聴データを収集している会社は数社しかなく、一般的な技術構成が知られていません。また、視聴率の計算には統計の知識とビッグデータを扱うノウハウが求められ、これだけでも一つの専門領域として成立します。

次に、ネット広告。Google、Facebook、YouTube、X、Instagram、TikTokと主要なプラットフォームだけでも多数ある上に、プラットフォームごとに微妙に指標が異なったり、同じ指標名でも定義が微妙に異なることさえあります。さらに弊社は地上波テレビも扱ってる関係で、獲得系ではなく認知系の広告、いわゆるアッパーファネルを主眼としており、ネット広告でアッパーファネルに強みを持つ企業自体が少ないです。

そして顧客。弊社の顧客はテレビCMを活用しているナショナルクライアントが中心です。潜在顧客の絶対数が限られるためデータドリブンな仮説検証が難しい領域です。相手の組織も大きいことが多く、意思決定構造を理解するにも時間と経験が必要です。結果として「こうしたら使われる」「こうしたら選ばれる」という感覚がエンジニアからは想像しづらくなっています。それでもプロダクトの設計判断にはそのドメイン理解が求められます。

どれか一つでも珍しい領域が3つ同時に存在しています。
AIがコードを書ける時代だからこそ、この複雑さを扱える組織であることが競争力になると考えています。
そのため今、改めて技術組織の構造を見直しています。

技術組織の全体像

現在のプロダクト開発部は、大きく以下のロールで構成されています。

Product Delivery Manager

機能開発における QCD+S（Quality / Cost / Delivery / Security）に責任を持つ役割です。
スコープ整理、優先度判断、スケジュール設計を担う、開発の交通整理役です。

SaaS Development Engineer

自社SaaSである、TVAL / XMI のアプリケーション開発を担当しています。
より細かくは、フロントエンド・バックエンドで専門性を持っており、プロダクトの体験そのものを作るエンジニアです。

QA Engineer

品質保証を担当しています。
弊社のような広告分析SaaSは広告への投資判断に使われるため、データ基盤やIoT機器まで横断的にテスト設計をおこなっています。
また、開発の後工程からテストを担当するのではなく、設計段階からQAに入り込む “シフトレフト” を前提に活動しています。

Platform Engineer

クラウド・データ基盤・SREを担当しています。
システムが単に “動く” ではなく、”長く安全に動き続ける” ことに責任を持っています。

IoT Engineer

視聴データを取得する調査機器を担当しています。
Android アプリとそれが動くハードウェアまで含めて、開発・保守を行なっています。

今までの開発の進め方

弊社では以下の流れで開発を進めています。

1. 企画メンバーがワイヤー・要件のたたきを作成
2. 企画・エンジニア・QAでキックオフ
3. フロントエンドのモック作成、バックエンドのAPI/DB設計、QAのテスト設計を並行して進めながら、企画と協働で仕様を詰めていく
4. 仕様の不明瞭な点をなくしてからスケジュールFIX
5. 実装 → 全員でテスト → リリース

特徴として、開発初期はアジャイル的な思想で不確実性の高い問題を解決していきつつ、リリースに近づくにつれ堅実な開発フローにシフトしていくことで、開発スピードと品質の両立を目指しています。

生成AIによって、今後どう変わるのか

これから求められるエンジニアとはどんな人でしょうか。

例えばスタートアップでは、創業者が生成AIを活用して1人でプロダクトを作るということが、実際にもう起こっています。
ビジネスドメインを理解し、生成AIの出力したコードに責任を持てる人が全てを判断していくことが、最も効率的なプロダクト開発だからです。

ただ、そんなことができる人は非常に希少です。

VPoEとして採用にも携わっている身からすると、エンジニアリングの全領域に対してテックリード級の専門性を持つジェネラリストだけを揃えたい、という願望に駆られることは多々ありますが、現実的ではありません。

もちろん、生成AIによって人がコードを書く機会は減っていき、遠くない将来にはゼロになる可能性もあると思います。ただそれでも、エンジニアが担うべき専門領域を再定義し、スケール可能な組織を構築していく必要があると考えます。

これから目指す体制と求めるエンジニア像

生成AI時代のエンジニアに求められるものはなんでしょうか。弊社では三つの軸で整理しています。

ドメインを理解し、構造化できる

ビジネスの現場では、人間が自然発生的に生まれる問題を解決していく中で、再現性の高い解決手段が編み出されていきます。
エンジニアの仕事はその解決手段を言語化し、構造に落とし込み、システムで実行可能な形にすることです。そしてそれだけでなく、設計したドメインモデルがコードに正しく反映されているかを担保することまでが、この役割の範囲だと考えています。弊社のような複雑なドメインほど、この精度がプロダクトの価値に直結します。

AIがパフォーマンスする開発プロセスを設計できる

生成AIをただ使うのではなく、AIが力を発揮できる開発の仕組みそのものを作れるかどうかも重要です。コーディングルールの整備、リファクタリングの判断基準、レビュープロセスの再設計。こういった開発プロセス全体をAI前提で組み直せる人が、これからのエンジニアリングの中核になると考えています。アーキテクチャがAI時代にどう変わるかはまだ誰も答えを持っていませんが、その答えを出し続けることが仕事になります。

人間としてシステムを評価できる

そして、人間が使うシステムとしてプロダクトの品質を評価できること。画面上に表示されていても、人間が認知できるか・理解できるかは人間にしか判断できません。また、ドメイン領域として正しい挙動かどうか、エッジケースでの挙動がプロダクト的に許容できる範囲かどうかも、深いドメイン理解があって初めて評価できます。
AIがテストコードを書ける時代でも、この判断だけは人間が担い続けると思っています。
ただし、これらを一人で全て担う必要はありません。それぞれの専門性を持ちながら、分担して協働できる組織を作ることが、私たちの目指す姿です。

最後に

生成AIがコードを書けるようになった今、シンプルなドメインであれば少人数、なんなら1人でもプロダクト開発が完結してしまいます。

スイッチメディアのドメインはそうではありません。生成AIの時代にも、とても1人では太刀打ちできない複雑なドメイン領域に面白さを感じた方、ぜひお話ししましょう。