たった50分でとりあえずひととおり分かった気にはなれるアジャイル入門【新装版】

たった30分で
とりあえず
ひととおり
分かった気
にはなれる
アジャイル入門新装版
新装版
50

自己紹介
滝川陽一（たきがわよういち）… takigawa401
•1978年07月26日生 (36歳)
•長野県飯田市近辺出身、東京在住
•株式会社インデックス(セガサミーグループ)所属
•職業：システムエンジニア
•前職：客先常駐上等！ n次請けSIer (11年在籍)
•ウォーターフォール代表
•FC東京／中日ドラゴンズ／松本山雅
•アジャイル／ロジカルシンキング
•BMG Works／TOCfE BC

2011年のとある日、客先にて

Androidアプリ開発
⽤用の開発標準作って
よ。アジャイルでオフ
ショアやりたいから
さ。宜しく頼むわ。
※画像はイメージです

それ以降、社内外で
アジャイルに様々な
形でトライしてきた

アジャイルについて
ざっくばらんにお伝えします

n アジャイルって最近良く聞くけど全然分かんなく
って……。
n そもそもウォーターフォールだって良く分かんな
いのに……。
n アジャイルってドキュメント書かないんでしょ？
n アジャイルで開発すると早くて安く上がるらしい
じゃん？
n アジャイルだと大規模開発できないんだろ？
n アジャイルなんて失敗多いもの採用出来るか！
対象者

n アジャイルって最近良く聞くけど全然分かんなく
って……。
n そもそもウォーターフォールだって良く分かんな
いのに……。
n アジャイルってドキュメント書かないんでしょ？
n アジャイルで開発すると早くて安く上がるらしい
じゃん？
n アジャイルだと大規模開発できないんだろ？
n アジャイルなんて失敗多いもの採用出来るか！
対象者
かかって
こい！！

アジェンダ
n アジャイルとは？
n アジャイルマニフェスト
n ウォーターフォールとは？
n アジャイルの種類
n なぜアジャイル？
n アジャイルなエンジニア
n どうやってアジャイルを学ぶ？

所要時間所要時間

アジャイル
ってなに？

「アジャイル」は形容詞、邦訳で「敏
捷な」「小回りのきく」という意味を
指す。
「開発がアジャイルだ」など状態を表
すことは出来るが、厳密には「アジャ
イル開発」という手法は存在しない。
便宜上の「アジャイル開発」という言
葉がに定着しているのが現状。

アジャイルのはじまり

アジャイル
マニフェスト

アジャイルソフトウェア開発宣言
(アジャイルマニフェスト)
2001年に、アジャイルソフトウェア開発手法の分野において名声
のあるケント・ベックら17人がアメリカ合衆国ユタ州スノーバー
ドに会し、彼らがそれぞれ別個に提唱していた開発手法の重要な
部分を統合することについて議論した。そして、彼らは「アジャ
イルソフトウェア開発宣言」(Manifesto for Agile Software
Development)という文書にまとめた。アジャイルソフトウェア
開発宣言は、アジャイルソフトウェア開発とその諸原則を公式に
定義した文書であると、広く認められている(参考: アジャイルソ
フトウェアの原則) 。
アジャイルソフトウェア開発 -‐‑‒ Wikipedia http://buﬀ.ly/U7AVk4

私たちは、ソフトウェア開発の
実践あるいは実践を手助けをす
る活動を通じて、よりよい開発
方法を見つけだそうとしてい
る。この活動を通して、私たち
は以下の価値に至った
アジャイルソフトウェア開発宣⾔言 http://agilemanifesto.org/iso/ja/

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

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

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

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

私たちは、ソフトウェア開発の実践
あるいは実践を手助けをする活動を通じて、
よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。
プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、
価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。
h$p://agilemanifesto.org/iso/ja/
アジャイルソフトウェア開発宣言
(アジャイルマニフェスト)

アジャイル宣言の背後にある原則
私たちは以下の原則に従う:
1. 顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。
2. 要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客
様の競争力を引き上げます。
3. 動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。
4. ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。
5. 意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで
彼らを信頼します。
6. 情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。
7. 動くソフトウェアこそが進の最も重要な尺度です。
8. アジャイル･プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるよう
にしなければなりません。
9. 技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。
10.シンプルさ（ムダなく作れる量を最大限にすること）が本質です。
11.最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。
12.チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのや
り方を最適に調整します。
アジャイル宣⾔言の背後にある原則 http://agilemanifesto.org/iso/ja/principles.html

