Loading...

【開発手法】アジャイル開発の考え方とスクラムの基礎知識について

開発手法
マイケル
マイケル
みなさんこんばんは!
マイケルです!
マイケル
マイケル
今日は突然だけど、
アジャイル開発とスクラムの基礎知識
について、整理がてらまとめていくよ!
エレキベア
エレキベア
急に出てきたクマね・・・
アジャイルってよく聞くクマが何なのクマ?
マイケル
マイケル
アジャイルは イテレーティブ(反復的)なソフトウェア開発手法の概念で、
変化に柔軟に対応できることから、IT業界以外でも注目されつつあるんだ!
マイケル
マイケル
その中でもスクラム開発はアジャイル開発の中でも
代表的な手法になっているよ!
エレキベア
エレキベア
それは興味深いクマね
是非クマ業界にも取り入れてみたいものクマ
マイケル
マイケル
(なんだその業界・・・)
それじゃさっそく勉強してみよう!
スポンサーリンク

参考書籍・ドキュメント

マイケル
マイケル
参考にした書籍は下記!
こちらはだいぶ前に自分がアジャイル検定の資格受験した時に使ったものです。

アジャイル検定公式テキスト アジャイルソフトウエア開発技術者検定試験 レベル1対応

マイケル
マイケル
あとは公式で提供されているドキュメントを参考にしました!
スクラムについても、公式のスクラムガイドを見るのが一番です!

アジャイルソフトウェア開発宣言

Scrum Guides

スクラムガイド

エレキベア
エレキベア
ネット上で見れるのはありがたいクマね

従来のソフトウェア開発

マイケル
マイケル
アジャイルの説明に入る前に、従来のソフトウェア開発が
どのようなものだったのか見てみよう!

ウォーターフォール開発

マイケル
マイケル
これまで主流だったのは、ウォーターフォール開発といって
下記のように設計からテストまで1つの流れで開発する手法となっていました。
01 waterfall↑ウォーターフォール開発の流れ
エレキベア
エレキベア
川の流れのように一本道なわけクマね
マイケル
マイケル
全体的な計画を立てやすいというメリットはあるものの、
この開発方法には下記のような問題がありました。

[ウォーターフォール開発のデメリット]
変化を容認できないため、イノベーションを抑制し、後半に提案されるいいアイデアは危険なモノとされる。
情報伝達の方法で文書化を重要視しているが、ドキュメントは不完全であり読んだ時に抽象的な考え方を創造してしまう。

マイケル
マイケル
僕は以前SI業界にいたことがありましたが、
設計書通りに実装できないことで文句を言っている開発者や、
変更が積み重なって炎上してしまう
光景を何度も見てきました・・・
エレキベア
エレキベア
ひどい光景クマ・・・
マイケル
マイケル
こんな状態でいいものなんて作れるわけがない!
このような問題を解決するために生まれたのがアジャイル開発手法です!

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

アジャイル開発とは

マイケル
マイケル
アジャイル開発は、1990年後半に提唱されたソフトウェア開発プロセスの総称で、
下記のようにイテレーティブ(反復型)のプロセスであることが特徴です!
マイケル
マイケル
ウォーターフォール開発と異なり、
一定の期間の中でリリース可能なものを作り上げて確認してもらうため、
要件変更や追加にも柔軟に対応することができるプロセスとなっています。
02 ajairu↑アジャイル開発の流れ
エレキベア
エレキベア
確かにこれなら途中で軌道修正できそうクマね
マイケル
マイケル
これまでの 人員・納期・品質 というスコープに、開発範囲を加えることで
必要最低限の機能に抑えることができるようになっているんだね。
ただその代わりに、開発メンバーは設計からテストまで行える多能工であることが求められるよ!
エレキベア
エレキベア
開発者にもそれなりのスキルが求められるわけクマね
マイケル
マイケル
それじゃ大体のイメージを掴んだところで、
アジャイル開発の考え方について見ていこう!

アジャイルソフトウェア開発宣言

