現場で実践するスクラム開発と、自宅で楽しむAI活用開発

プロアクシアコンサルティングでオープンソリューション事業部に所属しています H.K です。
クラウドを利用したサービス開発を担当しています。
今回はスクラム開発を用いてサービスの開発を行う上での、現場での取り組みについて紹介したいと思います。

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

これまでの経歴としましては、Web アプリケーションの開発を中心にお客様先のシステム開発を担当してきました。最近は、IoT デバイスとクラウドシステムを連携したエネルギーマネージメントサービスの開発に従事しています。

どのような案件でスクラム開発を活用しているのか

5年ぐらい前からスクラム開発を用いて開発を行っています。担当していた案件が実証用システムの開発案件だったこともあり、業務システムなどと比べて開発開始の段階では要件が確定していませんでした。このため、試行錯誤しながらよりよいサービスを目指して開発を進めていくためにスクラム開発を導入しました。

スクラム開発を導入した結果は

導入当初はスクラム開発を熟知しているのがスクラムマスターだけだったこともあり、色々と手探りで開発を進めました。このため、初期のころはスプリントで対応する作業の見積が不正確で、期日までに成果を出せないなど多くの問題が発生しました。

また、ミーティングやレビューについても効率的に実施できず話し合いに多くの時間を取られたり、こだわった進め方をしたことで非効率になったこともありましたが、チームが成熟するにつれて効率的に開発やミーティングが行えるようになりました。

今回はスクラム開発を実践した際の感想や、実際に導入した取り組みを紹介したいと思います。

スクラム開発を実践して大切と感じたもの

スクラム開発を実施する際に大切だと感じたのは、目的意識の共有、心理的安全性の確保の2点です。

目的意識の共有

スクラム開発における目的意識の共有は、チームの目標を明確にし、全員が同じ方向を向いて進むために不可欠です。目的意識を共有するためには、プロダクトオーナーが明確なビジョンを提示し、情報共有ツールを活用して、チームメンバー全員が最新の状況を把握できるようにすることが重要です。

心理的安全性の確保

心理的安全性の確保については、Google が「生産性が高いチームは心理的安全性が高い」と社内調査の結果を発表したことで注目されました。
Google では心理的安全性を下記の内容で定義してます。

「心理的安全性とは、対人関係においてリスクある行動を取ったときの結果に対する個人の認知の仕方、つまり、「無知、無能、ネガティブ、邪魔だと思われる可能性のある行動をしても、このチームなら大丈夫だ」と信じられるかどうかを意味します。心理的安全性の高いチームのメンバーは、他のメンバーに対してリスクを取ることに不安を感じていません。自分の過ちを認めたり、質問をしたり、新しいアイデアを披露したりしても、誰も自分を馬鹿にしたり罰したりしないと信じられる余地があります。」
出展：Google re:Work – ガイド: 「効果的なチームとは何か」を知る

心理的安全性を確保することで、メンバーが行動する際の心理的な負担を軽減し、より活発なチーム運営が実現できるようになります。このためには、チームビルディングでメンバーの考え方や関わっている背景を知るだけでは足りず、スプリント毎の振り返りを通じてメンバーの理解を更に深める必要があります。

スクラム開発を円滑にすすめるには

以前こちらのブログでも記載していますが、レトロスペクティブ(ふりかえり)を真剣に取り組むことが重要です。レトロスペクティブでは、より品質と効果を高める方法を計画するために、チームでそのスプリントで何が起こったか、よかったこと、解決した、あるいは解決しなかった問題を整理し共有します。

共有した内容は KPT 法を利用して改善が見込める点を洗い出し、その中の一つに絞って対策を進めていきます。上手くいった場合も単純に上手くいったではなく、上手くいった要因を考えて次回のスプリントでも活かせるようにすることで、チームの成熟度を上げることができます。
もっとも効果のあるアクションを選ぶことは、チームで他人が何を大きな問題ととらえているかが可視化されることでもあるので、目的意識の共有にもつながります。

また、レトロスペクティブというチームの現状をかえりみる機会を設けることで、自分の中でもやもやとしていることを吐き出したうえで次のスプリントに進めるようになります。個人で問題を抱え込まずチームの問題として捉えることにより、心理的安全性を向上させる効果があると感じています。