これでアナタも明日から
アジャイルなエンジニア！

たった30分で
とりあえず
ひととおり
分かった気
にはなれる
アジャイル入門新装版
新装版
50
ご清聴
有難うございました

原理とか原則とかどーでもいいから
さっさとアジャイルを教えろよ！！

アジャイルのすべては必ず
アジャイルマニフェストに通ずる
決して軽んずべからず

届ける「価値」を意識する

37
失敗こそが人をもっとも成長させる
h$p://www.genrei-‐koubou.com/zakin/

如何に早く小さく失敗するか

失敗によるダメージ
を最小限に抑え
学びを次に生かす

アジャイル
な開発手法
の種類

ウォーターフォール開発

開発プロジェクトを時系列に、要求定義→外部設計(概要
設計) →内部設計(詳細設計) →開発(プログラミング) →
テスト→運用などの作業工程に分割し、原則として前工
程が完了しないと次工程に進まない(設計中にプログラミ
ングを開始するなどの並行作業は行わない)事で、前工程
の成果物の品質を確保し、前工程への手戻りを最小限に
する。
ウォーターフォール・モデル -‐‑‒ Wikipedia http://buﬀ.ly/TxgnQH

ウォーターフォール・モデル -‐‑‒ Wikipedia http://buﬀ.ly/TxgnQH
嘘だ!!

本当のウォーターフォール開発は2度繰り返す

本開発の前にプロトタイプ開発を必ず行
い、技術検証を行うのが当初の「ウォータ
ーフォール開発」
プロトタイプ

h$p://ja.wikipedia.org/wiki/紙テープ
かつてのソフトウェア開発は
非常にシンプルだった

h$p://blogs.yahoo.co.jp/junji_daa/24103719.html
簡単な計算を行う程度の能力

薄れる検証の必要性薄れる検証の必要性

h$p://meiji.sakanouenokumo.jp/blog/archives/2010/06/post_815.html
日本に伝わるタイミングでは既に
プロトタイプ開発の工程が無かった

日本のウォーターフォールは
現在のプロトタイプ開発無しの
スタイルが主流となる

メリット
n 要求定義の工数見積に従って一括請負契約
を結ぶことができる
n 承認プロセスが明確であるため責任の所在
が明確である
n プロジェクト参加者が担う役割は固定的で
考える事が少ない(低スキルの技術者でも参
画し易い)

デメリット
n 開発途中での仕様変更に対応しきれない
n 仮説に基づいた要件にならざるを得ない
n システムの実物を確認出来るになるまでの
時間が長い
n 終盤にならなければ仮説の検証を行えない
n ひとつひとつの工程が長すぎる
n 前工程の成果物は完全であることを前提と
するため、誤りが発生した際手戻りが発生
する

アジャイルな
開発手法の種類

XP
(エクストリームプログラミング)

1999年に書籍『XPエクスト
リーム・プログラミング入門
―ソフトウェア開発の究極の
手法』(ケント・ベック著)に
よって発表された。柔軟性の
高い開発手法であるため、難
易度の高い開発やビジネス上
の要求が刻々と変わるような
状況に向いた開発手法。ドキ
ュメントよりもソースコード
を、組織的開発の歯車となる
ことよりも、個人の責任と勇
気を重んじる人間中心の開発
プロセスであるとしている。
エクストリーム・プログラミング -‐‑‒ Wikipedia http://buﬀ.ly/TygsUk

5つの価値
n コミュニケーション
n シンプル
n フィードバック
n 勇気
n 尊重
5つの価値は19のプラクティスに影響を与え、
XPの根幹を為す

19のプラクティス
n 共同のプラクティス(4つ)
n 反復
n 共通の用語
n 開けた作業空間
n 回顧(頻繁な振り返り)

n 開発のプラクティス(6つ)
n テスト駆動開発
n ペアプログラミング
n リファクタリング
n ソースコードの共同所有
n 継続的インテグレーション
n YAGNI

n 管理者のプラクティス(5つ)
n 責任の受け入れ
n 援護
n 四半期毎の見直し
n ミラー
n 最適なペースの仕事

