本記事はCraft Egg Advent Calendar 2021の12/11の記事です。
前回の記事は@aluminum1981さんの「瓶の中に入っている液体の簡易表現を実装してみる @ Unity」でした。
#はじめに
この記事では、「スクラム開発興味あるけど、思ったより時間がかかりそうだなぁ」とか「開発手法を導入してみたけど、なんだかなぁ」と思っている方向けに、スクラム開発を実際に体験してみたからこそ分かる効果をお伝えします。
導入や改善のきっかけになれば幸いです。
今回はお話の土台として、スクラム開発経験があった私が、まだ開発フローの整っていないチームに配属することになった時の経験などをもとに説明させていただこうと思います。
スクラム開発とは？
関連する記事、書籍はたくさんありますが、本記事でも「スクラム開発とは何か」について少し触れておきます（ご存知の方は、読み飛ばしてください）
スクラム開発は、アジャイル開発手法の１つで、「短い開発期間(スプリント）」で、「計画（スプリント計画)」、「進捗の検査（デイリースクラム)」、「スプリントでの成果の検査（スプリントレビュー）」、「改善の計画（振り返り）」を行い、それらを繰り返すのが特徴です。
これにより、作業の透明性を上げ、問題を素早く検知し、改善、適応していくことで作業の効率化や成果物の品質向上を図ります。
詳しく知りたい方はスクラムガイドを読んでみると良いかもしれません。
私もこのような開発を3年程経験してきました。
開発初期のチームにジョインして感じた課題
ここからは、以前私が所属していたチームでの経験をお話しします。
そのチームは私がジョインした当時、まだまだ発足したばかりで人数も少なく、進捗管理や開発フローも定まっていない状態でした。
そんな中で、私が特に感じたのは以下のことです。
チームとしてやっている作業、やろうとしている作業の内容と優先度が分からない
進捗管理のツールはあったものの、ちゃんと運用する流れが定まっていなかったため、「このタスクの状況は最新なのか？」とか、「全てのタスクはこのツール上で管理されているのか？」など、100%信用できる状態となっていませんでした。
また、作業が適切に分割および管理されておらず、具体的で細かな作業になるとどれが優先度が高いのかも分かりづらくなっていました。
他業種の人がどんなことをしていて、どのくらい進んでいるのか見えづらい
朝会など直接会話ができる機会がなかったことや、リモートワークの導入直後だったこともあり、他業種のメンバーと必要以上の会話をする機会がなかなかありませんでした。
また、先述の通り、進捗管理のツールの情報は信用しづらい状況であったため、他業種のメンバーが現在やっていることや、その進捗状態も把握できずにいました。
何かうまくいってない気がするけど、チーム全体で抱えている問題が見えづらい
漠然とうまくいっていない感覚はあるものの、問題について話し合う機会が少なく、自分の感じている問題がチームの共通の問題なのか、自分の視点では見えていない問題があるのではないか、など問題の全体像が見えにくい状態でした。
一緒に働くメンバーのことをもっと知りたい
やはり必要以上の会話がなされない状態や、チームに一度も話したことがないメンバーがいるような状態はどうにか変えたいと思いましたし、純粋に今、自分と同じチームで働くメンバーのことを、もっと知りたいと思いました。
開発の初期段階では、このように開発フローが整備されておらず、**「これは何のためにやる作業で、どうしたら目的を達成できるんだろう」**、**「他のセクションの状況が分からないけど、この作業始めていいのかな？」**と思うような場面が、よくあります。 私は以前のスクラム開発の経験から、スプリント計画を通したチーム全体としての作業の可視化や、デイリースクラムによる他業種の作業者の状況の可視化は可能であることを学んでいたため、 **「将来的にこんな価値を満たしたいから、今はこれに着手すべきなんだな」**とか**「他の作業者がまだ作業中だから僕はこれをやろうかな」**といった見通しを立ちやすくしたいと考えていました。
スクラムっぽい開発手法導入してみた
その後、チーム内に同じ課題感をもったメンバーも多く、「一旦やってみよう！」という勢いもあって、スクラムっぽい開発手法を導入して開発を進めていくことになりました。
内容としては以下のような形です。
- 開発するカテゴリごとに５人から、10人に満たない程度の小チームに分割
- 2週間を1スプリントとして継続的に開発していくことにする
- スプリント計画に倣い、スプリントの初めには小チームで集まり、スプリントで作業したいこと、できることを相談して決める
- デイリースクラムに倣い、毎朝小チームで集まり作業の状況や、相談したいことを話す
- スプリントレビューの代わりに、週に一回のチーム全体での共有会で、小チームごとの状況の共有と、動作を確認する
- 小チームのファシリテーターで集まって、振り返りをする
始めてみてよかったこと
初めてみて1ヶ月もしないうちに良い効果は見えてきました。以下に記載します。
作るものを具体的に相談するので、メンバーは目線合わせをした上で作業ができ、認識齟齬が減った
スプリントの初めに、ただどんな機能を作るかだけでなく、作ることになった背景や、目的を話し、目線合わせをするようになったため、ゴールのイメージが合いやすくなり認識齟齬が減りました。
今後の作業予定をすり合わせるので、これからやろうとしていることや、その優先度がわかりやすくなった
機能や価値ごとに作業を分割し、それらの作業順番をスプリントの初めに話すようにしました。そうすることで、やらなければならないことの優先度の認識が合い、着実に１つ１つの価値を作り出すことができるようになりました。
デイリースクラムを通して、他業種の人がやっていることがわかり、臨機応変に動きやすくなった
日々、進捗や状況、相談したいことを話すため、遅れている作業を代わりに巻き取ったり、変更があれば即座に対応できるようになりました。
相談や振り返りの場が増え、各所で抱えている問題が見えてきた
相談や振り返りを行なっていると、自分の視点だけでは見えない問題や、チーム全体で抱えている問題が見えてくるようになりました。
また、そういった場を用いて改善案をともに出すことができるようになり、より具体的に改善に向けて動きやすくなりました。
色々なメンバーと話す機会が増え、一体感が増した
こちらが個人的にはとても良い効果だと思っており、デイリースクラムなどの決まったタイミングでの相談以外でも、相談するハードルが下がり、問題や悩みの検知と改善までの動きが取りやすくなったと思います。
また、こちらもあくまで個人的な感覚ですが、チームの雰囲気も活発になったように感じました。
始めてみて見えた課題
もちろん良い点ばかりではなく、課題も見えていました。以下に記載します。
- スクラム開発に慣れていない方も多く、メンバー、ファシリテーター共に戸惑いながら進めることも多かった
- やるべき作業の優先順を分割した各チームで決めており、将来的にはプロダクト責任者との最終的な価値の認識ずれのリスクがあった
- 体制を変更したてということもあり、進行管理をする方など、一部の人の負担が大きくなった
- ミーティングにとられる時間が増えて、作業時間が削られた
これらの課題は、その時見えていた一部だと思います。ただ、課題が見えていて、相談し、改善案を出す場もあったため、課題はただのデメリットではなく、みんなで改善できるポイントでしかないと考えています。
これも短い期間で開発し、振り返りできるスクラム開発の特徴であり利点だと思います。
結局どうだった？
私としてはやはり、始めて良かったと思っています。
体感としてもチームの活気が良くなり、作業もしやすくなりました。課題もありましたが、チームの方々の新しいことや、変化への挑戦の意識も高く（そういった方々が集まっていたは元々良い環境だったのだと思います)、チーム一丸となって成功を目指せる気がしました。
今私自身は別のチームで働いているのですが、また一緒に仕事をしたいと思える人たちの集まりに感じられたのも、個人的には良かったと思います。
まとめ
アジャイル開発にはアジャイルソフトウェア開発宣言というものがあり、その中で「プロセスやツールよりも個人と対話を」と言う一文もありますが、スクラム開発では個々人と対話する機会が増えます。
対話することで、お互いの状況を確認したり、困っていることを相談するだけでなく、お互いが考えていることが齟齬なく、納得できるところまで落とし込み、共通認識とすることができます。
個人的にですが、スクラム開発ではこの部分が大事なのではと思っており、チーム全体で対話機会が増え、細かく認識を合わせて作業を進め、最終的にはチーム全体が共通認識を持ち、各々が納得している状態になると個々人の自走力も上がり、開発の速度やクオリティが上がるのではないかと思っています。
もちろん、それは理想的な形であり、そこまでの道のりは遠いのだと思いますが、今後もより良いチーム作りのためにあれこれ考えていきたいなと思います。
明日は@kanata2さんの記事です。