8-6 アジャイル開発の始め方本文it.27monka-itaku.net/wp-content/uploads/b76a260d8901363fbbf9f6c… · アジャイル開発という考え方アジャイルとは何か

アジャイル開発の始め方世界中のトップエンジニアが採用している新しい開発手法

ソフトウェア開発における管理手法の問題ソフトウェア開発の大きな問題ソフトウェア開発管理の改善の歴史新しい開発手法の必要性

アジャイル開発という考え方アジャイルとは何かマインドセットシフトの必要性アジャイルの価値

スクラムによるソフトウェアの開発スクラムにおける体制と役割スクラムにおける活動と成果物要求とユーザーストーリー見積とベロシティ

アジャイル開発の始め方

ソフトウェアの開発プロセスの問題

ソフトウェア開発の大きな問題開発プロセスの改善の歴史新しい開発プロセスの必要性

リリース直前に大きな問題がいつも発生する

ソフトウェア開発の大きな問題

開発者

開発の進捗はどうでしょうか、順調に進んでいますか？

はい、いま設計をしているところです。来週から実装に着手します。

ヶ月前

開発者

設計はおわり、実装に着手してますか？

一部、設計が終わっていない部分がありますが、実装を始めてます。

ヶ月前

開発者

来月リリースですね、実装の進捗はどうですか？

不具合があり、少し遅れがありますが、順調に進んでいます。

ヶ月前

プロジェクトマネージャ

開発者

えっーー！いままで順調だったのに、なぜ？君たちのいうことは信用できない。

いま、徹夜で作業していますが、設計に問題があり、リリースに間に合いません。

リリース前日

ソフトウェアは、状態とプロセスの複雑な組み合わせによって構成されている。ソフトウェアを作るためのプログラミング言語自体はそれほど複雑ではないが、数種類の単純な制御文と様々なデータ構造を組み合わせることにより、複雑な処理を行っている。このため開発において、ソフトウェアの全体像が見えてくるリリース間際に、その複雑性は飛躍的に増加し、様々な問題点が顕在化する。




正確な計画と設計があったら、大丈夫？


画面を日で実装できるエンジニアを名集めて画面を日で完成させる。

プログラミングは、すべてフレームワーク内で実施し、予め決められた開発標準に従い、変数の命名規則等、すべてのコードのレビューを実施し、レビューが完了していないプログラムはリリースしてはいけない。

またレビュー後は、カバレッジ％のテストケースにより自動テストを実施する。

様々な方法論と業界標準を駆使した分析手法と開発標準をベースに、時間単位の正確な作業計画を作成する。

時間単位で作業をリアルタイムで監視し、遅れが発生した場合は、リソースを追加して対応する。

全てのさぎょうに関する正確な手順書を作成し、属人化を防止する。


業務を理解しているを名集めての業務を日間で分析して設計を行う。

設計はすべて○○方法論に基づいたテンプレートを使用して、技術内容を統一させる。

設計は一言一句レビューを通し、レビューが完了していない設計書は開発チームに渡してはいけない。

システムエンジニアプログラマ

正確な開発標準

正確な技術設計

正確な手順

正確な実施計画

正確な要求定義

正しく動くソフトウェア？

正確な計画と設計を作っても、それが実現できるとは限らない


ソフトウェアの開発において、完璧な計画と設計が最も大切とされてきたが、それらの計画や設計を実現可能なのかどうかを事前に評価する手段がないため、非現実的な計画や設計が行われることが多い。また、実現可能かどうかは、それを実行する開発者に依存することが多いが、開発者個人のスキルや経験は考慮されない場合が多い。

凹凸のない完璧な水平な平面

°

風の影響を受けないように円筒の防風壁

を立てる

鉛筆を垂直に立てる

大量生産の工業製品と違い、作るものがいつも異なる


今日の工業製品は、作りたい製品の原型を作り、それを複製することで大量生産を実現している。これにより、生産設備を追加したり、増加したりすることによって、納期や生産数を適切に管理することが可能となっている。

しかしながらソフトウェアの場合、作りたいソフトウェアの要件の複雑さ、ソフトウェアの作り方や設計方法、開発者の経験や作業速度、使用する技術の成熟度や難易度等、様々な要素によって生産性が大きく変化する。このため、ソフトウェアの完成時期を予測することはとても難しく、正確な見積も困難であり、予め設定したゴールを計画通りに達成することはほとんどない。

この工程の流れは同じでも、作るものは毎回異なる。

話を聞いて分析して設計して製造してテストする



開発プロセスの改善の歴史

開発プロセスの変化

～1970 1980～1990 1990～2000 2000～2010

ウォーターフォール型

反復型（スパイラルやプロトタイピング、RUP）

アジャイル型（広義では反復型）

大規模アジャイル型


ウォーターフォール型（増加型）と反復型の大きな違い

全体を分割して部分的な実装を行いながら、組み合わせて開発を行うのがウォーターフォール型

全体の構造を実装しながら、基本機能から詳細機能を作り込んで開発を行うのが反復型


予測に基づくウォーターフォール型の開発プロセス

年代に考案されたプロセスであり、複数の段階を順番に実行していくことでソフトウェアをつくるというものである。まず作りたいソフトウェアの要求を定義して合意し、それを基に設計を行い、そこからプログラミングを行いソフトウェアを作成し、最後にそれらが正しく動作するかを検証するという流れで作業を行う。

このモデルは大規模プロジェクトではうまく機能せず、割のプロジェクトが中止され、割のプロジェクトが予算超過となり、納期通りに実現できたプロジェクトは割未満だったという統計結果も出ている。しかしながら、現在の多くの開発プロジェクトで使用されている。

業務分析

要求定義

分析及び設計

実装

テスト


ウォーターフォールがうまくいかなかった３つの要因

ヒアリングの不足不完全な要求と設計要求や設計の度重なる変更

ソフトウェアの要求を定義する際に、ユーザーからのソフトウェアの機能に関する意見を細かく取り入れることができなかったため、必要な機能が実装できなかったり、ユーザーのイメージと異なるものが出来上がってしまい、手戻りが発生してしまった。

要求と設計の記述において、ソフトウェアの規模が大きくなればなるほど、要求と設計の整合性や過不足の確認が困難になる。このため、実装段階に入ってはじめて様々な問題が判明し、実装がストップしてしまった。

