サラリーマンエンジニアブログ

大企業で働くなんちゃってITエンジニアのブログです。

アジャイル開発手法のうちの1つであるスクラム開発を実際にやってみて

scrum

今回はアジャイルソフトウェア開発手法の一つであるスクラム(scrum)について書きたいと思います。

目次

 

最初にスクラムを実際にやってみた感想を述べてたいと思います。

「アジャイル」や「スクラム」がわからない人は下を見て勉強していただければと思います。

 

スクラムを実際にやってみて

私が感じたメリット

1. チームやスクラムメンバーの状況を把握しやすい

カンバンボードを使って、毎日15分間のデイリースクラムを開催しているので、スクラムメンバーやチーム全体の進捗が把握でき、開発者間でのタスクの調整をしやすい。チームとしてタスク調整をうまくやるためにも属人化している仕事はなるべくなくさなければならない。

 

2. スクラムのチーム感がモチベーションへとつながる

スクラムメンバーでスプリントごとに決められたストーリーを完了させることが目標で、メンバーが皆同じ方向を向けるので、「チーム」で開発しているという感覚があり、一人で開発しているよりもモチベーションが上がる。スクラムメンバーで一つのプロジェクトを終えた時の達成感はハンパない!w

 

3. 開発の安心感がある

アジャイル開発では早くに「動くもの」がきでるし、不具合が発覚した時の出戻りが少ないので開発者としては安心感が持てる。

ウォーターフォールでは不具合時の出戻りリスクが大きいので、最初に考えられるリスクを全て網羅してそのリスクを防ぐ設計を机上で考えなければいけないので、頭でっかちな設計になりがち。その上、ソフトウェア開発は実際に動かしてみないとわからないことが多いので、経験上どんだけ考えてもエラーが出るものはでる!

そう言った意味でもウォーターフロー型開発よりはエラーや変化に柔軟に対応できる開発するアジャイル型開発の方が安心感がある。

 

難しいと思った点

1. 属人化しているタスクを手助けできない

属人化しているタスクは手助けできないので、できるだけ属人化を防ぎタスクの調整をしやすいようにするべき。我々は属人化しない工夫として、月に一度はチームで勉強会を開くようにして、情報共有やスクラム全体のレベルアップを図っている。

 

2.見積もりが難しい

スクラムはプランニング時にそのスプリントでやるストーリーを決定する。スプリント期間中にバックログからストリーを足すことは原則としてしてはいけない。余裕を持った見積もりをしてしまえば、後半やるタスクがなくなり無駄な時間が生まれてしまう可能性があるし、きつめにタスクを積めばストーリーを完了できず、目標に対する達成率が下がってしまう。

現在私の企業はスプリントが2週間で2週間ごとにプランニングを行なっているが、2週間でさえ調度よくプランニングをするのは難しいと感じてる。

ここはもっと経験や勉強が必要な部分である。

 

3. どこまでリファクタリングをするかが難しい

アジャイル開発では、計画段階で厳密な仕様を決めていないため、「もうちょっと改善したい」を繰り返し、リファクタリングをしているうちに当初の計画からズレてしまうことが多い。やっていきある程度仕様が見えたところで、区切りポイントを設けてやらないと永遠とプログラム改善が続いてしまう。

 

4. チームワークを悪化させてはいけない

スクラムはチームワークを重視した開発手法なので、メンバー間の関係が悪化した場合は仕事に支障がでることは覚悟しなければならない。まずはスクラムメンバーの性格を知るってのが非常に大事である思う。ITエンジニアは曲者が多いので、特に気をつけなければいけない点である。。。

 

 所感

スクラムについて、私個人の感想としてはやはり「楽しい」というのが一番です。

スクラムメンバーみんなが同じ方向を向いてプロジェクトを進めて行くという感覚があり、課題をチームみんなで解決したり、意見を出し合いながら共同開発したりするのはとても楽しいと感じております。勉強にもなります。(一人で黙々と開発するのも嫌いではないですが)という感ですね。

 

