はじめに
2025年7月、Skillnoteは開発組織の体制を見直し、新たな構造での運営をスタートさせました。
本記事では、以下のような問いに直面した私たちの組織再編について紹介します。
- なぜ、今の開発体制に限界を感じたのか？
- どのような構造に変えたのか？
- 組織構造と技術戦略をどう接続したのか？
- 現場メンバーの挑戦をどう後押しする構造にできるか？
現場の課題と向き合いながら、プロダクトの健全性と開発者の専門性を両立させるために私たちが取り組んだ内容を共有します。
開発体制を見直すことになった背景
これまでの開発体制では、
「スクラムチーム内でSREやQA、UX、BEやFEといった職能を横断した活動に十分な時間が取れない」
という構造上の課題がありました。
立ち上げ初期フェーズでは、意思疎通の効率性を高める効果もありましたが、次第に以下のような課題が顕在化しはじめました。
- スクラムチーム内に、SREやQA、UX、BE・FEなどの専門職能が混在しており、短期的な機能開発タスクが優先される傾向が強くなる中で、それらの横断的な活動に十分な時間を割けない状態が続いていました。
- チーム内で目の前の負債への対処は行われていたものの、構造的に再発や新たな課題の発生を防ぐ仕組みが不十分で、結果として技術的・組織的な負債が中長期で徐々に蓄積する傾向にありました。
こうした背景を踏まえ、機能開発と技術的改善の両立を可能にする組織構造を目指し、開発体制の再編に踏み切りました。
変更内容と、新たな構造の狙い
今回の体制変更では、以下のような構造への移行を行いました。
- スクラムチームを2体制で維持しつつ
- SRE・QAを統合し、プラットフォームエンジニアリングに特化した横断チームを新設
- UX領域にも専任チームを配置し、設計・検証・リサーチを一気通貫で支える体制としてUX室を新設
新設チームは、SREとQAを統合し、信頼性・パフォーマンス・品質に関わる技術的改善を横断的に担う、いわゆるプラットフォームエンジニアリングを目的とした組織です。
このチームには、開発メンバーの発案により、従来の「ギア」「スパナ」に続く新たな軸として 「シャフト」 という名称が付けられました。
これにより、スクラムチームがプロダクト機能開発に集中しやすくなる一方で、横断チームが長期的な技術的健全性や品質改善を継続的に支える構造を目指しています。
また、SREやQA、UXといった職能がスクラムチームに分散していた従来の構造から脱却し、専門性を束ねて磨ける集団として再定義したことも大きなポイントとなります。
技術戦略と組織構造をつなぐ
この変更は単なる「リソース再配置」ではなく、開発体制のあり方と技術戦略を接続し直す試みも目指しました。
現場ではこれまで、暗黙のうちに「技術的改善」や「品質向上」が個人の裁量や熱意に任されてきました。
一定の機能は果たしていたものの、全体戦略と接続された仕組みとは言い難く、担当者の経験やチーム内の暗黙知に依存する部分が多く、組織全体で再利用可能な知見として残りにくい構造でした。
例えば：
- E2E整備や監視設計が標準化されず、属人化する
- 技術的負債への取り組み方針や判断軸が、チームや個人の経験に依存していた
といった構造的な非効率が、開発スピードや品質安定性の足かせになりかねないフェーズに差し掛かっていたと認識しています。
「技術的な健全性をどのように定義し、どのように投資判断していくか」といった中長期の課題については、今後EM陣を中心に整理を進めていく予定です。
これまでと、これから
Skillnoteの開発組織はこれまで、フェーズの変化に応じて柔軟に体制を調整してきました。
そのなかで私自身が感じてきたのは、
どんな組織構造であれ、それが人の挑戦や活躍を後押しするものでなければ意味がない
ということです。そして、挑戦には失敗はつきものです。
今回の再編は、私にとってもこれまでの改善の延長線上にありつつ、次のフェーズへ向けた準備として整理し直したものだと感じています。
「この構造を作り出すか」ではなく、「この構造を通じて、どう仲間の力を引き出すか」 という本質的な問いに本気で向き合うフェーズに入ったと感じています。
過去にも改善は重ねてきましたが、それを全体戦略と接続し、チームや役割を超えて共有できるようにする。
今の構造を土台に、よりよい開発のあり方を模索していく新たなる段階に来ていると感じています。