n 顧客のプラクティス(4つ)
n ストーリーの作成
n リリース計画
n 受け入れテスト
n 短期リリース

このプラクティス
を全て実施するの
は非常に難しい

68
「ぼくのかんがえたさいきょうの
かいはつプラクティス」

69
個別に使ってもそこそこ強い。
(※ちゃんと使いこなせるなら)

70
XPのプラクティスが由来と知らずに
使っているケースもある

1993年、ジェフ・サザーランド
ら3名がラウンドトリップ・エンジ
ニアリング(一種の反復型開発)を取
り入れたオブジェクト指向プログラ
ミング設計・分析ツールを構築した
のが最初。当時、素早い開発が求め
られており、要求仕様を簡単に動作
するコードに変換する方法が求められていた。同じ頃、ケン・シュエイ
バーが自社(ADM)でのソフトウェア開発にこの手法を用いた。
スクラム的手法を以前から活用していた企業として、富士ゼロック
ス、キヤノン、(中略)などがある。これらのプロジェクトについては、
一橋大学の野中郁次郎と竹内弘高が Harvard Business Review
誌に「The New New Product Development Game」として
発表している(1986年1-2月)。
スクラム (ソフトウェア開発) -‐‑‒ Wikipedia http://buﬀ.ly/T8Cayk

Scrumは
「開発プロセス」
のフレームワーク
ソフトウェア開発以
外にも活用すること
ができる

Scrumは現在最も利用されている
アジャイルな開発手法

ユーザー要件を細小単位に分割し、さらに機能単位に分割したも
のを2∼4weekのイテレーションごとにチームが開発を行う。イ
テレーション終了時には製品・サービスの責任者が評価を行い、
完成とみなされたものだけがリリースされる。イテレーション終
了時には必ず開発チームで「ふりかえり」を行い、次のイテレー
ションに経験を生かす。

Scrum開発チーム
プロダクトオーナー
スクラムマスター
チーム

プロダクトオーナー(PO)
製品の総責任者。お客
様の意思の代表として
の役割を担う。ビジネ
ス視点(ROI等)でプロ
ジェクトに問題がない
事を保障する役割を持
つ。顧客の要望に優先
順位を付ける。

各メンバーが協力し、全
体として同じゴールを目
指す。チームの人数は5
人から９人が適当とさ
れ、実装とテストの能力
を持つ。チームは作業プ
ロセスと作業結果の責任
も持ち、自らチーム内の
管理を行う。
チーム

プロジェクトが円滑に
進むよう調整する。主
な作業はチーム内外の
ファシリテーションと
外部妨害の対処。従来
のPMの役割を担う事
が多いが最もプロジェ
クト管理責任が少ない
スクラムマスター(SM)

調整役
開発を実施
ビジネス要件を
出す
往々にして対立しがち(協調出来るのが勿論望ましい)なチームと
POの間を取り持ち、プロジェクトが円滑に進むようにバランスを
取るのがスクラムマスターの役割。
対立
バランス

優れた開発チームには
管理者は要らない

チームが成熟した状態が
最も生産性が高い

チームを解散してはならない

エリック・リースが提唱したベンチャービジネスの立ち上げ
手法のひとつ。「リーン」とはトヨタの「リーン生産方式」から
の引用。エリック・リースがプログラマだったことから、XPの要
素を色濃く持つ。「ビジネスを素早く立ち上げ、可能な限り早く
小さく失敗し、いち早く成功にり着く」ことを目的とする。

IDEA
ビジネスの着想となる最
初のアイディア。「仮
説」とも。大前提として
「誤っている」として捉
え、徐々に修正して行く
事が必要になる。

MVP
「Minimam Viable
Product(実用最小限の
製品)」の略。ユーザー
ニーズを測れる最低限の
機能を持った状態のサー
ビス・製品を指す。必ず
しも製品になっている必
要はなく、モックやコン
セプトビデオのような場
合もある。

Analysis
ローンチ後のMVPの利
用状況をログから計測す
る。指標の設定が非常に
重要で、誤った指標設定
を行っていた場合、ビジ
ネスを成功に方向修正す
ることが非常に困難にな
る。

Pivot
分析の結果として「仮
説」が誤っていると判断
出来た場合、新たに仮説
を立ててビジネスを方向
転換する。
一から考え直すのではな
く、微修正に留める。

