📘
学習体験エリアのプロジェクトの進め方

tsumura
2024/09/20に公開
プロジェクトマネジメント
アジャイル
tech
はじめましてatama plusの津村です。
今回はatama＋のプロダクト組織での取り組みについて紹介しようと思います
atama plusでは、プロダクト組織を３つに分けています。

オンライン塾を主に担当しているオンライン塾エリア、フランチャイズ展開を行なっているatama＋塾や各塾AI教材「atama＋」をSaaSで導入している各塾などのオフライン塾を主に担当しているオフライン塾エリア、そして学習体験を提供することを主な責務としている Learning Lab(LL)エリアです。

今日は私が所属しているLLエリアにおける業務の進め方の一つとしてプロジェクト方式を取り入れていることについて紹介します。
この記事を通じて、私たちの業務の進め方やチームの働き方が少しでもお伝えできればと思います。

 Learning Lab(LL)エリアの紹介まずはLLエリアについて簡単に説明します。LLエリアは、質の高い学習体験をオンライン塾エリア・オフライン塾エリアに提供することを主な責務としています。
プロダクト組織のエリア構成



（3分でわかるatama plusのエンジニア/about atama plus engineerより抜粋）
このエリアでは以下の４つのチームが協力して業務を進めています。
コンテンツチーム
質の良い講義動画や演習問題などの学習コンテンツの製作を責務とする
コンテンツ製作はコンテンツチームのメンバーが行う場合や提携している先生に依頼したり、外部の編集プロダクションに依頼することもある
コンテンツ製作の進捗管理や製作されたコンテンツの品質管理を確認などを行う


Algoチーム
ユーザーの学習状況に最適なコンテンツの提供を責務とする
AI 教材「atama＋」の学習エンジンの開発を行い、過去の学習データや提供したい学習体験を元にユーザーに最適な問題を提供できるようにする


Appチーム
ユーザーの学習体験を提供することを責務とする
AI 教材「atama＋」の開発や講師向けの「atama＋ COACH」、教室長向けの「atama＋ PORTAL」の開発を行い、ユーザーに最適な学習体験を提供する


Content Dev チーム
コンテンツチームが制作したコンテンツをプロダクトが利用できるように提供することに責務を持つ
コンテンツチームの円滑なコンテンツ制作もコンテンツ提供の改善として責務を持つ



各チームの担当領域の模式図

 学習体験の分類LLエリアで扱っている学習体験ですが、ここから学習体験に「狭義の学習体験」と「広義の学習体験」という考え方を取り入れます。


狭義・広義の学習体験の概念図と例

 狭義の学習体験狭義の学習体験は、短期間の学習プロセスを指し、一つの単元の学習や一回の講義の受講、一問の演習問題への挑戦（問題を読んで解答して解説を読む）などが該当します。 狭義の学習体験の特徴としては、変更を最終ユーザー（生徒や講師など）へ広く提供し、その反応を見て次のアプローチを考えるアジャイルな開発が可能な点です。場合によっては AB テストも行うことができます。
これは以下の点が要因として挙げられます
提供までに関わる人が少ない
主に生徒とシステムだけで完結するため、提供に際して関わる人が少ない
そのため、必要な準備・生成物が少なくて済み、提供が早くできる

開発・制作体制が整っている
機能提供対象であるユーザーの制御や提供コンテンツの制御が行えるフィーチャーフラグの仕組みを整えているため、小さく提供することができる
CI/CD が整備されているので、ソースコードの編集やコンテンツの追加・変更だけでユーザーへの提供が可能

アプローチ対象が小さい
学習体験期間が短く評価のための指標が明確にしやすい
ユーザーの実行頻度が高いものを対象にすることが多いためデータが集まりやすい

狭義の学習体験の具体的な例としては、「高校理科・社会での合格ロジックの変更」や「高校英語における単元構成の変更」などがあります。

 広義の学習体験広義の学習体験は、講義や演習を繰り返して行う長期的な学習プロセスが該当します。 多くの場合、生徒-システム間の関わりだけでなく、例えば塾を経由している場合だと、生徒-講師・教室長間、講師・教室長-システム間の関わりも含まれます。 広義の学習体験の特徴としては一つの変更の影響が大きく、提供後に反応を見て次のアプローチを考えて再度アプローチするという開発を短いサイクルで行うことが難しいことです。
