開発1週間に密着～Slackもミーティングもバックログも全部見せ～
こんにちは、atama plusでスクラムマスターをしている松村です。
最近、社外の方から「atama plusってどんな風に開発を進めてるの？」とよく聞かれます。
その際、開発体制や開発手法については、エンジニア向けのatama plus紹介資料で紹介していますが、日々の過ごし方については具体的にお伝えできていませんでした。
そこで、今回は「開発1週間に密着」と題して、チームに密着する形でatama plusの開発チームの1週間をご紹介したいと思います！
今回密着するチーム
atama plusには、生徒向けの学習アプリatama＋をはじめとしたプロダクトの開発を行うアプリチームがあります。
アプリチームは職能横断の5チームよって構成され、LeSS（Large-Scale Scrum）体制(※1)で開発を進めています。
今回は、アプリチームのうちの1チーム、Oyakataチームの1週間に密着します。チームメンバーは、
・UXデザイナー 1名（あっきー）
・Dev 3名（ゆっきー、がくと、ひらやん）
・QA 1名（ぼぶ）
です。
そのほか、プロダクトオーナー（りんだまん）もいます。（atama plusではニックネームで呼び合うカルチャーがあります）
※1：LeSSの詳細は以下を参照いただければと思います。
開発スタイルの特徴
アプリチームでは、基本的にスクラムのフレームワークに沿った形で開発しています。1スプリントは1週間で、水曜日の午後に始まり、翌週水曜日のお昼ごろに終わります。
また、特徴としては「デュアルトラックアジャイル」を行っていることがあげられます。
プロダクトで解くべき課題に対して、チームでソリューションアイデアの妥当性を検証する「ディスカバートラック」と、ユーザー価値を確信したアイデアを開発する「デリバートラック」の2つを並行して進めます。
※デュアルトラックアジャイルの詳細は以下の記事を参照いただければと思います。
では、説明も終わったので1週間の密着に入っていきます！
スプリント1日目（水曜日）
15:00 - 15:30 | スプリントプランニング1
アプリチームでは水曜日の午後からスプリントが始まります。
スプリントプランニング1では、5チームのほぼ全員が参加し、各チームが次のスプリントで取り組むアイテムを選びます。
まず、プロダクトオーナー（以下、PO）が現在のプロダクト戦略の方針を説明します。次に、各OKR(※2)担当から現在計測しているメトリクスの状況が共有されます。
※2：Objectives and Key Results（目標管理指標）の略称。atama plusでは全社で導入。
プロダクト戦略の状況について認識を合わせたあとに、プロダクトバックログから取り組むアイテムを選択します。
事前にPOがプロダクトバックログに優先順位をつけますが、チームからの情報共有や相談によりその場で変更されることも多いです。
例えば、このような会話が行われてます。
Dev（ゆっきー）「週次の学習時間表示の件で、Biz側からフィードバックもらってチーム内で検討したところ、優先順位をあげてこのスプリントで対応したほうが良さそう」
PO（りんだまん）「確かに、フィードバックの内容見る限り、早めに対応したいですね」
会話の結果、今回は学習時間表示のアイテムを優先することになり、元々優先順位の高かったアイテムの一部は次スプリントに申し送りになりました。このように、状況に応じて最適な計画をスプリント毎に立てています。
15:00 - 15:30 | スプリントプランニング2
取り組むアイテムが決まると、各チームで選択したアイテムを完了するための詳細な計画を立てます。
アイテムをサブタスクに分解する際に、対応する曜日の目安を書くことでデイリーで状況を確認できるようにします。
今回は影響範囲の広い機能を開発するので、そのための作戦会議が始まりました。
以下のように会話をしながら、サブタスクを消化する順番やメンバーのリソース配分を検討しています。
Dev（がくと）「月曜日までに実装したら、機能テスト(※3)ってできそう？」
QA（ぼぶ）「間に合わないかもしれないです。先に機能テストができそうな部分ってありそうですか？」
Dev（ひらやん）「うーん。たとえば、実装単位を分割して、徐々に機能テストを実施してもらうこともできるし、スプリントの後半は自分も機能テストに入れそう。」
※3：機能単体のテストのこと
チーム内の職種はUXデザイナー、Dev、QAと分かれます。しかし、職種はあくまで専門性を示すものであり、チーム内では役割を固定せず、タスクを完了させるために職種を超えて柔軟に対応しています。
スプリント2日目（木曜日）
10:30 - 10:45 | デイリー
スプリントバックログを見ながら、チーム全員で今日の作業内容を確認します。前日のプランニング後に作業や調査をした人がいればそれを共有します。
Dev（ゆっきー）「Devのおふたり、実装に取りかかる前に対象のソースコードについて確認したいので、ちょっと時間もらえます？」
一緒に作業をしたいことや話し合いたいことがあれば、このようにデイリーで宣言をすることが多いです。
デイリーでは、個人の忙しさを報告しあうことや、チームの状況を今日の一言で表すこともあります。チーム内外で助け合えるようにに様々な工夫をしています。
10:45 - 12:00 | 各人でワーク
デイリー後は各人でワークに取りかかります。
Discordを繋ぎ、必要なときに発言する運用にしているチームもあります。ただし、繋ぎっぱなしだとワークに集中しづらい人もいるので、チーム内でルールを決めて運用しています。
13:00 - 14:00 | DevMTG
Devメンバーは、DevMTGというatama plusの全Devが集まる定例打ち合わせに参加します。atama plusではチーム内のMTGだけでなく、職種別のMTGもあり、開発しているテーマ、抱えている課題を共有します。
同様に、UXデザイナーのMTG、QAのMTGもあります。
この日のDevMTGでは、新規ツールの導入を検証し始めたメンバーから「みんなに使ってみて欲しい」という案内がされました。
数十名以上集まるミーティングになっても全員がコメントや質問できるよう、Slackに打ち合わせ用のチャンネルがあり、この日も参加者が説明を聞きながらコメントをしていました。
14:00 - 18:00 | 各人でワーク
各メンバーがそれぞれワークを進めます。
SlackやDiscordで話しながら、必要に応じてミーティングを開催します。Discordを見て回ってると、ペアプロを行っているチームもいました。
18:00 - 19:00 | ユーザーヒアリング
ある学習塾の授業見学とユーザー（生徒さん、教室長さん）へのヒアリングを行います。UXデザイナーだけでなく、エンジニア、QA、ビジネスサイドのメンバーも参加します。
授業見学では、実際にプロダクトが使われる様子を観察します。見学で見つけた課題や生徒さんや教室長さんからのフィードバック、解決に向けたアイデアは、気軽にSlackの専用チャンネルに投稿できます。
授業見学後にも、Slackにはビジネス担当者、プロダクト担当者の両方からフィードバックやアイデアが投稿されました。
※投稿しているメンバーの職種は、上からUXデザイナー、マーケティング、カスタマーサクセス
※たんつまアラート: 生徒がつまずいている単元を表示するアラートのこと
スプリント3日目（金曜日）
10:30 - 10:45 | デイリー
Dev（がくと）「昨日、タスクフォースでの打ち合わせが想定より時間がかかり、思うように作業が進まなかったので、今日の進み具合次第で月曜日に再計画をするかもです」
Dev（ひらやん）「あ、それなら自分の方は思ったより進んだので分担できそうですよ」
前日に想定外のことがあればチームに共有して、スプリントの再計画を行います。アイテムはサブタスクに分割し、プランニング時に個人へ割り当てます。ただし、状況に応じて割り当てを見直すことや作業量が多いときには複数人で取り組むこともあります。
10:45 - 15:00 | 各人でワーク
実装が終わったアイテムはハッピーパスを優先しながら、QAが機能テストを始めます。想定外の挙動が見つかった場合には、QAがDevやUXデザイナーと一緒に確認を行います。
15:00 - 16:00 | プロダクトバックログリファインメント
リファインメントでは、次スプリント以降でアイテムに着手できるように、事前に関連情報の整理や対応コストの見積もりを行います。
そのアイテムに一番詳しいメンバーが場をリードし、対話しながらドキュメントにメモを取り、認識を合わせていきます。POは、リファインメントの結果から着手するタイミングを戦略的に調整することもあります。
また、リファインメントでは、ドメイン知識や開発知識が共有されるため、アイテムの機能に詳しい人だけでなく、その機能についての詳細を知りたい人も参加します。
アイテムごとにタスクを明確にした後、参加者全員でストーリーポイントをつける相対見積もりを行います。
ドキュメントに「せーの！」でタイミングを合わせて、ストーリーポイントを入力します。参加者間で入力したポイントの差が大きい場合には、その理由を議論して認識の違いをなくすよう話し合います。
今回のリファインメント対象のアイテムは、新規UI検討と新規機能開発の2アイテムです。前者はUXデザイナーが中心となり、後者はDev・QAが中心となり見積もりを行いました。
17:30 - 18:30 | 読書会
知識を深めるためにチーム企画の読書会が行われています。
読書会の実施方法はチームそれぞれですが、事前に各自で書籍を読んできて、学びが大きかった点や、理解ができなかった点、もっと話したい点などを書き出し、共有して、理解を深めていく形式が多いです。
今回は「プロダクト戦略の知識を深めたい」という声が上がったことから、「プロダクトマネジメント―ビルドトラップを避け顧客に価値を届ける」という書籍を選びました。
スプリント4日目（月曜日）
10:30 - 10:45 | デイリー
今日もデイリーからチームの一日がスタートです。スプリントも終盤にさしかかり、残りのアイテムを完了できそうか入念に確認します。
10:45 - 14:00 | 各人でワーク
ディスカバーを行っているアイテムについてUXデザイナーが課題と打ち手の整理を行ったので、チームで集まって方針を検討する会が開かれました。このように、個人ワークの時間内でも、作業が滞らないよう必要に応じてミーティングを開きます。
14:00 - 15:00 | シャッフルトーク
シャッフルトークは、チームをまたいだメンバー間のつながりを持つための全社コミュニケーション施策です。毎月1時間、エンジニア、ビジネス、コーポレートサイドなど職種・チームの異なるメンバー3名が集まり、業務内容を紹介し合います。全メンバーが月に1度参加します。
そのほか、お互いを知るためのコミュニケーション施策として入社3ヶ月以内のメンバー（スターメンバー）と既存社員が1on1〜2になって話すスタートークを行っています。メンバー全員がスプリントの中で時間をつくって参加しています。
開発業務以外に、職種やチームの異なるメンバーと交流する時間を確保することも、スプリントプランニング時に考慮します。
※コミュニケーション施策については、以下を参照いただければと思います。
15:00 - 16:00 | 各人でワーク
アイテムの完了に向けて、QAが見つけたバグをDevが修正しています。またUXデザイナーはUIを修正して打ち手を整理の進めています。
16:00 - 17:00 | Bizへのヒアリング
ディスカバーのアイテムに関して、教室側のペインを高い解像度で理解するためにビジネスサイドへのヒアリングを実施します。
このテーマは複数スプリントに跨って取り組むので、この日はまずはファクトの整理を行っています。
スプリント5日目（火曜日）
10:30 - 10:45 | デイリー
今日もデイリーからチームの一日がスタートです。スプリントも残り1日になったので、完了できなさそうなアイテムについては、次スプリントへ持ち越すかどうかを判断します。
15:00 - 16:00 | アイテム完了確認会
アプリチームのPOとアイテムの完了確認会を行います。ディスカバートラックで検討した打ち手の共有やデリバートラックで開発した機能のデモを行います。
UX（あっきー）「このペインに対して、打ち手を3つ検討して、チームとしてはA案かなあと思ってるところです」
<議論省略>
PO（りんだまん）「B案も捨てがたいですけど、たしかにA案が一番よさそうですね。次スプリントでデリバーしましょうか」
Dev（ひらやん）「このアイテムを実装した結果こういう挙動になります」
PO（りんだまん）「実際に動くと想像してた以上にいいですね〜、これはWowMTG(※4)で発表しましょうか？」
※4：毎週水曜日に行われる全社会議で、新しい機能を紹介するスプリントレビューも兼ねる。
持ち越しになったアイテムは、現在の状況と次スプリントにどの程度影響するかをPOに共有します。
次スプリント1日目（水曜日）
10:00 - 12:00 | WowMTG
午前中のWowMTGでは、今週デリバーしたアイテムのデモを行います。Slackにはビジネスやコーポレートのメンバーから「これを待っていた！」というコメントや、「もうちょっとこうでもいいかも」というたくさんのフィードバックが寄せられます。
ちなみに、この日のWowMTGでの全Slackコメント数は500件でした笑
13:00 - 14:00 | レトロスペクティブ
午後は、各チームでレトロスペクティブを行います。
今回のスプリントを振り返ります。シンプルに◯△✕で振り返るチームもあれば、「頑張ったこと」、「お礼したいこと」、「変えたいこと」などの項目を設定して振り返るチームもあります。
今回は、特に話したいテーマとして「計画通りに完了できず、アイテムを次スプリントに持ち越してしまったこと」が挙がりました。
原因を深堀りした結果、「適度にアイテム分割をできていなくて、作業完了を見通せていなかった」という結論に至りました。
次スプリントからは、「プランニング時にストーリーポイントやサブタスク数が一定数を超える場合は、アイテム分割をするかどうかをチーム内で再検討する」という方針に決まり、チームメンバーで合意しました。
14:00 - 15:00 | オーバーオールレトロスペクティブ
各チームでの振り返り後にチーム横断でのレトロスペクティブが行われます。ここで扱うのは各チームから話したい/相談したいと持ち込んだテーマや、POやスクラムマスターが企画したテーマが扱われます。
この日は、複数チームで連携して大きな機能の開発を行った際のプラクティスの共有が行われました。
このようにスプリントの終わりに、レトロスペクティブでしっかりと1週間の活動を振り返ります。
良かった点は、要因分析と言語化を行って、次スプリントでも再現できるようにします。改善すべき点は、原因分析とネクストアクションを決め、次のスプリントで改善を図ります。
振り返りが完了したら、スプリントプランニングに移り、次の1週間がスタートします。
おわりに
atama plusでの開発1週間を書いてみましたが、少しは雰囲気が伝わりましたか？
今後、プロセスも進化していくと思いますが、基本的には、このような1週間のスプリントのリズムで開発を進めています。
atama plusでは、本当にユーザーの価値となるものを作るために、UXデザイナー、Dev、QA、ビジネスと職種を跨いだメンバー、そして、ユーザーである生徒さんや塾の方々との連携を大切にしています。
atama plusで一緒にプロダクト開発しませんか？
atama plusはミッション実現のためにやることがたくさんあります。
プロダクトも開発プロセスもまだまだ途上だと思っているので、一緒に磨き上げていける仲間を探しています！
■募集ポジション一覧
■採用イベント