エンジニアの副業は週1からでも可能?副業の例や探し方も解説
- ITエンジニア
- 副業
あなたは「スクラム開発」がどういうものかご存知ですか? 「スクラム開発」という言葉自体は知っていても、実際にどのような開発手法なのか説明できる人は少ないでしょう。
そこで今回は、スクラム開発をする上で必要な情報をご紹介します。実際の開発の流れや使用ツール、メリット、デメリット等をまとめて記事にしました。
「スクラム開発ってなに?」「どうやって開発を進めるの?」と思われた方は、ぜひ本記事を参考にしてください。
はじめに「スクラム開発の概要を紹介した上で、スクラム開発とウォーターフォール型開発を比較します。
主なソフトウェア開発の進め方に「ウォーターフォール型」と「アジャイル型」の2種類の手法があります。スクラム開発は、アジャイル型開発のメジャーな手法のひとつです。
スクラム開発では、チームとして「何が必要か?」「いつまでに必要か?」という視点からタスクを割り振り、チームとしてプロダクトの完成を目指します。そのため、チームワークやコミュニケーションが重要と言われています。
スクラム開発には以下の役割があります。
プロダクトに必要な機能を定義し、タスクの順位付けを行います。最終的なプロダクトについて責任を持つ立場となります。
スクラムがうまく回るように全体調整する役割です。チームの状態を良くするために裏方からサポートを行います。
開発チームで出た課題を解決するために、外部と交渉を行なったり、メンバーと相談したりして課題解決を進めます。
実際に開発をしていくメンバーです。
なおスクラム開発においては、「設計者」「プログラマー」「デザイナー」といった区分けはありません。機能を横断的に作れる能力を持った人たちが、プロダクトを中心において開発を進めていきます。
スクラム型とウォーターフォール型ですが、どちらも長所と短所を持ち合わせています。
スクラム開発は、以下のような特徴を持っています。
- プロダクトへの作業は、バックログ(タスクを書いたカード)で管理する
- 少人数チーム。メンバー全員が、リーダーのつもりで開発を行う
- 固定の短期間(1~4週間)で開発を区切り、計画を立てる
- プロジェクト状況について、メンバー間で毎日話し合う時間を設け、必要があったら方向修正をする
ウォーターフォール型の開発は、以下のような特徴を持っています
- プロダクトに関する作業はWBS等で整理し、リーダーが各メンバーへタスクを振り分ける(WBSとはWork Breakdown Structureの略称であり、タスクやスケジュールを管理するツールである)
- トップダウン型でリーダーがスケジュールを組み、メンバーが作業を行う
- 「要件定義」「外部設計」「内部設計」「コーディング」「テスト」等の開発工程に分けて計画を立てる
- 各工程が終わるまで先に進まず、進んだ後は元の工程に戻らない
- プロジェクト内の会議では、メンバーが進捗状況を報告する
- 設計の段階で、プロダクトの要件が考え尽くされている(コーディングの段階でミスに気づいても、方向修正することは容易ではない)
スクラム開発型のばあい、プロダクトの開発・修正・リリースまでを短期間で行えます。比較的小規模のWeb制作やアプリ開発にオススメです。
ウォーターフォール型のばあい、要件定義を初期段階でしっかり行いタスクを振り分けるため、大型の業務システムを開発するときに向いています。企業の基幹システム開発などで大量の人員を投入できるばあいは、ウォーターフォール型が良いでしょう。
ここからは実際のスクラム開発の流れをご紹介します。
プロダクトバックログとは、ユーザー(顧客)が求めるプロダクトに対しての要求リストのことです。「タスクを書いた札」のようなものですね。プロダクトが完成するまでの間、プロダクトバックログは管理され続けます。
また、このプロダクトバックログのリストは順位付けされている必要があります。順位付けされていないと、スプリントバックログを作成できないからです。
プロダクトバックログを元に実際の作業を抽出し、順位付けしたものがスプリントバックログです。
スプリントバックログはチームメンバー全員で共有・確認します。その後、開発チームが工数を見積もり、最終的にどこまで開発するか決定します。
スプリントのフェーズでは、実際に開発を進めていきます。スプリントで行う作業は以下のとおりです。
要求確認 → 設計実装 → テストの作業は、スプリントの中で何度も繰り返します。繰り返していく中でプロダクトに修正を重ね、ブラッシュアップしていきましょう。
またスプリント中の作業のひとつとして「デイリースクラム」と呼ばれる、開発チームの活動状況報告会があります。主に毎朝、短い時間で以下の事項を共有し、チームとしてどうするかを決定します。
開発チームで障害を取り除くことができないばあい、スクラムマスターとその障害をどのように扱うか判断します。
スプリント完了時にプロダクトの確認を行います。プロダクトオーナーを含め様々な人からレビューを頂くことでプロダクトが計画時の条件を満たしているか確認するのが目的です。計画時に明示していた条件をクリアしていないと受け入れられないということもあります。
最終的には、今後の製品向上についての意見をまとめる場として活用しましょう。
スプリント内で発生した課題やどうやって解決したかを振り返りましょう。今後のスプリントを改善できるような意見を出し合う場となっていることが多いです。
ここからは、スクラム開発時に使うおすすめツールをご紹介します。
スクラム開発における使用ツールの選定ポイントは以下の2つ。
今回はこれらの条件を満たしたツールをご紹介します。
一番のオススメは、ATLASSIANの開発管理ツール『Jira』。スプリントの期間決定やかんばん方式のインターフェースはもちろんのこと、細かな設定も可能で汎用性が高いです。
ソースコードと連携出来ることが最大の特徴。コードとタスクを連携させ、履歴管理することは物理かんばん方式では実現不可能でした。
設定が少し複雑なのが欠点ですが、使い慣れてくれば問題ないでしょう。
次にオススメなのは『Trello』。基本的なかんばん方式の部分は、シンプルでわかりやすいUIが採用されています。
拡張機能を使用することで、スプリントの期間を設定することも可能。
Jiraほど複雑な設定はできませんが、小規模な開発であればTrelloの方が扱いやすいでしょう。
デジタルなツールではありませんが、物理的にホワイトボードを使用して管理する方法もあります。
拡張性が最も高く、かんばんを記入するタイミングでコミュニケーションが発生しやすいメリットがあります。しかしソースコードと結びつかないことや、履歴管理できないといったデメリットもあります。
物理かんばん方式を採用するばあいは、適宜ほかのツールも組み合わせて使うのが良いでしょう。
スクラム開発のメリットと、そのメリットから考える開発成功パターンを説明します。
スクラム開発には、以下のメリットがあります。
まず一つ目のメリットは、短期間で成果をあげられることです。スプリントが完了した段階でプロダクトに対して変更が加わっているため、すぐに成果を確認できます。
日々のデイリースクラムで情報共有をしているため、方向転換しやすいというメリットがあります。またスプリント完了時に開発を振り返るので、今後の改善につなげるというのも良いでしょう。
エンジニアは個々で動くものですが、デイリースクラムを通してチームで作業している感覚が身につきます。チームとしてお互いを支えられれば、離脱者を防ぐことにもつながるでしょう。また作業が属人化しないため、万一メンバーの離脱者が出ても他のメンバーが開発を進められるという利点もあります。
スクラム開発が成功するパターンとして、いくつかの条件が挙げられます。スクラム開発では、以下の項目に当てはまっているか確認しつつ開発を進めましょう。
チームで進めるスクラム開発で一番の肝となるのが情報共有です。チームやプロダクトの課題を、全員が同じ粒度で認識していることが重要です。
認識のズレはバックログから発生することが多い傾向にあります。できるだけ定量的かつ、誰もが理解可能な言葉でバックログを書きましょう。
デイリースクラムは時間が短ければ、それだけ作業時間が増えます。「課題が出たときにどうするか?」というのを前もって決めておけば、デイリースクラムも早く終えられるでしょう。
メリットで挙げた「短期間で成果を確認できる」というのは、スピード感が重要になってきます。デイリースクラムの時点からスピード感を意識して取り組むことが重要でしょう。
スクラム開発のデメリットと、それに付随した失敗パターンをご紹介します。
スクラム開発は以下のようなデメリットがあります。
ウォーターフォール型の開発に慣れているばあい、スクラム開発へ移行するのは大変なことです。
スクラム開発の要である「チームワーク」は、全員がスクラム開発を理解していることで威力を発揮します。全員がスクラム開発に慣れるまで、2回ほどスプリントを回した方が良いでしょう。
スクラム開発では開発期間が短いため、都度顧客からのフィードバックが必要となります。ウォーターフォール型と異なり、フィードバックの回数が多くなるため顧客の協力が必要不可欠です。
またフィードバックをもらうまでの時間もスピーディである必要があります。フィードバックで1〜2週間と時間を使われてしまうと、今後のスプリントに影響を及ぼしてしまうでしょう。
開発チームのメンバーだけでなく顧客も含め、全員がスクラム開発を理解し、協力すべきです。
スクラム開発が失敗する典型的なパターンをあげてみました。スクラム開発時には、以下のことに気をつけながら進めると良いでしょう。
スクラム開発の手法を習得できていないメンバーが多いとプロジェクトは失敗してしまいます。開発手法を教えるコストが掛かりすぎてしまい、実際の開発が進まないパターンをこれまで何度も見てきました……。
ルールを明確にしたマニュアルを作成し、少しでも早く慣れてもらう仕組みを作りましょう。
スクラム開発の最大のメリットはスピード感です。それにも関わらず、デイリースクラムの時間が長かったり、顧客フィードバックが遅いとメリットが薄れてしまいます。
いつまでに何を終わらせるか、明確なスケジュールを全員で立てましょう。
今回は、スクラム開発をする上で必要な情報についてご紹介しました。スクラム開発のメリットは、短い期間で開発でき、方向修正も容易なことです。
メリット、デメリットを把握した上で、最適な開発手法を選択しましょう。
こちらもおすすめ!▼
アジャイル開発を更に加速化させる「継続的デリバリ」の可能性
Workship MAGAZINE
LEGOはどうやって”デザインスプリント”を全社規模で導入したのか
Workship MAGAZINE
プロダクトデザインの設計プロセスで役立つ9つのハック
Workship MAGAZINE