これは以下の観点が要因として挙げられます
提供に関わる人が多い
エリアによるが提供する体験が生徒-システム間に閉じないため大勢が関わり、最終ユーザーへの提供までに必要な準備・生成物が膨大になる
オンライン塾では広告を出す広報や、生徒保護者とのコミュニケーションを検討し浸透させる必要があったり、生徒と接するスタティトレーナーの研修への組み込みが必要になることもある
オフライン塾では講師/教室長のオペレーションを検討したり、各塾の提供方法に組み込める形にする必要がある
一度浸透させた決定を修正する場合もその修正を浸透させる必要がある

そのため、LLだけでなく、オンライン塾エリア・オフライン塾エリアのメンバーもプロジェクトに参画することが多い

開発・製作量が膨大
関わりが増えるため、生徒が利用する AI 教材「atama＋」の開発だけでなく、講師向けの「atama＋ COACH」や教室長向けの「atama＋ PORTAL」の機能の開発が必要になり、狭義の学習体験を対象とした場合よりも開発量が増加する
長期間の学習に必要なコンテンツ量や幅広い生徒像を対象としたコンテンツを製作する必要があるため、狭義の学習体験を対象とした場合よりも製作量が増える

アプローチできる頻度が少ないため一度アプローチした後に次のアプローチまでに時間が空いてしまう
例えば、講習期は年に最大３回（「夏期講習」「冬季講習」とすると年に１回）、受験期は年に１回、定期テストは年に最大６回（「１学期中間テスト」などとすると年に１回）など

広義の学習体験の具体例としては、「小学生・中学生向け国語教科の追加」や「中学生向け講習期教科の追加」などがあります。

 広義の学習体験へのアプローチをプロジェクトとして進める広義の学習体験では一回のアプローチを行うために長期かつ大量の準備が必要であり、 そのアプローチを良いものにするため「プロジェクト」として進めることが重要だと考えています。
ここから LL エリアでのプロジェクトの進め方を紹介します。 LL エリアではプロジェクトを以下の４つのフェーズに分けて進めています。
立ち上げ
進行中
終了
完了


プロジェクトの各フェーズと概要

 プロジェクト立ち上げこのフェーズの目的
異なる目的・バックグラウンドを持つ複数のチームを一つの大きなプロジェクトチームとして機能させる
場合によってはLL エリア内だけでなく他エリアのチームを含めることもある

プロジェクトを進行させるリズムを作成する
明確なフェーズの定義はありませんが、プロジェクトのキックオフ前からプロジェクト内の定例会議の初回あたりまでがこのフェーズになります。
このフェーズで行う主なことは以下の通りです
プロジェクトの目的の文書化
プロジェクトのスケジュールの原案の作成・共有
プロジェクト体制の明確化
プロジェクトメンバーの責務の明確化
プロジェクト内の定例会議の設定
プロジェクト外との会議の設定（必要に応じて定例化する）
プロジェクトキックオフの実施

 プロジェクト進行中このフェーズの目的
各チームがそれぞれのタスクに集中しつつ、お互いに協力しあえるような環境を作る
不測の事態を早期に発見し対処する
プロジェクト立ち上げ以降から計画してた体験をプロダクション環境に提供開始するまでがこのフェーズになります。
このフェーズでは以下のような活動を行います
エリア内外に提供予定の体験を共有し、改善点や受け入れ可能かなどのフィードバックを受ける
LL プロジェクト進捗レビュー会でプロジェクトの目的や進捗を共有・確認し、フィードバックを受ける
LL 内で横断のスプリントレビュー・スプリントレトロ・スプリントプランニングを実施する
プロジェクト内外で問題が発生したら検知し、必要な対処を実施する
プロジェクト外の変化を検知し対応する
提供予定の体験を社内で体験会を行い、フィードバックを受けて改善を行う
プロジェクト終盤ではプロジェクトの終了フェーズに移行するための準備を行う
上記であげたような活動を行う中で大切なことは以下だと考えています。
プロジェクト外の変化へアンテナを張り変化へ対応すること
プロジェクトが長期になるとプロジェクト外の状況が大きく変わることがあるためプロジェクト内だけでなく、プロジェクト外にも注意しておく
例えば、プロジェクト開始時には存在していなかった事業領域がプロジェクト進行中に追加されたため連携先を増やす、といったこともあった

