Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
たった30分で
とりあえず
ひととおり
分かった気
にはなれる
アジャイル入門新装版
新装版
50
2
……の、その前に
3
誰だオマエ?
自己紹介
滝川 陽一(たきがわ よういち)… takigawa401
•1978年07月26日生 (36歳)
•長野県飯田市近辺出身、東京在住
•株式会社インデックス(セガサミーグループ)所属
•職業:システムエンジニア
•前職: 客先常駐上等...
自己紹介
滝川 陽一(たきがわ よういち)… takigawa401
•1978年07月26日生 (36歳)
•長野県飯田市近辺出身、東京在住
•株式会社インデックス(セガサミーグループ)所属
•職業:システムエンジニア
•前職: 客先常駐上等...
前置き
2011年のとある日、客先にて
Androidアプリ開発
⽤用の開発標準作って
よ。アジャイルでオフ
ショアやりたいから
さ。宜しく頼むわ。
※画像はイメージです
それ以降、社内外で
アジャイルに様々な
形でトライしてきた
アジャイルについて
ざっくばらんにお伝えします
対象者
n アジャイルって最近良く聞くけど全然分かんなく
って……。
n そもそもウォーターフォールだって良く分かんな
いのに……。
n アジャイルってドキュメント書かないんでしょ?
n アジャイルで開発すると早くて安く上がるらしい
じゃん?
...
n アジャイルって最近良く聞くけど全然分かんなく
って……。
n そもそもウォーターフォールだって良く分かんな
いのに……。
n アジャイルってドキュメント書かないんでしょ?
n アジャイルで開発すると早くて安く上がるらしい
じゃん?
...
アジェンダ
アジェンダ
n アジャイルとは?
n アジャイルマニフェスト
n ウォーターフォールとは?
n アジャイルの種類
n なぜアジャイル?
n アジャイルなエンジニア
n どうやってアジャイルを学ぶ?
所 要 時 間所 要 時 間
アジャイル
ってなに?
アジャイル
開発
「アジャイル」は形容詞、邦訳で「敏
捷な」「小回りのきく」という意味を
指す。
「開発がアジャイルだ」など状態を表
すことは出来るが、厳密には「アジャ
イル開発」という手法は存在しない。
便宜上の「アジャイル開発」という言
葉が に定着している...
アジャイルのはじまり
アジャイル
マニフェスト
アジャイルソフトウェア開発宣言
(アジャイルマニフェスト)
2001年に、アジャイルソフトウェア開発手法の分野において名声
のあるケント・ベックら17人がアメリカ合衆国ユタ州スノーバー
ドに会し、彼らがそれぞれ別個に提唱していた開発手法の重要な...
私たちは、ソフトウェア開発の
実践あるいは実践を手助けをす
る活動を通じて、よりよい開発
方法を見つけだそうとしてい
る。この活動を通して、私たち
は以下の価値に至った
アジャイルソフトウェア開発宣⾔言  http://agilemanifes...
プロセスやツー
ルよりも個人と
対話を
包括的なドキュメ
ントよりも動くソ
フトウェアを
契約交渉よりも
顧客との協調を
計画に従うこと
よりも変化への
対応を
私たちは、ソフトウェア開発の実践
あるいは実践を手助けをする活動を通じて、
よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。
プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウ...
アジャイル宣言の背後にある原則
私たちは以下の原則に従う:
1. 顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。
2. 要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客
様の競争力を引...
これでアナタも明日から
アジャイルなエンジニア!
たった30分で
とりあえず
ひととおり
分かった気
にはなれる
アジャイル入門新装版
新装版
50
ご清聴
有難うございました
原理とか原則とかどーでもいいから
さっさとアジャイルを教えろよ!!
アジャイルのすべては必ず
アジャイルマニフェストに通ずる
決して軽んずべからず
届ける「価値」を意識する
37
失敗こそが人をもっとも成長させる
h$p://www.genrei-­‐koubou.com/zakin/
如何に早く小さく失敗するか
失敗によるダメージ
を最小限に抑え
学びを次に生かす
アジャイル
な開発手法
の種類
と、その前に
ウォーターフォール開発
開発プロジェクトを時系列に、要求定義→外部設計(概要
設計) →内部設計(詳細設計) →開発(プログラミング) →
テスト→運用 などの作業工程に分割し、原則として前工
程が完了しないと次工程に進まない(設計中にプログラミ
ングを開始するなどの...
ウォーターフォール・モデル  -‐‑‒  Wikipedia  http://buff.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エクスト
リーム・プログラミング入門
―ソフトウェア開発の究極の
手法』(ケント・ベック著)に
よって発表された。柔軟性の
高い開発手法であるため、難
易度の高い開発やビジネス上
の要求が刻々と変わるような
状況に向いた開...
5つの価値
5つの価値
n コミュニケーション
n シンプル
n フィードバック
n 勇気
n 尊重
5つの価値は19のプラクティスに影響を与え、
XPの根幹を為す
19のプラクティス
19のプラクティス
n 共同のプラクティス(4つ)
n 反復
n 共通の用語
n 開けた作業空間
n 回顧(頻繁な振り返り)
19のプラクティス
n 開発のプラクティス(6つ)
n テスト駆動開発
n ペアプログラミング
n リファクタリング
n ソースコードの共同所有
n 継続的インテグレーション
n YAGNI
19のプラクティス
n 管理者のプラクティス(5つ)
n 責任の受け入れ
n 援護
n 四半期毎の見直し
n ミラー
n 最適なペースの仕事
19のプラクティス
n 顧客のプラクティス(4つ)
n ストーリーの作成
n リリース計画
n 受け入れテスト
n 短期リリース
19のプラクティス
このプラクティス
を全て実施するの
は非常に難しい
68
「ぼく の かんがえた さいきょうの
かいはつ プラクティス」
69
個別に使ってもそこそこ強い。
(※ちゃんと使いこなせるなら)
70
XPのプラクティスが由来と知らずに
使っているケースもある
Scrum
 1993年、ジェフ・サザーランド
ら3名がラウンドトリップ・エンジ
ニアリング(一種の反復型開発)を取
り入れたオブジェクト指向プログラ
ミング設計・分析ツールを構築した
のが最初。当時、素早い開発が求め
られており、要求仕様を簡単に動作
す...
Scrumは
「開発プロセス」
のフレームワーク
ソフトウェア開発以
外にも活用すること
ができる
Scrumは現在最も利用されている
アジャイルな開発手法
ユーザー要件を細小単位に分割し、さらに機能単位に分割したも
のを2∼4weekのイテレーションごとにチームが開発を行う。イ
テレーション終了時には製品・サービスの責任者が評価を行い、
完成とみなされたものだけがリリースされる。イテレーション終
...
Scrum開発チーム
プロダクトオーナー
スクラムマスター
チーム
プロダクトオーナー(PO)
製品の総責任者。 お客
様の意思の代表として
の役割を担う。ビジネ
ス視点(ROI等)でプロ
ジェクトに問題がない
事を保障する役割を持
つ。顧客の要望に優先
順位を付ける。
スクラム  (ソフトウェア開発)  -‐...
各メンバーが協力し、全
体として同じゴールを目
指す。チームの人数は5
人から9人が適当とさ
れ、実装とテストの能力
を持つ。チームは作業プ
ロセスと作業結果の責任
も持ち、自らチーム内の
管理を行う。
チーム
スクラム  (ソフトウェア開発)...
プロジェクトが円滑に
進むよう調整する。主
な作業はチーム内外の
ファシリテーションと
外部妨害の対処。従来
のPMの役割を担う事
が多いが最もプロジェ
クト管理責任が少ない
スクラムマスター(SM)
スクラム  (ソフトウェア開発)  -‐‑...
調整役
開発を実施
ビジネス要件を
出す
往々にして対立しがち(協調出来るのが勿論望ましい)なチームと
POの間を取り持ち、プロジェクトが円滑に進むようにバランスを
取るのがスクラムマスターの役割。
対立
バランス
優れた開発チームには
管理者は要らない
チームが成熟した状態が
最も生産性が高い
チームを解散してはならない
Lean Startup
エリック・リースが提唱したベンチャービジネスの立ち上げ
手法のひとつ。「リーン」とはトヨタの「リーン生産方式」から
の引用。エリック・リースがプログラマだったことから、XPの要
素を色濃く持つ。「ビジネスを素早く立ち上げ、可能な限り早く
小さく...
IDEA
ビジネスの着想となる最
初のアイディア。「仮
説」とも。大前提として
「誤っている」として捉
え、徐々に修正して行く
事が必要になる。
MVP
「Minimam Viable
Product(実用最小限の
製品)」の略。ユーザー
ニーズを測れる最低限の
機能を持った状態のサー
ビス・製品を指す。必ず
しも製品になっている必
要はなく、モックやコン
セプトビデオのような場
合もあ...
Analysis
ローンチ後のMVPの利
用状況をログから計測す
る。指標の設定が非常に
重要で、誤った指標設定
を行っていた場合、ビジ
ネスを成功に方向修正す
ることが非常に困難にな
る。
Pivot
分析の結果として「仮
説」が誤っていると判断
出来た場合、新たに仮説
を立ててビジネスを方向
転換する。
一から考え直すのではな
く、微修正に留める。
91
h$p://www.officiallyjd.com/archives/155047/20120717_matsumotohitoshi_15/
全てのアイディア
は、最初は寝言で
妄言に過ぎない
92
ユーザーの本当に欲しいものはユーザーしか分からない。
取締役承認を得たからといって成功するとは限らない。
93
ユーザーの声に
耳を傾ける
ユーザーの声に
耳を傾ける
ユーザーインタビュー
ログ分析
MVPの作成→ローンチ→分析→ピボットの作成
を素早く繰り返し、いち早くユーザーの心をつかむ
97
h$p://www.slideshare.net/kkd/about-­‐annotatedbibliographyinx-­‐pinesm
アジャイルな開発手法とそのスコープ
何故
アジャイル?
なぜ受託開発ビジネスは
ウォーターフォール開発ばかり?
for Business
自分たちの本業とは
異なるIT関連作業を
丸投げしたいユーザ
ー企業
ユーザー企業から契
約( 稟議)を引き出し
たいSIer
双方の思惑の一致から、最初に金額を決定
する現行の受託開発ビジネスが生まれた
ウォーターフォールは現行の
受託開発ビジネスに最適の開発手法
ウォーターフォール開発は、開発の最中での仕様
変更や、漏れ・抜け・誤りを一切許さない
ミスをしない人間はいない
赤字プロジェクトや
デスマーチが簡単に
発生する要因
ウォーターフォールが当たり前なのは
IT業界の中でも受託開発ビジネスだけ
IT業界の他の分野、特にゲームは
アジャイルで開発せざるを得ない
Why?
例:キャサリン
(Playstation3 / ATLUS)
メインはパズルゲーム。足下が崩れて行くブロック
の山(壁)を、ブロックを押したり引っ張ったりして
移動させながら、ぶら下がったり飛び跳ねたりする
ことで一番上まで り着けばゴール。これらは全て
主人公の夢(悪夢)の中で行われる。恋人に結婚を迫
...
メインはパズルゲーム。足下が崩れて行く
ブロックの山(壁)を、ブロックを押したり
引っ張ったりして移動させながら、ぶら下
がったり飛び跳ねたりすることで一番上ま
で り着けばゴール。これらは全て主人公
の夢(悪夢)の中で行われる。恋人に結婚を
...
ゲームが面白いかどうかは
作って遊んでみないとわからない
ユーザーニーズの多様化
Windows95とインターネットの登場
携帯電話の普及
スマートフォンの台頭
その都度増える一般ユーザーのIT利用
様々なシーンでソフトウェアが活用され、
一方でITエンジニアの役割も急増した
アーキテクチャの複雑化
メインフレーム
クライアント&サーバ
Webアプリケーション
RIA スマートフォン
PC 組み込み
AWS
クロスプラットフォーム
iOS
Android
Firefox OS
GoogleApps
WIndows Azure
O2O
Map...
ビジネススピードの加速
ある程度の規模の企業に
業務システムは導入される
ユーザーよりも業務に詳しい
ベテラン情シスが業務システムを支える
雇用の流動化
技術・業務知識の
積み上げ
の喪失
n 開発側に負担がかかり過ぎる
n 評価軸が不確かな製品やサー
ビス
n ユーザーニーズの多様化
n ビジネススピードの加速
n アーキテクチャの複雑化
n etc…
ユーザーに価値を届け、数々の課題に対応
し、エンジニアを健全な状態に保つ方法と
してアジャイルが選ばれつつある
アジャイルと
ウォーターフォール
アジャイルなら早く上手く安く作れる?
プロセスが異なるだけでシステム開発の本質には変わり
ない。むしろアジャイルの方が高くつくかも。ただし
「ユーザーが本当に欲しいもの」が作れる可能性が高
く、結果的に安くなる事もある。
アジャイルでは大規模開発は出来ない?
Salesforceは数百人が参画するプロジェクトを
アジャイルで実施。世界最大のスクラムチームを
持つ。(世界最大はマイクロソフトという説も)
日本の受託開発ビジネスで
アジャイルな開発を導入するのは難しい?
アジャイルな開発では準委任の契約形式が
望ましい。一括請負は非常にリスキー。
アジャイルはよく失敗するって聞くけど?
これまでウォーターフォール開発が
何万回失敗して来たと思ってるんだ!?
これまでウォーターフォール開発が
何万回失敗して来たと思ってるんだ!?
歴史とは人間が流した血の河
だ。正義や真理などその河に付
けられた呼び名にすぎん。
̶ 真刈 信二 (勇吾) ̶
140
h$p://www.amazon.co.jp/dp/B00005HU5J
ソフトウェア開発もまた然り
まずは失敗してよい場所で小さく試すのが理想的
小さく始めて
成功体験を
積み上げる
受託開発(ウォーターフォール)の現場では
アジャイルな開発は出来ないのか?
NO!
アジャイルの手法は
「現場を改善する
Tips」の集合
それぞれの現場に合わせて
必要なプラクティスだけ
導入すればいい
アジャイルな
プラクティス
http://www.ryuzee.com/contents/blog/4741
全員同席
開発チーム全員が同じ場所(同じビル同じフ
ロアの隣り合った席)で一緒に仕事を行う。
プロダクトオーナーなども同様。
テスト駆動開発(TDD)
プロダクトのソースコードを書く前にテス
トコードから書く。プロダクトのソースコ
ードはそのテストがクリア出来るように記
述する。
http://www.ryuzee.com/contents/blog/4741
ペアプログラミング
二人一組で1台のPCを用いてプログラミン
グを行う。TDDと組み合わせて、1人がテ
ストコードを、1人が実装を行う事も。
http://www.ryuzee.com/contents/blog/4741
継続的インテグレーション
実装したソースコードを定期的にテスト環
境にデプロイや自動テストを行い開発対象
の品質を保つ事。Jenkinsなどのツールを
用いる事が一般的。
http://www.ryuzee.com/contents/blog/...
朝会
開発チーム全員が一同に会し、短時間で進
捗度合いや課題を共有するミーティングを
行う。
http://www.ryuzee.com/contents/blog/4741
ふりかえり
イテレーションやプロジェクトの終了時に
開発チームで良かった点反省点を出し、次
の開発へ繋げる改善案を話し合う。
http://www.ryuzee.com/contents/blog/4741
Kanban
タスク毎に付箋に書き出し、ホワイトボー
ド等に貼って進捗状況を可視化する。
http://www.ryuzee.com/contents/blog/4741
リファクタリング
実装済みのソースコードを、より読み易く
シンプルに書き直すことで、メンテナンス
性を高めておく。
http://www.ryuzee.com/contents/blog/4741
コードの共有所有
CVSやSubversion、gitを用いて、チー
ムで開発中のソースコードやドキュメント
を一元管理し、他者が手を入れ易い状況を
保つ。
http://www.ryuzee.com/contents/blog/4741
http://qiita.com/kozayupapa/items/fb9408260c2f39c66235
インセプションデッキ
10の質問に答える形で、プロジェクト開始
時に必要な方針(目的・背景・開発対象・
リスク)をチーム全員で把握・合...
http://www.chihayafuru.jp/tdiary/?date=20090116
ニコニコカレンダー
開発メンバーの体調や仕事の忙しさをフェ
イスマークの表情で可視化し、個々の状況
をチーム全員で把握し易くしておく。
イテレーションを回さなくても、アジャイルの要
素を取り入れた開発を行う事は出来る
大事なのは現場を改善
して行こうという意識
アジャイルな
エンジニア
実はアジャイルだろうが
ウォーターフォールだろうが
あんまり変わりない
チームで同じ目的・価値を目指す
自分の範囲を広げる
自分に最も適した役割を
最適のタイミングで果たす
自分が提供するものの価値を意識する
王道な「アジャイル開発」は北極星
いつも「アジャイルマニフェスト」を心に
強い意志を持って常に向上し続ける
アジャイルの
学び方
書籍
172
173
174
175
h$p://d.hatena.ne.jp/takigawa401/20120305/1330927135
勉強会※関東の場合
177
AgileSamurai BaseCamp
178
POStudy
179
アジャイルサムライ横浜道場
180
すくすくスクラム
181
DevLOVE
たった30分で
とりあえず
ひととおり
分かった気
にはなれる
アジャイル入門新装版
新装版
50
たった30分で
とりあえず
ひととおり
分かった気
にはなれる
アジャイル入門新装版
新装版
50
ご清聴
有難うございました
たった50分でとりあえずひととおり分かった気にはなれるアジャイル入門【新装版】
たった50分でとりあえずひととおり分かった気にはなれるアジャイル入門【新装版】
たった50分でとりあえずひととおり分かった気にはなれるアジャイル入門【新装版】
Upcoming SlideShare
Loading in …5
×

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

45,782 views

Published on

以前公開したアジャイルの資料を2年振りに改めて社内で発表する機会を得たため、アップデート版を掲載致します。
http://www.slideshare.net/takigawa401/30-15760436

Published in: Technology
  • Be the first to comment

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

  1. 1. たった30分で とりあえず ひととおり 分かった気 にはなれる アジャイル入門新装版 新装版 50
  2. 2. 2 ……の、その前に
  3. 3. 3 誰だオマエ?
  4. 4. 自己紹介 滝川 陽一(たきがわ よういち)… takigawa401 •1978年07月26日生 (36歳) •長野県飯田市近辺出身、東京在住 •株式会社インデックス(セガサミーグループ)所属 •職業:システムエンジニア •前職: 客先常駐上等! n次請けSIer (11年在籍) •ウォーターフォール代表 •FC東京/中日ドラゴンズ/松本山雅 •アジャイル/ロジカルシンキング •BMG Works/TOCfE BC
  5. 5. 自己紹介 滝川 陽一(たきがわ よういち)… takigawa401 •1978年07月26日生 (36歳) •長野県飯田市近辺出身、東京在住 •株式会社インデックス(セガサミーグループ)所属 •職業:システムエンジニア •前職: 客先常駐上等! n次請けSIer (11年在籍) •ウォーターフォール代表 •FC東京/中日ドラゴンズ/松本山雅 •アジャイル/ロジカルシンキング •BMG Works/TOCfE BC
  6. 6. 前置き
  7. 7. 2011年のとある日、客先にて
  8. 8. Androidアプリ開発 ⽤用の開発標準作って よ。アジャイルでオフ ショアやりたいから さ。宜しく頼むわ。 ※画像はイメージです
  9. 9. それ以降、社内外で アジャイルに様々な 形でトライしてきた
  10. 10. アジャイルについて ざっくばらんにお伝えします
  11. 11. 対象者
  12. 12. n アジャイルって最近良く聞くけど全然分かんなく って……。 n そもそもウォーターフォールだって良く分かんな いのに……。 n アジャイルってドキュメント書かないんでしょ? n アジャイルで開発すると早くて安く上がるらしい じゃん? n アジャイルだと大規模開発できないんだろ? n アジャイルなんて失敗多いもの採用出来るか! 対象者
  13. 13. n アジャイルって最近良く聞くけど全然分かんなく って……。 n そもそもウォーターフォールだって良く分かんな いのに……。 n アジャイルってドキュメント書かないんでしょ? n アジャイルで開発すると早くて安く上がるらしい じゃん? n アジャイルだと大規模開発できないんだろ? n アジャイルなんて失敗多いもの採用出来るか! 対象者 かかって こい!!
  14. 14. アジェンダ
  15. 15. アジェンダ n アジャイルとは? n アジャイルマニフェスト n ウォーターフォールとは? n アジャイルの種類 n なぜアジャイル? n アジャイルなエンジニア n どうやってアジャイルを学ぶ?
  16. 16. 所 要 時 間所 要 時 間
  17. 17. アジャイル ってなに?
  18. 18. アジャイル 開発
  19. 19. 「アジャイル」は形容詞、邦訳で「敏 捷な」「小回りのきく」という意味を 指す。 「開発がアジャイルだ」など状態を表 すことは出来るが、厳密には「アジャ イル開発」という手法は存在しない。 便宜上の「アジャイル開発」という言 葉が に定着しているのが現状。
  20. 20. アジャイルのはじまり
  21. 21. アジャイル マニフェスト
  22. 22. アジャイルソフトウェア開発宣言 (アジャイルマニフェスト) 2001年に、アジャイルソフトウェア開発手法の分野において名声 のあるケント・ベックら17人がアメリカ合衆国ユタ州スノーバー ドに会し、彼らがそれぞれ別個に提唱していた開発手法の重要な 部分を統合することについて議論した。 そして、彼らは「アジャ イルソフトウェア開発宣言」(Manifesto for Agile Software Development)という文書にまとめた。 アジャイルソフトウェア 開発宣言は、アジャイルソフトウェア開発とその諸原則を公式に 定義した文書であると、広く認められている(参考: アジャイルソ フトウェアの原則) 。 アジャイルソフトウェア開発  -‐‑‒  Wikipedia  http://buff.ly/U7AVk4
  23. 23. 私たちは、ソフトウェア開発の 実践あるいは実践を手助けをす る活動を通じて、よりよい開発 方法を見つけだそうとしてい る。この活動を通して、私たち は以下の価値に至った アジャイルソフトウェア開発宣⾔言  http://agilemanifesto.org/iso/ja/
  24. 24. プロセスやツー ルよりも個人と 対話を
  25. 25. 包括的なドキュメ ントよりも動くソ フトウェアを
  26. 26. 契約交渉よりも 顧客との協調を
  27. 27. 計画に従うこと よりも変化への 対応を
  28. 28. 私たちは、ソフトウェア開発の実践 あるいは実践を手助けをする活動を通じて、 よりよい開発方法を見つけだそうとしている。 この活動を通して、私たちは以下の価値に至った。 プロセスやツールよりも個人と対話を、 包括的なドキュメントよりも動くソフトウェアを、 契約交渉よりも顧客との協調を、 計画に従うことよりも変化への対応を、 価値とする。すなわち、左記のことがらに価値があることを 認めながらも、私たちは右記のことがらにより価値をおく。 h$p://agilemanifesto.org/iso/ja/ アジャイルソフトウェア開発宣言 (アジャイルマニフェスト)
  29. 29. アジャイル宣言の背後にある原則 私たちは以下の原則に従う: 1. 顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。 2. 要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客 様の競争力を引き上げます。 3. 動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。 4. ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。 5. 意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで 彼らを信頼します。 6. 情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。 7. 動くソフトウェアこそが進 の最も重要な尺度です。 8. アジャイル・プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるよう にしなければなりません。 9. 技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。 10.シンプルさ(ムダなく作れる量を最大限にすること)が本質です。 11.最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。 12.チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのや り方を最適に調整します。 アジャイル宣⾔言の背後にある原則  http://agilemanifesto.org/iso/ja/principles.html
  30. 30. これでアナタも明日から アジャイルなエンジニア!
  31. 31. たった30分で とりあえず ひととおり 分かった気 にはなれる アジャイル入門新装版 新装版 50 ご清聴 有難うございました
  32. 32. 原理とか原則とかどーでもいいから さっさとアジャイルを教えろよ!!
  33. 33. アジャイルのすべては必ず アジャイルマニフェストに通ずる 決して軽んずべからず
  34. 34. 届ける「価値」を意識する
  35. 35. 37 失敗こそが人をもっとも成長させる h$p://www.genrei-­‐koubou.com/zakin/
  36. 36. 如何に早く小さく失敗するか
  37. 37. 失敗によるダメージ を最小限に抑え 学びを次に生かす
  38. 38. アジャイル な開発手法 の種類
  39. 39. と、その前に
  40. 40. ウォーターフォール開発
  41. 41. 開発プロジェクトを時系列に、要求定義→外部設計(概要 設計) →内部設計(詳細設計) →開発(プログラミング) → テスト→運用 などの作業工程に分割し、原則として前工 程が完了しないと次工程に進まない(設計中にプログラミ ングを開始するなどの並行作業は行わない)事で、前工程 の成果物の品質を確保し、前工程への手戻りを最小限に する。 ウォーターフォール・モデル  -‐‑‒  Wikipedia  http://buff.ly/TxgnQH
  42. 42. ウォーターフォール・モデル  -‐‑‒  Wikipedia  http://buff.ly/TxgnQH 嘘だ!!
  43. 43. 本当のウォーターフォール開発は2度繰り返す
  44. 44. 本開発の前にプロトタイプ開発を必ず行 い、技術検証を行うのが当初の「ウォータ ーフォール開発」 プロトタイプ
  45. 45. h$p://ja.wikipedia.org/wiki/紙テープ かつてのソフトウェア開発は 非常にシンプルだった
  46. 46. h$p://blogs.yahoo.co.jp/junji_daa/24103719.html 簡単な計算を行う程度の能力
  47. 47. 薄れる検証の必要性薄れる検証の必要性
  48. 48. h$p://meiji.sakanouenokumo.jp/blog/archives/2010/06/post_815.html 日本に伝わるタイミングでは既に プロトタイプ開発の工程が無かった
  49. 49. 日本のウォーターフォールは 現在のプロトタイプ開発無しの スタイルが主流となる
  50. 50. メリット
  51. 51. メリット n 要求定義の工数見積に従って一括請負契約 を結ぶことができる n 承認プロセスが明確であるため責任の所在 が明確である n プロジェクト参加者が担う役割は固定的で 考える事が少ない(低スキルの技術者でも参 画し易い)
  52. 52. デメリット
  53. 53. デメリット n 開発途中での仕様変更に対応しきれない n 仮説に基づいた要件にならざるを得ない n システムの実物を確認出来るになるまでの 時間が長い n 終盤にならなければ仮説の検証を行えない n ひとつひとつの工程が長すぎる n 前工程の成果物は完全であることを前提と するため、誤りが発生した際手戻りが発生 する
  54. 54. 本題
  55. 55. アジャイルな 開発手法の種類
  56. 56. XP (エクストリームプログラミング)
  57. 57. 1999年に書籍『XPエクスト リーム・プログラミング入門 ―ソフトウェア開発の究極の 手法』(ケント・ベック著)に よって発表された。柔軟性の 高い開発手法であるため、難 易度の高い開発やビジネス上 の要求が刻々と変わるような 状況に向いた開発手法。ドキ ュメントよりもソースコード を、組織的開発の歯車となる ことよりも、個人の責任と勇 気を重んじる人間中心の開発 プロセスであるとしている。 エクストリーム・プログラミング  -‐‑‒  Wikipedia  http://buff.ly/TygsUk
  58. 58. 5つの価値
  59. 59. 5つの価値 n コミュニケーション n シンプル n フィードバック n 勇気 n 尊重 5つの価値は19のプラクティスに影響を与え、 XPの根幹を為す
  60. 60. 19のプラクティス
  61. 61. 19のプラクティス n 共同のプラクティス(4つ) n 反復 n 共通の用語 n 開けた作業空間 n 回顧(頻繁な振り返り)
  62. 62. 19のプラクティス n 開発のプラクティス(6つ) n テスト駆動開発 n ペアプログラミング n リファクタリング n ソースコードの共同所有 n 継続的インテグレーション n YAGNI
  63. 63. 19のプラクティス n 管理者のプラクティス(5つ) n 責任の受け入れ n 援護 n 四半期毎の見直し n ミラー n 最適なペースの仕事
  64. 64. 19のプラクティス n 顧客のプラクティス(4つ) n ストーリーの作成 n リリース計画 n 受け入れテスト n 短期リリース
  65. 65. 19のプラクティス このプラクティス を全て実施するの は非常に難しい
  66. 66. 68 「ぼく の かんがえた さいきょうの かいはつ プラクティス」
  67. 67. 69 個別に使ってもそこそこ強い。 (※ちゃんと使いこなせるなら)
  68. 68. 70 XPのプラクティスが由来と知らずに 使っているケースもある
  69. 69. Scrum
  70. 70.  1993年、ジェフ・サザーランド ら3名がラウンドトリップ・エンジ ニアリング(一種の反復型開発)を取 り入れたオブジェクト指向プログラ ミング設計・分析ツールを構築した のが最初。当時、素早い開発が求め られており、要求仕様を簡単に動作 するコードに変換する方法が求められていた。同じ頃、ケン・シュエイ バーが自社(ADM)でのソフトウェア開発にこの手法を用いた。  スクラム的手法を以前から活用していた企業として、富士ゼロック ス、キヤノン、(中略)などがある。これらのプロジェクトについては、 一橋大学の野中郁次郎と竹内弘高が Harvard Business Review 誌に 「The New New Product Development Game」として 発表している(1986年1-2月)。 スクラム  (ソフトウェア開発)  -‐‑‒  Wikipedia  http://buff.ly/T8Cayk
  71. 71. Scrumは 「開発プロセス」 のフレームワーク ソフトウェア開発以 外にも活用すること ができる
  72. 72. Scrumは現在最も利用されている アジャイルな開発手法
  73. 73. ユーザー要件を細小単位に分割し、さらに機能単位に分割したも のを2∼4weekのイテレーションごとにチームが開発を行う。イ テレーション終了時には製品・サービスの責任者が評価を行い、 完成とみなされたものだけがリリースされる。イテレーション終 了時には必ず開発チームで「ふりかえり」を行い、次のイテレー ションに経験を生かす。
  74. 74. Scrum開発チーム プロダクトオーナー スクラムマスター チーム
  75. 75. プロダクトオーナー(PO) 製品の総責任者。 お客 様の意思の代表として の役割を担う。ビジネ ス視点(ROI等)でプロ ジェクトに問題がない 事を保障する役割を持 つ。顧客の要望に優先 順位を付ける。 スクラム  (ソフトウェア開発)  -‐‑‒  Wikipedia  http://buff.ly/T8Cayk
  76. 76. 各メンバーが協力し、全 体として同じゴールを目 指す。チームの人数は5 人から9人が適当とさ れ、実装とテストの能力 を持つ。チームは作業プ ロセスと作業結果の責任 も持ち、自らチーム内の 管理を行う。 チーム スクラム  (ソフトウェア開発)  -‐‑‒  Wikipedia  http://buff.ly/T8Cayk
  77. 77. プロジェクトが円滑に 進むよう調整する。主 な作業はチーム内外の ファシリテーションと 外部妨害の対処。従来 のPMの役割を担う事 が多いが最もプロジェ クト管理責任が少ない スクラムマスター(SM) スクラム  (ソフトウェア開発)  -‐‑‒  Wikipedia  http://buff.ly/T8Cayk
  78. 78. 調整役 開発を実施 ビジネス要件を 出す 往々にして対立しがち(協調出来るのが勿論望ましい)なチームと POの間を取り持ち、プロジェクトが円滑に進むようにバランスを 取るのがスクラムマスターの役割。 対立 バランス
  79. 79. 優れた開発チームには 管理者は要らない
  80. 80. チームが成熟した状態が 最も生産性が高い
  81. 81. チームを解散してはならない
  82. 82. Lean Startup
  83. 83. エリック・リースが提唱したベンチャービジネスの立ち上げ 手法のひとつ。「リーン」とはトヨタの「リーン生産方式」から の引用。エリック・リースがプログラマだったことから、XPの要 素を色濃く持つ。「ビジネスを素早く立ち上げ、可能な限り早く 小さく失敗し、いち早く成功に り着く」ことを目的とする。
  84. 84. IDEA ビジネスの着想となる最 初のアイディア。「仮 説」とも。大前提として 「誤っている」として捉 え、徐々に修正して行く 事が必要になる。
  85. 85. MVP 「Minimam Viable Product(実用最小限の 製品)」の略。ユーザー ニーズを測れる最低限の 機能を持った状態のサー ビス・製品を指す。必ず しも製品になっている必 要はなく、モックやコン セプトビデオのような場 合もある。
  86. 86. Analysis ローンチ後のMVPの利 用状況をログから計測す る。指標の設定が非常に 重要で、誤った指標設定 を行っていた場合、ビジ ネスを成功に方向修正す ることが非常に困難にな る。
  87. 87. Pivot 分析の結果として「仮 説」が誤っていると判断 出来た場合、新たに仮説 を立ててビジネスを方向 転換する。 一から考え直すのではな く、微修正に留める。
  88. 88. 91 h$p://www.officiallyjd.com/archives/155047/20120717_matsumotohitoshi_15/ 全てのアイディア は、最初は寝言で 妄言に過ぎない
  89. 89. 92 ユーザーの本当に欲しいものはユーザーしか分からない。 取締役承認を得たからといって成功するとは限らない。
  90. 90. 93 ユーザーの声に 耳を傾ける ユーザーの声に 耳を傾ける
  91. 91. ユーザーインタビュー
  92. 92. ログ分析
  93. 93. MVPの作成→ローンチ→分析→ピボットの作成 を素早く繰り返し、いち早くユーザーの心をつかむ
  94. 94. 97 h$p://www.slideshare.net/kkd/about-­‐annotatedbibliographyinx-­‐pinesm アジャイルな開発手法とそのスコープ
  95. 95. 何故 アジャイル?
  96. 96. なぜ受託開発ビジネスは ウォーターフォール開発ばかり?
  97. 97. for Business
  98. 98. 自分たちの本業とは 異なるIT関連作業を 丸投げしたいユーザ ー企業
  99. 99. ユーザー企業から契 約( 稟議)を引き出し たいSIer
  100. 100. 双方の思惑の一致から、最初に金額を決定 する現行の受託開発ビジネスが生まれた
  101. 101. ウォーターフォールは現行の 受託開発ビジネスに最適の開発手法
  102. 102. ウォーターフォール開発は、開発の最中での仕様 変更や、漏れ・抜け・誤りを一切許さない
  103. 103. ミスをしない人間はいない
  104. 104. 赤字プロジェクトや デスマーチが簡単に 発生する要因
  105. 105. ウォーターフォールが当たり前なのは IT業界の中でも受託開発ビジネスだけ
  106. 106. IT業界の他の分野、特にゲームは アジャイルで開発せざるを得ない
  107. 107. Why?
  108. 108. 例:キャサリン (Playstation3 / ATLUS)
  109. 109. メインはパズルゲーム。足下が崩れて行くブロック の山(壁)を、ブロックを押したり引っ張ったりして 移動させながら、ぶら下がったり飛び跳ねたりする ことで一番上まで り着けばゴール。これらは全て 主人公の夢(悪夢)の中で行われる。恋人に結婚を迫 られた主人公がある夜初めて会った美女と一夜を共 にしてしまってから始まった悪夢。毎晩命がけで登 り続けることになる。 ゲーム概要
  110. 110. メインはパズルゲーム。足下が崩れて行く ブロックの山(壁)を、ブロックを押したり 引っ張ったりして移動させながら、ぶら下 がったり飛び跳ねたりすることで一番上ま で り着けばゴール。これらは全て主人公 の夢(悪夢)の中で行われる。恋人に結婚を 迫られた主人公がある夜初めて会った美女 ゲーム概要 イラストも無しに説明文だけ でこのゲームを「面白い」と 判断するのは至難の業
  111. 111. ゲームが面白いかどうかは 作って遊んでみないとわからない
  112. 112. ユーザーニーズの多様化
  113. 113. Windows95とインターネットの登場
  114. 114. 携帯電話の普及
  115. 115. スマートフォンの台頭
  116. 116. その都度増える一般ユーザーのIT利用
  117. 117. 様々なシーンでソフトウェアが活用され、 一方でITエンジニアの役割も急増した
  118. 118. アーキテクチャの複雑化
  119. 119. メインフレーム クライアント&サーバ 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
  120. 120. ビジネススピードの加速
  121. 121. ある程度の規模の企業に 業務システムは導入される
  122. 122. ユーザーよりも業務に詳しい ベテラン情シスが業務システムを支える
  123. 123. 雇用の流動化
  124. 124. 技術・業務知識の 積み上げ の喪失
  125. 125. n 開発側に負担がかかり過ぎる n 評価軸が不確かな製品やサー ビス n ユーザーニーズの多様化 n ビジネススピードの加速 n アーキテクチャの複雑化 n etc…
  126. 126. ユーザーに価値を届け、数々の課題に対応 し、エンジニアを健全な状態に保つ方法と してアジャイルが選ばれつつある
  127. 127. アジャイルと ウォーターフォール
  128. 128. アジャイルなら早く上手く安く作れる?
  129. 129. プロセスが異なるだけでシステム開発の本質には変わり ない。むしろアジャイルの方が高くつくかも。ただし 「ユーザーが本当に欲しいもの」が作れる可能性が高 く、結果的に安くなる事もある。
  130. 130. アジャイルでは大規模開発は出来ない?
  131. 131. Salesforceは数百人が参画するプロジェクトを アジャイルで実施。世界最大のスクラムチームを 持つ。(世界最大はマイクロソフトという説も)
  132. 132. 日本の受託開発ビジネスで アジャイルな開発を導入するのは難しい?
  133. 133. アジャイルな開発では準委任の契約形式が 望ましい。一括請負は非常にリスキー。
  134. 134. アジャイルはよく失敗するって聞くけど?
  135. 135. これまでウォーターフォール開発が 何万回失敗して来たと思ってるんだ!? これまでウォーターフォール開発が 何万回失敗して来たと思ってるんだ!?
  136. 136. 歴史とは人間が流した血の河 だ。正義や真理などその河に付 けられた呼び名にすぎん。 ̶ 真刈 信二 (勇吾) ̶
  137. 137. 140 h$p://www.amazon.co.jp/dp/B00005HU5J ソフトウェア開発もまた然り
  138. 138. まずは失敗してよい場所で小さく試すのが理想的
  139. 139. 小さく始めて 成功体験を 積み上げる
  140. 140. 受託開発(ウォーターフォール)の現場では アジャイルな開発は出来ないのか?
  141. 141. NO!
  142. 142. アジャイルの手法は 「現場を改善する Tips」の集合
  143. 143. それぞれの現場に合わせて 必要なプラクティスだけ 導入すればいい
  144. 144. アジャイルな プラクティス
  145. 145. http://www.ryuzee.com/contents/blog/4741 全員同席 開発チーム全員が同じ場所(同じビル同じフ ロアの隣り合った席)で一緒に仕事を行う。 プロダクトオーナーなども同様。
  146. 146. テスト駆動開発(TDD) プロダクトのソースコードを書く前にテス トコードから書く。プロダクトのソースコ ードはそのテストがクリア出来るように記 述する。 http://www.ryuzee.com/contents/blog/4741
  147. 147. ペアプログラミング 二人一組で1台のPCを用いてプログラミン グを行う。TDDと組み合わせて、1人がテ ストコードを、1人が実装を行う事も。 http://www.ryuzee.com/contents/blog/4741
  148. 148. 継続的インテグレーション 実装したソースコードを定期的にテスト環 境にデプロイや自動テストを行い開発対象 の品質を保つ事。Jenkinsなどのツールを 用いる事が一般的。 http://www.ryuzee.com/contents/blog/4741
  149. 149. 朝会 開発チーム全員が一同に会し、短時間で進 捗度合いや課題を共有するミーティングを 行う。 http://www.ryuzee.com/contents/blog/4741
  150. 150. ふりかえり イテレーションやプロジェクトの終了時に 開発チームで良かった点反省点を出し、次 の開発へ繋げる改善案を話し合う。 http://www.ryuzee.com/contents/blog/4741
  151. 151. Kanban タスク毎に付箋に書き出し、ホワイトボー ド等に貼って進捗状況を可視化する。 http://www.ryuzee.com/contents/blog/4741
  152. 152. リファクタリング 実装済みのソースコードを、より読み易く シンプルに書き直すことで、メンテナンス 性を高めておく。 http://www.ryuzee.com/contents/blog/4741
  153. 153. コードの共有所有 CVSやSubversion、gitを用いて、チー ムで開発中のソースコードやドキュメント を一元管理し、他者が手を入れ易い状況を 保つ。 http://www.ryuzee.com/contents/blog/4741
  154. 154. http://qiita.com/kozayupapa/items/fb9408260c2f39c66235 インセプションデッキ 10の質問に答える形で、プロジェクト開始 時に必要な方針(目的・背景・開発対象・ リスク)をチーム全員で把握・合意するこ とが出来る。
  155. 155. http://www.chihayafuru.jp/tdiary/?date=20090116 ニコニコカレンダー 開発メンバーの体調や仕事の忙しさをフェ イスマークの表情で可視化し、個々の状況 をチーム全員で把握し易くしておく。
  156. 156. イテレーションを回さなくても、アジャイルの要 素を取り入れた開発を行う事は出来る
  157. 157. 大事なのは現場を改善 して行こうという意識
  158. 158. アジャイルな エンジニア
  159. 159. 実はアジャイルだろうが ウォーターフォールだろうが あんまり変わりない
  160. 160. チームで同じ目的・価値を目指す
  161. 161. 自分の範囲を広げる
  162. 162. 自分に最も適した役割を 最適のタイミングで果たす
  163. 163. 自分が提供するものの価値を意識する
  164. 164. 王道な「アジャイル開発」は北極星
  165. 165. いつも「アジャイルマニフェスト」を心に
  166. 166. 強い意志を持って常に向上し続ける
  167. 167. アジャイルの 学び方
  168. 168. 書籍
  169. 169. 172
  170. 170. 173
  171. 171. 174
  172. 172. 175
  173. 173. h$p://d.hatena.ne.jp/takigawa401/20120305/1330927135 勉強会※関東の場合
  174. 174. 177 AgileSamurai BaseCamp
  175. 175. 178 POStudy
  176. 176. 179 アジャイルサムライ横浜道場
  177. 177. 180 すくすくスクラム
  178. 178. 181 DevLOVE
  179. 179. たった30分で とりあえず ひととおり 分かった気 にはなれる アジャイル入門新装版 新装版 50
  180. 180. たった30分で とりあえず ひととおり 分かった気 にはなれる アジャイル入門新装版 新装版 50 ご清聴 有難うございました

×