Classi開発者ブログ

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

セキュリティインシデントと大規模障害を経てClassiは開発組織をどう変化させたのか

こんにちは、元テックリード、この10月からVPoT(Vice President of Technology)に就任した、Classiの丸山(id:nkgt_chkonk)です。

前回の記事では、前CTO(現VPoE=Vice President of Engineer)の佐々木が「Classiで発生した2つの問題を繰り返さないために我々が取り組んでいること」というタイトルで、社内体制を変更したことをお伝えしました。

今回はわたしから、組織体制の変更の背景や、現在どのような体制で、どのような課題に取り組んでいるのかをさらに詳しくお伝えしたいと思います。

4月~5月にかけての2つの問題の原因となった「甘え」

前回の記事でお伝えしたとおり、2020年の4月〜5月にかけて、Classiは外部の攻撃者による不正アクセスおよびデータの漏洩という大きなセキュリティインシデントと、アクセス増による大規模なアクセス障害を起こしてしまいました。その根本的な原因は、長い間取り組むべき課題の優先順位を間違えてしまっていたというひとことに尽きると思っています。

なお、セキュリティインシデントの直接の原因については、すでに対策を講じており、外部のコンサルタントの協力を得て、さらなる改善を継続的に行っております。この記事では、遠因となった組織体制の問題について述べたいと思います。

アクセス障害の背景として、Classiは学校が導入し、年間を通じて使っていただくサービスであるという特性上、突発的にユーザー数が大きく増減することのないサービスでした。そのため、たとえば、他のコンシューマアプリなどのように、テレビで紹介されていきなりアクセスがスパイクする、というような急激なアクセス増加の蓋然性は低い、という「甘え」が、技術上の意思決定層に存在していました。実際には、今回の新型コロナウイルス感染拡大に伴う学校一斉休校のように、社会の状況が変われば、サービスの使われ方は変わり、負荷のかかり方も大きく変わることが生じてしまったわけです。

さらに、今となって問題を振り返ってみると、当時から「もっと既存のサービスを改善していくべきだ」「もっと投資のバランスを検討したほうがいいのでは」という声が、社内の開発現場からしっかりと上がっていたにも関わらず、きちんと現場の課題を見極めることができず、先延ばしの意思決定してしまっていたことに対して、後悔の気持ちでいっぱいです。

CTOの果たすべき役割の変化を認識できなかったという反省

なぜこのような状況を生み出してしまったのかを改めて考えたとき、わたしたちは「サービスのフェーズが変わって、それに応じて意思決定のあり方も変化していかなければならなかったのに、変化できていなかった」ということに気づきました。

佐々木のCTO就任当時は、ふたつの大きな課題が存在していました。ひとつは「学校 x ICT」というのは今と比べても未知なことが多く、学校現場に求められているサービスがどんなものなのかまったくわからないし、それを理解しにいくための足がかりすらない中でサービスを作らなければならなかったこと。もうひとつは、サービス開発のノウハウが社内にほとんどない中で、手探りでサービス開発を進めなければならないこと。

このふたつの課題に対して必要となるCTOの役割は、強い推進力であったと思います。なにがなんでもサービスを形にして、まずは協力してくださる学校に使ってみてもらうこと。ゼロからはじめて、オーナーシップを持って意思決定して、やり遂げる力こそが、CTOに求められる役割でした。その中で、佐々木は替えの効かない役割を果たしてくれたし、その結果として、多くの生徒、先生、保護者のみなさまにサービスを届けられるようになったことを、わたしは(あとから入ったメンバーではありますが)誇りに思っています。

しかし、サービスの拡大にともない、開発に関わるメンバーが増えるに応じて、CTOが本来担うべき役割は、わたしたちが気づかないうちに変化していました。多くの機能が存在するサービスに対して、一人ですべての意思決定を行うことはできませんし、技術的な課題に対しても目が届かなくなっていきます。本来であれば、サービスの拡大に伴い、開発現場の課題をよくわかっているメンバーに意思決定を移譲していかなければならなかったところ、オーナーシップを持って意思決定してやり遂げる役割のまま、CTOに意思決定が集中するという状況を生み出してしまいました。どのような課題に取り組むか? そのために誰になにをやってもらうか? そのために必要な人材の採用・育成は? という全てをCTOが決定する形になっていたわけです。

その構造が、開発現場から「これはまずい」という声が出ているにも関わらずそれを吸い上げきれない、という状況を生み出してしまったし、アクセス障害などの緊急時に意思決定のボトルネックとなってしまったと感じています。

意思決定をプロダクトチームへ移譲

以上のような反省のもと、最初は全ての機能、すべてのコードに対して、どのプロダクトチームが責任を持つかを決めることから体制の再構築をはじめました。その上で、各チームにチーム責任者と、テックリードという役割を置きました。

チーム責任者は、一般的にプロダクトオーナーと呼ばれる存在に近く、自分のチームの責任範囲にあるサービスで取り組むべき課題の優先順位を決定する責務を負います。

