📡

スクラム/アジャイル型のプロジェクトの適正に関する考察

2024/07/27に公開

組織

スクラムマスターを務めているごーと申します。今回はスクラムチームの適正についてまとめてみました。
プロダクト開発を複数回してくると自然と何度かスクラムチームを作ることになります。本当ならばすでに立ち上がったチームに対して新しい仕事(プロダクト開発)を渡すのが理想とされていますが現実的にはそうもいかず、新しいチームを考える人も多いのではないでしょうか？
その際、スクラム適性がわかりづらいと思ったので言語化を兼ねてまとめてみました。

その前の前提

スクラムは イテレーション方式(期間を固定して何度も回す) のプロジェクトで、ウォーターフォールは 初めから終わりが全て計画された 考え方のプロジェクトです。
体制も大きく違います。ウォーターフォールのプロジェクトだと、要件定義->設計->製造->テスト->デリバリー(運用)の各フェーズで入れ替わりが発生することが多い一方で、スクラムはメンバー変更が起きません。基本的に全ての領域をいるメンバーでやる必要があります（クロスファンクショナルあるいは多能工と呼ばれています）

それらを考えると次のようになるかと考えています。

3つの素養

スクラム開発（というよりイテレーション式の開発）を行う上で必要なスキルは3点に集約されると考えています。

協調性とコミュニケーション力
-> 人間力
変化への適応と改善の意志
-> カイゼン文化
ビジネスインパクトへのこだわり
-> デリバリーの意識

この3点について少しずつ解説していこうと思います。

1. 人間力(協調性とコミュニケーション力)

協調性（きょうちょうせい、英: Agreeableness）とは、(中略) 個人の行動特性に現れる性格特性のことである
協調性の下にグループ化された下位レベルの特性、つまり側面因子は、利他主義、協力性、謙虚さ、道徳性、共感性、信用性である
(wikipediaより引用)

スクラムはウォーターフォールよりもコミュニケーション量が圧倒的に多いです。そのため、人間力が低い=協調性がないメンバーはトラブルを生みやすくなります。
協調性がないメンバーは、自分の意見がいつも正しいと思い込む、自分の成果ばかりを主張する、場合によってはチームへの攻撃などを行うことがあります。
スクラムの自己組織化をしていく上では、1番重要な概念だと思いますので、チーム発足時には特にメンバーの素養として重要視すると良いでしょう。

協調性が高いと判断する振る舞いは次のようなものがあります。

議論の際、相手の発言を頭から否定しない（特にレビューや設計時）
自分がOwnerでないサブチケット(PBIの子タスク)などに対して、自分のやり方を強力に押し付けない。
想定外に発生した作業に対して自ら実施する。
時間を守る。イベントや会議時に相手の時間を奪ってないか気を使っている。

過剰すぎてもいけませんが、過小すぎてもいけないので判断が難しいですがバランスを見てチームにふさわしいか判断していく必要があります。

また、コミュニケーション力も重要です。協調性に近いですが、自発的なコミュニケーションや適度な雑談などの会話ができる人が望ましいです。
プロダクトオーナーや必要に応じてステークホルダーとの会話など、想像以上に開発者以外との会話が発生します。適切な言葉遣いや表現ができるスキルも必要になります。
1点気をつけなければいけないのは、コミュニケーションというのはただ話せればいいというわけではありません。口下手で必要十分なコミュニケーションしかしない人もいますし、自発的なコミュニケーションが苦手な人もいます。話がただ長い人や、適切な応答ができない人（質問に対して全く異なる内容を返答する）などはチームコミュケーションの障害になることもありますので注意が必要です。

個人的にコミュニケーション力がある人は次のような振る舞いがあると考えます。

質問に対する回答をする際、前後関係やタイムボックスを意識して回答する。
POやステークホルダーに対して、技術的な単語を使わずに説明する（POは技術に疎いことも多い）
相手の質問の意図がわかるまで丁寧に回答あるいは質問を掘り起こす

ここにまとめてみたように、人間力にかかわる要素は一目見てわかるものではありません。またいわゆるエンジニアに要求するには難しい?部分もありますが、チームビルディングをするとなると何度重要と強調してもキリがありませんので、甘く見ずに検討していくとよいと思います。

2. カイゼン文化（変化への適応と改善の意志）

スクラムは毎スプリントで振り返って次に活かす活動で、これを行わなければスクラムをやっている意味がありません。そのため、現状維持や言われたことをくりかえすだけのようなメンバーがスクラムに入るとスクラムでの効果が薄れます。
また、スプリントごとのカイゼンで一見うまくいっているように見えても、実は改善の余地があることが多いです。レビューやCI/CD、コミュニケーションのプロセスなどあらゆる領域に目が届き、１度うまくいっても次にもっといい方法があると思えるメンバーであるとそのチームは確実に機能すると思います。
カイゼン効果が出てくると、自然とスクラムチーム（プロダクトオーナーだけでなく）から技術以外の仕様や動作の改善案が出てきたり、プロダクトのKPIとして新たな視点が提案されたりしてきます。こうなってくるとそのプロダクトはMVPを離れ、社内(あるいはHD単位)、顧客に対してインパクトを与え生存するプロダクトを開発できるようになります。

メンバーにカイゼン文化、心持ちがあるかどうかを判断する観点として次のような振る舞いが考えられます。

スプリントで漫然とやっている作業に対して不安をもち、少しでも楽しようとする。（単純に手を抜こうとしているかどうかはよく観察する必要あり）
スプリントレトロスペクティブで振り返りで意見を出している。特に次につながるTRYを出せている。
ソースや設計のレビュー、スプリントプランニング時に相手の意図などを捉える質問が出てきている。
各工程、イベントの時間に気を配り、ボトルネックになっている工程の短縮をするための発言が出る。

3. デリバリーの意識(ビジネスインパクトへのこだわり)

スクラムに関する誤解は数多くありますが、その中でもよくあるのが スクラムでやると早く安くできる というものです。
特にSIの文脈だと、このようなワードがよくでますが実際は早くなるのは非常に難しいというのがこれまでの経験です。スクラム開発がウォーターフォールより優れているのは、フロー効率(細切れにされた機能のデリバリーまでの速さ)で、作成物の量だけを見るならばウォーターフォールの方が多いと思います。

問題はこの一括で物を作るウォーターフォールのやり口だと、変化が大きい領域でのプロダクト開発では、モノができたタイミングで価値がなくなっていることがあるということです。
逆に変化に対応できるようにするには、頻繁にリリースする必要 = スクラムやXPの考え方が必要になり、これを活かすためにはPOだけでなく開発者もビジネスへの感覚が必要になってきます。

意味のないリリースするならば、それは生産性の悪いウォーターフォールと大差がなくなってしまうため、プロダクトを利用しているユーザーや現場の雰囲気を感じ取り、素早くプロダクトに反映していく意識が重要です。

メンバーにビジネスインパクトの意識があるかどうかを判断する観点として次のような振る舞いが考えられます。

ユーザーからのフィードバックは良いものも悪いものも楽しんで受け付けられる
積極的にプロダクト内にユーザの振る舞いを検知して統計を取れる仕組みを入れる
スクラムイベントでの議論でPBIの狙いとインパクトについて質問したり、提案したりできる

終わりに

これまでの内容は若干SIの視点からの記載になってしまいましたが、内製開発する組織においても同様の考え方にでしょう。
スクラムは長期的に同じメンバーでやっていくことが条件です（暗黙知の共有）。スクラム向きのメンバーをチームに受け入れたり、長期的にメンバーを育成していくなどして力強い組織を作っていきましょう。