認定スクラムマスターを取得したので、自社にスクラムのエッセンスを取り入れられないかを考える
【ご注意】
🔰 このnoteではスクラムの理論については触れておりません！
🔰 「スクラムの考え方を自社に活かすとしたら」というメモです。
先日、スクラムマスター研修を受け、認定スクラムマスターを取得しました。スクラムのやり方を学んだ私は、早速自社にそのエッセンスを導入してみたいと考えています。しかし、スクラムガイドに書かれている理論通りに実践するのは、現実的には容易ではありません。
そこで、自社の現状を見つめ直し、「スクラム研修で学んだことから何か一つでも役立てられないか？」という観点で考えてみることにしました。
このnoteでは、「それはスクラムの原則とは違うのでは？」という指摘もあるかもしれませんが、ここでの目的はスクラムを理論通りに正しく導入することではなく、学んだことを自社に活かしてみることにあります。
▼ ちなみにJoe先生の研修を受けました！💪
Fantastic to work with bright people like @akinatty_dev 🎓 https://t.co/EeiYjkPkrX
— JoeJustice 💪🦾 (@JoeJustice) November 6, 2024
1️⃣ 私たちのチームの現状
まずは、私たちのチームがどのような状況にあるのかを整理してみます。
フルリモートでのソフトウェア開発
PMF前のフェーズで、新規事業の立ち上げや未経験の分野など、不確実性の高い開発が続いている
各メンバーが複数のプロジェクトに関わっており、1つのプロジェクトにフルコミットできない
事業フェーズ的にステークホルダーの意向が強い
役割を定めず自主性を重視するカルチャー
2️⃣ 私が感じる課題
このような状況の中で、以下の課題を感じていました。
1. リクエストの整理ができない
ステークホルダーからの機能開発リクエストが次々と溜まる一方で、優先順位付けや着手、不要なものの整理ができない状態です。忙しくてできていない、のではなく、時間があったとしてもできないのです。（4に関連）その結果、リクエストの箱が溢れ、入れたリクエストがどこにあるのか、今どんな状況なのかがわからないという状態が発生しました。
2. 生産性が低いと見られている
ステークホルダーからは、開発チームの生産性が低いという指摘がありました。しかし、なにを指して生産性が低いと言っているのか、そしてその具体的な原因や改善策も明確でないままの状態が続いていました。
3. 納期に間に合わない
ステークホルダーが要求する納期に対して間に合わない、にもかかわらず事前にアラートが上がらないため、ステークホルダーに対して能動的に交渉ができない状態が頻発していました。
4. 役割と責任範囲が不明確
「手を挙げた人がやる」「気付いた人がやる」というスタンスを大事にするカルチャーであり、誰が何を決めるのかがその時々によって曖昧です。
5. 進捗状況と生産性の可視化が不足
NotionやGitHubで情報を共有しているものの、差し込みや遅延により、共有されたスケジュールが参考にならない状態です。また、進捗や生産性を客観的に示す指標がなく、課題の把握が難しいです。
3️⃣ スクラムで学んだことを活かしてみる
これらの課題に対して、スクラムで学んだエッセンスを取り入れることで改善を図れないかと考えました。
1. 役割の明確化
課題：リクエストの整理ができていない、役割と責任範囲が不明確
前述したように「手を挙げた人がやる」という自主性を重んじるスタイルであり、かつステークホルダーの意向や差し込みもあるため、誰がリクエストを管理し、優先順位を決めるのかが曖昧でした。
これらに対しては、役割と責任範囲を明確にすることを試みます。たとえばスクラムでは、以下の役割が定義されています。
プロダクトオーナー（PO）：ステークホルダーの要望をまとめ、バックログの管理と優先順位付けを行う
スクラムマスター（SM）：プロセスの改善とチームのサポートを行う
開発者（Developers）：実際の開発作業を行い、品質を担保する ※実際にスクラムチーム内で作業を行う役割のことで、エンジニアに限らない
カルチャーや事業フェーズによって難しい場面もありますが、役割を明確にすることで、リクエストの整理がスムーズになり、タスクの滞りを減らすことが期待できそうです。
それでもどうしても、いろんな事情によって役割を明確にすることが難しいと感じる場合（たとえばスキル的に難しいが人がいないなど）は、スクラムのクロスファンクショナル（機能横断型）なチームという概念が役立つかもしれません。
スクラムでは、リリースまでに必要なスキル（アーキテクト、デザイン、エンジニアなど）を備えた最小のチーム構成をとります。この構成では、最終的にお互いからスキルや知識を学び合い、メンバー同士が複数の役割を担えるフルスタック人材を目指していきます。
この考え方を適用すると、たとえばPO、SM、Developersの役割はお互いを行き来できるということになります。まずはいろんな役割を担ってみて、だれがどの役割のときにチームがスムーズに機能するのか、を探ってみるとよいのかもしれません。
2. 進捗状況と生産性の可視化（バーンダウンチャートの活用）と振り返り
課題：生産性が低いと見られている、進捗状況と生産性の可視化が不足
「プロジェクトの進捗状況を可視化する」ことは永遠の課題です。私たちはこれまで、Notion上でリクエストの可視化、Github上で開発スケジュールの可視化を行っていました。しかし、差し込みや遅延により、スケジュールが参考にならない状態でした。また、ステークホルダーからは生産性が低いという曖昧な指摘がありました。
そのような中ではバーンダウンチャートが活用できそうです。バーンダウンチャートは、残りの作業量と時間を視覚的に示すことで、進捗を一目で把握できます。
ステークホルダーからの要望によって優先順位が日々変わる状況では、逐一チャートで進捗状況を更新するのは難しいかもしれません。でも、進捗状況が見えないからこそ、優先順位が日々変わってしまうのかもしれないとも考えました。
さらに、生産性が低いという指摘に対してもバーンダウンチャートは役立ちます。最小プロジェクトからスプリントを回し、スプリントを重ねるごとにスピードアップしていれば、チームとして成長しているかどうかが明確になります。
これにより、チームの実際の作業量や進捗を客観的に示すことができ、ステークホルダーとのコミュニケーションが円滑になります。生産性に関する指摘に対しても、データをもとに具体的な改善策を検討できそうです。
個人的には以下の記事がチャートの読み解きに役に立ちました。
そして「チームとして成長しているか」を把握するためにも、振り返りは必須です。特に、なかなか成果が見えづらい事業の初期フェーズでは、DDDDの合言葉をいいことに走り続けがちです。うまくいかないことばかりの中で、向き合うのもつらいでしょう。
スクラムでは、スプリントの終わりにレトロスペクティブという振り返りの時間があります。その時間で、うまくいったこと、改善すべき点、次の具体的なアクションなどをスクラムチームで共有し合います。
その時間を恐れずとることで、HappyでFastな開発を続けることができます。
恐れずとる。つまり、つらくない、暗くならない、楽しく有意義な振り返りをしましょう。以下の画像では「Sailboat Retrospective（セイルボート・レトロスペクティブ）」という手法で振り返りを行なっています。
Sailboat Retrospectiveは、プロジェクトを航海に見立て、チームの進捗や課題を視覚的に整理する方法です。この手法では、以下の要素を用いてチームの状況を分析します。
🏝️島（Island）：チームが目指す目標やゴールを象徴します。
🌪️風（Wind）：プロジェクトを前進させる要因や推進力を示します。
⚓️錨（Anchor）：進捗を妨げる障害や課題を表します。
🪨暗礁（Reef）：将来的に直面する可能性のあるリスクや問題点を示唆します。
🌞太陽（Sun）：チームの士気を高める要因や成功体験を示します。
このように、視覚的なメタファーを活用してチームの状況を多角的に分析し、次のスプリントやプロジェクトフェーズに向けた具体的な改善策をポジティブに導き出すのに役立ちます。
▼Sailboat Retrospectiveについて詳しく書かれています
▼レトロスペクティブのやり方は他にもいろいろあるようです！
3. 完了の定義（DoD）の明確化
課題：納期に間に合わない、品質にばらつきがある
これまで、タイトなスケジュールやその他の要因によって、暗黙的に、ステークホルダーからのリリース要求日＝本番環境で操作できる日となっていました。しかし、それは「リリースはするが、正しく動くかどうかはテストしてみないとわからない」という状況で、顧客から指摘されて不具合が判明することも多々ありました。
ここでは、完了の定義（Definition of Done）をチームで合意し、ステークホルダーが言う「リリース」とはどういう状況を指すのかの認識合わせを行うとよさそうです。
スクラムでは、例えば、
テストが全てパスしていること
コードレビューが完了していること
ドキュメントが更新されていること
といった具体的な基準を設定します。
テキストで書くと「そんな当たり前のこともできていないのか」と自分でも思えるのですが、事業フェーズによっては現実的ではない場面もあるのではないでしょうか。
それでも、完了の定義をチームで合意することにより、品質のばらつきを防ぎ、リリース時の不具合を減らすことが期待できそうです。また、納期に対して現実的な見積もりが可能になり、遅延のリスクを早めに把握してステークホルダーに報告できます。
4. チームの合意事項を作成し、コミットする
課題：役割と責任範囲が不明確、生産性が低い
いろいろ理想論を書きましたが、なにより大事だと感じたのは、チーム全員で合意事項を作成し、それにコミットメントすることです。そうしないと、どんなに正論を言ったところで絵に描いた餅といいますか、何も変わらないまま日が過ぎてしまいます。
スクラムでは5つの価値基準を定めています。
確約 (Commitment):
意味: チームメンバーはスプリントの目標達成にコミットする必要があります。
背景: スクラムは目標達成に向けて協力するチームワークに基づいています。各メンバーが目標達成に全力を尽くす確約は、プロジェクトの成功に不可欠です。
集中 (Focus):
意味: チームはスプリントの目標に集中し、それを達成することに専念する必要があります。
背景: スクラムチームが目標にフォーカスすることで、効果的な成果を生み出し、目標達成に近づけます。
公開 (Openness):
意味: チームメンバーは作業状況、課題、アイデアなどをオープンに共有する必要があります。
背景: スクラムの進捗と課題は全員で共有されるべきで、これによりチーム全体が改善点を見つけ、協力して解決策を見出せます。
尊敬 (Respect):
意味: チームメンバーは互いに尊重し合い、個々の貢献を認めるべきです。
背景: 互いに尊重し合うことで、チームの結束力が強まり、より効果的な協力が可能になります。
勇気 (Courage):
意味: チームメンバーは困難な問題に直面しても、正しいことをする勇気を持つべきです。
背景: スクラムでは透明性が重視され、チームは問題を隠さずにオープンに議論し、解決策を見つける勇気が求められます。
簡単なように見えますが、全員のコミットメントを得ることは容易ではありません。
スクラムはチームワークや心理的安全性を重視しているため、いくつかのルールは万人に受け入れられるものではないと感じます。
この不安に対し、スクラム研修では、「最初から全員で取り組む必要はない」と学びました。もちろん全員で取り組めるのが理想だが、まずは興味を持った1〜2人から始めてみよう、と。
たとえば私はスクラムでいうとモブやレトロやLean Coffeeなどはどんどんやってみたい！のですが、万人が好むものでないことを理解しています。
これらの取り組みに限らず、まずは興味を持つ少数から始める。そこで生産性が上がったり、ポジティブな結果が得られたら、その成功体験をもとに仲間を増やしていけば良いとのことです。
おわりに
スクラムを学んだことで、自社の課題に対して新しい視点を持つことができました。すべてを一度に変えるのは難しいですが、一つずつ試してみることで何かしらの変化が生まれることを信じています。
最後に記載した「できる人から始める」という方針を胸に、まずは自分自身が1つでも率先して取り組み、成功体験を共有していきたいです。スクラムのエッセンスを活かし、チーム全体が前向きに進んでいけるよう努力していきます💪
📩 スクラムにおけるPO、SMの役割をもっと深めていきたいです。界隈の方はぜひつながってください！ @akinatty_dev