それでは「アジャイル開発」や「スクラム」についてわからない方のために説明していきたいと思います。

アジャイルとは

ソフトウェア開発手法は大きく分けて4つあります。
そのうちの1つです。

  • ウォーターフォール型開発
  • アジャイル型開発
  • プロトタイプ型開発
  • スパイラルモデル開発

では一体どうゆう開発手法なのかと言いますと、
1 ~ 4週間くらいの短い単位で設計、実装、テストの1セットを何度も繰り返して完成形に持っていく開発方法です。

アジャイル開発のメリット・デメリット

メリット
  • 仕様変更などの「変化」に柔軟に対応できる
  • 早い段階で「実際に動く画面や機能」を顧客が試せるので、仕様や機能の抜け漏れを事前に防げる
  • 開発者としてもドキュメントにこだわらずに開発できるので、開発に集中できる
デメリット
  • ユーザからの追加要求を飲みすぎるあまりに収束しなくなる可能性がある
  • その場、その場的な開発になってしまい、プロジェクトの計画からずれる可能性がある
  • 日本でアジャイル開発経験者が少ないために、何かしらの問題が生じたときに対応が困難になる可能性がある

 

メリット・デメリットについて詳しくはこちらで

codelab.website

アジャイル開発誕生きっかけ

アジャイル開発誕生のきっかけはの2001年にソフトウェア開発の分野において専門性の高い人たちが集まり「アジャイルソフトウェア開発宣言」という宣言をしたのがきっかけです。

内容は

私たちは、ソフトウェア開発の実践

あるいは実践の手助けをする活躍を通じて、

より良い開発方法を見つけ出そうとしている。

この活動を通じで、私たちは以下のような価値に至った。

"プロセスやツール"よりも個人と対話を、

"包括的なドキュメント"よりも動くソフトウェアを、

"契約交渉"よりも顧客との協調を、

"計画に従う"ことよりも変化への対応を価値とする。

すなわち左記の事柄に価値があることを認めながらも、私たちは右記の事柄により価値を置く。

 

アジャイル開発についてはこんな感じです。
それではその開発手法の1つであるスクラムについて書いていきたいと思います。

 

スクラムとは

アジャイル開発手法の一つで最もアジャイル開発で使用されている手法。

大雑把に言えば下記の4つの特徴を持っています。

  • スプリントという一定の期間(1~4週間)ごとに動くソフトウェアを作る
  • ストーリー(タスク)を優先順位付けしてバックログに保管しておく
  • 各スプリントにおいて、バックログの優先順位を基に、そのスプリントでやるストーリーを決定する
  • スプリントごとにバックログへのストーリーの追加や優先順位の見直し、開発チームが開発したソフトウェアの評価をプロダクトオーナーという役割の人が行う

引用: スクラム (ソフトウェア開発) - Wikipedia

スクラムガイド

スクラムについてのガイドです。

https://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-JA.pdf

 

スクラムってどんな感じ

 一言で言えば「チームのコミュニケーションを重視した手法」です。

  • あたかもラグビーのスクラムを組むように、チームで肩を組み、ゲーム中に適切なボールのパスワークを行うように、スピーディーにチームワークで仕事をこなしていく。
  • 変化には対応しながらもスプリントにおいてはゴールを明確にし、全員で"完了"を目指す。(スプリント:1〜4週間単位の決められた開発期間。個人的には2週間が一般的だと感じている)
  • スプリントごとに出荷可能で動くものをアウトプットする。またこのフィードバックを得る。
  • Continuous Integration/Continuous Developmentで動的な開発ができるようにする。(絶えず動く状況にあるので、開発時の安心感がある)
  • 自己組織チーム
  • モチベーションを持って仕事ができるように!(ビジョンや状況の共有、Work with Respectを忘れない)

 

スクラムチームの構成メンバー