効果が高かったアクション

実際に振り返りを実施したことで生まれた対策で効果のあったものを紹介します。

1時間に1度立ち上がる

開発を進める中で、しばしば課題に突き当たって闇雲に時間だけが過ぎるということが発生していました。他のメンバーに定期的に相談しようとしても、はまっているとそれも生返事になって手を動かし続けることになってしまい、効率的に作業進めることができませんでした。

このような状態を予防するためのアクションとして、1時間に1度チーム全員で立って顔を見合わせるようにしたことで、強制的に手を止めてずるずると嵌り込まないようになります。

その後、立ち上がったタイミングに情報共有する取り組みをしたり、肥大化したものを削ったり試行錯誤することで、チームの特色となりました。この取り組みは他のチームでは実施されていなかったこともあり、メンバーの入れ替わりの際に新メンバーがまず戸惑う風習となっています。

空中戦は不利

レビューやふりかえりなどの会議の際に、予定していた時間より伸びてしまうことが度々発生しました。これに対するアクションとして、会議前にアジェンダを必ず作成するルールにしました。

アジェンダの項目ごとに予定時間を設定します。予定時間を超過するときは議論を中断し、時間を延ばして議論を続けるかいったん持ち帰るかの判断を徹底するようにしました。今、全員の時間を使って話すべき事柄か、冷静な判断が行えるようになりました。
また、アジェンダに会議の目的を明記することで、議論がふわふわと浮いたときに立ち戻れる着地点を見つけることができるようになります。

バックログアイテム (BI) を大切につくる

スクラムガイドによると、BI は作業をおこなう唯一の情報源と定義されています。さまざまな問題が発生しふりかえりを実施した結果、最終的に BI に行き着くことが多かったです。
このため、BI の作成について下記の対策を実施しました。

• BI にユースケースを明記する。
  どのように使用されるのかを考えずに進むと、レビューでプロダクトオーナーに見せた時に、想定と異なった物が出来上がっている場合がある。
• 明確で簡潔な受け入れ状況を記載する。
  長大なやることリストでは共有が上手くできない。
• BI 作成時に受け入れ条件とユーザストーリが合っているか確認する。
  ポイントをつけて積むだけの作業になると、受け入れ条件とユーザストーリが合っていないにもかかわらず実施される場合がある。

効果が薄かったアクション

チームメンバーが入れ替わると、チームの文化の違いによりどうしてもベロシティが低下してしまいます。この際の対策として、新チームメンバーの課題を解決することをアクションにしても、あまり効果がないことが多かったです。このことから、チームとしての問題を個人に帰してはいけないことを学びました。

一時的にベロシティが下がるのを許容し、進め方を共有して慣れてもらうことで改善するのを待つ方がいいと考えています。無理に課題解決を進めようとすると、新しく来た人へのプレッシャーになって、心理的安全性を損ねる要因となります。

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

新しいことに挑戦できるような案件、かかわる人が同じ目的に向かって協力できるような案件に携わっていきたいです。例えば、今のチームで開発手法に AI を導入して、ボイラープレートや単純作業を AI にまかせて作業効率を上げるなどの取り組みもしてみたいです。

最近取り組んでいることはありますか

AI の新しい機能が続々と登場していることもあり、趣味で AI に活用する取り組みをしています。
自分を PO、ChatGPT を PM、Vercel v0 をデザイナ、GithubCopilotAgent を開発者に見立てて個人プロダクトを進めています。まだまだ思った通りの開発を行ってもらえません。Agent で利用するモデルを変えたり、Agent に指示するプロンプトを ChatGPT と考えたり試行錯誤の日々です。

suno でプロダクトのテーマを作曲し歌ってもらうなど、モチベーションを上げる試みもしています。うまく使えたら生産性は一気にあがる予感がするので、AI のできること、できないことの感触を自分の手で確かめています。

他、Elm や Rust など気になる開発言語についてもチュートリアルを試す遊びをしています。

プロアクシアコンサルティングのつよみについて

やりたい案件やしたいことを相談できる土壌がある、できるだけ希望に沿った案件に参画させてもらあえるので、やりがいがあります。

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

新しいことを学びつつこれまでの経験を活かして、細かく見る視点、俯瞰してみる視点を切り替えていけるようになりたいです。