スクラム開発での円滑なチーム運営について

プロアクシアコンサルティングでオープンソリューション事業部に所属している K.A です。
今回はスクラム開発を実施する際に、円滑なチーム運営を行うために心がけていることについて紹介いたします。

プロアクシアでの役割とこれまでの経験を教えてください

これまでの経歴としましては、オープン系を中心にお客様先のシステム運用やアプリケーション開発を中心に担当してきました。

最近は、IoT デバイスと連携するクラウドシステムの開発に従事しており、開発チームのスクラムマスタを担当しています。

スクラム開発とは

ソフトウェアの開発手法には、ウォーターフォール開発手法やアジャイル開発手法などがあります。

アジャイル開発手法は最近主流になってきている開発手法の一つで、スプリントやイテレーションと呼ばれる短いサイクルで、「計画→設計→実装→テスト」 といった開発工程を繰り返し実施しながら開発を進めていく手法です。

スクラム開発はアジャイル開発手法の一つで、チームを組んで役割やタスクを分散しつつ、コミュニケーションをとりながら開発を行っていく特徴があります。

スクラム開発に関する詳細な説明ついては、以前公開されているこちらのブログを参照ください。

スクラム開発を行うことのメリット/デメリット

スクラム開発では、チームとして必要なタスクを各メンバーに割り当て、それぞれのタスクを達成することで全体の開発を完成させていきます。それぞれの作業が他の人の作業を支える形になりるため、チームワークやコミュニケーションがとても重要になります。

円滑にチーム運営できるようになれば、個々のメンバーが役割をもって開発を進めることができるため、様々な作業を同時に進めることができ、効率的に開発を進めることができるようになります。

スクラム開発を行う際の注意点としては、プロジェクトに参画するメンバー全体でスクラム開発を理解していないと円滑に運用が行えない点です。メンバー間でスクラム開発の理解度が異なるとコミュニケーションの妨げとなり、開発がスムーズに進まなくなります。

このため、スクラム開発を始める前段階での準備が非常に重要になってきます。

スクラム開発を行う際に準備すること

スクラム開発では、最初のスプリントに入る前の準備段階の事をスプリントゼロと呼びます。

スクラム開発でプロジェクトを順調に進めるためには、スプリントゼロでどれだけ入念に準備できているかが重要です。チームが構築された初期段階の立ち上げをスムーズに行うためにも、スプリントゼロで開発を行うための事前準備や、スクラム開発の理解とチーム内の共通認識の調整を行ってください。

私が参画しているプロジェクトでは、開発を円滑に進めるための準備として、スプリントゼロで以下の項目に重点を置いて準備をしています。

  • 関係者の一覧化と役割を明文化する
    プロジェクトにはプロダクトオーナー、スクラムマスタ、開発者などの役割があります。
    それぞれの役割を誰が担当しするのかと、それぞれの役割に求められている事項を整理し、チーム内で認識を合わせる必要があります。
    それ以外にも、プロジェクトを進めていくためには多くのステークスホルダーがいます。ステークスホルダーが多くなればなるほど、責任の所在不明や決定スピードの遅延などが発生するので、円滑に進めるために明文化しておく必要があります。
  • どんな価値を提供したいのか決定する
    これから開発するプロダクトで、ユーザーにどういった価値を提供するのかを明確にし、開発のゴールを設定します。
    提供する価値が曖昧なままであれば、開発を進める中で大きなブレが生じるため、安定した開発を行うためにも最初に明確にしておく必要があります。
  • 開発の共通ルールを決定する
    チームのメンバー内でスクラム開発の理解度を合わせるのと並行して、開発する際の共通ルールを作成します。
    共通ルールは開発方法やチーム運用などで重要だと思うこと整理し、メンバー全体で理解できるルールにします。運用では決定したルールを重視しながら、デイリースクラムで情報共有を行います。
    なお、共通ルールについては、必要に応じて見直しと改訂を実施することも重要です。

スクラム開発を行う際に気を付けること

スクラム開発を行うには、個人ではなくチームで開発を行うことが重要です。このため、チーム内で良否関係なく気軽に報告ができる環境を構築し、プロジェクトが終了するまで保つ必要があります。
特に困り事や開発遅延の相談などは、早期に連携することで個人で抱え込まずにチーム全体で対応できるようになるため、早期解決に繋がります。

私が参画しているプロジェクトでは、チーム内で気軽に報告ができる雰囲気を作るために、以下のことに気を付けています。

  • デイリースクラムでの報告の際に、個人に対して報告を行うのではなく、カンバンボードなどの進捗を管理する物を利用してチーム全体に報告するようにする。
  • 問題やミスが発生しても、無駄な犯人捜しをしたり、人を責めるようなことはしない。
  • コミュニケーションの場では否定的な意見をのべるのではなく、協調性をもって前向きな意見を中心に議論する。
  • プログラムのコードレビューを行う場合に、開発者に対して指摘を行うのではなく、コード内容について検討したり改善案を提案するようにする。

スクラム開発を円滑に運用するために心がけること

スクラム開発の運用を円滑に進めていくためには、心がけている点として2点あります。

1点目は、タイムボックスを順守することです。
チームが1つのタイムボックスで消化できるストーリーのポイントを合計したものをベロシティーと呼び、ベロシティーを利用して開発期間を算定していきます。このため、タイムボックスが守られないと、正確なベロシティーが算出できなくなり、開発期間の算定が不正確になります。

