こんにちは、やうやう白くなりゆく諸行無常の蛙飛び込むバックエンドエンジニアの庄子です。

最近は「スクラム開発」を少しずつ取り入れて日々の開発業務をおこなっています。

スクラムと聞いて、ラグビーのスクラム等を思い浮かべる人もいるとは思いますが、ここではアジャイルソフトウェア開発の手法を指します。今回はそんな「スクラム開発」について紹介していきます！

アジャイルソフトウェア開発の特徴

スクラム開発を紹介する前に、アジャイルソフトウェア開発について紹介します。

【アジャイルソフトウェア開発の特徴】

• 日々の目的の達成のために協力する
• フィードバックを継続的に得ながら計画を調整していく
• まとめてやるのではなくて、細かく進め、作っているものが合っているか都度確認する

最終的な成果物の仕様を、最初から完璧に予測して作り上げるのは不可能、という前提で進めるのがアジャイルソフトウェア開発の特徴です。

最初に計画を立てて進めていても、いつの間にか違う機能がほしいと言われたり、ここを変更してほしいと後から必ず言われます。

なのでアジャイルソフトウェア開発では、都度検査と調整を行いながら作業を進めます。

スクラム開発の特徴

アジャイルソフトウェア開発の一つである「スクラム開発」には、以下のような特徴があります

【スクラム開発の特徴】

• 必要な機能やモノを並び替えて、その順番に作っていく（そのリストのことをプロダクトバックログと呼ぶ）
• 短い期間に区切って進めていく（その期間をイテレーションまたはスプリントと呼ぶ）
• 現状や問題点をオープンする
• 定期的に進め方を検査する
• 問題があれば、やり方を変えて適応させる

無秩序かつ持続性のあるものを扱うプロジェクトにおいて、スクラム開発は効果を発揮します。

一方で、手順を作れば誰でも実行できるような定期的な作業や、一つのことに深く踏み入れる必要があるもの、スクラムをやっている暇がないほど短納期なもの、割り込みが多いものの場合、スクラム開発はあまり効果的ではありません。

詳しくは以下の記事を参照してみてください。

クネビンフレームワークを使って、関わっているプロダクトはスクラム開発が有用なのか判断する

スクラム開発における役割分け

スクラム開発には、いろんな役割の人が存在してます。

その役割をざっくりと説明していきます。

👮 ステークホルダー: 決裁者、ビジネス全体の優先順位を管理する係

👨 プロダクトオーナー: ステークホルダーの要望を加味して、プロダクトの価値を最大化する係

👩 スクラムマスター: スクラムがうまくまわるように何でもやる係

👶 メンバー: 一生懸命ストーリー（※）を消化する係

（※スクラム開発ではタスクのことを「ストーリー」と呼ぶ）

1チームに上記の役割の方がいることがスクラム開発を進める条件になります。

チームの人数は5〜8人が最適だと言われています。人数がそれ以上の場合はチームを分割し、LeSS（Large-Scale Scrum）を用いてスクラム開発を進めていきます。

参考:LeSSの概要

スクラム開発って具体的にどうやって進めていくの？？

スクラム開発は、いろんなイベントで構成されています。

🙊 1.スプリントプランニング

👕 2.デイリースクラム

📔 3.スプリントレビュー

🌀 4.スプリントレトロスペクティブ

💻 5.開発作業

以上の5つのイベントを、下図のように進めていきます。

🙊 1.スプリントプランニング

スプリントプランニングは、スプリント（一定期間）に、どれだけのストーリーをリリースできるかを計画するイベントになります。

スプリント中にメンバーがどれだけストーリーを消化できるかは、ストーリーポイントという指標を用います。

ストーリーポイントの見積もりはリファインメントと呼び、ストーリーポイントはプランニングポーカー等の決め方があります。

プランニングポーカーは、一人でストーリーの見積もりを行うのではなく、開発に関わるメンバーで見積もりを行い、認識の差異や、スキルのギャップを埋めていくものです。見積もりの基準となるストーリーを決めて、そのストーリーに対して相対的に数値をつけていきます。つけていく数値にはフィボナッチ数列を用いたりします。

弊社でプランニングポーカー時に使用するツールはこちらを用いています。

👕 2.デイリースクラム

デイリースクラムは前回のデイリースクラムからやったこと、次回のデイリースクラムまでやることの確認する。

連絡事項があるかを確認したり、スプリント内にストーリーが終わらないそうな人がいれば、アサインを相談したりします。

いわゆる朝会のようなものですね。

📔 3.スプリントレビュー

スプリント中に完成したものに関して、ステークホルダーにレビューをもらう時間になります。

デモや共有を行って、フィードバックをもらいます。

状況の変化や全体の共有を行います。

🌀 4.スプリントレトロスペクティブ

スプリント中に起こったことに対するレトロスペクティブ（ふりかえり）を行います。

一般的にKPTなどのふりかえりフレームワークを用いてふりかえることが多いと思います。

レトロスペクティブの注意点として、スプリントの最後にスプリント全体を振り返ろうとしてもなかなか項目が思い出せないので、随時項目を書き出せるような仕組みにしたほうが効果的だと思っています。

💻 5.開発作業

イベントが無いときには、スプリント内に終わるようにストーリーを進めていく時間になります。

スクラム開発のメリット

１、リリースを素早くできる

リリースを素早くできるので、機能の価値を最大化することができます。

まとめてリリースするより、ユーザーが機能を使うことができる期間が増えるので価値が最大化するということです。

また、メンバーコミュニケーションを取りつつ進められるので、顧客のニーズに最大限応えることをできる。

２、属人性を排除できる

スクラム開発では基本イベントはチームで行うので、先述したリファインメント（工数決め）をみんなで行うことで、そのプロダクトに対しての知識の差が出ないように進められます。

チームで話すタイミングも多いので、コミュニケーションの増加が個人的には良い点だと思います。

スクラム開発のデメリット

１、MTGの時間が多くかかる

スクラム開発には先ほど紹介したように、いろいろなイベントが発生します。なので、イベント自体に時間を取られるので、メンバーの開発する時間は少なくなってしまいます。

またコミュニケーションが増えるため、コミュニケーションが苦手な方には辛いかもしれません。

２、請負開発には向いていないと言われている

請負開発では、予算や納期が決まっていることが多いので、いつ開発が終わるかがわかりにくいスクラム開発は向いていません。

３、クライアントの理解が必要

上記にもありますが、納期ありきの手法ではないので、スクラムに難色を示すクライアントも多いと思います。いくら生産性が上がりますと言われても、いつ完了するかわからない状態では安心できないクライアントもいるはずです。

まとめ

以上です！

スクラム開発の概要をなんとなく理解していただけたでしょうか？

先述したとおり、スクラム開発には向き不向きがあり、「銀の弾丸」とはなり得ません。適切な場面のみで導入したほうが良いと考えています。

また、全てを完璧にやる必要もないと考えています。レトロスペクティブだけ取り入れてみる、プロダクトバックログを作って優先順位だけ管理してみるというのも有効だと思います。やれるところからやってみましょう！

それでは良いスクラムライフを！

庄子肇

バックエンドエンジニア。宮城大学事業構想学部デザイン情報学科を卒業後、ベンチャー企業でエンジニアとして常駐先のシステム開発やサイト制作の経験を積んだ後、2019年10月にGIGにジョイン。