完全な要求や設計を行っても、外部環境の変化等の要因によって、設計中の要求の変更や実装中の設計の変更が発生してしまい、多くの手戻りによって、納期や予算を超過してしまった。


それでもウォーターフォールが採用される理由

ウォーターフォール型は大規模なプロジェクトでの成功事例は少ないものの、その段階的なアプローチがシンプルで分かりやすく、またもっとも長い設計及び実装期間の作業負荷が低いため、多くのプロジェクトで採用されている。

また、ウォーターフォールでは最後のテスト行程を最も重要視する傾向があるが、その理由は、テストがプロジェクトリスクを解消させるための唯一の手段であるためであると考えられる。

ウォーターフォール型の開発におけるユーザーやマネジメントにかかる負荷

要求定義設計及び実装テスト

最も時間のかかるこの期間に問題が起きにくいため楽である

ウォーターフォール型の開発における潜在的なリスクの大きさ

要求定義設計及び実装テスト

机上による評価のためリスクは減少しない


フィードバックを取り入れた反復型の開発プロセス

ウォーターフォールの反省をもとに、要求を理解するために実験的な試作品を作りながら、それらのフィードバックを活用して要求を固めていく手法を取り入れたのが反復型の開発プロセスである。

反復型の開発プロセスの一つであるラショナル統一プロセス（）は、方向づけ、推敲、作成、移行というフェーズで構成されているが、ウォーターフォールと異なり、各フェーズにおいて要求の定義や設計が段階的に実行されるのではなく、それぞれのフェーズの中で設計や実装、テストなどが重なり合いながら実行されるプロセスである。このため、ソフトウェアの実装中に判明した新しい要求を取り入れたり、設計を変更したりすることが可能になっている。

方向づけ推敲作成移行

反復反復反復反復反復反復反復反復

要求定義

業務分析

分析及び設計

実装

テスト


ユーザーやマネジメントにかかる負荷と開発リスク

反復型の開発プロセスでは要求定義や設計、実装及びテストを定期的に繰り返すため、ウォーターフォール型の開発プロセスと比較して一定量のユーザの負荷やマネジメントの負荷がプロジェクト期間中に発生する。しかしながら、プロジェクトのリスクや問題点の早期発見を行うことができるため、プロジェクトのリスクは早い段階で解消することが可能である。

反復型の開発におけるユーザやマネジメントにかかる負荷

要件定義設計及び実装テスト

平均して負荷がかかる

反復型の開発における潜在的なリスクの大きさ

要件定義設計及び実装テスト

実装して受入テストを繰り返すことによりリスクが減少



新しい開発プロセスの必要性

新しい開発手法が必要な３つの理由

生き続けるウォーターフォール

テクノロジを活用したデジタルサービスの登場

ソフトウェア開発のおけるテクノロジの進化

コーディングの自動化

ネット配信


ウォーターフォール型が生き続ける理由

ユニファイド統一プロセスは、ウォーターフォール型の開発プロセスが対応できなかった大規模プロジェクトにおいて多くの成功事例を持っていると言われている。しかしながら、いまだにウォーターフォールの開発プロセスが主流となっているのは何故か？

その主な原因は、非常にわかりやすく理想的であるということ、プロジェクトの中盤まで問題が起きないためうまく進むということ、顧客の要求が期日と要求を基本としていることの３つだと考えられる。このため、関係者が多く、大規模であればあるほどウォーターフォールモデルが採用されることが多い。


反復型のRUPは、よくわからないけどウォーターフォール型は基本的なプロセスのようだから、少し勉強すればできそうだ。

今回のプロジェクトは、納期も作ることも決まっており、契約もこの内容で書いてあるから、ウォーターフォールでやらなければだめだ。

前回、ウォーターフォール型のプロジェクトでは、テストの直前まではうまくできたので、テストフェーズをしっかりやれば、成功するぞ。今回もウォーターフォール型にしよう。


テクノロジを活用したデジタルサービスの浸透

スマートデバイスとインターネット環境の急速な普及により、音楽配信やビデオ配信等のデジタルデータを活用したデジタルサービスの普及が急速に進んでいる。

ドバイではという裁判の申立から判決までのプロセスをスマートフォンを用いて時間日可能なバーチャル裁判所サービスを提供している。市民、法律事務、書記官、裁判官、傍聴人はスマートフォンを使用して裁判プロセスを実行することが可能であり、テクノロジがなければ実現が困難なサービスである。


これまでのビジネスにおいて、テクノロジーはビジネスを実現するための手段だった

ビジネスモデルそれを実現する技術ビジネス


いまやテクノロジー主導でビジネスが変革しておりこれらの開発に対応できる新しい開発プロセスが求められている。

ビジネスモデル

技術


従来の開発手法による開発

モデル駆動型開発手法による開発

話を聞いて分析して設計して製造してテストする

話を聞いて設計して自動で製造させてテストする

コーディングを行わないソフトウェア開発手法の拡大

クラウドコンピューティングの拡大とソフトウェアモデリングの発展に伴い、モデル駆動型開発手法を中心としたコーディングを行わないソフトウェア開発手法の採用が拡大している。この流れに伴い、これまでのスクラッチ開発中心の開発プロセス自体への見直しが進んでいる。


必然的に反復型の開発プロセスが発生

最新の開発手法によってコーディングが自動化されたことにより、これまでの開発プロセスでもっとも時間とコストがかかっていたソフトウェアの設計と実装の時間が飛躍的に短縮され、開発プロセス自体が自然に反復型となる。このため、この新しい開発手法に対応した新しい開発プロセスが求められている。

ヒアリング担当

開発者

ユーザー要求定義

作りたいイメージ

二週間単位で使えるシステムを作ることが出来るようになり自然と反復型になる

この部分の作業をソフトウェアを使用して自動化

設計＆実装

アジャイルという考え方

アジャイルとは何かマインドセットシフトの重要性アジャイルの価値

アジャイルとは何か

ウォーターフォールからアジャイルへ

成功

ウォーターフォール

成功

アジャイル

年から年のソフトウェア開発プロジェクトの成功率を開発プロセスで比較した場合、アジャイル開発はウォーターフォール開発と比較して３倍の成功率となっており、ウォーターフォールよりも開発期間と開発コストが低いという結果が出ている。このような結果からも、アジャイルの考え方はこれから世界中で広まっていくと考えられる。


