過去の重大な問題の反省と組織改革
Classiは、2020年4月から5月にかけて、セキュリティインシデントと大規模なアクセス障害という2つの重大な問題を引き起こした。EdTechサービスを提供する同社にとって、コロナ禍で急増したオンライン教育需要への対応は必定。堅牢なインフラとセキュリティを打ち立てるべく、セキュリティ体制や開発フローの抜本的な見直しが始まった。
鈴木氏は当時を振り返り、こう語る。「メンバー一人ひとりが力を発揮したことで、組織やプロセスの変革は一定の成果を上げ、現在のClassiはコロナ禍を超えるトラフィックにも対応できるようになった。言語やミドルウェア、フレームワークの継続的なアップグレードが組織に浸透し、システムアラート対応の負担が特定のメンバーに集中するという、よくある開発組織の課題も解消された」。きっかけこそネガティブであったものの、サービス信頼性と運用水準は確実に向上したのだ。
一方で、インシデント後の2年間、ビジネス面では停滞が続いた。事業の成長は止まり、顧客の解約も相次いだ。売り上げに関わるプレッシャーを受け続けるなかで、営業組織も疲弊。「この状態が続けば、事業は立ち行かなくなる」…そんな危機感に直面したClassiは、「マイナスをゼロに戻す仕事」から「ゼロをプラスにする仕事」へシフトさせる決断をした。
まずは各機能を整理し、「領域」と呼ばれる責任単位を定義。その上で、各領域にプロダクトマネージャー（PdM）をアサインし、プロダクト開発を進める体制に変更した。各PdMには、意思決定の補佐役としてエンジニアリーダーを配置。一見、合理的な体制だが、実のところは「うまく機能しなかった」。間を置かずして鈴木氏のもとに、職能を問わず、さまざまなメンバーが相談しにくるようになったのだ。
寄せられた相談を分析した鈴木氏は、相談の種類は大きく2つに分けられると気付いた。「人が足りない」と、「優先順位がつけられない」の2つだ。
このうち「人が足りない」背景には、チームが生産能力を大きく上回る計画を立ててしまっている問題が隠れていた。チームが無理な計画を立て、実現可能性の検証が不充分なままにプロジェクトが進められていたのだ。また、サービス運用ではトラブルや問い合わせなどの想定外の事象が頻発するが、それも計画に反映されていなかった。そのうえ無理がある計画に、チームメンバーが誰もストップをかけられない状況に陥っていた。
一方で「優先順位がつけられない」には、チーム間の意思決定の競合が解決できないという課題が潜んでいた。同社のシステムは分断されたモノリス構造だったため、機能の相互依存が多く、チームをまたがるタスクも頻発していた。その結果、目標のコンフリクトやコミュニケーションのトラブルが発生していたが、自分たちでは解決できず、鈴木氏のもとに駆け込む流れだった。
「意思決定の競合は、マトリクス型組織にはよくあるトラブルだ」と鈴木氏は話す。マトリクス型組織は本来、製品・市場への適合と機能統合によるメリットの両方を盛り込むことを目的とする。しかし、大きな意思決定が必要な場面では、製品・市場の要求と機能部門の要求がコンフリクトしてしまうリスクもある。
当時のClassiは、職能組織（エンジニアや営業など）と機能組織（製品開発チーム）が並存するマトリクス型組織であった。そして多分に漏れず、コンフリクトに悩まされた。その結果、「決めてください」という相談が舞い込む状況に至ったのだ。
