■ 1. 半年の構造改革の結論
- 職種の廃止:
- iOS・Android・Web・バックエンドという職種を廃止した
- アウトプット10倍:
- 開発のアウトプットは半年で10倍になり、品質は落ちなかった
- 次はアウトカム:
- アウトプットの最適化を経て、次は本丸のアウトカムへ向かう
- 記録の位置づけ:
- 音声のtoCプラットフォーム開発の現場で起きたリアルな構造改革の記録
- 何を決めて、いかにして開発組織の基盤を作り替えたのかを記す
- 後半では手に入れた速度を事業のアウトカムへどう向けるかを述べる
■ 2. プロダクトエンジニアへの再定義
- 4職種の統合:
- 4つの職種名を廃止し、全員をプロダクトエンジニアに再定義した
- QAエンジニアとSREは専門性を維持する職種として残している
- 求める6つのコンピテンシー:
- 技術力: エンジニアリングスキルであり引き続き最重要
- 課題解決: 課題発見力・解決能力
- ビジネス: ドメイン知識・事業への深い理解
- UX/デザイン: UI/UXへの感度
- 連携: PdM・デザイナーとの円滑なコミュニケーション
- スタンス: 自律性・主体性
- 評価軸の拡張:
- コードを書く技術に加え、事業・顧客・チームに貢献する多角的なコンピテンシーを評価する
■ 3. 職種を廃止した理由
- ソフトウェアを作る前提の変化:
- これまでの働き方やスキルが壊れていく前提でいないと、アウトカムにも事業にも本質的に近づけない
- 職能の境界が体験の切れ目:
- 得意領域だけを見る体制では、それぞれが正しく仕事をしてもプロダクト全体の体験に誰も責任を持てない
- リスナーはアプリとWebを区別して使っていないのに、組織図はそこで割れていた
- 専門性の非対称性の縮小:
- AIにより、触ったことがないから書けないだった領域が、調べながらなら書けるになった
- 専門で人を割る合理性そのものが弱くなっている
- 判断を固めた現場:
- Web側の手が空いているのにアプリ側がボトルネックになり、リリースが遅れる現場を目の当たりにした
- 専門性を守ることがプロダクトの価値提供を遅らせていると痛感した
■ 4. 職種廃止の半年後
- 専門領域外PRが55.5%:
- エンジニアの仕事の半分以上が、これまで自分の担当ではなかった領域になった
- 当初の不安:
- 自分の専門性が薄れるのではないか、全領域をキャッチアップできるのかという声があった
- 意識の転換:
- ペアプロとチーム内のナレッジ共有を徹底し、小さな越境体験を重ねた
- 全体を見て自分で解きにいける面白さへと意識が変わっていった
■ 5. AIが書きやすい形への作り替え
- 設計基準の追加:
- これはAIが書きやすいコードかという基準を、読みやすいか、テストしやすいかと同じ列に並べた
- 組織変更だけでは不十分:
- AIが書きにくいソフトウェアを持つ限り、組織をどう変えても速度は上がらない
- 境界が曖昧で暗黙の前提が多く、動かさないと壊れたか分からないコードは人間と同じ理由でAIにも難しい
- むしろAIのほうが、その難しさに正直である
- AIネイティブの定義:
- 境界がはっきりし、前提が言語化され、壊れたかどうかが自動で分かる状態
■ 6. バックエンド noah のAIネイティブ化
- 中心から着手:
- チャンネルや放送を作るコア機能と決済機能という、根幹かつ壊すと影響が大きい領域から手をつけた
- 安全なところから始める選択肢もあったが、周辺だけAIネイティブにしても意味がない
- 速度が必要なのは中心のほうである
- データベースの統一:
- 分散していたデータの持ち方を揃えた
- 地味な作業だが、AIに文脈を渡すコストという観点では効き方がまったく違った
- 構造が揃っているほど、AIは正しく書ける
■ 7. フロントと自動テスト基盤
- アーキテクチャの根本見直し:
- Webやモバイル側はアーキテクチャそのものを見直している
- Web側では自動テスト基盤の導入を完了させた
- ボトルネックの移動:
- AIが速くコードを書けるようになると、ボトルネックは書くから確かめるに移る
- 人間のレビューと手動確認が律速になれば、いくら生成が速くても意味がない
- 順番の重要性:
- テストが自動で回る状態を先に作らなければ、速度は品質と交換になってしまう
■ 8. 執行そのもののAI載せ替え
- 組み直しの方針:
- 既存の仕事をAIで改善するのではなく、Claude（MCPやSkill）を前提に執行そのものを組み直した
- 改善では不十分な理由:
- 改善では元の業務フローが残り、残った分だけAIネイティブになりきれない
■ 9. 社内業務AI基盤 ai-no-te
- 拡大の規模:
- 3ヶ月で450件以上の改善を重ねた
- 1.5ヶ月で47スキル・7プラグインまで広がった
- 全社への展開:
- PS（パーソナリティサクセス）チームの業務効率化として始まった
- Biz、コーポレート、プロダクト、PdMへと全社に展開した
- 広がり方の特徴:
- エンジニア組織が作ったものを配ったのではなく、現場が自分でスキルを書き足していった結果である
■ 10. QAからCREへの拡張
- 担当範囲の転換:
- QAチームはCRE（Customer Reliability Engineering）への転換を進めている
- リリース前の品質保証だけでなく、カスタマーサポートの一次対応までQAエンジニアが担う
- AIへの委譲:
- Zendeskとの連携を新設し、問い合わせの一次調査をAIに委譲した
- 役割の変化:
- 品質を守る人から、顧客からの信号を受け取ってプロダクトに返す人へ変わりつつある
- 効果:
- 不具合の検知からプロダクトへの反映までが同じチームの中で閉じる
- 顧客の声が仕様や修正に届くまでの距離が縮まり、信頼性の向上が滑らかにつながるようになった
■ 11. 現場主導で進んだ改革
- 3つの取り組みに共通する点:
- いずれも私が作ったものではない
- 方針は出したが、実際に組み立てたのは各チームである
- 最大の成果:
- 指示しなくても、各チームが自分の領域を自分でAIネイティブに作り替え始めた
- 職種を廃止して境界線を消したことと無関係ではない
■ 12. 開発速度の上昇と品質の維持
- PRマージ数の伸び:
- 1名1日あたりのPRマージ数は0.4件から3.6件へ伸び、10倍以上に跳ね上がった
- AIへの移譲を推進し、狙い通り圧倒的なアウトプット向上を実現できた
- 品質の推移:
- 直近半年の重大不具合数は過去からの推移と比較して減っている
- 減少要因は他にもあるが、AIによる速度向上が品質に大きく影響していない
- 両立できた理由:
- 執行のAI化とソフトウェアの改革に尽きる
- 生成を速くする前に、確かめる仕組みを作った
- 順番が逆だったら、まったく違う結果になっていた
■ 13. アウトプット最適化の位置づけ
- この半年の主題:
- 大きなアウトカムを生み出すための、アウトプット（開発基盤・組織・執行）の最大化と最適化
- 基盤を先に作る必要性:
- 事業戦略やプロダクト構想が優れていても、デリバリー能力が弱ければ検証の速度は上がらない
- まず開発速度を10倍にし、品質を維持できる基盤を作り切る必要があった
- 個別施策の意味:
- オンボーディング改善、導線整理、新機能追加はすべて巨大な開発マシンを完成させるための最適化ステップ
- 次フェーズの位置づけ:
- これまでの半年が武器を研ぐフェーズなら、これからは速度でプロダクトと事業の価値を跳躍させるフェーズ
■ 14. 今後の挑戦
- 局所最適から全体最適へ:
- 一部の画面や導線にとどまらず、リスナーとパーソナリティの体験そのものを根本から変革する施策に注力する
- ソフトウェアのリストラクチャリング継続:
- noahとモバイル、Webで始めた基盤刷新をさらに推し進める
- AIを使って迅速にアップデートを重ね、不具合の出ない高速度なアーキテクチャへの移行を完了させる
- 事業推進する工場の完成:
- ai-no-teによる社内業務のAI化をさらに一段引き上げる
- CSやプロダクト運用にAIハーネスとデータ基盤を完全に組み込む
- 人が事業価値の創出に100%集中できる環境を完成させる
- プロダクトの外への越境:
- エンジニアがプロダクト開発に閉じず、事業やサービスのコア領域まで染み出していく
- アウトカムに挑むとは、エンジニア自身が事業の成長ドライバーになることである