アジャイルとは最高のチームを作るための方法論

アジャイルとは、ソフトウェアの開発チームが、いままでより効果的な考え方をしたり、効率的な作業方法を実践したり、よりよい決定をするための手順や方法論をまとめたものである。

これらは、従来型のソフトウェア開発やプロジェクト管理、プロセス改善などの領域に適用することができ、ソフトウェア開発に係るプロセス全体を改善することができる。


アジャイルは計画重視ではなく価値重視型

ウォーターフォール型を代表するこれまでの開発プロセスは、プロジェクトの立ち上げ時にプロジェクトの計画を立て、その計画からぶれないようにプロジェクトを遂行していく計画重視型のプロセスである。

アジャイルでは、プロジェクトの立ち上げ時にコストとスケジュールを固定し、より良い価値を追求するために、必要に応じてスコープを可変させるという価値重視型のプロセスであることが大きく異なる。より良い価値をチームで一丸となって追求することで、チームの自己組織化と開発チームの生産性の向上を図ったものになっている。

スコープ

スケジュールコストスコープ

スケジュールコスト

ウォーターフォール型アジャイル型プロジェクトの立上げ時に固定

状況に応じて可変


ウォーターフォール型と反復型との違い

価値重視型計画重視型

業務分析

要求定義

分析及び設計

実装

テスト

業務分析

要求定義

分析及び設計

実装

テスト

業務分析

要求定義

分析及び設計

実装

テスト

アジャイル型ラショナル統一プロセスウォーターフォール型

反復型

業務分析

要求定義

分析及び設計

業務分析

要求定義

分析及び設計

業務

要求定義

業務

要求定義

分析及び設計分析及び設計


ウォーターフォール型とアジャイル型の基本的な考えの違い

計画及び方針、体制を決めてスタートしなければ、物事を進めることができないため、計画と体制作りに時間をかけ、準備を万全にする必要がある。問題がある場合は、作業を停止し、計画と体制を見直さなければならない。

計画段階では、やってみなければ分からないことが多く存在するため、マネジメントが大変だが、プロジェクトを進行しながら、計画と体制を変更しつつ迅速に適合させていかなくてはならない。

すべての実装は、単体テストを完全にパスするまで実装をやめてはいけない。作業時間が足りない場合は納期を延期して、リソースを強化し、実装作業の継続を優先させなければならない。

完全な設計を行わなければ、品質が低下してしまう。そのため、実装の前行程にて詳細設計を完璧に行わなければならない。

イテレーションの期間中に実装できなかったものや単体テストをパスできなかった実装は、作業途中であっても、次のイテレーションへ繰り越す。リズムと期間を固定化することにより、納期への意識付けと開発効率性の向上を図る。実装できないものが増加した場合は、チーム単位で体制を変更する。

設計は実装の品質に大きな影響を与えるため、設計の正しさを判断するために、すぐに実装を行い、受入テストをを実施することで、設計の不具合を検証する。

ウォーターフォール型の考えアジャイル型の考え


アジャイル型のマネジメント手法の特徴

顧客の価値とフローに着目成果物と計画に着目

チームは自律的に活動するプロジェクトマネージャによって管理される

仕様変更は期待され歓迎される仕様変更は厳格な変更管理プロセスによって拒否される

顧客は業務変更やソフトウェア開発に積極的に参加する顧客は月次の定例や承認で限定的に参加する

前進しながら計画を立てていく事前に詳細な計画を立てる

顧客が優先度を決定し、限られた時間でデリバリを行うマネージャが交渉して、スコープ主体でデリバリを行う

機能のロードマップによって管理されるWBSによる進捗管理によって管理される

自律的に活動するチーム同士が協同するトップダウンで指示及び制御される

必要最低限の軽い方法論を使用するしっかりと規定された重い方法論を使用する

価値に着目した評価基準官僚的な評価基準とコントロール

アジャイル型におけるマネジメント手法は、従来の手法と大きく異なるため、プロジェクトマネージャレベルではなく、ソフトウェア開発に携わるプロジェクトメンバ全員がその手法を理解しなければならない。

従来型のマネジメント手法アジャイル型のマネジメント手法


ウォーターフォール型とアジャイル型における役割の違い

ビジネス


ビジネス分析

アーキテクチャ

開発

インテグレーション

テスト

移行

システム運用

ウォーターフォール

プロダクトオーナー

デリバリーマネージャ

スクラムマスタ

カスタマ＆ユーザーエクスピアリエンス

エンジニアリング• アーキテクチャ• 開発• インテグレーション

テスト

DevOps

アジャイル



マインドセットシフトの重要性

アジャイルを実践するにはまず「考え方」を変えること

アジャイルによる開発手法を導入したけれど、目覚ましい効果が出ていないというチームが多く実在している。この原因の多くは、アジャイルを実践するチーム全員がアジャイル型に考え方を切り替えるというマインドセットシフトを行っていないためである。

アジャイルを用いて最高のチームを作るためには、プロジェクトマネージャだけでなくチーム全員が、アジャイルの新しい考え方を理解しなければならない。特に従来型の開発の経験が多ければ多いほど、マインドセットシフトに時間がかかると考えられるため、アジャイルの実践中においても、常にアジャイルのマインドセットを確認できる仕組みを作り上げる必要がある。


アジャイルを初めて実践するプロジェクトマネージャアジャイルを初めて実践する開発者たち

アジャイルを取り入れて最高のチームを作り上げてみせるよ！私の言うルールに従ってくれ。

アジャイル？開発の生産性が上がるのなら協力してもいいよ。


デイリーミーティングにおけるマインドセットの問題

毎朝、チーム全員が集まってデイリーミーティングを実施します。そこで各自、前回のミーティングから実施した内容と、これからやること、自分の作業の妨げとなる障害になっていることの３つを報告してください。

プロジェクトのルール

プロジェクトマネージャ開発者

計画通りに開発が進んでいるか毎日チェックして問題点を把握するぞ。

毎日、毎日、ミーティングの時間がもったいない。分でも時間が惜しいので、ミーティングが面倒だ。早く開発に戻りたい。

昨日の作業が遅れちゃったな、でも今日取り戻せばいいので、順調に進んでいると報告しておこう。

問題点はその場で指示してチームを適切な方向へ導くから、具体的に言ってくれ。