マイケル
マイケル
アジャイルでは、アジャイルソフトウェア開発宣言
という考え方が公開されています。

アジャイルソフトウェア開発宣言


プロセスやツールよりも個人と対話
包括的なドキュメントよりも動くプログラム
契約交渉よりも顧客との協調
計画に従うよりも変化への対応

アジャイルソフトウェア開発宣言

プロセスやツールよりも個人と対話を
マイケル
マイケル
これは結局仕事をしているのは人であるため、ツールでの伝達だけで済まさず、
直接対話をすることで本来の意図や情報の抜け漏れも防ぎ、仕事を円滑に進めようという考え方です!
またコミュニケーションを円滑にすることにより、チーム内での知識共有にも繋がります。
エレキベア
エレキベア
人であるために対話で本来の意図を掴むのが大切クマね
包括的なドキュメントよりも動くプログラムを
マイケル
マイケル
これは決してドキュメントが不要ということではなく、
ドキュメントで判断するのでなく動くプログラムで判断しましょうという意味になります。
ドキュメントを書き終えても実際の価値には繋がっていないので、実物で判断することは重要になってきます。
エレキベア
エレキベア
ドキュメントも必要な場合は作成するが、判断するのは実物になるクマね
契約交渉よりも顧客との協調を
マイケル
マイケル
従来の開発では、最初に契約した納期通りに約束通りのものを作ることに専念し、それ以外のことはなるべくやらないようにしてきました。
しかし、アジャイル開発では変更を受け入れることを前提に顧客が求める価値を提供することを重要視しています。
エレキベア
エレキベア
納期最優先でいいものを提供できないのは
かなりの問題があったクマね
計画に従うよりも変化への対応を
マイケル
マイケル
これは先ほどの話とも繋がってきますが、変化を受け入れることを前提とし、
計画を改善しながら進めていく
ことを意味しています。
エレキベア
エレキベア
改善していくことで見積もりの精度もあげていくことができるクマね

12の原則

マイケル
マイケル
これらの宣言の背後には、下記のような原則が設定されています。
こちらもしっかり目を通して考えておきましょう!

アジャイル宣言の背後にある原則


私たちは以下の原則に従う:

顧客満足を最優先し、

価値のあるソフトウェアを早く継続的に提供します。

要求の変更はたとえ開発の後期であっても歓迎します。

変化を味方につけることによって、お客様の競争力を引き上げます。

動くソフトウェアを、2-3週間から2-3ヶ月という

できるだけ短い時間間隔でリリースします。

ビジネス側の人と開発者は、プロジェクトを通して

日々一緒に働かなければなりません。

意欲に満ちた人々を集めてプロジェクトを構成します。

環境と支援を与え仕事が無事終わるまで彼らを信頼します。

情報を伝えるもっとも効率的で効果的な方法は

フェイス・トゥ・フェイスで話をすることです。

動くソフトウェアこそが進捗の最も重要な尺度です。

アジャイル・プロセスは持続可能な開発を促進します。

一定のペースを継続的に維持できるようにしなければなりません。

技術的卓越性と優れた設計に対する

不断の注意が機敏さを高めます。

シンプルさ(ムダなく作れる量を最大限にすること)が本質です。

最良のアーキテクチャ・要求・設計は、

自己組織的なチームから生み出されます。

チームがもっと効率を高めることができるかを定期的に振り返り、

それに基づいて自分たちのやり方を最適に調整します。


アジャイル宣言の背後にある原則

エレキベア
エレキベア
4つの宣言についての考えが書かれているクマね

各種手法

