たった50分でとりあえずひととおり分かった気にはなれるアジャイル入門【新装版】...
183
たった30分で とりあえず ひととおり 分かった気 にはなれる アジャイル入門 新装版 新装版 50
-
Upload
youichi-takigawa -
Category
Technology
-
view
1.323 -
download
5
Transcript of たった50分でとりあえずひととおり分かった気にはなれるアジャイル入門【新装版】...
たった30分でとりあえずひととおり分かった気にはなれるアジャイル入門新装
版新装版
50
2
……の、その前に
3誰だオマエ？
自己紹介
滝川 陽一（たきがわ よういち）… takigawa401
•1978年07月26日生 (36歳)•長野県飯田市近辺出身、東京在住•株式会社インデックス(セガサミーグループ)所属•職業：システムエンジニア•前職： 客先常駐上等！ n次請けSIer (11年在籍)•ウォーターフォール代表•FC東京／中日ドラゴンズ／松本山雅•アジャイル／ロジカルシンキング•BMG Works／TOCfE BC
自己紹介
滝川 陽一（たきがわ よういち）… 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://buff.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://buff.ly/TxgnQH
ウォーターフォール・モデル -‐‑‒ 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エクストリーム・プログラミング入門―ソフトウェア開発の究極の手法』(ケント・ベック著)によって発表された。柔軟性の高い開発手法であるため、難易度の高い開発やビジネス上の要求が刻々と変わるような状況に向いた開発手法。ドキュメントよりもソースコードを、組織的開発の歯車となることよりも、個人の責任と勇気を重んじる人間中心の開発プロセスであるとしている。
エクストリーム・プログラミング -‐‑‒ Wikipedia http://buff.ly/TygsUk
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名がラウンドトリップ・エンジニアリング(一種の反復型開発)を取り入れたオブジェクト指向プログラミング設計・分析ツールを構築したのが最初。当時、素早い開発が求められており、要求仕様を簡単に動作
するコードに変換する方法が求められていた。同じ頃、ケン・シュエイバーが自社(ADM)でのソフトウェア開発にこの手法を用いた。 スクラム的手法を以前から活用していた企業として、富士ゼロックス、キヤノン、(中略)などがある。これらのプロジェクトについては、一橋大学の野中郁次郎と竹内弘高が Harvard Business Review 誌に 「The New New Product Development Game」として発表している(1986年1-2月)。
スクラム (ソフトウェア開発) -‐‑‒ Wikipedia http://buff.ly/T8Cayk
Scrumは「開発プロセス」のフレームワーク
ソフトウェア開発以外にも活用することができる
Scrumは現在最も利用されているアジャイルな開発手法
ユーザー要件を細小単位に分割し、さらに機能単位に分割したものを2～4weekのイテレーションごとにチームが開発を行う。イテレーション終了時には製品・サービスの責任者が評価を行い、完成とみなされたものだけがリリースされる。イテレーション終了時には必ず開発チームで「ふりかえり」を行い、次のイテレーションに経験を生かす。
Scrum開発チームプロダクトオーナー
スクラムマスター
チーム
プロダクトオーナー(PO)製品の総責任者。 お客様の意思の代表としての役割を担う。ビジネス視点(ROI等)でプロジェクトに問題がない事を保障する役割を持つ。顧客の要望に優先順位を付ける。
スクラム (ソフトウェア開発) -‐‑‒ Wikipedia http://buff.ly/T8Cayk
各メンバーが協力し、全体として同じゴールを目指す。チームの人数は5人から９人が適当とされ、実装とテストの能力を持つ。チームは作業プロセスと作業結果の責任も持ち、自らチーム内の管理を行う。
チーム
スクラム (ソフトウェア開発) -‐‑‒ Wikipedia http://buff.ly/T8Cayk
プロジェクトが円滑に進むよう調整する。主な作業はチーム内外のファシリテーションと外部妨害の対処。従来のPMの役割を担う事が多いが最もプロジェクト管理責任が少ない
スクラムマスター(SM)
スクラム (ソフトウェア開発) -‐‑‒ Wikipedia http://buff.ly/T8Cayk
調整役
開発を実施ビジネス要件を
出す
往々にして対立しがち(協調出来るのが勿論望ましい)なチームとPOの間を取り持ち、プロジェクトが円滑に進むようにバランスを取るのがスクラムマスターの役割。
対立バランス
優れた開発チームには管理者は要らない
チームが成熟した状態が最も生産性が高い
チームを解散してはならない
Lean Startup
エリック・リースが提唱したベンチャービジネスの立ち上げ手法のひとつ。「リーン」とはトヨタの「リーン生産方式」からの引用。エリック・リースがプログラマだったことから、XPの要素を色濃く持つ。「ビジネスを素早く立ち上げ、可能な限り早く小さく失敗し、いち早く成功に辿り着く」ことを目的とする。
IDEA
ビジネスの着想となる最初のアイディア。「仮説」とも。大前提として「誤っている」として捉え、徐々に修正して行く事が必要になる。
MVP
「Minimam Viable Product(実用最小限の製品)」の略。ユーザーニーズを測れる最低限の機能を持った状態のサービス・製品を指す。必ずしも製品になっている必要はなく、モックやコンセプトビデオのような場合もある。
Analysis
ローンチ後のMVPの利用状況をログから計測する。指標の設定が非常に重要で、誤った指標設定を行っていた場合、ビジネスを成功に方向修正することが非常に困難になる。
Pivot
分析の結果として「仮説」が誤っていると判断出来た場合、新たに仮説を立ててビジネスを方向転換する。一から考え直すのではなく、微修正に留める。
91h$p://www.officiallyjd.com/archives/155047/20120717_matsumotohitoshi_15/
全てのアイディアは、最初は寝言で妄言に過ぎない
92
ユーザーの本当に欲しいものはユーザーしか分からない。取締役承認を得たからといって成功するとは限らない。
93
ユーザーの声に耳を傾ける
ユーザーの声に耳を傾ける
ユーザーインタビュー
ログ分析
MVPの作成→ローンチ→分析→ピボットの作成を素早く繰り返し、いち早くユーザーの心をつかむ
97h$p://www.slideshare.net/kkd/about-‐annotatedbibliographyinx-‐pinesm
アジャイルな開発手法とそのスコープ
何故アジャイル？
なぜ受託開発ビジネスはウォーターフォール開発ばかり？
for Business
自分たちの本業とは異なるIT関連作業を丸投げしたいユーザ
ー企業
ユーザー企業から契約(≒稟議)を引き出し
たいSIer
双方の思惑の一致から、最初に金額を決定する現行の受託開発ビジネスが生まれた
ウォーターフォールは現行の受託開発ビジネスに最適の開発手法
ウォーターフォール開発は、開発の最中での仕様変更や、漏れ・抜け・誤りを一切許さない
ミスをしない人間はいない
赤字プロジェクトやデスマーチが簡単に
発生する要因
ウォーターフォールが当たり前なのはIT業界の中でも受託開発ビジネスだけ
IT業界の他の分野、特にゲームはアジャイルで開発せざるを得ない
Why?
例：キャサリン(Playstation3 / ATLUS)
メインはパズルゲーム。足下が崩れて行くブロックの山(壁)を、ブロックを押したり引っ張ったりして移動させながら、ぶら下がったり飛び跳ねたりすることで一番上まで辿り着けばゴール。これらは全て主人公の夢(悪夢)の中で行われる。恋人に結婚を迫られた主人公がある夜初めて会った美女と一夜を共にしてしまってから始まった悪夢。毎晩命がけで登り続けることになる。
ゲーム概要
メインはパズルゲーム。足下が崩れて行くブロックの山(壁)を、ブロックを押したり引っ張ったりして移動させながら、ぶら下がったり飛び跳ねたりすることで一番上まで辿り着けばゴール。これらは全て主人公の夢(悪夢)の中で行われる。恋人に結婚を迫られた主人公がある夜初めて会った美女と一夜を共にしてしまってから始まった悪夢。毎晩命がけで登り続けることになる。
ゲーム概要イラストも無しに説明文だけでこのゲームを「面白い」と
判断するのは至難の業
ゲームが面白いかどうかは作って遊んでみないとわからない
ユーザーニーズの多様化
Windows95とインターネットの登場
携帯電話の普及
スマートフォンの台頭
その都度増える一般ユーザーのIT利用
様々なシーンでソフトウェアが活用され、一方でITエンジニアの役割も急増した
アーキテクチャの複雑化
メインフレーム
クライアント＆サーバ
Webアプリケーション
RIA スマートフォン
PC 組み込み
AWSクロスプラットフォーム
iOSAndroid
Firefox OS GoogleApps
WIndows Azure O2OMap Reduce
Hadoop
O/R Mapper
MVC
アセンブラUNIX
LinuxWindows Server
RDB
KVSNoSQL
ストアドプロシージャ
ERP
EDI
SOA
ESBBPM
EAI
COBOLJava
JavaVMC言語
C++C#
Swift
VB.NETjQuery
Haskel
PHP
LAMP
Python
SOAP
Ajax
RESTGoLang
GoLang
GIS
h$p://blog.livedoor.jp/miniaturenews/archives/6838961.html
全ての要素を把握し最適解を出すなどもはや不可能
DWH
BI
ビジネススピードの加速
ある程度の規模の企業に業務システムは導入される
ユーザーよりも業務に詳しいベテラン情シスが業務システムを支える
雇用の流動化
技術・業務知識の積み上げの喪失
n 開発側に負担がかかり過ぎるn 評価軸が不確かな製品やサー
ビスn ユーザーニーズの多様化n ビジネススピードの加速n アーキテクチャの複雑化n etc…
ユーザーに価値を届け、数々の課題に対応し、エンジニアを健全な状態に保つ方法と
してアジャイルが選ばれつつある
アジャイルとウォーターフォール
アジャイルなら早く上手く安く作れる？
プロセスが異なるだけでシステム開発の本質には変わりない。むしろアジャイルの方が高くつくかも。ただし「ユーザーが本当に欲しいもの」が作れる可能性が高く、結果的に安くなる事もある。
アジャイルでは大規模開発は出来ない？
Salesforceは数百人が参画するプロジェクトをアジャイルで実施。世界最大のスクラムチームを持つ。(世界最大はマイクロソフトという説も)
日本の受託開発ビジネスでアジャイルな開発を導入するのは難しい？
アジャイルな開発では準委任の契約形式が望ましい。一括請負は非常にリスキー。
アジャイルはよく失敗するって聞くけど？
これまでウォーターフォール開発が何万回失敗して来たと思ってるんだ!?これまでウォーターフォール開発が何万回失敗して来たと思ってるんだ!?
歴史とは人間が流した血の河だ。正義や真理などその河に付けられた呼び名にすぎん。
真刈 信二 (勇吾)
140h$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/4741
朝会
開発チーム全員が一同に会し、短時間で進捗度合いや課題を共有するミーティングを行う。
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
ご清聴有難うございました