週間単位のイテレーション開発におけるマインドセットの問題

これから2週間単位でソフトウェアをリリースしてください。作ってほしい要件を伝えるので、その後はチーム内でどういう順番でどういうふうに開発するかを話し合って決めてください。

プロジェクトのルール


スケジュールに従い、週間単位でリリースしてテストしてレビューを通してほしい。

週間単位で何をリリースしていけばいいの？２週間で正しく動くものを作るのは無理じゃない？

問題が発生したり、途中で要件が変更が変更された場合はどうするの？それを取り込んでリリースすることは大変じゃない？

作業が遅延した場合は二週間ごとに計画を立て直すので協力してほしい。


リーダーシップにみるマインドセットの違いによる問題


先週は開発が進まなかったなあ。開発者はあまりプロジェクトのことを考えていないので、私が仕事をアサインしないと進まない。

伊藤さんはの開発担当にして、山田さんはの開発担当、佐々木さんはの開発担当にしたいけど、そうするとの開発担当をどうしようかな、アサイン計画を立てて、明確に指示しないとプロジェクトが止まってしまう。

この機能の実装ってあまり価値がないように見えるなぁ。もう少し要件を検討したほうがよさそうなんだけど、先が見えない。でも、意見したら叱られそうだし。

最近は運用部分の実装ばかりやっているので、次の開発ではモバイルのアプリを作ってみたいけど、無理かなぁ。モバイルはたぶん小林さんがやるんだろうな。

計画通りやっているけど、なんか違和感あるし、うまくいくとはおもえないな。でもが言っているから仕方ない。


アジャイルが最も大切にしているものはヒトそのもの

プロジェクトマネージャも開発者も、みんな一人の人間。

それぞれに将来の夢や仕事への異なる価値観があり、能力の差はあるかもしれないけど、みんな一所懸命に仕事に取り組んでいる。

仕事を辞めたり、会社を辞めたりする時、その理由の多くは人間関係であり、仕事のパフォーマンスもその人間関係に左右される可能性が高い。

ソフトウェアの開発には複雑な問題を解決するためのプロセスや、効率性を高めるためのツールがとても重要だが、個人と対話こそが最も重要な価値である。

この考え方を理解し、チーム全員のマインドセットシフトを行わない限り、アジャイルの導入の実現は困難である。



アジャイルの価値

アジャイルソフトウェアの開発宣言にみるアジャイルの価値

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

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

契約交渉よりも顧客との協働を

計画に従うことよりも変化への対応を


優れたプロセスとツールより大切なものは個人と対話

もし、優れたプロセスとツールを用意することでソフトウェア開発プロジェクトを成功に導くことができるのであれば、ソフトウェアの開発経験の少ないエンジニアとマネジメント経験のないマネージャにプロジェクトを任せることができる。

しかしながら、どんなに優れたプロセスやツールがあっても、それを実行する個人の力量によって、プロジェクトの成功は大きく左右されてしまうことが多い。また、どんなに優れたマネージャがいても、ソフトウェアを作る開発者が一人もいなければ、ソフトウェアを作ることさえも出来ない。

アジャイルがプロセスとツールを重要視しながらも、それ以上にチームメンバの各個人に着目し、チームメンバとの対話に価値を置いているのは、このような現実に常に直面しているためである。


ドキュメントよりも動くソフトウェアを重視

ソフトウェア開発で必要なものは、正しく動くソフトウェアであり、大量のドキュメントではない。

アジャイルでは、ユーザーに対して定期的に動くソフトウェアを提供するために、ソフトウェアを作るために必要なドキュメントよりも、正しく動くソフトウェアの実装とテストにフォーカスしている。動くソフトウェアそのものが進捗の最も重要な尺度である。

このためチームでは、単体テストからシステムテストまでの様々なレベルのテストの実施を視野に入れ、ユーザーが操作できるレベルに達するまで、可能な限りの多くのテストを実施することに価値を求めている。


契約内容ではなく顧客と協働することを重視

年近く前から、顧客が開発プロジェクトに積極的に参加し、定期的なフィードバックを行いながらソフトウェアの開発を進めていくプロジェクトでは、従来の倍以上の成功率を収めている。このため、アジャイルでは顧客の積極的なプロジェクト参加に大きな価値をおいている。

しかしながら、実際のプロジェクトにおいては、顧客がプロジェクトチームに常時参加することは不可能であるため、顧客へのコンタクトポイントを集中させ、プロダクトオーナーと呼ばれる顧客の代理を立てることによって顧客とのコラボレーションを実施する。

チーム内に顧客と同じ視点をもったプロダクトオーナーを配置することで、顧客が求める価値を開発チームが素早く正しく理解することが可能となる。


計画に従うのではなく変化に対応することを重視

ソフトウェアの機能や要求の％は、プロジェクト中に変化していくと言われており、顧客が求めるものは常に時間と共に変化していくものだと考える必要がある。

また顧客は実際に動くソフトウェアをみなければ、本当の要求を理解できないことが多く、アジャイルでは多くのフィードバックを顧客の代理人であるプロダクトオーナーから受け取れるプロセスになっている。

顧客の求める価値の％は、実装される機能の％に含まれていると言われており、チームは動くソフトウェアを作りながら、顧客が求める価値を追求し、常に変更する要求に対応できる心構えを持つ必要がある。

スクラムによるソフトウェア開発

スクラムにおける体制と役割スクラムにおける活動と成果物要求とユーザーストーリー見積とベロシティ

スクラムにおける体制と役割

スクラムは強力だが銀の弾丸ではない

オセロのキャッチフレーズとして「覚えるのに一分、極めるのは一生」という言葉がある。スクラムは一分で理解することはできないが、とてもシンプルでわかりやすいルールが定義されており、それを理解することは難しくない。しかしながら、オセロと同じく、それをマスターすることはとても難しいとされている。

スクラムのプロセスはとてもシンプルであるため、アジャイルの考え方へのマインドセットシフトを実施する前に、そのプロセスを計画重視の考え方のまま使用してしまうケースが多い。この場合、プロセスとしては機能するが、ソフトウェアの品質や生産性は低下してしまい、結果としてスクラムは使えないという意識を全員が持ってしまう。