マイケル
マイケル
これまでアジャイルの考えについて紹介しましたが、
これらはあくまで概念であり、実際の手法は別に定義されています。
ここではアジャイルの概念を適用できる主要な手法について2つ紹介します!
スクラム
マイケル
マイケル
スクラムは適応型ソリューションをチームで開発し価値を生み出すための軽量級フレームワークになります!
というと難しそうですが、イテレーションを回して開発を行っていくためのフレームワークというものになります。
エレキベア
エレキベア
アジャイル開発といえばスクラムというところもあるクマね
マイケル
マイケル
これについての詳細は、この後紹介していきます!
エクストリームプログラミング(XP)
マイケル
マイケル
エクストリームプログラミングはソフトウェア品質を向上させ、変化する顧客の要求を高めることを目的としたソフトウェア開発プロセスの総称です。
この中に具体的な手法がいくつもあり、主要なものを紹介します!

ペアプログラミング

2人1組で1台のマシンを利用して1つのプログラムを開発する手法。
レビューも同時に行うことで品質の高いコーディングが期待できる。
最近では3〜4人を1組で1つのプログラムを開発する「モブプログラミング」も流行っている。

リファクタリング

ソフトウェアの振る舞いを買えずに内部の構造を安全に改善する。
バグ発見が容易になる、提供するまでの時間が短くなる等の利点がある。

常時結合(継続的インテグレーション、CI)

自動的な結合、ビルド、テスト等の一連のプロセスを行うことでこまめに確認する。
開発が完了したコードから自動で常時ビルドを行う。

テスト駆動開発

テストコード作成→実装→リファクタリング
を短いサイクルで繰り返すことで開発を進める手法。
動く状態を保ちつつソースコードの構造を考えながらリファクタリングすることで、信頼性を高めながら開発できる。また、CIも行いやすくなるという利点もある。

エレキベア
エレキベア
どれもよく聞く手法クマね

スクラム開発

マイケル
マイケル
それではアジャイルの主要な手法であるスクラムについて紹介します!
基本的に、下記のスクラムガイドを参考にまとめてみました!

スクラムガイド

エレキベア
エレキベア
公式に提供されているのはありがたいクマね

スクラム開発とは

マイケル
マイケル
スクラム開発は1990年台初頭にケン・シュウェイバー(Ken Schwaber)、J・J・サザーランド(jeff sutherland)らによって開発されたフレームワークです。
1つのイテレーションを1スプリントとして扱い、複雑な問題に対応することのできる軽量なフレームワークとなっています。
02 ajairu↑1つのイテレーションを1スプリントとして扱う
経験主義とリーン思考
マイケル
マイケル
スクラム開発は「経験主義」と「リーン思考」に基づいています。
エレキベア
エレキベア
なんだか難しそうクマ・・・
経験主義
マイケル
マイケル
経験主義は「知識は経験から生まれ意思決定は観察に基づく」という考え方で、
透明性を高めた上で、検査と適応のサイクルを回すことを重視しています。


・透明性
→プロセスや作業を、作業を実行する人と作業を受け取る人に見えるようにする。
・検査
→望ましく無い変化や問題を検知するため、頻繁かつ熱心に検査する。
・適応
→許容範囲を逸脱していたり、成果が受け入れられなかったりした時には調整する。

エレキベア
エレキベア
状況を見えるようにして、経験から改善していこうというわけクマね
マイケル
マイケル
これから紹介しますが、スクラムでは検査と適応のための4つのイベントを用意しています。
リーン思考
マイケル
マイケル
リーン思考はムダを省き、本質に集中するといった考え方です。
これは説明するのが難しいですが、例をあげるとすれば
 ・やらなくてもいい作業はやらずに最低限のことだけ行うよう改善する
 ・フローの中のボトルネックを改善する
といったことがあげられます。
マイケル
マイケル
これも透明性が高くなって状況が分かるようになってこそ改善できることだと思います。
エレキベア
エレキベア
ムダなことや障害を取り除くということクマね
5つの価値基準
マイケル
マイケル
そしてスクラムで成功するかどうかは次の5つの価値基準を実践できるかどうかにある、と定義しています。


・確約
→ゴールを達成し、お互いにサポートすることを確約する。
・集中
→スプリントを達成できるよう集中する。
・公開
→スクラムチームとステークホルダは、作業や課題を公開する。
・尊敬
→お互いに個人として尊敬し、同じように尊敬される。
・勇気
→正しいことをする勇気や困難な問題に取り組む勇気を持つ。

