セキュリティインシデントと大規模障害を経て組織改革、オーナーシップとプロダクトマネジメントの未来

【24-C-7】オーナーシップは誰のものか プロダクトマネージャーに頼らないプロダクトマネジメントへの挑戦

　プロダクト開発の現場では、プロダクトマネージャーがオーナーシップを発揮し、組織の運営や課題解決に当たるのが一般的だ。しかし、時には意思決定や責任をマネージャーひとりに依存せず、チームメンバー全員がオーナーシップを持って取り組むアプローチが有効なこともある。本セッションでは、セキュリティインシデントと大規模障害を経験したClassi株式会社のプロダクト本部 副本部長であり、プログラマーの鈴木 雄大氏が登壇。抜本的な組織改革の中で直面した課題や試行錯誤を通じて、プロダクトマネジメントにおける個々のオーナーシップの重要性について語った。

過去の重大な問題の反省と組織改革

　Classiは、2020年4月から5月にかけて、セキュリティインシデントと大規模なアクセス障害という2つの重大な問題を引き起こした。EdTechサービスを提供する同社にとって、コロナ禍で急増したオンライン教育需要への対応は必定。堅牢なインフラとセキュリティを打ち立てるべく、セキュリティ体制や開発フローの抜本的な見直しが始まった。

　鈴木氏は当時を振り返り、こう語る。「メンバー一人ひとりが力を発揮したことで、組織やプロセスの変革は一定の成果を上げ、現在のClassiはコロナ禍を超えるトラフィックにも対応できるようになった。言語やミドルウェア、フレームワークの継続的なアップグレードが組織に浸透し、システムアラート対応の負担が特定のメンバーに集中するという、よくある開発組織の課題も解消された」。きっかけこそネガティブであったものの、サービス信頼性と運用水準は確実に向上したのだ。

　一方で、インシデント後の2年間、ビジネス面では停滞が続いた。事業の成長は止まり、顧客の解約も相次いだ。売り上げに関わるプレッシャーを受け続けるなかで、営業組織も疲弊。「この状態が続けば、事業は立ち行かなくなる」…そんな危機感に直面したClassiは、「マイナスをゼロに戻す仕事」から「ゼロをプラスにする仕事」へシフトさせる決断をした。

Classi株式会社 プロダクト本部 副本部長 鈴木 雄大氏

　まずは各機能を整理し、「領域」と呼ばれる責任単位を定義。その上で、各領域にプロダクトマネージャー（PdM）をアサインし、プロダクト開発を進める体制に変更した。各PdMには、意思決定の補佐役としてエンジニアリーダーを配置。一見、合理的な体制だが、実のところは「うまく機能しなかった」。間を置かずして鈴木氏のもとに、職能を問わず、さまざまなメンバーが相談しにくるようになったのだ。

　寄せられた相談を分析した鈴木氏は、相談の種類は大きく2つに分けられると気付いた。「人が足りない」と、「優先順位がつけられない」の2つだ。

　このうち「人が足りない」背景には、チームが生産能力を大きく上回る計画を立ててしまっている問題が隠れていた。チームが無理な計画を立て、実現可能性の検証が不充分なままにプロジェクトが進められていたのだ。また、サービス運用ではトラブルや問い合わせなどの想定外の事象が頻発するが、それも計画に反映されていなかった。そのうえ無理がある計画に、チームメンバーが誰もストップをかけられない状況に陥っていた。

　一方で「優先順位がつけられない」には、チーム間の意思決定の競合が解決できないという課題が潜んでいた。同社のシステムは分断されたモノリス構造だったため、機能の相互依存が多く、チームをまたがるタスクも頻発していた。その結果、目標のコンフリクトやコミュニケーションのトラブルが発生していたが、自分たちでは解決できず、鈴木氏のもとに駆け込む流れだった。

　「意思決定の競合は、マトリクス型組織にはよくあるトラブルだ」と鈴木氏は話す。マトリクス型組織は本来、製品・市場への適合と機能統合によるメリットの両方を盛り込むことを目的とする。しかし、大きな意思決定が必要な場面では、製品・市場の要求と機能部門の要求がコンフリクトしてしまうリスクもある。

　当時のClassiは、職能組織（エンジニアや営業など）と機能組織（製品開発チーム）が並存するマトリクス型組織であった。そして多分に漏れず、コンフリクトに悩まされた。その結果、「決めてください」という相談が舞い込む状況に至ったのだ。

当時の組織図