このような間違ったプロセスの適用を防ぐためにも、従来の計画重視の考え方から個人と対話を重視したアジャイルの考え方へのマインドセットシフトがやはり重要である。

スクラムをマスターすることが難しい理由は、アジャイルが単なるツールやプロセスではなく、モノづくりの考え方自体を見直すためであり、プロジェクトマネージャだけでなく、ユーザーとなる顧客や開発者を含め、チーム全員がアジャイルのマインドセットを理解し共有することが必要なためである。スクラムは銀の弾丸ではない。


週間の反復でスクラムを行う場合の開発のイメージ

プロダクトオーナーソフトウェアの機能と要求の責任者

作りたいもの

プロダクトバックログ作りたいソフトウェアの要求定義

開発チーム設計と実装及びテストを行う技術者

スプリントバックログ週間の実装期間で実装を予定している要求定義

スクラムマスターチームの生産性を向上させる責任者

インプリメント前回の週間で実装された実際に動作させることができるソフトウェア

二週間単位で動くソフトウェアをリリースしていく

ユーザーや利害関係者


プロダクトオーナーの役割

プロダクトオーナーとは、作るべきソフトウェアの機能や要求をすべて理解しているチームのリーダーのことである。

このため、開発するソフトウェアの機能の実装と優先順位に責任をもっており、プロダクトバックログと呼ばれるソフトウェアの機能や要求の整理と優先付けを行う。このため、プロダクトオーナーは、ソフトウェアの機能や要求のメンテナンスを行うために、技術的なことも含めてプロジェクトに係るすべてのステークホルダと常に話し合いを行い、ソフトウェアの機能や要求を必要に応じて追加や削除を繰り返しながら整理していく。

また、開発チームからの機能や要求に関する疑問に対して、スクラムマスターと協働しながら、できる限り早く回答を行い、実装やテストを支援して、チームの生産性を向上させる役割も持っている。


プロダクトオーナーソフトウェアの

機能と要求の責任者


作りたいもの

現状や課題

プロダクトバックログ作りたいソフトウェア

の要求定義


機能や要求に関する質疑


スクラムマスターの役割

スクラムマスターとは、プロダクトオーナーと開発チームのコーチとして、最高のパフォーマンスを発揮できるようにするチームのマネージャーである。

スクラムを導入する場合、チーム内に不安や混乱が生じることが少なくない。スクラムマスターは、チームのマインドセットシフトの手助けを行い、スクラムの導入に関して直面する不安を解消しながら、チームに合った適切なプロセスを定義してチームの生産性を改善を行っていく。

またチームの生産性を向上させるために、チームメンバーが直面した障害や外部からの妨害を取り除くことにも責任をもつ。スクラムマスターはサーバントリーダーと呼ばれており、チームメンバーへ指示を行わず、チームを助けるために活動のみを行う。



スクラムマスターチームの生産性を向上させる責任者


他のチーム

様々な要求

様々な批判や意見

不安の解消

プロセス定義

チームの手助け

様々な影響からチームを守る


開発チームの役割

開発チームとは、プロダクトオーナーと話し合って決めたスプリントバックログを、予め決められた期間で設計、実装及びテストを行うチームのことである。

スクラムにおける開発チームでは、アーキテクトやデザイナー、データベース管理者、テスターなどが一つのチームとして構成され、設計と実装、テスト等、プロダクトを作るために必要な作業に責任を持つ。

また、開発チームはソフトウェアを開発することに専念するために、チーム外のコミュニケーションは基本的に行わない。開発時に機能の詳細や要求事項で疑問が生じた場合は、開発するための機能や要求の詳細を把握しているプロダクトオーナーに対して相談を行う。発時に発生する様々な障害や問題の場合は、スクラムマスターに相談をしながら解決していく。


プロダクトバックログ作りたいソフトウェア

の要求定義


機能や要求に関する質疑

プロダクトオーナーソフトウェアの

機能と要求の責任者

プロダクトインプリメント前回の週間で実装された実際に動作させることができるソフトウェア



スクラムにおける活動と成果物

スクラムの基本パターン

スプリント実行

デイリースクラム

スプリント計画

プロダクトバックログ

スプリントレビュースプリント

バックログインクリメント

グルーミング

レトロスペクティブ

スプリント


スクラムのスケジュールのイメージ1/8 – 1/19 1/22 – 2/4 2/7 – 2/18 2/21 – 3/1

プロダクトバックログ数：30

新しいバックログ数：21












スプリントレビュー

















































プロダクトバックログとは、プロダクトオーナーがチーム内外のプロジェクトの利害関係者から集めたソフトウェアの機能や要求、改善要望等を、そのサイズと共に、価値の高い順に並べたものである。

スクラムにおいては、価値のある仕事を最優先して遂行していくが基本であるため、常にプロダクトバックログの優先順位が重要視される。開発中の場合、プロダクトバックログの中には、新規の機能や既存機能の変更要求、不具合の修正要求、技術的な改善などが含まれ、これらも優先順位順に並べられる。

プロダクトバックログのサイズは、それを作るための工数と比例するが、絶対的な基準を用いてサイズを定義することは難しいため、「機能Ａをとすると、機能Ｃはぐらいかな」という風に相対的に決定していく。

機能R 6

作り直しF 11

不具合修正16 1

機能C 2

機能D 8

機能A 1

処理速度改善Ａ 6


優先順位


メンテナンス


グルーミング

グルーミングとは、プロダクトバックログの工数見積や、分割、統合、新規追加、優先順位の変更、削除など、プロダクトバックログの作成と改良、見積、優先順位付けを行う作業のことである。

グルーミングは、プロダクトオーナーによって実施され、ユーザーや利害関係者の意見や、開発チームからのフィードバックを取り入れながら実施していく。グルーミングを実施するタイミングは、明確に決められていないが、スプリント計画時やスプリント計画時に行ったり、必要に応じてスプリント実行中でも実施される。

機能R 6

作り直しF 11

不具合修正16 1

機能C 2

機能R 8

機能B 2

処理速度改善Ａ 6

機能K 2

機能変更G 8

機能F 3

機能A 10機能R 8

機能B 2

機能A 機能A 10

工数見積

分割新規追加

削除優先順位変更

機能S 2

機能Z 1機能ZS 3

統合


スプリント

