開発サイクルが短くなり、よく見聞きするようになったスクラム開発は、アジャイルの中でも有名な開発手法です。
…という説明を前回の記事でしましたが、正直こう思った方もいるでしょう。
「アジャイルとスクラム開発って何が違うの?」と。
大丈夫、初見の私と同じです
アジャイルもスクラム開発も最近よく見るようになった言葉なので、意味合いを混同しがち。
この記事ではアジャイルとスクラム開発の違いに触れつつ、スクラム開発とは何なのか真意をお伝えしましょう。
\エンジニアに上場企業の給与と自由を/
そもそもアジャイルってなんだっけ?
スクラム開発の説明をする前に、まずアジャイルについてざっと説明しますね
そもそもアジャイルとは何か、要点を押さえておきましょう。
アジャイルとは「計画・設計・テスト・実装」を1サイクルとみなし、このサイクルを短いスパンで繰り返す開発手法です。
要件定義・設計・開発・テスト・実装を一つ一つ進める従来の開発手法と比べて、ユーザーの声を取り入れやすく、仕様変更に強い点が特徴。バージョンアップを頻繁に行うようになった現代の開発環境に合っています。
もうちょっと詳しく知りたい場合はこちらの記事を読んでくださいね!
スクラム開発はあくまでアジャイルの手法の一つ
さて、このアジャイルに分類される開発手法は複数存在しています。
エクストリーミングプログラミングや適応的ソフトウェア開発などある中で、特に有名な手法がスクラム開発です。
え!?アジャイルで進めるならスクラム開発しかないと思ってた!
正直に言うと私もそう思ってた時期があった
アジャイルの中にスクラム開発が含まれているだけで、アジャイル=スクラム開発というわけではないです。
簡単にスクラム開発の歴史と概要に触れておきましょう。
スクラム開発が生まれたのは1990年代初頭。アメリカのJeff Sutherland、John Scumniotales、Jeff McKennaの3人によって生み出されました。
実は、着想を得たきっかけとなったのは日本人の経営学者が書いた論文。この論文に出てきた内容をもとに作ったのがスクラム開発なのです。
スクラム開発はラグビーのスクラムを組むように、チームで密に連携を図りながら進めていきます。役割分担が非常に明確で、コミュニケーションを活発に取るのが特徴。3人以上の複数人で進めるため、従来の開発方法であるウォーターフォール開発との相性が比較的良いです。
まぁ、ウォーターフォール開発ができればスクラム開発も余裕!…ではないですがね
スクラム開発の要は役割分担!
スクラム開発では、参加するメンバーが自分の役割をいかに集中するかが大変重要です。
スクラム開発の起源やスタンスなどを、スクラム開発の生みの親が記したスクラムガイドにはこう記されています。
Scrum をうまく活用するには、人々が次の 5 つの価値観をよりよく実践できるかどうかにかかっています。
コミットメント、集中、オープンさ、尊敬、そして勇気
スクラム チームは、目標を達成し、お互いをサポートすることに尽力します。彼らの主な焦点は、これらの目標に向けて可能な限り最善の進歩を遂げるためのスプリントの作業です。スクラム チームとその関係者は、作業と課題についてオープンです。スクラム チームのメンバーは、お互いを有能で独立した人々として尊重し、一緒に働く人々からもそのように尊重されます。スクラム チームのメンバーは、正しいことを行い、困難な問題に取り組む勇気を持っています。
Scrum GuideTM
つまり自分の役割をしっかりとこなしつつ、開発をガンガン回していくのが大事ってことですね
スクラム開発における役割は以下の3つです。
スクラムマスター
スクラム開発の肝
スクラムマスターはスクラム開発を成立させるためのけん引役です。
「スクラム開発とは?」という基礎・基本を教えることから始まり、スクラムイベントと呼ばれる独自のミーティング・レビューの場を設けて課題を潰して、円滑に開発を進めることがスクラムマスターの主目的です。
先ほど紹介したスクラムガイドをほぼ完璧に理解してチームメンバーに浸透させ、コミットメントを集中・促進させることを重視します
PO(プロダクトオーナー)
スクラム開発というよりプロダクト全般の責任者
プロダクトオーナーは開発したプロダクトの責任者です。
開発したプロダクトが売れないと意味がありません。いかに売れるようにするかビジネスの観点から分析したり、リリース後の改修内容を検討したりするのが役割です。
スクラム開発の知識はあまりなくてもよく、どちらかといえばマーケティングなどビジネス領域の知識が求められます。
スクラムマスターとPOの兼任は、スクラムの主目的から外れてしまうので非推奨です
メンバー
メンバーはそのままメンバーですね
メンバーは開発実務を行います。スクラム開発における開発メンバーは作業をしている人全般を指すので、実はエンジニアに限っていません。
開発プロダクトによってはWebデザイナーやWebライターのようなクリエイティブ分野の職種も含まれます。
上下関係は”つくらない”
ウォーターフォール開発では、PMが開発の進ちょく管理やメンバーマネジメントを行っています。しかしスクラムにおいて何かを管理するという概念は存在しません。
先ほど紹介したスクラムガイドに「スクラム チームのメンバーは、お互いを有能で独立した人々として尊重し、一緒に働く人々からもそのように尊重されます。」とあるように、お互いを尊重しながら同じ立場で作業を進めるのです。
「POだから偉い」「スクラムマスターが一番」ということはありません。良いプロダクトを作るという目的のために全員が同じ目線で物事を見て動くことがスクラム最大の特徴です。
\エンジニアに上場企業の給与と自由を/
スクラム開発成功に欠かせないスクラムイベント
スクラム開発でもレビューのようなものがあります。しかもタイミングも含めて厳密に定義されています
スクラム開発の特色は役割分担だけではありません。スクラムイベントと呼ばれるミ―ティングやレビューのような集まりを頻繁に開催します。スクラムイベントの中で有名な4つについてざっくり説明しましょう。
スプリントプランニング
作業期間(スプリント)が確定したら、スプリントプランニングという実施計画を作るミーティングを開きます。
今回のスプリントのゴールは何か、プロダクトの修正箇所はどこかを確認後、ゴールと作業内容に合わせて作成計画を立てます。
スプリントの期間に応じて、スプリントプランニングにかける時間も決まっています
デイリースクラム
スプリントプランニングに沿って作業を進めても、どこかでズレが生じるもの。そのズレをできるだけ早く修正するためにも、毎日15分ほど進捗を共有する時間を作っています。これがデイリースクラム。
課題に応じてスケジュールを調整したり、プロダクトの開発内容の微調整を行います。
スプリントレビュー
開発したものを経営者などステークホルダーに見せる場がスプリントレビュー。デモ操作をしてもらい、フィードバックをもらいます。
ウォーターフォール開発などのレビューと異なり、レビューをお願いする相手がPMなど知識がある人ではない場合もあります。
あくまでユーザーやステークホルダー側の意見をもらう場。コードレビューとは違うので注意
スプリントレトロスペクティブ
プロダクトが完成する・しないにかかわらず、スプリントが終了したらスプリントレトロスペクティブという振り返りを行います。
今回のスプリントの課題はどこだったか、今後の継続したい取り組みなどを共有して、次のスプリントに活かします。
このイベントを繰り返し、より全員が尊重しあって集中できる環境を作るのがスクラム開発の醍醐味です。
エンジニアにとって、スクラム開発のメリットは?
ここまでスクラム開発について説明しましたが、個人を尊重しつつ集中して開発できる環境がエンジニアにもたらすメリットとは何でしょうか?
最も大きなメリットは仕事が属人化しないことです。
毎日15分のデイリースクラムで自分の状況は常に把握されており、質問やアドバイスもすぐもらいやすい環境。同時にデイリースクラムを通して「自分の業務量、もしかして多い…?」とキャパシティー把握にも役立ちます。
仕事が個人ではなくチームで管理されるので、手が空いた人が助けに行きやすく負担が減るのが良いところです。
ということは残業も減る…?
最終的にはそうなるかもね。他にもこんなところもメリットです
- 見積もりの精度が上がる
- スケジュールに無理が生じにくい
- 仕様変更が急じゃない
- 生産性が向上しやすい
- 顧客とのコミュニケーションがとりやすい
さいごに
アジャイルの代表格であるスクラム開発。チーム内で役割を決め、その役割に集中できるよう環境を作る点が一番の特徴です。
スプリントプランニングや毎日のデイリースクラムなど決められたイベントを実施することで、開発のゴールが見えやすくなって共有がスムーズに進みます。
自分の仕事量がわかりやすく、周りに助けを求めやすくなるので、スクラム開発をきちんと理解して進めればエンジニアの負担も減ります。
一部の案件ではスクラム開発を取り入れているので、もし実例を聞きたい場合は無料の面談に申し込んでください!「私、スクラムマスターしています」という方も大歓迎ですが、転職を迷っている方もぜひ!
\エンジニアに上場企業の給与と自由を/