エンジニアの不安を取り除く-アジャイル開発で推奨されていること-

はじめに

こんにちは、テクノロジー本部の楊です。

2022年7月から、アジャイルトレーニングに参加しました。今までなんとなく進めてきたアジャイルやスクラムについて定義や内容を再認識することができました。今回はスクラム開発チームの一員として不安を取り除くために、２つのプラクティスと２つのイベントから特にスプリントプランニングに重心をおいて紹介したいと思います。

そもそもスクラムとはなんだろう？という方がいらしたら、こちらの記事も合わせて読んでください。

プラクティス:インセプションデッキ

インセプションデッキは開発初期に要件を整理したり、目的を確認するプラクティスです。

開発チームとしては、特に「Howを明らかにする」ところで関わります。プロジェクトを始めたばかりの時期なので、不確定要素も多く、かなり不安だと思います。不安を除くためにも、開発視点では「やらないことリスト」、「夜も眠れない問題」が重要になってきます。

「やらないことリスト」、「夜も眠れない問題」で本当に解決したい課題に集中し、不安・考慮不足などを文章まで落とし込みます。
不安をメンバーに共有し、カタルシス効果^1で不安を軽減します。

プラクティス:チームビルディング

チームビルディングとはチームメンバーが主体的に自分らしさ、多様性を発揮しつつ、相互に関わりながら一丸となって共通のゴールを達成しようとチャレンジするチームを作るための取り組み全般です。^2

『アジャイルサムライ』で紹介されているチームビルディング手法：「ドラッカー風エクササイズ」

画像出典

ドラッカー風エクササイズではチームにおける得意・不得意の把握、役割ごとの期待のすり合わせができます。

お互い頼れる頼られる存在、チームとしての信頼関係を築きます。
自分が他のメンバーから求められていることを再確認でき、対人関係によるストレスが軽減されます。^3

イベント:スプリントレトロスペクティブ

スプリントレトロスペクティブとは、スプリント中のチームの活動やプロセスを振り返るイベントです。

スプリントレトロスペクティブで使われる手法：「KPT」

画像出典

エンジニアはProblemとして課題をあげ、POには把握しづらい技術的な負債の返却（リファクタリングなど）に早期かつ計画的に対応することで不安が軽減されます

イベント:スプリントプランニング

スプリントプランニングは、スプリントを開始するスクラムにおけるイベントです。スプリントプランニングの目的は、スプリントの実⾏内容や作業の達成⽅法を定義することです。では、冒頭で述べたようにスプリントプランニングについて掘り下げて紹介します。

画像出典

プランニング第1部(what)

第1部はスプリントの実⾏内容を設定するフェーズです。

「なぜ作るか？」を明確にしましょう
- まず一番重要なのは、「なぜ作るか？」を明確にすることです。価値のあるものを提供し続けるため、スプリントプランニングの最初にその価値を確認することが目的です。開発チームはその価値を認識し、ゴールを目指して開発意欲を維持できます。
「何を作るか？」を明確にしましょう
- 次に重要なのは、「何を作るか？」を明確にすることです。スプリントプランニングの時、POからの説明を受けて、ただ説明を受け入れるのではなく、少し噛み砕いて技術の視点から、POの考慮が漏れた要件、条件など提示することがポイントです。「何を作るか？」を明確にすることで、ゴールが見える状態で、POとの認識のズレも少なく開発が進められます。
完成の定義を明確にしましょう
- 3つ目に、完成の定義を明確にします。先述した「何を作るか？」を確認するタイミングで条件を出したことによって、「どうすればそのユーザーストーリーが完了したと言えるか？」が明確になります。
- 動作以外も、ユーザー関連のドキュメント作成も完成の定義に入れましょう。ウォーターフォールと違い、最初からすべてのドキュメントがそろっていないため、ユーザーストーリー関連のドキュメントを将来のために残すことが重要です。完成の定義に入れることによって、きちんとしたタイムボックスを確保してドキュメントを作成することができます。
スプリントのベロシティを確認しましょう
- 「スプリントでどのくらいベロシティ（作業量）をとるか」は理想を高くしすぎないことが大事です。^4高すぎるともちろん残業前提のプランニングになりますし、計測したベロシティも実際のベロシティより高くなるため、長期的に残業にハマる可能性があります。そのためプランニングではベロシティとキャパシティを確認することが必要です。
スパイクや改善のユーザーストーリーを取り入れましょう
- スプリントレトロスペクティブで上げた課題や直近数スプリントで可能性のあるユーザーストーリーの技術的な課題の調査や検証をスプリントに入れましょう。こちらもきちんとタイムボックスを設定した上で、改善したいこと、検証したいことを実行し、これからの不安をなるべく早めに解消することが効果的です。同時に改善によって、チーム全体の効率Upやスパイクが行われ、ユーザーストーリーの見積精度Upにつながります。

プランニング第2部(how、who)

第2部では第1部で決めたスプリントの実⾏内容に対して、主に開発チームは「どのように作るか？」をタスクとして細分化するフェーズです。

タスクの基準とサイズに気をつけましょう
- タスク出しのポイントは、完成の定義を達成するために、具体的にどのような作業を行うかを明確にすることです。原則としては1タスクは1日以内に収めるようにします。これにより、実際のタスクを取る時のペース配分も計画しやすいです。ディリースクラムの時も「今日やること」「昨日やったこと」の情報共有が素早くできます。
- 誰か1人に作業の負荷が集中しないようにタスクのサイズを見ながら、チームのメンバーに均等に分けます。
どのように作るか？
- 第2部の「どのように作るか？」を具体的にタスク出しするときに、第1部で気づいていなかったことが見つかります。そこでPOに再確認し、完成の定義の更新を行うことで、開発チームは仕様の曖昧さを回避します。これにより、スプリントゴールが達成しやすくなるのではないでしょうか。

最後に

今回はアジャイル、スクラムで推奨されていることと、私が過去経験したことを紹介しました。開発チームが感じた不安はすでに現実化したものは課題になります。現実化していないものはリスクになります。長期的に課題とリスクを抱えている状況は、プロジェクトの品質はもちろんチームメンバーのモチベーション低下にも直結します。プロジェクト立ち上げから開発中は大なり小なり不安を感じることがあると思います。チームメンバー間で不安を共有し、不安が課題になる前に解消しましょう。今回紹介した内容がみなさまの不安の解消に少しでもお役に立てば幸いです。