スプリントとは、チームが作業を完了させるための固定期間の反復の単位のことである。ひとつスプリントは、一般的に週間から週間で構成され、常に同じ長さのスプリントを定義し、開始日と終了日を固定することで、開発を進めていく。

スプリントがタイムボクシングと呼ばれる固定期間による作業を基本としている理由は、一度に実行する作業数の制御や、優先順位の明確化、正確な進捗報告の実現、完璧主義の排除、計画のしやすさである。また、終了日を明確にすることで、チームにモチベーションを与えることができる。

固定期間固定期間固定期間

スプリントスプリントスプリント

全てのスプリントは同じ期間で設定する

スプリント内の活動



スプリント計画とは、これから始まるスプリントで実装されるプロダクトバックログを選択し、スプリントを実行するためのタスクを定義することである。

スプリント計画は、通常二つのパートで実施される。最初のパートでは、これからのスプリントで何を作るか（ＷＨＡＴ）に着目し、プロダクトオーナーと話し合いながら、プロダクトバックログの優先度やサイズを基準にそれらの選択を行う。次のパートでは、どうやって作るのか（）に着目し、それら選択されたプロダクトバックログをタスクレベルに落とし込み、工数や実現可能性を考慮してスプリントゴールを調整していく。

スプリント計画にかける時間は、週間のスプリントで約時間が標準的な時間である。


スプリントバックログ



スプリントバックログとは、スプリント計画で作成され、スプリント内で実施されるタスクのセットであり、プロダクトバックログをタスクに分解したものである。スプリントバックログは、スプリント実行中は開発チームによって定期的にメンテナンスが行われる。

スプリントバックログは、そのスプリントのゴールでもあり、これらを完了させることがスプリントの目標となる。

不具合修正16 1機能D 8機能A 3

データモデル定義 3h

自動テストの作成 2h

Uiの実装 2h

データモデルの修正 3h


パーツの実装 8h

エラーログの追加 2h

ボタンの処理の修正 3h


アクションの追加 4h

ダイアログの追加 8h

タスクタスクタスク



スプリント計画によって、スプリントバックログが決定すると、開発チームはスクラムマスターの支援を得ながら、開発を進めていく。

スプリントの実行では、タスクレベルに落とされたものをどのようにどのような順番ですすめるかを開発チームに指示する人はいない。このため、開発チームはスプリントのゴールに向かって自己組織化を行いながら、開発を進めていく必要がある。



機能D 8

データモデルの修正 3h


パーツの実装 8h

エラーログの追加 2h

タスク


開発チーム設計と実装及びテスト

を行う技術者

実施



デイリースクラムとは、開発チームが時間毎に分以下のミーティングを行う活動のことである。

チームメンバは各々が、前回のデイリースクラムからどんな成果を上げたのか、次のデイリースクラムまでにどんな作業を行うのか、作業を妨げる障害や妨げは何か、の３つの問いに答えることを基本としている。チームメンバ全員が、これらの問いに答えることにより、スプリントゴールに向けて誰が何をしているのかを把握し、計画の変更の必要性や解決すべき問題を明確化することが目的である。

デイリースクラムは、問題を解決するためのミーティングではないため、問題の解決策について話し合う場合は、デイリースクラムの後に、少人数で集まって話し合いを行う必要がある。また、従来のプロジェクトマネジメント手法におけるプロジェクトのスタータスを更新する行為とは異なり、より良い仕事を行うために、開発チームだけで実施するミーティングである。




インクリメント

インクリメントとは、各スプリントにおいて開発されたプロダクトバックログの結果であり、実際に動作させることができる機能のことである。

各スプリントで開発されたプロダクトバックログのインクリメントは、予め開発チームで定めている完了の定義に基づいた評価と、該当するプロダクトバックログに定義された受入れ基準に基づいた評価により、作業完了の判断が行われる。完了の定義は、一般的に、設計、実装、テスト、ドキュメンテーションの作業を完了させることを基本としているため、これらの作業が完了し、かつプロダクトバックログの受入れ基準を満たした場合に、そのインクリメントは作業完了となり、該当するプロダクトバックログも完了となる。

作業完了と評価されたインクリメントは、リリース可能なインクリメントとして、プロダクトオーナーの手に届けられるが、リリース可能なインクリメントを実際にリリースするかどうかはビジネス判断となる。

機能A 3

受入れ基準

スプリントの完了の定義

・設計がレビューされていること・プログラムが実装されていること・ロジックのリファクタリングが完了していること・ユニットテストが完了していること・リグレッションテストが完了していること・既知のバグがゼロであること・デモ環境に配備されてること・ドキュメンテーションが完了していること

○○が○を登録することができる。△の場合、○○○が表示される。□を選択した場合は、○○が表示される。もし○の場合は、△を行うことができる。



スプリントレビューとは、スプリント実行が終わった後にプロダクトオーナーや開発チーム、その他の利害関係者や他のチームを集め、リリース可能なインクリメントに対して、それが満足できるものかどうかを話し合い、開発の方向性を修正していく最も重要な活動の一つである。

スプリントレビューでは、顧客やその他の様々な利害関係者に対して、リリース可能なインクリメントのデモンストレーションを行いながら現在のプロジェクトの進捗を明確に示す必要がある。このデモンストレーションを通して、それらが本来の目的と適合しているかどうか、不足はないかどうか、やりすぎてないかどうか等を質疑応答を繰り返しながら全員で検討を行い、その後のグルーミングやスプリント計画で方向性を修正していく。

スプリントレビューは、現状の開発の状況を理解し、その方向性を決定することが目的であるため、現在抱えている課題の解決に関する話し合いは別のミーティングで行うことが望ましい。




スクラムマスターチームの生産性を向上させる責任者インクリメント

他のチーム

デモ

過不足に関する意見

様々な質問

開発内容の説明

利用可否の判断




レトロスペクティブとは、スプリントレビューと同じくスプリント実行後に実施され、プロダクトオーナーとスクラムマスター、開発チームの全員が参加し、直前のスプリントにおける活動を振り返りながら、開発プロセスを改善するための施策を話し合うミーティングのことである。

レトロスペクティブは、直前のスプリントで開発したソフトウェアではなく、それを作り上げたプロセスにフォーカスすることにより、これからも続けていくこと、次のスプリントでやめること、次のスプリントでやってみたいことをバックログとしてまとめ上げていく。個々のチームメンバが自らの活動を振り返りながら改善を続けることで、チームの自己組織化が徐々に実現する。