チームを立ち上げた当初や、初期のスプリントではベロシティーにばらつきがでますが、スプリントを繰り返すことでベロシティーは安定し、成熟したチームになるほど上昇していきます。
安定したベロシティを利用することで、開発期間を正確に把握でき、プロジェクトの進捗管理を円滑に進めれるようになります。

2点目は、ふりかえり(レトロスペクティブ)を真剣に取り組むことです。
スプリント毎にふりかえりを実施し、開発に関する問題点や改善のアイデアなどをチーム内で議論することで、チーム内の交流も深まり、より成熟したチームへと成長できます。
このためには、ふりかえりを形式的に実施するのではなく、各メンバーが真剣に意見を交えることが重要です。

ふりかえりの目的や重要性について

ふりかえりでは、スプリントで 「何がうまくいったのか」、「何がうまくいかなかったのか」 を議論を行います。実施する目的としては、チーム全体で議論した結果を次のスプリントでの改善点として取り入れることで、作業効率や作業品質を向上させるためです。

何も考えずに議論を行うと、悪かった点ばかりに目が行きがちになり、反省会になりやすいです。このため、私のチームでは KPT 法を活用してふりかえり実施しています。
KPT は Keep (成果が出ていて継続すること)、Problem (解決すべき課題)、Try (次に取り組むこと) の頭文字で、「良かった事」、「悪かった事・直したい事」、「どうやって解決・改善するのか」 を洗い出して議論する方法です。KPT 法を利用して、良かった点についても深堀して、「なぜ良かったのか」、「どうすればさらに良くなるのか」、「他に活用できないのか」 などの前向きな議論を実施することで、チーム内の交流を深めチームとしての成熟度を上げていけると思っています。

私が参画している2つのチームでは、それのチームに合わせて KPT 法を少しカスタマイズしながら実施しています。

チームA では、標準的な KPT 法を利用しています。
Keep や Problem を洗い出した後に、それぞれに対して議論し、Try を導きだします。そのうえで、すぐに Action に移せそうなものについては、次のスプリントから改善を実施するようにしています。
ふりかえりの進め方についても議論を行い、より円滑に進めれるようにふりかえりのふりかえりを実施しています。

チームB では、タイムライン + KPT 法を利用しています。
最初に時系列に出来事を整理したうえで、それぞれの出来事について Keep 、Problem、Try を議論して、Action を導きだす流れで行っております。
こちらのチームでも、ふりかえりのふりかえりを実施しております。

ふりかえりの進め方は KPT 法以外にも色々な方法があるので、各チームでどの方法が進めやすいか模索しながら改善していってください。定期的にチーム内で情報共有を実施し、メンバー全員が積極的に議論行うことで作業効率や作業品質を向上させ、より成熟したチームへ成長することが最終目的になります。

スクラム開発を行うことで感じた事について

スクラム開発を行うまでは、自分の作業範囲の開発を黙々とこなす時間が多く、他のメンバーがどういったことをしているのか、どういったことで困っているのかなど、あまり共有しないまま開発に取り組んでいました。このため、分からない箇所や問題が発生した時に、一人で考えたり悩んだりする時間が多かった気がします。

スクラム開発を始めてからは、価値を意識することやメンバー同士が話しやすく質問しやすい空気を作ることがいかに重要かを考えるようになりました。これにより、個人ではなくチーム全体で開発を進めれるようになり、情報連携を活発にすることでチーム全体の開発能力が底上げされたと感じています。

今後とりくみたいこと、改善していきたいこと

同じメンバーでチーム組んで開発していくと成熟度やベロシティが向上してきますが、成熟したチームになるほどそれ以上にチームの成熟度やベロシティを高めていくことが難しくなると共に、マンネリ化や属人化をしやすくなってきます。このため、今後もチームとして成長していくために、何か新しい切り口が見つけられないかを考えています。

現在進めている取り組みとしては、他のチームの取り組みや進め方を参考にして、いい点を取り入れていくようにしています。特にスクラムマスタ同士で意見交換会などを実施し、それぞれのチームでの課題や改善方法などを議論することで、新しい気付きが得れると思っています。

社内の取り組み以外でも、SNS やメールマガジンなどで色々の方が自身のスクラム開発に関する知見や考察について情報発信されているので、できるだけ新しい情報を収集して自身で活かしていけるように取り組んでいます。

今後どのような案件に携わっていきたいと考えられていますか

最近は AI に関連する案件にも携わってきましたが、めまぐるしく日々進化してしていることを感じます。
AI を利用したサービスを開発するだけでなく、スクラム開発を行う中で生成 AI の機能を活用するなども検討されており、ふりかえりの中で AI スクラムマスタにコメントを求めるなどの利用事例もあるようなので、今後はスクラム × AI でコラボするような案件に携わってみたいと思っています。

今後エンジニアとして、どのように成長していきたいとお考えですか

現在はスクラムマスタとして業務を担当していますが、今後はアジャイルコーチとして働きかけができるエンジニアになっていければ良いなと思っています。

そのためには、もっとアジャイルを深く理解して、チームを俯瞰的に見ながら意見をしていけるようになる必要があるので、今後も継続して努力していきたいと思います。