構成メンバー

  • プロダクトオーナー(1名)
    • チームがリリースするプロダクトに責任を持つ
  • スクラムマスター(1名)
    • スクラムに精通している献身的なリーダー(スクラムの掛け持ち可)
  • 開発チーム(5−9名)
    • 開発メンバー/QAメンバー、チームの主人公
禁止事項
  • プロダクトオーナーとスクラムマスターは兼任してはいけない。

  

開発者の中からテックリーダー(1−2名)という役を作り、開発の責任者としている企業もある。

 

スクラムの流れ

  • スプリントごとに目標を立てて成果をアウトプットします。(ピリオディックであることよりもリズムを掴む)
  • 以下の会議体を持つ
    • デイリースクラム
      • 毎日15分くらい各々のタスク状況を報告し合う。
    • プロダクトオーナー主導のプロダクトバックログの見直し(グルーミング)
      • バックログストーリーの作成や修正、また見積りや優先順位を付ける。
    • スプリントプランニング
      • これから開始するスプリントの計画を立て全員で同意する。
    • スプリントレビュー
      • スプリントで開発した成果が動く状態であることを示す。ステークホルダーからフィードバックをもらう。
    • スプリント振り返り(レトロスペクティブ)
      • スプリント終了時に、スプリント実行において伸ばす点、改善する点をチームメンバーで考える。

 

  •  スプリントの終わりには出荷可能なインクリメントができる

プランニングポーカーとは

  • 開発メンバーで各ユーザーストーリーを見積もること。
  • スプリントプランニング時に実行可能なユーザーストーリーをプロダクトオーナーと協議する。

プランニングポーカーのルール

  1. 「0」,「1/2」,「1」,「2」,「3」,「5」,「8」,「13」,「20」,「40」,「100」,「?」,「∞」のポイント(人日)が書かれた見積もりカードをスクラムメンバーに配る。
  2. スクラムメンバー全員がそのストーリーについてどのくらい工数が必要かを考え、ポイントが書かれた見積もりカードを提示する。
  3. 話し合いをして、全員一致でそのストーリーのポイントを決定する。

注意する点

  • 多数決ではない。
  • 見積もりカードに書かれている数字以外のポイントにはできない。
  • 20日以上要する場合はストーリーを分割した方が良い。

 

スクラムに使うべきツール

私的にはスクラムで使用するカンバンボードは「JIRA」一択な気がします。

非常に使いやすい!Atlassian製品は優秀です!

他にAtlassianが出しているサービスのうちの一つに「Confuluence」というものもあり、情報共有・情報公開などにはとても便利なサービスです。

fullvirtue.com

 

スプリント実施の重要ポイント

  • スプリント計画において、プロダクトオーナーと開発メンバーは以下をコミットする。
    • プロダクトオーナーはたかが数週間の計画を途中で変更しない。
    • チームはそのスプリントにおいて、「選択したストーリーを全力でDoneにしようとする」ことをコミットする。
  • 全員がチームの目標と現状を理解し取り組む。
  • 持続可能なペースで、あらゆる効率的な手法を取り入れながら、目標を達成する。

 

スクラムにおいて大事なこと

お偉いさんが「やれっ!」といっているからやるんだ!ではなく....

  • チェンジマインド
  1. みんながゴールを理解する
  2. その結果を理解する
  3. 計画する
  4. 納得する
  5. チームワーク
  6. 実行する
  7. 評価する
  8. 修正する

 

まとめ

スクラム開発で一番大事なことはチームワーク!

私の会社も「チームで楽しく仕事をする」がモットーです。

スクラムは非常に理にかなったソフトウェア開発で、最近は様々な企業がスクラムを導入しているという情報を得ています。

これからも続いていく開発手法だと思いますし、まだやったことのない方は試しに会社でやってみたいと提案してみてはいかがでしょうか。

 

参考

codelab.website

geechs-magazine.com