アジャイル勉強会公開資料

アーキテクチャG 主催「ソフトウェア工学」勉強会
第1ターン「ソフトウェアライフサイクルモデル」
第1回「アジャイルについて」

2Copyright © 2016 Bigtree Technology&Consulting Ltd. All Rights Reserved.
1. ソフトウェアライフサイクルモデル
2. ソフトウェアプロジェクトの難しさと本質的な課題
3. 課題に対する解法（アジャイルが進めようとすること）
4. アジャイル方法論（エコシステム）概要
5. アジャイルが向かう道
アジェンダ

 最初の第1ターンでは、社内で取り組んでいる「方法論」の検討などを踏まえ、ライフサイクル
モデルはひとつではないことを紹介したいと考えました
 このテーマは「ソフトウェアエンジニアリングプロセス」分野のサブの分野（ソフトウェアライ
フサイクル）のトピックとなります
（ソフトウェアプロセス定義、ソフトウェアライフサイクル、ソフトウェアプロセス査定および
改善、ソフトウェア計量、ソフトウェアエンジニアプロセスツール）
1 ソフトウェアライフサイクルモデル
ウォータフォール
モデル
（線形モデル、予測型モデル）
開発を各フェーズ（フェーズ内でのフィードバックと反復がある）に分割して、そ
れらを線形に接続し、実行するプロセスモデル。（SWEBoK）
（一般的には、要件定義、基本設計、詳細設計、実装、単体テスト、結合テスト、
総合テスト等にフェーズを分ける）
反復モデル
（適応型モデル）
反復サイクルに従った機能性の漸次拡大をおこなうプロセスモデル。（SWEBoK）
（インクリメンタル、イテラーティブ開発などとも呼ぶ。RUP（Rational Unified
Process）が代表的な手法。テーマを決めて進めるのであれば段階的リリースはこち
らのモデルに近い）
アジャイルモデル
（適応型モデル）
一般に、短い反復サイクルで、頻繁に、実行するソフトウェアを、顧客、またはソ
フトウェア開発に指示を与えるユーザ代表者に作動・展示し、引渡し可能で、小さ
な拡張部分の作動可能ソフトウェアをその都度、形成する。
（SWEBoK）
本日のテーマ

 ソフトウェア開発プロジェクト（特に新規開発）の難しさはどこから来るのか考えてみましょう
2 ソフトウェア開発プロジェクトの難しさ
 プロジェクト期間中に知識を得て、情報が生成される学習プロセスとして特徴づけられる。
 プロダクトとプロジェクトのスコープの不確実性、およびプロジェクトの進展につられて得られる知識である。
 ソフトウェアとは人間の認識プロセスの直接の成果物であるからである。
 ソフトウェア・プロジェクトは、建設や製造プロジェクトよりも研究開発プロジェクトにより類似している。
 ステークホルダーはソフトウェア・プロダクトによって満たされるニーズについて十分明確にできずに合意しない
ことが多いからである。
 あいまいなコミュニケーションを経て、作り手が学習して、
認知した「要件・仕様」がニーズと異なるのは当たり前！
 しかも、それを初期段階（学習中）に変更無く作ることは
できないのが当たり前！
PMBOKガイド第5版ソフトウェア拡張版 1.3.1を参照。

2 3つの背景と2つの課題
 市場が大きく変化し、要求・要件を決めたときと状況が変わって
いる。短期間で市場に出したい。（市場への早期展開）
 顧客は、要求・要件は、実物をみないと深く考えない、考えられ
ない。（要求・要件の暗黙知の必然性）
 作り手は本当の意味で、要求・要件（その背景）を学習途中で設
計・構築する必要がある。（フィードバックループの必然性）
 あいまいな要求・要件に基づく仕様、更に続く伝言ゲーム。
（仕様のあいまいさ）
 変化に対して対応できない。（柔軟性の欠如）
 p4の内容を検討し、3つの背景と2つの課題に分類した