テックリードは、技術的な「やばいところ」に目を光らせ、チーム責任者に対して技術的な課題の優先順位を提案します。今までは、テックリードは全体を見る役割でわたしひとりだったのですが、今回テックリードの役割を再定義し、それぞれのチームの中の技術に責任を持つように変更した形です。

また、各チームが抱えている課題を解決するために必要な開発プロセスの改善や、採用戦略についても、プロダクトチームが一人称で動いていけるように、権限の移譲を進めています。

そのような体制を作っていきながら、何度も現場のメンバーに今なにに困っているかや、最近よかったことをヒアリングをしました。その結果、現体制の良い点として、ようやく技術的にもサービス的にもプロダクトを改善するために力を使えるようになったという声を聞くことができ、この点に関しては一定の成功を収めていると言えそうでした。

一方、「チームの中で技術的な決定をしていくことに不安がある」「プロダクト改善をはじめた結果、別のところに組織的なボトルネックを感じはじめている」「プロダクトチーム内で意思決定するとはいえ、会社としての意思決定の軸がなくて困っている」「このプロダクトの価値を判断するための会社としての指針が欲しい」というような声も上がってきました。その他にも、「自分の伸ばしたいことと今やっていることに乖離がある」「仕事の仕方を相談できる相手がいない」などの、仕事のしやすさや働き方についての問題点を指摘する声も聞こえてきました。

責務を見直してVPoTとVPoEによるスケーラブルな体制を構築

ちょうどその頃、佐々木と丸山を中心に「CTOの役割の再定義が必要」という課題に取り組んでいたこともあり、「こういう、プロダクトチームの内部だけでは解決できない問題に対して、解決となる構造を与えるのが、現在のClassiに求められるCTOの役割ではないか」という議論を進めていきました。その結果として、

技術的な視点として:

  • 各プロダクトチーム間にトレードオフが生じるときに、そのトレードオフをどこに落とし込むのかを決める意思決定の役割
  • テックリードが迷った時の駆け込み先
  • Classi全体の技術的アセットを健全に保つ仕組みづくり

というような役割を、

また、メンバーマネジメントの視点として:

  • CTOや部長が少ない人数で全体を見るのではなく、各メンバーに対してエンジニアメンターを置き、さまざまな悩みに対して最初の相談先を明確にする
  • そのエンジニアメンターが拾い上げた相談ごとのうち、組織として対応が必要なものを解決する仕組みや構造を作る役割
  • エンジニアが成長し、キャリアを積んでいける仕組みづくり

というような役割を、今のClassiのCTOは果たすべきではないか、と仮定しました。

この仮定をもとに佐々木と協議したところ、ふたりは得意分野が異なり、わたしはメンバーマネジメントが得意ではないけれど、技術的な視点では役にたてるところがあると感じていること、一方で佐々木は、メンバーマネジメントの分野で多くの現場メンバーから期待されていることが見えてきました。

そこで、今のClassiでは、CTOの役割を

  • 技術を見るVPoT
  • 人を見るVPoE

に分割した上で、VPoTを丸山、VPoEが佐々木が担う体制を作り上げました。

この体制の運用は始まったばかりで、まだ何がうまくいって何がうまくいかないかは十分には見えてきていません。VPoTとVPoEにはこういう役割が必要なのではないか、と立てた仮説も、まだ十分に検証されてはいません。一方で、この方向に改善を進めていくこと自体に間違いはないという手応えも得つつあります。

ClassiのMissionである「子供の無限の可能性を解き放ち、学びの形を進化させる」を実現するために、仮説を立てて終わりではなく、それで本当に子供の無限の可能性を解き放ち、学びの形を進化させるためのプロダクト作りに寄与できているのか? ユーザーのみなさまの学びの機会を奪ってしまうような失態を繰り返さないための構造を作れているのか? ということを定期的に問い直し、前向きに組織の改善を続けていきたいと思っています。

終わりに

Classiは、大きな失敗により、多くの先生・生徒・保護者のみなさまに多大なるご心配と迷惑をおかけし、多くの信頼を失ってしまったと思います。しかしながら、当社のメンバーは「子供の無限の可能性を解き放ち、学びの形を進化させたい」と本気で強く思っており、この思いの強さには自信があります。このMissionに向かっていくためには、一つひとつ、いまある課題を解決していく必要があると思っています。わたし自身、新しいポジションについたばかりで、毎日失敗を繰り返しながら、すこしずつ学びながら課題に向き合っています。

そして、これらの課題に取り組み続けるためには、今後も多くの力がClassiには必要になってきます。そのため、今、Classiでは、この大きなチャレンジに力を貸してくれるエンジニアを、積極的に募集しています。決して天国のように整った環境ではなく、むしろたくさんの成長痛をともなうような現場ではありますが、手強く解きがいのある課題が盛りだくさんで、自分が手を動かせば動かしただけ課題を解決できる、力を振るいたいエンジニアにとってはその力を存分に発揮できる現場ですし、「天然物」の課題に取り組む中で大きく成長できる現場だと思っています。

Missionに共感していただけて、腕に自信のあるエンジニアはぜひ、採用情報からご一報いただけるとうれしいです。一緒に課題を解決していきたいです。

© 2020 Classi Corp.