エレキベア
エレキベア
中々全てを満たすのは難しそうクマね・・・

スクラムチーム

マイケル
マイケル
それではここからは実際のスクラムの進め方について紹介します。
スクラムチームは「プロダクトオーナー」「スクラムマスター」「開発者」で構成されます。
それぞれの役割は下記のようになっています。
04 roll↑スクラムでの役割
開発者

10人以下(6人程度が推奨)で構成され、利用可能なインクリメントを作成することを確約する。
また、次の結果に責任を持つ。
スプリントバックログを作成する。
・完成の定義を忠実に守る。
・ゴールに向けて毎日計画を適応させる。

プロダクトオーナー

1つのプロダクトに1名で、プロダクトの価値を最大化することの結果に責任を持つ。
また、効果的なプロダクトバックログ管理にも責任を持つ。

スクラムマスター

スクラムを確立させることの結果、スクラムチームの有効性に責任を持つ。
スクラムチーム、各メンバーに対してスクラム進行の支援を行い、障壁があれば取り除く

エレキベア
エレキベア
開発者、プロダクトオーナーに加えてスクラムマスター
というポジションがあるクマね
マイケル
マイケル
スクラムマスターはあくまで開発チームの実施プロセスがうまく回るよう支援するリーダーで、回るようになればチームから立ち退けるようになることが理想なんだ。
これら3つの役割で構成されて、更に
機能横断型で自己管理型な組織であることが求められます。


・機能横断型
→価値を生み出すために必要な全てのスキルを備えている。
・自己管理型
→誰が何をいつ行うかをスクラムチーム内で決定し、権限も与えられている。

エレキベア
エレキベア
これがスクラムチームクマか・・・

4つのイベント

マイケル
マイケル
スクラムでは下記4つのイベントを1スプリントとして、
反復、改善することで進めていきます!
03 sprint↑スプリントで開催するイベント
マイケル
マイケル
1スプリントは1ヶ月以内の決まった長さとし、
スプリント内でレビュー可能な成果物を作成し、レビューと振り返りを行なうことで改善していきます。
エレキベア
エレキベア
4つあるのは分かったクマが、英語ばかりでよく分からないクマ
マイケル
マイケル
これらのイベントを通して3つの作成物を作成するのですが、それは次の項目で紹介します。
それぞれのイベントについて何をするのかについては下記になります!
スプリントプランニング

スプリントで実行する作業の計画を立て、スクラムチーム全体の共同作業によって作成される。
プロダクトオーナーは参加者に対して、最も重要なプロダクトバックログアイテムそれらとゴールの関連性について話し合う準備ができているかを確認する。

デイリースクラム

計画された今後の作業を調整しながらスプリントゴールに対する進捗を検査し、
必要に応じてスプリントバックログを適応させる。
コミュニケーションを改善し、障害物を特定し、迅速な意思決定を促進する。

スプリントレビュー

スプリントの成果を検査し、今後の適応を決定する。
スプリントで何が達成され、自分達の環境で何が変化したかについてレビューする。

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

品質と効果を高める方法を計画する。
どのように進んだか、迷わせた仮説があれば特定しその真因を探求する。
不都合な問題が隠されてしまうため、スクラムマスターは心理的安全性を確保するよう気をつける。

マイケル
マイケル
経験主義で出てきた、検査、適応という言葉がちらほらと出てきています。
これらのサイクルを通して少しずつ改善していく、というわけです。
マイケル
マイケル
また、プロダクトバックログは作られたタイミングだと大きすぎたり
理解されていなかったりするため、別途リファインメントのイベントを設ける場合もあります。
バックログリファインメント

大きなエピックは小さなユーザーストーリー形式のプロダクトフィーチャーに分割する。
小さくすることで重要な価値を早く提供することができる。