また、レトロスペクティブを効果的な活動にするためには、チーム全員が同じ気持ちや意気込みを持つ必要がある。このために、スプリント中に起きたイベントと各個人の感情の変化を時系列で示したエモーショナルセイスモグラムを使用して、チーム全員で一つのコンテキストを共有するという方法が効果的である。

感情の起伏

発生した様々なイベント


スクラムにおける体制と役割スクラムにおける活動と成果物要求とユーザーストーリー見積とベロシティ技術的負債の管理

要求とユーザーストーリー

スクラムにおける要求定義

要求定義は、これから開発を行うソフトウェアに求められる機能を定義したものである。スクラムでは従来のウォーターフォール型の要求定義の方法と大きく異なる。このため、スクラムによる開発を導入する場合、この大きな違いが導入の壁となることが多く、チームメンバ全員が共通の理解を持つことが大切である。

ウォーターフォール型の要求定義は、プロジェクトの前半で詳細化され、設計や実装時にその内容を変更することは難しい。このため、というプロジェクト前半に巨大で詳細な要件が出来上がるという状態が発生し、多くのプロジェクトが失敗へ進んでいく。

ソフトウェアは、それが正しく動かなければ価値がない。ソフトウェアは完成するまで目で見ることも触れることも出来ないため、机上でソフトウェアの機能を詳細に定義したり、設計することは困難である。このため、動くかどうかもわからない、価値があるかもわからない要求定義をプロジェクトの前半で完了させてしまうウォーターフォール型の開発を大規模プロジェクトに適用することは避けるべきである。実際に、ウォーターフォール型のプロジェクトでは変更をゼロにすることは難しいため、多段階承認の変更管理プロセスを使用して変更を管理していくが、このプロセスは非常に重たく、迅速な対応は不可能である。

スクラムでは必要な時（）に、必要な分だけ（）の要求定義を行う。アジャイル型は要求定義も設計もしないといわれることが多いが、必要に時に必要な分だけ、それらを実施するという理解が正しい。必要な時に必要な分の要求定義を行うことで、開発中に判明した課題や、様々な状況の変化を取り入れながら、要求定義や設計を行っていく。この方法は、ウォーターフォール型と比較して、要求定義にかかる時間を削減し、より価値の高いソフトウェアを構築するための方法として基本的な考え方となっている。


要求は継続的に改善させていく

スクラムでは、必要な時（）に必要な分だけ（）の要求定義の詳細化を行うことで、継続的な改善を実現する。

スプリント2

スプリント3

スプリント１

機能1000

機能2000

機能3000

機能2000

機能3000

1130 1140

1110 1120機能1100

機能1200

機能2100

機能2200

機能3000

2130 2140

2110 2120

機能3100

機能3200 3130 3140

3110 3120


対話を一つのツールとして活用する

従来型の管理手法において、要求定義は膨大なドキュメントを記述する作業であることが多い。特に大規模なプロジェクトでは、形式的でわかりにくい言葉で記述された膨大なドキュメントを、様々な人が記述していく。しかしながら、それらを理解し、設計及び実装をおこなうためには、多くの関係者と対話をしながら進めなければならず、最終的に対話に頼ることが多い。

アジャイル型では、ドキュメントは作らないというイメージが先行しているが、そうではない。我々にとってもっとも理解しやすい会話という手段を重要なツールとして活用することを重点に置いている。ドキュメントは必要に応じて作成するが、それらはわかりやすさを重視し、それがなぜ必要なのか、なぜそうなったのかを理解できるように記述することが求められている。

膨大なドキュメントを書くことよりも、設計や実装がスムーズに進むように、関係者との対話を重視することで、本当に必要で価値あるものをチーム全体が共有できるようにすることが大切である。

あれこれはい

これってこう？なるほど


ユーザーストーリー

ユーザーストーリーとは、ソフトウェアの機能をプロダクトバックログに記述するときの形式のことであり、ユーザーと技術者の双方が理解できる言葉で書かれたものである。

機能に関するプロダクトバックログを、ユーザーストーリー形式で書くという決まりはなく、とてもわかりやすくシンプルなプロダクトバックログの記述方法の一つとして、ユーザーストーリー形式が使用されているだけである。このため、この型にはめることに固執してしまい、わかりにくい要求定義を記述することは無意味である。

ユーザーストーリー形式は、ユーザーの視点からみた機能を記述する形式であり、その機能を誰が使い、どのように動作し、どんな価値があるのか、の点にフォーカスして記述していく。これは、その機能が誰のために、何のために、それを実現するのかを明確に残すことで、プロジェクト後半で「この機能はなぜ必要なのか？なぜこうなったのか？」という議論を繰り返さないためである。

役割として価値のため機能ができる

タイトル

販売サイトの顧客が、購入したい商品をカートに入れる前に納期を確認できるように、顧客のお届け先の住所をもとに、納期日の予測を商品の価格の下に表示する。

納期日のリアルタイム表示

ユーザーストーリー形式ユーザーストーリーの例


検証ストーリー

検証ストーリーとは、ソフトウェアの機能なく、開発を進めるうえで必要な技術検証等の要求をプロダクトバックログに記述するときの形式であり、スパイクやと呼ばれることもある。

記述するための形式はユーザーストーリーと同様であるが、検証ストーリーはソフトウェアの機能を実現するための検証作業が目的であるため、ユーザーストーリーとは分けて整理する。検証ストーリーの内容は、技術的なものが多くなるが、その多くは機能を実現するためのハードウェアやソフトウェア等のコストや実装工数を調べるためのものでもあるため、プロダクトオーナーはその経済的な価値を考慮したうえで、優先順位を付けなければならない。

検証ストーリーの例

開発者として、万件の全文検索を行う場合に適切なパフォーマンスを得るためのアーキテクチャを決めるため、種類のプロトタイピングを行いたい。

検索エンジンの比較

検索速度の比較インデックス作成の速度比較インデックスデータのサイズ及びデータ増加率の比較

受入れ基準


ユーザーストーリーの粒度

ユーザーストーリーの粒度は、その開発期間に比例して、プロジェクトのリリース計画やスプリント計画から開発チームのタスクの実行まで、段階的に定義していく。粒度が大きいユーザーストーリーは計画時に作成され、粒度が細かいユーザーストーリーは開発時にされるのが一般的である。

