とりあえず30分でひととおり分かった気にはなれるアジャイル入門

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

自己紹介

滝川陽一（たきがわよういち）… takigawa401

• 1978年07月26日生 (34歳05ヶ月)
• 長野県飯田市近辺出身、東京在住
• 「技術コンサルG」というの組織に所属
• RIA、モバイル(スマートデバイス) 、アジャイル
• ブログ :ミッションたぶんPossible
• FC東京／中日ドラゴンズ／松本山雅
• 特記 :これがこの会社での最後のプレゼンです

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

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

※画像はイメージです

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

SIビジネスの中ではなかなか経験でき
ないアジャイルについてお伝えします

対象者
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/

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

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

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

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

私たちは、ソフトウェア開発の実践あるいは実践
を手助けをする活動を通じて、よりよい開発方法
を見つけだそうとしている。この活動を通して、
私たちは以下の価値に至った。

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

価値とする。すなわち、左記のことがらに価値が
あることを認めながらも、私たちは右記のことが
らにより価値をおく。
アジャイルソフトウェア開発宣⾔言 http://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分で
とりあえず
ひととおり
ご清聴
分かった気
有難うございました。
にはなれる
アジャイル入門

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

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

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

ウォーターフォール開発

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

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

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

プロトタイプ

本開発の前にプロトタイプ開発を必ず行い、技術
検証を行うのが本来の「ウォーターフォール開
発」。米国から日本に伝わる際、誤って伝わった
ものがそのまま定着してしまったのが、現行の
「日本式ウォーターフォール開発」。

メリット
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  短期リリース

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等)でプ
ロジェクトに問題がな
い事を保障する役割を
持つ。顧客の要望に優
先順位を付ける。

スクラム (ソフトウェア開発) -‐‑‒ Wikipedia
http://buﬀ.ly/T8Cayk

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

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


調整役

バランス
ビジネス要件
開発を実施対立を出す

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

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

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

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

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

IDEA

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

MVP

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

Analysis

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

Pivot

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

MVPの作成→ローンチ→分析→ピボットの作成
を素早く繰り返し、いち早くユーザーの心をつかむ
サービス・製品を作り、市場に提供する

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ユーザーニーズの多様化

ビジネススピードの加速

アーキテクチャの複雑化

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

全員同席

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

[Agile]Agile Buﬀet Cardを作りました – Ryuzee.com
http://www.ryuzee.com/contents/blog/4741

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

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

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

朝会

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


ふりかえり

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


Kanban

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


リファクタリング

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


コードの共有所有
CVSやSubversion、gitを
用いて、チームで開発中のソー
スコードやドキュメントを一元
管理する。メンテナンスはチー
ム全員で行うことを合意する。

ニコニコカレンダー

開発メンバーの体調や仕事の忙
しさをフェイスマークの表情で
可視化し、個々の状況をチーム
全員で把握し易くしておく。

ちはやふるの⽇日記 -‐‑‒ ゆるふわニコニコカレンダー
http://www.chihayafuru.jp/tdiary/?date=20090116

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

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

アジャイルな
エンジニア

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

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

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

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

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

とりあえず30分でひととおり分かった気にはなれるアジャイル入門

More Related Content

とりあえず30分でひととおり分かった気にはなれるアジャイル入門