たった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://buff.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://buff.ly/TxgnQH

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

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

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

プロトタイプ

メリット

メリット 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のプラクティス

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

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

スクラムマスター(SM)

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

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

チーム

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

調整役

開発を実施 ビジネス要件を出す

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

対立 バランス

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

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

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

番外

Lean Startup

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

IDEA

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

MVP

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

Analysis

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

Pivot

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

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

サービス・製品を作り、市場に提供する

何故 アジャイル？

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

for Business

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

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

たいSIer

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

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

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

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

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

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

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

Why?

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

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

ゲーム概要

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

ゲーム概要 イラストも無しに説明文だけでこのゲームを「面白い」と

判断するのは至難の業

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

ユーザーニーズの多様化

ビジネススピードの加速

アーキテクチャの複雑化

n  開発側に負担がかかり過ぎる

n  評価軸が不確かな製品・サービス

n  ユーザーニーズの多様化 n  ビジネススピードの加速 n  アーキテクチャの複雑化 n  etc…

ユーザーに価値を届け、数々の課題に対応し、エンジニアを健全な状態に保つ方法と

してアジャイルが選ばれつつある

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

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

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

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

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

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

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

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

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

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

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

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

NO!

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

例えば

[Agile]Agile  Buffet  Cardを作りました  –  Ryuzee.comhttp://www.ryuzee.com/contents/blog/4741

全員同席

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

[Agile]Agile  Buffet  Cardを作りました  –  Ryuzee.comhttp://www.ryuzee.com/contents/blog/4741

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

[Agile]Agile  Buffet  Cardを作りました  –  Ryuzee.comhttp://www.ryuzee.com/contents/blog/4741

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

[Agile]Agile  Buffet  Cardを作りました  –  Ryuzee.comhttp://www.ryuzee.com/contents/blog/4741

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

[Agile]Agile  Buffet  Cardを作りました  –  Ryuzee.comhttp://www.ryuzee.com/contents/blog/4741

朝会

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

[Agile]Agile  Buffet  Cardを作りました  –  Ryuzee.comhttp://www.ryuzee.com/contents/blog/4741

ふりかえり

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

[Agile]Agile  Buffet  Cardを作りました  –  Ryuzee.comhttp://www.ryuzee.com/contents/blog/4741

Kanban

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

[Agile]Agile  Buffet  Cardを作りました  –  Ryuzee.comhttp://www.ryuzee.com/contents/blog/4741

リファクタリング

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

[Agile]Agile  Buffet  Cardを作りました  –  Ryuzee.comhttp://www.ryuzee.com/contents/blog/4741

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

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

ニコニコカレンダー

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

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

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

アジャイルな エンジニア

実はアジャイルだろうが ウォーターフォールだろうが

あんまり変わりない

同じバスに乗る

自分の範囲を広げる

自己組織化

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

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

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

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

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

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

ご清聴 有難うございました。