開発

計画

数時間

数カ月

数カ月

数週間

数日


ユーザーストーリーマッピング

ユーザーストーリーマッピングとは、時系列で流れる業務フローやユーザの行動に合わせて、ユーザーストーリーを整理し、ユーザーストーリーの優先順位を視覚化するものである。

業務システムの場合は、業務の流れに合わせてユーザーのアクティビティを定義し、その下にユーザーストーリーを優先順位順に並べていく。このユーザーストーリーマッピングを行うことで、部分的なリリースを行いながらイテレーティブな開発を行うというイメージを、開発チームに伝えやすくなり、ユーザーへのデモンストレーションにおいても効果的に作用すると考えられる。

見積注文請求

優先順位

業務の流れ


ルール

ユーザーストーリーはルールに従って記述することが最も効果的である。

独立しているユーザーストーリー間で複雑な依存関係がないような定義を行うというルール。独立していないユーザーストーリーは見積やテストが出来ない可能性もあり、とに違反してしまう可能性が高い。

交渉可能である実現したいことは明確だが、設計や実現方法に関してはいくつかの選択肢を持たせるというルール。設計や実装方法等、技術的な側面までを厳密に規定した場合、本来の開発とは異なる作業が発生したりすることを防止する。

価値があるユーザーにとって価値のないユーザーストーリーを記述しないというルール。開発チームが本来のビジネスとは関係のない価値のないユーザーストーリーを作成すること防止する。

見積可能である見積でできるレベルの技術をするというルール。内容の曖昧さや具体的でないユーザーストーリーの作成を防止する。

適切な大きさである巨大で漠然とした記述をしないというルール。見積ができず、テストも容易ではない大きなサイズのユーザーストーリーの作成を防止する。

テストが可能であるテストが実行可能であるユーザーストーリーを記述するというルール。実際に動かして価値を確認できないユーザーストーリーの作成を防止する。



見積とベロシティ

工数の見積はチーム全員で実施する

これまでのプロジェクトにおいて、開発の工数見積を行うのはプロジェクトマネージャであったが、スクラムにおいてはチーム全員が参加して工数の見積を行う。

チーム全員が参加することで、チームメンバのそれぞれの経験や視点から様々な意見を取り入れることが可能となり、想定している機能が思ったよりも容易であったり、実は実現が困難だということが判明し、より正確な見積を行うことができるようになる。

また見積方法は、ユーザーストーリーの大きさによって変えることが望ましい。例えば、大まかな機能で分類した機能に関してはのようなＴシャツモデルで見積を行い、プロダクトバックログのレベルでは、相対的な数値（ストーリーポイント）を用いて見積を行い、タスクレベルでは一時間単位で工数の見積を行うようなイメージである。

M5 6

8 816

11時間

時間による見積ストーリーポイントによる見積Ｔシャツモデルによる見積

こういうことだね？


ストーリーポイント

ストーリーポイントとは、プロダクトバックログの開発工数を示した数値であり、プロダクトバックログにおいて相対的な数値が使用される。

プロダクトバックログの見積は、開発チームのこれまでの開発実績等を考慮しながら、その工数を相対的に算出していく。ストーリーポイントはあくまでの相対値による算出を行い、時間や日数のような絶対的な基準を使用しないほうがよい。

これは、一般的に絶対的な基準による見積もり作業は時間がかかる上、正確ではないことが要因として考えられるが、「機能は機能の倍の工数がかかる」という相対的な見積は非常にシンプルでわかりやすく、絶対的な基準による見積と比較しても、その正確性はそれほど変わらないためである。

機能は機能の三倍の工数がかかりそうなるほど

機能A 10

機能B 30


ベロシティ

ベロシティとは、それぞれのスプリントでチームが完了させたプロダクトバックログのストーリーポイントの総和のことである。完了していないプロダクトバックログは、ベロシティには加えない。ベロシティは、ソフトウェアのリリース計画を立てたり、チームの生産性の能力を評価及び改善するための重要な数値として使用される。

開発チームの週間のベロシティの平均値がであった場合、ストーリーポイントが前後のプロダクトバックログを～件、週間後にリリースできることを推測することが可能となり、ソフトウェアのリリース計画を容易に行うことができるようになる。

また、ベロシティの変化をトラッキングすることで、開発チームで発生している課題を早期発見したり、開発プロセスの改善効果を測定したりすることが可能となる。

ベロシティはチームの生産性を示しているため、チームのパフォーマンス評価の軸として使用することは可能であるが、ベロシティの数値をそのまま、チームの評価制度に使用した場合、見積時に多めのストーリーポイントを付けるという不正が発生する可能性がある。このため、ベロシティを評価軸として使用する場合は、その用途に注意しなければならない。

また、ベロシティは相対的な数値であるストーリーポイントで構成されているため、他のチームとの比較のためにそれぞれのチームのベロシティを直接比較することは望ましくない。

最後に現在、アジャイル型の開発は徐々に広がっているが、そのスピードはそれほど速くはない。しかしながら、アジャイルそのものの考え方は、ソフトウエア開発にとどまらず、会社の予算編成や組織体系の見直しに活用され始めており、計画重視型の考え方から、個人と対話にフォーカスする考え方へシフトが始まっている。この流れをしっかりと捉え、アジャイルの考え方をいろいろな場面で実践をしてほしい。

学校法人麻生塾麻生情報ビジネス専門学校

〒 812-0016 福岡県福岡市博多区博多駅南 2 丁目12-32

電話：092-415-2291　FAX：092-415-2297

●本書の内容を無断で転記､掲載することは禁じます。

平成 28 年 2 月

アジャイル開発の始め方

平成 27 年度文部科学省委託「成長分野等における中核的専門人材養成等の戦略的推進事業」

福岡県をモデルとしたクラウド時代のＩＴビジネスクリエータ地域版学び直し教育プログラムの拡充と展開

Documents

8-6 アジャイル開発の始め方 本文it.27monka-itaku.net/wp-content/uploads/b76a260d8901363fbbf9f6c… · アジャイル開発という考え方 アジャイルとは何か

8-6 アジャイル開発の始め方本文it.27monka-itaku.net/wp-content/uploads/b76a260d8901363fbbf9f6c… · アジャイル開発という考え方アジャイルとは何か