背景
課題

私たちは、ソフトウェア開発の実践
あるいは実践を手助けをする活動を通じて、
よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。
プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、
価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。
3 アジャイルソフトウェア開発宣言
2001年に発表されたものです。（日本語訳はずっと後）
http://www.agilemanifesto.org/iso/ja/
（翻訳は倉貫さんとのこと）
•Kent Beck（XP)
•Mike Beedle (Scrum)
•Arie van Bennekum (DSDM)
•Alistair Cockburn (クリスタル）
•Ward Cunningham (XP)
•Martin Fowler (XP)
•James Grenning (組込みアジャイル、プ
ラニングポーカー）
•Jim Highsmith (ASD)
•Andrew Hunt (達人プログラマの著者)
•Ron Jeffries (XP)
•Jon Kern （FDD)
•Brian Marick
•Robert C. Martin （アジャイル開発の
奥義の著者）
•Steve Mellor （Shlaer–Mellor法）
•Ken Schwaber (Scrum)
•Jeff Sutherland (Scrum)
•Dave Thomas (達人プログラマの著者)
 これらの状況を鑑みて、「アジャイルソフトウェア開発」を推進する動きが生まれた！

3 （解法）小さなフィードバックループの実現
要求・要件の暗黙化
フィードバックループの必要性
小さなフィードバックループの実現
優先度のつけ方
ビジネス価値の高いもの順
仕様のあいまいさ
 要求・要件の問題、作り手の学習の問題、いずれの問題についても「動くソフトウェア」をもと
に、フィードバックすることで解決することを考える
 そのフィードバックループは小さければ小さいほど、容易かつコストがかかりにくい
フィードバック
「動く」ソフト
ウェア
開発
顧客
開発メンバ
この1サイクルを
短くする
フィードバック単位が小さいことで、見積精度が上
がり、管理しやすさにもつながる

 段階リリースはアジャイル以外のプロセスモデルでも利用されているが、期間を小さくし、フィー
ドバックを顧客だけでなく、利用者からも得て改善していく
3 (解法）小さな単位でのリリースサイクル
市場への早期展開小さな単位でのリリースサイクル
優先度のつけ方
ビジネス価値の高いもの順
ウェア
開発
顧客
開発メンバ
この2つのフィードバックルー
プの1サイクルを短くする
（SIモデル）
リリースされた
ソフトウェア
利用者
リ
リ
ー
ス

 変更容易性を確保するために、変更する箇所の削減、よい設計・実装の採用、デグレ防止を実現
する必要がある
3 （解法）変更容易性の確保
柔軟性の欠如変更容易性の確保
デグレの防止
よい設計・実装の維持
変更工数の低減
変更工数の低減
「変更追跡性を担保する」あるいは「不要な文書」を作成しないなどの施策に
より、変更する場合の工数を低減する。
よい設計・実装の維持
よいプログラム設計の技法（OCP、DIPなど）、よい実装の技法（DRY、KISS
等）を用いたプログラムとする。
あいまいな要件やとりあえず～の実装をおこなう場合（「技術的負債が増加す
る」といいます）の修正は期間を決めて、リファクタリングをおこない、技術
的負債を返済し、『よい設計・実装』を維持する。
デグレの防止
モジュールレベルの単体テスト、コントローラからの単体テスト、正常系とバ
リデーションレベルのE2Eテストをおこなうといった施策によってデグレが起
こった場合に判定できるようにする。

 管理手法を「コマンドオブコントロール」リーダシップから「サーバント」リーダシップへ変更する
 主眼をチームにおき、チームが成長できるように「プロセス」を従とするコミュニケーションに変更
する
3 （解法）コミュニケーションの改善
仕様のあいまいさコミュニケーションの改善
士気の向上
理解しようとするマインド醸成
進め方の改善をおこなう
オンサイト顧客
（XPプラクティス）
要求・要件を説明できる顧客がすぐ目の前にいるようにすることでコミュニ
ケーションコストを低減する手法。
レトロスペクティブ
（ふりかえり）
進め方を一定期間（2週間、フェーズ単位など）分を振り替えて、進め方を改
善する手法。
（予測型プロセスにおけるSEPG（Software Engineering Process Group）
と同義）
コードの共同所有
（XPプラクティス）
コードを共有することで変更への影響を確認したり、仕様を確認することを促
進するプラクティス。

 アジャイル開発を説明した最初の手法
 4つの価値（コミュニケーション・シンプル・フィードバック・勇気）と12のプラクティスを紹介
4 XP（エクストリームプログラミング）
コードの共同所有
オンサイト顧客計画ゲーム
ペアプログラミング
メタファ週40時間労働
YAGNI
（You Aren’t
Going to Need It)
短期リリースリファクタリング
テストファースト
継続的インテグレーション
コーディング規約
今は「受入テスト」ファースト
もよくやられるので、テスト粒
度が重要。

 アジャイル開発をメジャーにした貢献者。
 管理に特化してアジャイルの解法・プラクティスを取り入れたため「管理者」が率先して採用し
た。
4 Scrum (スクラム）
動作検証の結果をフィードバック
しバックログに追加する
4.フィードバック
ウェア
3.スプリント
2～4週間程度のタイ
ムスケジュール。実
行中のスプリントは
外部からの変更を受
け入れない
プロダクトの機能、顧
客からの要求、バグ等
に優先順位を付けた一
覧
1.プロダクトバックログ
プロダクトの機能、顧
客からの要求、バグ等
に優先順位を付けた一
覧
2.スプリントバックログ顧客顧客
顧客目線で実際に動作
するソフトウェア
スクラムプロセスをコ
ントロールする。スプ
リントバックログのタ
スクへの落とし込み及
び進捗管理を実施する
スクラムマスター
開発メンバ
プロダクトを開発する。
実作業としては、スプ
リントバックログに紐
づく個々のタスクを
日々消化していく。
プロダクトオーナー
プロダクト(最終成果
物)に対して責任を持
ち、バックログに優先
順位を付ける

 RADを形式化した手法
 機能、設計構築、実装のフェーズを分けて、フェーズの中およびフェーズ間を反復で実現する手
法
4 DSDM (Dynamic Solution Delivery Model)
アジャイルソフトウェア開発エコシステムから図を引用（p253)

 アリスタコーバンが主張した手法。
 テラーリングを意識し、重要度とメンバ数で分類して、現実的な方法論として整理している。
（下図参照）
4 クリスタル
以降
Maroon (81-200)
Diamond (201-500)
Sapphire (501-1000)
と続く
Orange Webというのもある。
http://users.dcc.uchile.cl/~nbaloian/cc1001-03/ejercicios/crystalclearV5d.pdf
から図を引用。アジャイルソフトウェア開発エコシステムから図を引用（p262)

 アジャイル開発というのは効果があることがわかっています
 いつ導入するかという選択のみが問われます
 アジャイルはもはやその枠を超えて、発展し始めています
5 アジャイルが向かう道
アジャイル
エンタープライズ
SAFe（Scaled Agile Framework)
DAD（Disciplined Agile Delivery)
顧客の対話
DDD（Domain Driven Development)
速度の向上
DevOps
ボトルネックがリリー
スに移った
（Amazon/Netflix)
インフラ技術の向上
クラウド技術の普及
MSAの発達
が背景
ここにも影響
Immutable Infrastructure
Infrastructure as a Code
Blue/Green Deploy
Canary Deploy

なぜ、今アジャイル開発が進められていないでしょうか？
議題

アジャイル勉強会 公開資料

More Related Content

Viewers also liked

Similar to アジャイル勉強会 公開資料

More from Atsushi Takayasu