エレキベア
エレキベア
改善しながら進めるというのが素晴らしいクマ
実施すべきイベントが定義されていると、現場にも取り入れやすいクマね

3つの作成物

マイケル
マイケル
これらのイベントを通して、「プロダクトバックログ」「スプリントバックログ」「インクリメント」の3つの成果物を作成します。
これらは透明性を高めるための確約が含まれており、イメージと概要は下記のようになります。
05 backlog↑ラーメン店との連携アプリ開発例
プロダクトバックログ

プロダクトの改善に必要なものの一覧であり、作業の唯一の情報源である。
リファインメントの活動を通じて、選択に必要な透明性を獲得する。

確約:プロダクトゴール
プロダクトの将来の状態を表しており、計画のターゲットとなる。

スプリントバックログ

スプリントゴール(なぜ)、選択されたプロダクトバックログアイテム(何を)、
実行可能な計画(どのように)で構成
され、開発者のための計画である。

確約:スプリントゴール
スプリントの唯一の目的であり、スプリントプランニングで作成される。

インクリメント

プロダクトゴールに向けた具体的な踏み石である。
価値を提供するためには、インクリメントを利用可能にしなければならない。

確約:完成の定義
プロダクトの品質基準を満たすインクリメントの状態を示した正式な記述である。
プロダクトバックログアイテムが完成の定義を満たした時に誕生する。

マイケル
マイケル
バックログはRedmine、Jiraといったツールを利用することで
管理しやすくなります。
また、スプリントバックログについてはタスクボードやカンバンを使用することで透明性を高めることができます。
エレキベア
エレキベア
なんとなくイメージは分かってきた気がするクマ
マイケル
マイケル
実践しないと掴めないところもあると思うから、
実際に適用して体で感覚を掴んでいくのが一番な気がするね

ニワトリとブタ

マイケル
マイケル
最後に、スクラム参考書などでよく出てくる「ニワトリとブタ」の話を紹介します!

むかしむかし、ニワトリとブタが話をしていました。
「いいアイデアがあるんだ」とニワトリは叫びました。
「レストランをオープンしようよ。店名はハムエッグ」と聞いてブタは少し考えて、こう答えました。
「遠慮しとくよ。キミはただ卵を産むだけ(関与するだけ)で、ボクは身を切らないと(コミットしないと)いけないからね。」
アジャイルなゲーム開発 より

エレキベア
エレキベア
アメリカンジョーククマ
マイケル
マイケル
これはニワトリをチーム外の顧客、ブタをチームメンバーとして、
スクラムにおける役割を例えた話です。
マイケル
マイケル
ニワトリはスプリント間のプロジェクトの方向性に影響を与えるため、
ブタと今後のスプリントゴールを議論し優先順位を決定する
必要があります。
ニワトリはチームが邪魔されずに達成できるようにコミットすることで、スクラムが機能する、ということのようです。
エレキベア
エレキベア
ちょっと皮肉も含まれてて面白いクマね

おわりに

マイケル
マイケル
というわけで今回はアジャイルとスクラムについてでした!
どうだったかな?
エレキベア
エレキベア
イメージは分かってきたから使ってみたいクマ〜〜!!
マイケル
マイケル
スクラムはあくまでフレームワークだから、原則さえ守っていれば
それぞれの現場に応じて独自のルールを取り入れるのも大事になってくるよ!
例えばゲーム開発だとどのように適用するべきか?については、下記の書籍が参考になりました!

アジャイルなゲーム開発 スクラムによる柔軟なプロジェクト管理

マイケル
マイケル
アジャイルやスクラムについての考え方や書籍はいくつもあるけど、
基本的な概念は同じだからそこは押さえておきたいね!
業界の違いだけに限らず、現場それぞれなところもあるから柔軟に取り入れていこう!!
マイケル
マイケル
それでは今日はこの辺で!
アデュー!!
エレキベア
エレキベア
クマ〜〜〜〜〜〜

【開発手法】アジャイル開発の考え方とスクラムの基礎知識について 〜完〜

コメント