91
h$p://www.oﬃciallyjd.com/archives/155047/20120717_matsumotohitoshi_15/
全てのアイディア
は、最初は寝言で
妄言に過ぎない

92
ユーザーの本当に欲しいものはユーザーしか分からない。
取締役承認を得たからといって成功するとは限らない。

93
ユーザーの声に
耳を傾ける
ユーザーの声に
耳を傾ける

ユーザーインタビュー

MVPの作成→ローンチ→分析→ピボットの作成
を素早く繰り返し、いち早くユーザーの心をつかむ

97
h$p://www.slideshare.net/kkd/about-‐annotatedbibliographyinx-‐pinesm
アジャイルな開発手法とそのスコープ

なぜ受託開発ビジネスは
ウォーターフォール開発ばかり？

自分たちの本業とは
異なるIT関連作業を
丸投げしたいユーザ
ー企業

ユーザー企業から契
約( 稟議)を引き出し
たいSIer

双方の思惑の一致から、最初に金額を決定
する現行の受託開発ビジネスが生まれた

ウォーターフォールは現行の
受託開発ビジネスに最適の開発手法

ウォーターフォール開発は、開発の最中での仕様
変更や、漏れ・抜け・誤りを一切許さない

ミスをしない人間はいない

赤字プロジェクトや
デスマーチが簡単に
発生する要因

ウォーターフォールが当たり前なのは
IT業界の中でも受託開発ビジネスだけ

IT業界の他の分野、特にゲームは
アジャイルで開発せざるを得ない

例：キャサリン
(Playstation3 / ATLUS)

メインはパズルゲーム。足下が崩れて行くブロック
の山(壁)を、ブロックを押したり引っ張ったりして
移動させながら、ぶら下がったり飛び跳ねたりする
ことで一番上までり着けばゴール。これらは全て
主人公の夢(悪夢)の中で行われる。恋人に結婚を迫
られた主人公がある夜初めて会った美女と一夜を共
にしてしまってから始まった悪夢。毎晩命がけで登
り続けることになる。
ゲーム概要

メインはパズルゲーム。足下が崩れて行く
ブロックの山(壁)を、ブロックを押したり
引っ張ったりして移動させながら、ぶら下
がったり飛び跳ねたりすることで一番上ま
でり着けばゴール。これらは全て主人公
の夢(悪夢)の中で行われる。恋人に結婚を
迫られた主人公がある夜初めて会った美女
ゲーム概要
イラストも無しに説明文だけ
でこのゲームを「面白い」と
判断するのは至難の業

ゲームが面白いかどうかは
作って遊んでみないとわからない

ユーザーニーズの多様化

Windows95とインターネットの登場

スマートフォンの台頭

その都度増える一般ユーザーのIT利用

様々なシーンでソフトウェアが活用され、
一方でITエンジニアの役割も急増した

アーキテクチャの複雑化

メインフレーム
クライアント＆サーバ
Webアプリケーション
RIA スマートフォン
PC 組み込み
AWS
クロスプラットフォーム
iOS
Android
Firefox OS
GoogleApps
WIndows Azure
O2O
Map Reduce
Hadoop
O/R Mapper
MVC
アセンブラ
UNIX
Linux
Windows Server
RDB
KVS
NoSQL
ストアドプロシージャ
ERP
EDI
SOA
ESB
BPM
EAI
COBOL
Java
JavaVM
C言語
C++
C#
Swift
VB.NETjQuery
Haskel
PHP
LAMP
Python
SOAP
Ajax
REST
GoLang
GoLang
GIS
h$p://blog.livedoor.jp/miniaturenews/archives/6838961.html
全ての要素を把握し最適解を出すなど
もはや不可能
DWH
BI

ビジネススピードの加速

ある程度の規模の企業に
業務システムは導入される

ユーザーよりも業務に詳しい
ベテラン情シスが業務システムを支える

技術・業務知識の
積み上げ
の喪失

n 開発側に負担がかかり過ぎる
n 評価軸が不確かな製品やサー
ビス
n ユーザーニーズの多様化
n ビジネススピードの加速
n アーキテクチャの複雑化
n etc…

ユーザーに価値を届け、数々の課題に対応
し、エンジニアを健全な状態に保つ方法と
してアジャイルが選ばれつつある

アジャイルと
ウォーターフォール

アジャイルなら早く上手く安く作れる？

