トグルホールディングス（以下、トグル）でデベNAVIチームのスクラムマスター兼エンジニアとして働いている君田（君田）です。
トグルホールディングスエンジニアアドベントカレンダーの4日目の記事です！
今年の春くらいから社内の開発体制もスクラムを取り入れ、マイクロチーム（2〜5名程度のチーム）のリーダーになったのでそのお話をできればと思います！
まずは自己紹介
新卒で営業職からエンジニアスクールに通い、180度方向転換してエンジニアとして働き始めました。
エンジニアとしては今年で5年目になります。今までは主にフロントエンドエンジニアとして働いてきましたが、トグルではフロントエンドもバックエンドも、TypeScriptで開発していることもあり、どちらの開発にも携わっています。
トグルの開発環境に関してはこちらの動画を見ていただければ！
スクラム開発とは？
まずは大前提ですが、スクラム開発とはどんな開発手法なのかです。
ソフトウェア開発を中心としたプロジェクト管理や作業遂行のためのアジャイル開発手法の一つです。スクラムでは、変化の多い要求や複雑な課題に柔軟に対応するために、反復的かつ増分的な作業方法を採用しています。特に小規模から中規模のプロジェクトにおいて、迅速な価値提供を目指すためのフレームワークとして広く用いられています。
とChatGPTの回答を引用してみましたが、つまり変化に強い開発手法だと自分なりに解釈しています。
現在のトグルでは日々開発要望が上がってくる中で、その優先順位や内容も目まぐるしい速さで変化していきます。そのスピードに対応するためにはスクラムを取り入れた開発をするのが最も良いと考えています。
また、トグルのスクラム開発は以下のような構成でチームを組んでいます。
- プロダクトオーナー => 1人
- プロジェクトの成果物（プロダクト）の価値を最大化する責任を持つ
- バックログの管理
- 要件の優先順位付け
- ステークホルダーとの調整
- スクラムマスター => 1人
- チームがスクラムのフレームワークを正しく運用できるように支援する役割
- チームメンバーの課題解決を支援
- プロセスの改善を促進
- スクラムイベントの円滑な実施をサポート
- 開発メンバー => 4人
- 実際にプロダクトの開発を担当する
- スプリント内で機能する成果物を作成
その中でも自分はスクラムマスターと開発メンバーのどちらの役割も担っています。
スクラムマスターの役割とは？
先ほどのところでも書きましたが一般的なスクラムマスターの役割としては以下です。
- チームがスクラムのフレームワークを正しく運用できるように支援する役割
- チームメンバーの課題解決を支援
- プロセスの改善を促進
- スクラムイベントの円滑な実施をサポート
列挙してみましたが、これだけでは実際の現場での役割としてどんなことをやっているのかというのはその開発現場ごとに変わってくると思います。ここで記載するのは現在自分が実際に行なっている役割に関して記載していこうと思います。
チームがスクラムのフレームワークを正しく運用できるように支援する役割
これはスクラム開発の立ち上げ期に行なっていました。スクラム開発にはイベントがいくつかあり、各イベントの役割説明やスプリント（現在は1週間で行なっています）に沿った開発リズムを作るための支援を行なっていました。
軌道に乗ってきた現在はもう行なっていませんが、新たにメンバーが参画してきた時には必要になるでしょう。
チームメンバーの課題解決を支援
これに関しては技術的な課題はもちろん、プロダクトオーナーとの交渉も入ると思っています。ただ、メインは開発項目の仕様策定・プロダクトオーナーとの開発スケジュールの調整だと思っています。
プロダクトオーナーが最優先とした開発項目は基本的には機能要件レベルで依頼されることが多いです。開発メンバーに依頼する前に、その機能要件をどのよう実現するかの仕様策定を行いスムーズに開発できるように心がけています。完璧な仕様作てでなくても開発メンバーが開発アイテムを渡されたてすぐに走り出せるような準備を行うこともスクラムマスターの役割だと考えているためです。
また、自分のタスクよりもチームメンバーのタスクを優先するように心がけています。これはチーム全体の進捗率を上げるためには開発メンバーのレビュー等の待ち時間を極力少なくするようにするためです。
ここの思考の切り替えには少し時間がかかりました。自分も長らく開発メンバーとして働いてきたのでチーム立ち上げの最初の頃はどうしても自分のタスクを終わらせることに集中していましたが、自分のタスクはチームのレベルで見るとごく一部であることをいつからか思うようになったためです。自分の進捗よりもチームの進捗を重要視する見方ができるようになったのは個人的な成長かなと感じています。
プロセスの改善を促進
毎週行っているレトロスペクティブで出てきた課題に対しての改善策を実施してきました。これはプロセスに限った話ではありません。いくつか実例を挙げてみると
- 不具合のissueに対してカテゴリをつけられるようにしてスプリントごとに分析できるように
- スプリントで実施する開発項目の優先度を明確にし、フォーカスするべきものを明確にした
- 不具合イシュー一覧のカンバンを作成し、稼働に余裕のあるメンバーがピックアップして対応するようにした
- 1スプリントで終わらないことが見込まれる開発に関してはロードマップを作成し、スケジュールを可視化させるようにした
- QAメンバーと協力して優先度ごとにテスト開始のタイミングを決めた
- QAメンバーと協力してリリース前のテストで不具合が見つかった時にロールバックするか、不具合対応をしてリリースまで持っていくかの基準を定めた
- ストーリーポイントの予測値と実測値をつけ、見積もりの正確さを可視化
- 毎スプリントごとにベロシティを出し、1スプリントで消化できるストーリーポイントの見積もりの基準を作成した
列挙してみましたが、それぞれスプリント後のレトロスペクティブで出てきた課題をアクションに移したものです。プロダクトの開発手法もアジャイルをとっていますが、チームもアジャイル的に改善していっていると個人的には感じています。
そのような改善活動を主導していくのもスクラムマスターの役割です！
スクラムイベントの円滑な実施をサポート
基本的には全てのイベントのファシリテーターとして参加しています。今行っているイベントは以下です。
- デイリースクラム
- スプリントプランニング
- バックログアイテム共有会
- レトロスペクティブ
「バックログアイテム共有会」が一般的なスクラムイベントとは異なっているかもしれません。これはスプリントプランニングで出た内容の深掘りと優先順位の確認を行なっています。アサインされた開発メンバーが開発を行う上での疑問点をクリアにし、QAメンバーにも参加してもらい、テスト設計の観点から仕様的な不明点を出してももらったりしています。この共有会で実装内容がかなり明確になります。また、各アイテムの優先度を明確にします。現時点は
- must
- 必ずこのスプリントでリリースしたい内容
- 最優先
- better
- できればこのスプリントでリリースしたい内容
- mustの方が優先
- if possible
- もしできればレベル
- ストレッチゴールを置くようにしている
- 基本的にはリファクタリングや優先度低の不具合
といった感じで優先度分けしています。この優先度をQAメンバーを含め、チーム全員が認識することでコードレビューと自分のタスクが競合した時にどちらを優先させれば良いかという基準ができるので良いと思っています。
これからやりたいこと
様々な改善施策を実行してきて個人的にはかなり軌道に乗ってきたと思います。さらにこれからやりたいこととしていくつか挙げておこうかなと思います。
スプリントレビューの実施
スクラム開発手法を取り入れた初期段階では実施していたのですが、いつかのタイミングで実施しなくなりました。最近エンジニアとプロダクトセールス・グロースチームとのコミュニケーションが不足しているように感じるのでスプリントレビューを再開したいと考えています。
会議体の検討は必要ですが、個人的に考えている1番の目的は「エンジニアが自分の作ったもののリアクションを得る」ことです。
エンジニアがユーザーインタビュー or プロダクトオンボーディングを実施
時間やリソースの制約はあるにしろエンジニアが直接ユーザーと話す機会を設けたいと考えています。組織の作り方ではんエンジニア部隊が社内受託になってしまう可能性もあると考えているからです。そうならないためにもエンジニア自身が「誰のためなのか」「どのよような課題を解決するための要望なのか」を意識した開発を心がけてほしいと考えているからです。
最後に
スクラムマスターも、チームマネジメントも初めての経験ですが、自分なりに様々な意見を取り入れたり、自分で調べたりしてチームを良い方向に進めていけているような手応えを感じています。これからも慢心せず、より良いチームを目指して走っていきたいと思っています！