本記事は BASE アドベントカレンダー 2023 の6日目の記事です。
はじめに
こんにちは。
Shop to Shop チームでマネージャーをしている髙嶋です。
本記事は昨日からの続編になりますので、前編については以下の記事を参照ください。
さて、本日は開発チーム内で取り組んだ10個の取り組みのうち、後半5個についてご紹介させていただきます。
再掲すると、以下の No.6 以降を取り上げようと思います。
| No. | 取り組んだ内容 |
|---|---|
| 1 | チームとしての出社日運用の廃止 |
| 2 | 雑談の活性化 |
| 3 | No Slack Day（日単位での原則 Slack 禁止） |
| 4 | No Slack Time（時間単位での原則 Slack 禁止） |
| 5 | オンライン会議ツールを Google Meet からハドルミーティングに変更 |
| 6 | タスク管理ツールを Notion から GitHub Projects に変更 |
| 7 | スクラムイベント時に使用するツールを FigJam から GitHub に変更 |
| 8 | スクラムイベント実施日を毎週水曜日から金曜日に変更 |
| 9 | デイリースクラムを4日間から2日間に削減 |
| 10 | GitHub Discussions の活用 |
本日も、まずはこの記事で伝えたい要点だけ先に列挙しておきます。
- GitHub サイコー
- スクラムイベントも、前提を疑って守破離で言う破にチャレンジしていくことも大事
では続きに参りましょう。
⑥タスク管理ツールを Notion から GitHub Projects に変更
こちらもまずはその背景から話を進める必要があります。
全社的に、それまで使っていたタスク管理ツールとしての Asana、加えてそれ以外のツールも含めて Notion に一本化しようという動きがありました。
その際、私たちのチームでも Asana でやっていたことを Notion で表現しようと試みました。
Notion は非常に便利で強力なツールであり、タスク管理という文脈においても一定再現することはできました。
しかしながらその変更のカジュアルさや機能性の高さが却って仇になる場面もあり、もう一度自分たちのやりたいことをフラットに考え直しました。
結局のところ、開発チームとしての成果物は GitHub 上に生み出されることが多く、であればその近くにタスクの管理場所も作るのがよいのではと考え、GitHub Projects を使ってみることにしました。
結論、これも今回の取り組みの中で評価が高かったものの一つになりました。
チームメンバーが抱えていた課題への打ち手としてハマった、そしてイテレーションでの開発を進めるうえで必要な機能が GitHub Projects に必要十分なレベルで備わっていたことがその理由になるかと思っています。
メンバーからの声としては以下のようなものがありました。
- 仕様の質問などがその機能開発のための Issue 上で行え、「あの話どこでしてたっけ」と迷子になることが減った
- エンジニアの成果物がコードであることが多いという前提もあり、Issue / PR / Discusssion と、GitHub 上で連携して一元管理できるメリットが大きい
- GitHub API を利用したチーム活動に関するデータ集計がしやすくなった
- 機能上、親タスクに子タスクをぶら下げるような階層は作れるが、同列に見えてしまったり親タスクの進捗がぱっと把握しづらかったりする
結果：4点満点中3.9点で継続
GitHub Projects でできることへの理解が進み、後続の取り組みへと繋がっていきます。
⑦スクラムイベント時に使用するツールを FigJam から GitHub に変更
ここで言うスクラムイベントが何を指しているかでいうと、以下の4つになります。
- スプリントレビュー
- レトロスペクティブ
- リファインメント
- スプリントプランニング
それらを進行するための会場として、FigJam を使用する形でしばらく運用してきていました。
FigJam は各々の頭の中にあるものを発散するという意味では非常に優れたツールであり、各スクラムイベント自体はそれなりに活気のある状態ではあったと思います。
一方で、結局タスク化に際しては GitHub などツールをまたいだり、あるいは発散するのはよくてもそれを一つに収束させていくといったことが求められたり、冷静に見つめ直すとそのデメリットも浮かび上がってきました。
そうした状況を踏まえて、実は GitHub Projects である程度表現できるのではないかと考えて一度トライすることにしてみました。
結論、これも想像以上に上手くできた、という結果になりました。
FigJam と比較すると表現の幅に制約が生まれたのは確かですが、その制約があるからこそ最適な形を改めて考えることができたように思います。
メンバーからの声としては以下のようなものがありました。
- レトロスペクティブで出たトライをそのままタスク化しやすいなど、話して発散だけして満足とならないのが良い
- 扱うツールが減ったことで運用しやすくなった
- スクラムイベント終了後も話途中や気になった議題などについては引き続き GitHub 上（GitHub Discussions 等）でやりとりできるようになり、そういう意味での時間的制約がなくなったと感じた
- 不便さはないが、スタンプなどで反応できないのは若干寂しい
結果：4点満点中3.4点で継続
慣れ親しんでいたスクラムイベントのやり方に大きくメスを入れたことで、他にも前提を疑ってトライできないかといった思考が強くなっていきます。
⑧スクラムイベント実施日を毎週水曜日から金曜日に変更
これはある意味やったことはその通りでしかないのですが、一般的に連休にされやすい月曜日や金曜日にスクラムイベントを置くのはアンチパターンのように言われることも多いと思います。
ただそれまでのチーム状況を改めて振り返って水曜日と金曜日を比較したときに、特段の違いを感じられませんでした。
これは BASE における休暇の取りやすさということであったりも影響しているのではないかなと思います。
そうなると、週の終わりにスクラムイベントを置くということの分かりやすさ、リズムの作りやすさのメリットの方が大きくなるのではないかと考えました。
結論、これは良くも悪くも特に影響がありませんでした。
水曜日に実施していたことによるメリットは、実はそこまでなかったことが証明されたとも言えます。
メンバーからの声としては以下のようなものがありました。
- スプリントが月曜日から開始するため気持ちが良く、そのまま木曜日まで連続するため振り返りもしやすい
- プロジェクト外の業務あるいは業務外のことも含めて、週のサイクルと揃って分かりやすくスケジュールもたてやすくなった
- 当初懸念していた「土日を挟むことで忘れてしまう」といったことも特に起きなかった
- 特に水曜日と比較したときの変化は感じなかった（ニュートラル）
結果：4点満点中3.5点で継続
がっつりスクラムイベントを実施する日だけではなく、デイリースクラムも見直せないかなと考えることになっていきます。
⑨デイリースクラムを4日間から2日間に削減
スプリント期間としては1週間、つまり稼働日ベースでは5日間でまわしています。
そのうちの1日は上述したスクラムイベント実施日のコンテンツにマージされているような格好であるため、明確にデイリースクラムのみやっているのが元々4日間であったというのが前提となります。
ここの課題感としては、デイリースクラムを待って問題を話すという事象を極力なくしたかったのと、よりバックログを正しい状態に保つこと、作業時間を柔軟に確保することも併せて推し進めたかったということが挙げられます。
チームないしプロジェクトが発生してから一定期間は毎日やる意味は確かにありましたが、そこから時間がたって同じように必要かで言うと、もはやそういう状況ではないだろうと考えたのが出発点になります。
結論、2日間に削減したからといって業務が滞るわけではない、ただチームメンバーの顔を見る機会が少し減ったのは若干寂しいといった結果になりました。
メンバーからの声としては以下のようなものがありました。
- 以前は開催すること自体が目的のように思っていたが「なぜ開催するのか」を考えやすくなり、改めてその意義を見直すことができた
- 問題が発生したら、デイリースクラムを待たずにコミュニケーションをとるようになったと感じた
- 特に業務上の支障があるわけではないが、顔を見る機会が多少減ったことで他メンバーがどんな感じのテンションでいるのか気になる（根詰まってるのか、全然大丈夫なのかなど）
結果：4点満点中3.1点で継続
スクラム開発のフレームワークは認識しつつも、そこから外れていくこともポジティブな理由であれば、今のチーム状況を考えれば決して悪手ではないということが確認できました。
⑩GitHub Discussions の活用
レトロスペクティブといったスクラムイベントに限らず、課題になる前のトピックについては FigJam や Slack 上でコミュニケーションをとるのではなく GitHub Discussions に集約してはどうかと考えました。
これは各々がより考えたうえで言語化するとともに、Slack で散見されるような「あれどこで会話したっけ？」といった事象の削減を促進したかったというのが背景にあります。
つまり特定のトピックに対するやり取りをフロー情報として扱って迷子にさせない、加えて GitHub の活用が推進されてきたという状況も相まって、積極的に GitHub で提供されている機能を使っていこうといったマインドになっていたということもあります。
結論、こちらも概ねポジティブで、とりわけそれまで GitHub 上でそこまで業務を進めるということが少なかった PdM やデザイナーのメンバーからも好評だったのが意外ではありました。
Slack がフロー情報で流れやすいというつらみを、上手く補完できたのが良かったのかなと思っています。
メンバーからの声としては以下のようなものがありました。
- 問題提起したけどそのままうやむやになるということがなくなり、会話が流れず非同期で確認できるので良い
- 一つの話題を深く議論したい際に、まさにピッタリなツール、使い方だと思った
- あとから話題を思い出す時に、どこで会話したかを探すのに苦労するということがなくなった
- GitHub Discussions から明確なトライに繋げる動きがまだまだできていない
結果：4点満点中3.6点で継続
自身の考えを適切に言語化してアウトプットする、それに対するフィードバックを重ねていくという点において有用なツールになりうることを確認できました。
まとめ
なんとなくそうだろうと思っていたことも、実際に試してみると良い意味でちょっとギャップがあるものだなと改めて感じることができました。
とにかく失敗を恐れずにどんどんチャレンジしてみる、そしてそこから得た知見をネクストアクションとして繋げていくという空気を今後も醸成していきたいと考えています。
ただ本当にしたいのは、一つのチームに閉じて自分たちのやり方を磨いていくということではなく、チームをまたいでこういった知見を共有しあい、組織全体として開発手法や運用、あるいはその他様々なことをアップデートしていくことなのではないかなとも思っています。
明日は matzz さん、matsuyuki さんの記事です。お楽しみに！ devblog.thebase.in
