Classi開発者ブログ

教育プラットフォーム「Classi」を開発・運営するClassi株式会社の開発者ブログです。

チームトポロジーを参考に新組織の編成を考えた話

みなさん、こんにちは。開発本部で本部長をしている徹郎(id:tetsuro-ito)です。 Classiでは今年度より組織のあり方を少し見直し、チームトポロジーの考え方も導入してみたので、今回はその過程の話を紹介します。

Classiのこれまでの組織

Classiでは、2020年に起こしてしまったセキュリティインシデントおよび高負荷障害の対策を全社でとるべく、組織のあり方を変えていました。

7月からは、動作しているすべてのコードに対して、チームの責任範囲を明確にしました。また、技術的な課題をそれぞれのチームの責任において改善するような動き方にも変えました。やるべきことが明確(「再建プロジェクト」と「セキュリティ強化」が最優先)で、かつ、チームが主体となって意思決定する形にしたことで、現在は各チームが担当する機能やリポジトリをしっかりとメンテナンスしていく、そんな体制になってきたと思います。

Classiで発生した2つの問題を繰り返さないために我々が取り組んでいることより抜粋

過去の組織図

このようにClassiのプロダクトに対して、それぞれの機能を担うフィーチャーチームが組成され、それぞれのチームが持つコードやリポジトリの責務も明確にし、プロダクトの再建とセキュリティの強化に取り組んできました。

当時の組織変更はとてもうまくいき、それまでなかなか改善ができていなかったプロダクトの内部品質を向上させたり、古くなってしまったライブラリや言語のアップデートやEOL対応も主体的に進めました。 その甲斐もあり、1年後には当時大障害を起こしてしまうようなアクセスが来ても、プロダクトは止まることもなく、繁忙期のアクセスも捌けるような状態に改善しました。

徐々に顕在化した課題

しかし、個々の責務を明確にし、それぞれの主体性をもって問題解決にあたれるようになった結果、それぞれのチーム内の責務については順調に解決できる一方、チームをまたぐ問題や全社に共通するような大きな課題が徐々に顕在化するようになりました。

組織的な課題を解決した結果、ボトルネックが移動したと認識しており、着実に進んでいるという認識ではあったものの、一つ一つが大きな課題や問題のため、経営陣やマネジメントレイヤーはこの問題をどのように解決していくべきかを検討し始めました。

そんな折に、「チームトポロジー 」が出版されました。「はじめに」で引用されているコンウェイの法則の文言に魅了され、この考え方をベースにしながら新組織のあり方を検討していきました。

システムを設計する組織は、その構造をそっくりまねた構造の設計を生み出してしまう、というのが基本的な主張だ。この事実がシステム設計の管理において重要な意味を持つことがわかった。主要な発見は設計を行う組織を構造化するための基準である。コミュニケーションの必要性に応じた設計活動を行うべきなのだ。

個々のチームで扱いにくい大きな問題に対処できるような組織体制を構築し、これまでうまくいっていた部分を引き継ぎながら新たな組織の形を見出すことで、課題の解決を目指しました。

新たな組織体制

新たな組織体制

新たな組織として、4つのストリームアラインドな領域を定義しました。

  • 学習I(ラーニング)
  • 学習II(コーチング)
  • コミュニケーション
  • サービスオペレーション

学習I(ラーニング)

学習I(ラーニング)領域は生徒のラーニングサイクルを確立し、目標に向けて学ぶことをミッションとした領域です。Classiの機能では先生が生徒に向けてテストや宿題を配信するWebテスト、オンラインで自主的に問題に取り組むWebドリル、オンライン授業を視聴することのできる学習動画などの学習機能があり、それらを担当しています。 また、5月末にリリースしたAIを搭載した個別学習機能もこちらの領域が担っています。 https://corp.classi.jp/news/2710/

学習II(コーチング)

学習II(コーチング)領域は学習I(ラーニング)領域の表裏一体となり、先生が生徒と向き合いコーチングを行うサイクルを確立するためのミッションを持った領域です。 生徒が自分の学習時間などを記録する学習記録や、生徒一人一人の情報を確認することができる生徒カルテなどの機能があり、それらを担当しています。 こちらも今年度、学校内のClassiの利用状況が一元的に把握できるダッシュボード機能をリリースしています。

コミュニケーション

コミュニケーション領域はClassiのコミュニケーション機能全般を担っています。先生から生徒へ、先生から保護者へ連絡をすることができる校内グループや保護者から学校へ連絡ができる欠席連絡、他にもアンケートやコンテンツボックスといった機能も担当しています。 それぞれのユーザーや各機能をつなぐハブとして重要なミッションを持った領域です。

サービスオペレーション

サービスオペレーション領域はClassiを利用するにあたって根幹となる機能である設定登録やログイン/認証、連携サービスなどの機能を担当する領域です。ミッションとしてはClassiの利用開始から終了までの顧客体験に一本の筋を通すことを担っています。また、Classiではいくつかのネイティブアプリを運用していますが、それらの責務もこの領域が担っています。*1

これらのストリームアラインドチームを支えるためにプラットフォームチームとして、システムプラットフォーム領域を設定し、イネーブリングチームとしてはシステムイネーブリングチームを置いています。

Classiでは、この組織体制でそれぞれのラーニングサイクルとコーチングサイクルを確立させ、それらを有機的に紐づけていくことで、学校活動をつなげていくことをミッションとして活動しています。

ミッションのイメージ図

組織は作って終わりではありません。まずはこのように設計し、走り出しましたが、その時の最善が今後も最善であり続ける保証はありません。チームトポロジーでは冒頭で下記のようにチームを説明しています。

組織は単に自律的なチームを求めるだけでは不十分で、顧客に素早く価値を届けるためにチームのことを考え、チームを進化させなければいけないのだ

私たちも、この教えに従い、顧客に素早く価値を届けられる組織として継続的に進化していけるようにしていきたいと思っています。

*1:サービスオペレーション領域は責務分割が完全ではなく、現在の組織を運用しながらもう一歩踏み込んだ責務分割を検討していく予定です。

© 2020 Classi Corp.