はじめに

こんにちは、サーバーサイドエンジニアの@hokitaです。

この記事は Enigmo Advent Calendar 2021 の 8 日目の記事です。

今回はテックリード兼スクラムマスターとして約8ヶ月間プロジェクトを運用していく中で学んだことを8つ紹介したいと思います。

学び

1. ストーリーポイントと難易度

例えば2ポイントのストーリーがあり、経験の長いAさんは2日、初心者のBさんは4日かかるとします。では作業量が倍と見積もった4ポイントのストーリーはどうでしょうか。Aさんは倍の4日でできたのですが、Bさんは始めての作業だったので3倍の12日かかってしまいました。このようにスキルや難易度によってポイントと工数が単純な比例関係にならないことがよくあります。そのため、メンバーのスキルを認知しつつ、どのような策をとるべきか考える必要がありました。

納期が迫っているなら、Bさんが苦手なタスクをAさんにやってもらう
スケジュールに余裕があるなら、Bさんに苦手なタスクをやってもらいながらスキルアップを目指す
Aさんに余力があるなら、Bさんを手伝ってもらう（ペアプロを実施するなど）

それぞれメリット・デメリットあるので、その時々で判断する必要があるかと思います。

2. フル稼働ではなく1名助人役になる

プロジェクト開始時は私を含めた2名で開発していました。そのときのベロシティは約7ポイントで、途中で人員を増やし4名になってからは約14ポイント消化できるようになりました。人数が倍になったからベロシティも倍になったと思うかもしれませんが、そうではなく、私はあまり開発をせずに助人役に回っていました。実際には下記のようなことを行っていました。

進捗が著しいタスクを発見して対策を考える
ストーリー着手前に一緒に設計を考える
コードレビュー
手が空いたときには小さめのストーリーを消化

私が開発に集中することもあったのですが、進捗は逆に低下することが多かったです。開発中に発生する問題は思った以上に工数を膨らませます。それを解消する役がいることで安定した開発スピードを出すことができると気づきました。

3. レビューファースト

スクラム開発ではスプリント内で成果物を残し、ステークホルダーへデモを見せフィードバックを貰うことが重要です。よくあったのが、一人で同時に複数ストーリーを進めて、結局どのストーリーもスプリント内に終わらせることができなかった、というものです。なぜそのようなことが発生するかというと、レビューを返すまでに時間がかかっていることが原因でした。レビュー依頼を出した開発者はレビューが返ってくるまでは他のストーリーに着手するかと思います。そうしているうちに複数ストーリーのマルチタスクとなって、結局どのストーリーも消化できずじまいとなってしまいます。レビューはなるべく早く返して、１つのストーリーを確実に終わらせることが大事です。

4. ベロシティがプレッシャーに

良くなかったなと反省しているのですが、1on1の時に各開発メンバーに「次のスプリントでは○ポイントの消化を目指しましょう」とストーリーポイント基準で目標を設置していました。数値目標で管理しやすいと思っていたのですが結果どうなったかと言うと、コードの品質が下がり、時には仕様を満たないプルリクがくることもありました。個人のコーディングスピードはいきなり上がるものではないので、時間を省くとなればデバッグ時間となっていたのだと思います。それに気づいた後は、まずは安定したアウトプットができること、そして、ポイントはあくまで目安に過ぎないことを意識し、目標は消化ポイントとは別のものに変更しました。

5. レトロスペクティブが自己評価になりがち

レトロスペクティブではメンバーそれぞれがKPT法で書いていました。そこでよく上がってくるものは「〇〇の実装で時間がかかってしまった。なので、〇〇を勉強する」のような自己評価が多かったです。個人の能力を伸ばすことも重要ですが、どちらかというとチームとしてなにができるのかを議論することのほうが重要だと思っています。「〇〇で時間がかかった。」のは相談する機会がなかったのが原因なら「朝会で相談する（相談しやすくする）」やスキルが足りない場合は「詳しい人とペアプロの時間を設ける」というのが良い振り返りかと思います。これは開発している本人だと気づけないことが多いので、他の人が提案してあげることが望ましいです。

6. スプリント内で終わらないストーリーは放置しない

前述したとおりスプリント内で成果物を残すことは重要なことですが、どうしてもストーリーを消化できないことは多々発生します。ストーリーの粒度を小さくすることは心がけていたもののどうしてもそうはならないストーリーもありました。ほとんどの場合次の週にも継続して開発するのですが、なぜ終わらなかったのかを調査し対策することが大切です。例えば一人で行き詰まって終わらなかったのなら、次週はペアプロでそのタスクを最優先で終わらせる、もし思っていた以上に作ることがあった（例えばAという機能を追加するのに実はBという機能を作る必要があったなど）なら、まずストーリーを分解することはできないか、他のメンバーと役割分担はできないか、今のまま続けるとしたらどのくらいかかりそうか、など念入りに調査し対策を考えます。これを怠ると何スプリントにもまたがるストーリーになる可能性があり、開発者のメンタルを下げ、負のスパイラルに陥ることが多い印象です。

7. 早くリリースしたいなら機能を削る

まず下記をスクラムチーム全員で認識を合わせる必要があるかと思います。

開発スピードが劇的に向上しないこと
最初に作成した仕様の大半は不要な機能であること

それを前提に納期へ向けてできることといえば「機能を減らす」もしくは「納期を伸ばす」しか手段はないかと思います。今回のプロジェクトもバックログを全て消化するにはベロシティなどの数値から計算して目標納期に間に合わせるのは「不可能」でした。やったことと言えば、優先度の低い機能をごっそりと削ることでした。リリース後にその削った機能を開発したかというとほとんどの機能は「不必要」でした。

8. 興味を引くスプリントレビューを

本プロジェクトはバックエンドのメンバーが多かったので、デザインは後回しにして簡素なページを作成していき、デモでは毎週動くものを提供していたのですが、ステークホルダーからのフィードバックが薄いことに気付きました。その後デザインが当たった段階でやっといろいろな意見をいただけるようになりました。動けば良いというものではなく、もしデザインファーストなプロトタイプを作っていればもっと早い段階で多くのフィードバックを貰えたかと思われます。機能やステークホルダーのよりけりだと思いますが、興味を引くようなプロトタイプを作ることも重要だと気づきました。