はじめに
こんにちは。学習トレーニングチーム（以下、学トレチーム）でソフトウェアエンジニアをしている工藤 ( id:irisuinwl ) です。最近のマイブームはウイスキーを飲むことと氷作りです。
自分は2023年までアダプティブラーニングチーム(以下、ALチーム)のリーダーをしていました。
現在ではALチームを再編し、学習トレーニングチームでソフトウェアエンジニアをしております。
新しくなった学習トレーニングチーム発足から1年半ほど経ち、いくつものリリースを通じて、チームとして上手く機能できています。
この記事では、自分がどのようにチーム再編を意思決定し、メンバー全員がチームで活躍できるようにどう取り組んだか、新チームとして上手く機能するために何をしてきたかを書きます。
チームの背景とチーム再編の結果
Classiの組織ではプロダクト本部内の学習PMF部にWebディレクター、ソフトウェアエンジニアをはじめとした様々な職能が集まり、システム群全体のプロダクトマネジメントを実行しています。
ALチームとは、ソフトウェアエンジニアによる Classiのアダプティブラーニングエンジン (以下 CALE) を提供するシステム開発と、データサイエンティストによる学習トレーニングにおけるコンテンツ関連のデータ分析と研究開発を行うチームでした。
しかし、一つのチームに異なる複数の役割があることが煩雑であること、また、学習トレーニング開発チームとは独立してCALEのみを作っているだけでは学習体験全体の最適化は難しいと感じ、チーム編成を変える決断をしました。
そして、ALチームのソフトウェアエンジニアはストリームアラインドチーム1 である学習トレーニング開発チームに異動しました。元々CALEが学習トレーニングのサブコンポーネントであったこともあり、以前より朝会に同席したり、一部共同での開発をしていたため、問題なく合流できました。
データサイエンティストはDSチームとして独立し、部全体、コンテンツチーム、学習トレーニング開発チームと連携するイネーブリングチーム2として新設しました。
最終的にはプロダクトのデータ分析に注力をするのが良いと考えて、データサイエンティストも学習トレーニングチームへと合流しました。
チーム異動の結果として、
- データサイエンティストは、役割が明確になることでコンテンツ分析だけでなく、学習プロダクト全体の分析に力を入れることができ、プロダクトKPIの策定、部署全体の意思決定に介入できるようになりました。
- 新学トレチームのソフトウェアエンジニアは、新しくなったチームの目指すべきところを決め、リリースした施策ごとの効果からインパクトの高い施策を実施する状態を作ることができました。
新しい学トレチームになって実施したこと
チームが新しくなり、元ALチームのソフトウェアエンジニア・データサイエンティスト、それまで学トレ開発を担っていたソフトウェアエンジニアを含めた新旧メンバーが、齟齬なくチームとして機能するために実施したことを紹介していきます。
チームビルディングを行う
チームが新しくなった際、新旧の異なる職種のメンバー間で、ビジョン・ミッション、前提知識、コンテキストの認識に差がありました。
そこで、それらの異なる前提を揃えて「学習トレーニングチームが何を目指すのか」、「何に注力していくのか」を明らかにするための チームビルディング を行いました。
チームビルディングと一言でいっても様々なものがあります。
たとえば、ドラッカー風エクササイズやチームラーニングなどが有名なものです。
しかし、チームビルディングにおいて重要なことは、チームの形成状態や抱えている課題認識から適切な会を設定する、つまり、チームビルディングの目的を明確にした会の設計をすることです。
今回の新学トレチームでは、新旧メンバーでコンテキストが異なること、複数の職能によるチームで関心が異なることから、 シンプルなWhy（チームがなぜ存在し、何をするのか）を問いかける のが良いだろうと考えました。
そして、以下のアジェンダでチームビルディングを設定しました。
◆今日の目的 ・我々学トレチームは、なぜ存在しているのか？（Why) を定め、個人の役割や成果がチームの目的達成のために貢献していることを感じられる組織になるための目線合わせをすること ◆背景 ・FY24下期からALチームの工藤さん、〇〇さんがジョイン、チーム責任者も〇〇さんにバトンタッチと体制変更 ・[Webox](https://get.wevox.io/) による組織サーベイの結果から、学トレチームは「健康」「環境」は良いが、「役割」「成長」の観点が低めで、エンゲージメントは高いとは言えない状態 ◆本日のアジェンダ ・⓪ 前提情報の確認 ・① 学トレチームは、チームのWhy（＝ミッション）を言語化して定めよう！ ・② 定めたミッションに対して、自分は「これで貢献するぞ！」を宣言してみよう！ ・③ それを実現するにあたり、issueとなっているものが何かを洗い出してみよう！ ・④ issueに対してのhowは、朝会などでみんなで知恵を出し合って解決していこう！
チームビルディングの結果として
- チームの向くべき方向として 「生徒・先生・学校すべてのユーザーの価値につながる、KPIに寄与するプロダクト開発をしていく」 というWhyを目線合わせすることができました
- チームが持っている Issue として 「計画した大きいリリースへのリソースが集中しており、様々な開発要望に対して集中すべき優先付けした対応ができていなかった」 という課題を抱えていることを明らかにしました。
既存の技術スタックや開発プロセスを理解する
学習トレーニングはフロントエンドにAngular、 バックエンドにRuby on Railsを使っています。
特に自分（工藤）はこれらの技術スタックでの開発に慣れていなかったので、ある程度習得が必要で、また新しいチームとなったうえで既にある開発プロセスを理解する必要もありました。
技術もプロセスも理解するのであれば、何はともあれ「リリースする」ことがキャッチアップへの近道だと思い、新しいメンバーで何らかの機能リリースを行うことを目指しました。
その際、新しいメンバーでも迷うことなく1〜2週間ほどでリリースができる粒度のタスクを選定し、自らコードベースを読み、プロダクトバックログを見つつ、既存のチームメンバーに相談していきました。
実作業をするうえでも ワーキングアウトラウド をしながら困った部分はslackでメンバーに相談することで、問題なく1週間ほどでリリースすることが出来ました。
チームの信頼を獲得する
チームにいきなり所属しても一朝一夕で信頼を得ることは難しいです。
そこで、それぞれのチームメンバーと相互に理解しあい、信頼関係を得るため 1on1 をしました。
単に1on1と言っても闇雲に雑談をしても効果は薄いので、チームや個人の状況に合わせた 1on1の目的 を設計 して1on1に臨みました。
たとえば、相互理解、メンバーから見たチームや組織の課題は何なのか、メンバーのwillと現状のギャップ、働くうえでの障壁はあるか、チームのいいところ・悪いところ、といった1on1の目的とそれに合わせた問いを事前に設定します。
新しいチームとなった最初のうちは、 相互理解 と チームのそれまでの課題と理想 というチームビルディングの延長をメンバーレベルで話し合うことを1on1のテーマとして選んで会話をしていきました。
新しい学トレチームでどんな成果を残したか
これらのチーム形成を通じて、新学トレチームは1年ほど経ち、無事開発チームとして様々なリリースをすることが出来ております。最近では、大きな機能として以下の機能をリリースすることができました。
また、当初の課題であった「大きめのリリースへのリソース集中」の解消だけでなく、VoC （Voice of Customer）によるリリースや目に見えるカイゼン活動も出来始めております。
そして、チームビルディングでWhyとして掲げたKPIについても、1学期では目標から130%を超える規模で目標達成することができました。
また、学習トレーニングの週次利用は昨年と比べて、ピーク時において150%以上の増加をしており、
（学トレチームの力だけではなく学習PMF部全体の尽力の結果ではありますが）
ユーザーに価値を還元できるプロダクト開発チームになっていると考えています。
まとめ
最後のまとめとして、新チームの発足と編成において実施してきたこと、その成果は以下になります。
それまで存在したALチームを解散して新学トレチームを組成しました。
- アダプティブラーニング機能を作り続けるだけではなく、学習体験全体をデザインする必要があるため、エンジニアチームの合流を意思決定しました。
新しいチームが機能するための施策を実施しました。
- チーム状況に適合したチームビルディングでチームのWhyとIssueを明らかにしました。
- 既存の技術スタックや開発プロセスの理解のためのリリースとワーキングアウトラウドを意識しました。
- チームの信頼獲得のための1on1とその設計をしました。
結果として、
- 大きなリリースと細かなカイゼンの両軸を開発できるチームとなりました。
- KPIも目標を上回って達成し、利用も大幅に増加（ピーク時で150%以上）することができました。
新学トレチームは成果を出していけるチームになることができましたが、今後は引き続き学習機能の改善を進めていきながら、別の機能チームとコラボレーションをしていき、Classi全体で良いサービスを作っていこうと思ってます。
- チームトポロジーによるチーム形態の一つ。ビジネスドメインのストリームに沿ったチーム。https://teamtopologies.com/key-concepts↩
- チームトポロジーによるチーム形態の一つ。他のチームの障壁や新しい能力開発を支援するチーム。https://teamtopologies.com/key-concepts↩