プロセスが異なるだけでシステム開発の本質には変わり
ない。むしろアジャイルの方が高くつくかも。ただし
「ユーザーが本当に欲しいもの」が作れる可能性が高
く、結果的に安くなる事もある。

アジャイルでは大規模開発は出来ない？

Salesforceは数百人が参画するプロジェクトを
アジャイルで実施。世界最大のスクラムチームを
持つ。(世界最大はマイクロソフトという説も)

日本の受託開発ビジネスで
アジャイルな開発を導入するのは難しい？

アジャイルな開発では準委任の契約形式が
望ましい。一括請負は非常にリスキー。

アジャイルはよく失敗するって聞くけど？

これまでウォーターフォール開発が
何万回失敗して来たと思ってるんだ!?
これまでウォーターフォール開発が
何万回失敗して来たと思ってるんだ!?

歴史とは人間が流した血の河
だ。正義や真理などその河に付
けられた呼び名にすぎん。
̶ 真刈信二 (勇吾) ̶

140
h$p://www.amazon.co.jp/dp/B00005HU5J
ソフトウェア開発もまた然り

まずは失敗してよい場所で小さく試すのが理想的

小さく始めて
成功体験を
積み上げる

受託開発(ウォーターフォール)の現場では
アジャイルな開発は出来ないのか？

アジャイルの手法は
「現場を改善する
Tips」の集合

それぞれの現場に合わせて
必要なプラクティスだけ
導入すればいい

アジャイルな
プラクティス

http://www.ryuzee.com/contents/blog/4741
全員同席
開発チーム全員が同じ場所(同じビル同じフ
ロアの隣り合った席)で一緒に仕事を行う。
プロダクトオーナーなども同様。

テスト駆動開発(TDD)
プロダクトのソースコードを書く前にテス
トコードから書く。プロダクトのソースコ
ードはそのテストがクリア出来るように記
述する。

ペアプログラミング
二人一組で1台のPCを用いてプログラミン
グを行う。TDDと組み合わせて、1人がテ
ストコードを、1人が実装を行う事も。

継続的インテグレーション
実装したソースコードを定期的にテスト環
境にデプロイや自動テストを行い開発対象
の品質を保つ事。Jenkinsなどのツールを
用いる事が一般的。

朝会
開発チーム全員が一同に会し、短時間で進
捗度合いや課題を共有するミーティングを
行う。

ふりかえり
イテレーションやプロジェクトの終了時に
開発チームで良かった点反省点を出し、次
の開発へ繋げる改善案を話し合う。

Kanban
タスク毎に付箋に書き出し、ホワイトボー
ド等に貼って進捗状況を可視化する。

リファクタリング
実装済みのソースコードを、より読み易く
シンプルに書き直すことで、メンテナンス
性を高めておく。

コードの共有所有
CVSやSubversion、gitを用いて、チー
ムで開発中のソースコードやドキュメント
を一元管理し、他者が手を入れ易い状況を
保つ。

http://qiita.com/kozayupapa/items/fb9408260c2f39c66235
インセプションデッキ
10の質問に答える形で、プロジェクト開始
時に必要な方針（目的・背景・開発対象・
リスク）をチーム全員で把握・合意するこ
とが出来る。

http://www.chihayafuru.jp/tdiary/?date=20090116
ニコニコカレンダー
開発メンバーの体調や仕事の忙しさをフェ
イスマークの表情で可視化し、個々の状況
をチーム全員で把握し易くしておく。

イテレーションを回さなくても、アジャイルの要
素を取り入れた開発を行う事は出来る

大事なのは現場を改善
して行こうという意識

アジャイルな
エンジニア

実はアジャイルだろうが
ウォーターフォールだろうが
あんまり変わりない

チームで同じ目的・価値を目指す

自分に最も適した役割を
最適のタイミングで果たす

自分が提供するものの価値を意識する

王道な「アジャイル開発」は北極星

いつも「アジャイルマニフェスト」を心に

強い意志を持って常に向上し続ける

h$p://d.hatena.ne.jp/takigawa401/20120305/1330927135
勉強会※関東の場合

179
アジャイルサムライ横浜道場

たった50分でとりあえずひととおり分かった気にはなれるアジャイル入門【新装版】

Recommandé

Recommandé

Contenu connexe

Plus de 陽一滝川

Plus de 陽一滝川 (10)