プロジェクト内外からのフィードバックを受けアジリティ高く対応すること
各エリアへ体験を共有したり、社内体験会などを実施しフィードバックを受けそれらに素早く対応する


 プロジェクトのアジリティを高めるこのようにプロジェクト型とはいえ事前に決められたことだけを行うわけではなくアジリティが求められます。そのため狭義の学習体験の提供で利用した開発・制作体制はそのまま活用しつつ、以下のような対応をしています。
LL内における開発・制作はスクラム開発をベースとして一部変更する（例えば、スプリントレビューは全エリアのステークホルダーを同時に集めるのは関心がそれぞれで異なる上に時間を合わせるのが現実的ではないため、エリアごとに参加者を絞って複数回実施するようにした）
開発した機能はフィーチャーフラグなどを活用し、最終ユーザーへは本番リリースせずに提供しないが本番環境へは取り込む
コンテンツ制作はユーザーとって最小限提供して意味のある単位に分割して制作とリリースを繰り返す（例えば、一年分をまとめてつくるのではなく、一学期中に学習できる分をまず作り、二学期・三学期はそれ以降に作る）
このような対応を行うことでプロジェクトのアジリティを上げています。

 プロジェクト終了プロジェクトの終了フェーズでは基本的にプロジェクトチームは集まって活動することがなくなり、 プロジェクトの活動を行うとしても基本的には単発で行いプロジェクトチームメンバー同士が協働することは少なくなります。そのためこのフェーズの目的は、プロジェクト終了フェーズを設けることでフェーズを移行するために必要な準備を進行中フェーズで行えるようにすることが目的です。

　ただし、プロジェクトの終了フェーズに移行してもプロジェクト自体は存続します。 広義の学習体験は提供しても対象とする期間が長く、最終的な結果を見るまでに時間がかかるためです。そのためプロジェクトを存続させておかないと効果検証の実施の優先順位が下がってしまったり、実施の存在が忘れられてしまうことがあるからです。
プロジェクトの終了フェーズへ移行するために行うことは以下のようなものがあります。
速報値での効果測定の計画を立て、実施時期を予定する
実際の実施時期はプロジェクト外の状況次第で変更するためLLエリアのプロダクトオーナーが決定する

プロジェクト全体のレトロを実施して結果をエリア内外に共有する
ドキュメントを整備し、プロジェクト完了後にもプロジェクトの内容を把握できるようにする

 プロジェクト完了速報値での効果測定計画の実施など、プロジェクトの成果を評価します。 こちらを実施して初めてプロジェクトを完了させることができます。

　またプロジェクト成果をエリア内外に共有し、次のプロジェクトに活かすことができるようにします。

 今後の課題と展望このようにプロジェクト方式で LLエリアは業務を進めていますが、まだまだ課題が残っています。 いくつか例を挙げると以下のようなものがあります。
プロジェクト運営負荷の軽減
プロジェクトの ROI の向上
discover track のプロジェクト化

 プロジェクト運営負荷の軽減エリア内外の複数チームによる連携が必要で、プロジェクト内外の状況に対応する必要があるため プロジェクトを運営するのはまだ負荷が高く、状況への対処が精一杯になったり、進捗管理に終始してしまう場合があり、よりプロジェクトのアウトカムに集中できるようにする必要があります。

 プロジェクトの ROI の向上特にプロジェクトが長期に渡った場合に起きやすいのですが、プロジェクトの中に入ってしまうとプロジェクトの完了が目的になってしまい、 アウトカムではなく、アウトプットが目的になってしまうことがあります。 そのためプロジェクトの目的に対してプロジェクトの実施内容が最適かどうか、プロジェクトの実施時期は今が最適かなどの視点を失いがちなため、プロジェクトの外からもプロジェクトを見て評価することでプロジェクトの ROI を向上させる必要があります。

 discover track のプロジェクト化atama plusではデュアルトラックアジャイルを採用しており、discover track と deliver track を分けて進めています。 今回紹介したプロジェクト方式は deliver track をメインの対象としています。 一方でdiscover track はプロジェクト化があまり進んでおらず、過剰に工数をかけてしまうことがあります。そのためdiscover trackに合ったプロジェクト化を行う必要があります。
デュアルトラックアジャイルに関しては弊社の記事：デュアルトラックアジャイルって結局何なの？でも説明していますので興味があれば読んでみてください！

 終わりにこのように Learning Labエリアでは、プロジェクト方式で業務を進め、エリア一丸となってより良い教育コンテンツを提供しようと頑張っています。
ここまでお読みいただき、ありがとうございました。