Agile Conference tokyo 2011 に行ってきた。

Agile Conference Tokyo 2011 というイベントに行ってきたので、そのメモ。

伊藤穣一さんとPivotal LabのIanさんの講演に行って以来、すっかりアジャイルがマイブームな今日この頃。最近TLで話題になったtwitterの求人でもagileという単語がRequirementsに入ってて、おお！と思ったり。

hadoopが流行りだした時は、どんだけマルチスレッドなプログラミングが書けますといきがったたところで、でかめのバッチ処理（当時よく書いてた）で、hadoopをちょこっと使える新人プログラマーと対戦すると、スループットで負けてしまいそうという危機感から結構勉強した覚えがありますが、アジャイルに関しても危機感ドリブンな感じで、これまではプログラミングの勉強さえしっかりとしていれば、いいものを作ることにつながっていくという思いがあり、あまり手法論には興味がなかったのですが、伊藤さんの講演で語られた向こうのアジャイル手法と、今まで自分が経験してきた開発とのあまりの感覚の違いにビックリして、もはやこの手法に対する理解＆実践なくして、10年後には生き残ってられないんじゃないかという危機感を覚えて頑張ってキャッチアップ中。

そして、hadoopなどの大規模処理にしてもアジャイルにしても、勉強しだすと、そこにはそれまであまり知らなかったもの凄くレベルの高い先駆者の人たちがいて、こんな世界があったのかという驚きと、（自分から見ると高みにいる）その人たちが貪欲に新しい知識を吸収しようとしている姿に、色々と刺激を受けてモチベーションが上がるとともに、同時に自分との差に危機感を覚えて日々精進だな〜と気が引き締まるので、ここまでくれば定年まで安泰だと思えるまで（笑）、定期的に無理矢理にでも新しい世界に自分を突っ込むべきだな〜と思っている今日この頃でもあります。

と前置きが長くなりましたが、以下、メモ。

21世紀のソフトウェアデザイン Martin Fawler（ThoughtWorks Inc.）

http://www.martinfowler.com/ (公式サイト。色んな論文もあり。)
http://www007.upp.so-net.ne.jp/kengai/fowler/ (翻訳論文サイト)

The essence of agile

Agileの起源。
- 1990年代頃から現れ始めた考え方。
- Scrum, extream programmingなど、様々な形に派生している。
- Manifest for Agile software development http://agilemanifesto.org/iso/ja/
- Semantic Deffusion
- アジャイルの考え方は広がりを見せる中で、どんどんと本来の意味が薄まってきてしまっている。アジャイルの先駆者達にとってはストレスだが、考えが広まって行く中ではしょうがない面もある。
AgileとPlan drivenの違いについて
- http://martinfowler.com/articles/newMethodology.html　に詳細説明あり。
- Plan driven
  - 橋を建設する時に、詳細な設計書を作ってから、橋の建設に着工する感じ。
  - Requirement → Plan がはっきりと定義できることが前提。
  - プロジェクトの成功はPlan通りのものを作成すること
  - どのようなRequirementがあるのかを厳密に定義できないといけない。planはrequirementに依存する。
  - しかし、現実問題として、ソフトウェア作成では要求が曖昧なことが多い。
- Agile
  - Requirementへの依存を取り除く。
  - A late change in requirements is a competitive advantage.（後からの変更は競争性を保つのにいいことだ！！）
  - Adaptive plannnig →　ちょっとプランを立てては実行し、そのフィードバックから学習して、新しいちょっとしたプランニングを立てる。
  - Release early and often.
  - Adaptive plannningをするには、革新的な様式、やり方が必要になってくる。
  - Self testing code, Continuos release などなど。
- Process first (plan driven)
  - Flederick Winslow Taylorという人が提唱した、仕事への取り組み方の指標。製造業の機械化が進んでいく中での考え方。
  - 色々なプランニングを行い、そのプランに基づいて適材適所を行う。
  - In the past man was first,In the future the system must be first.
  - ソフトウェア開発でもこの思考が取り込まれた。
- People first(adaptive planning)
  - Agileはplan firstに疑問を持った。一部の優秀な人(与えられたプランを工程通りにこなせる人)だけでやるなら、それでもいけるかもしれない。しかし、現実はそうではない。
  - A bad process will beat a good person every time.
  - シーンに応じて、自分達でやり方自体を考えてもらうほうがいい。
  - self adaptivity(自主性)が生まれる。自分たちで構築した方法なので、改善にむけてみんなが考える。
  - In software development , perfect is a verb, not an adjective.
  - 「perfect」という単語は、形容詞だと「完璧な」になるが、動詞だと「完璧に近づける」という意味。ソフトウェア開発において、perfectは動詞でのみ用いるべし。

Integrationに関して

それぞれの担当の開発は終わっている（はず）けど、それを統合して動かすのに、どれくらいかかるか分からない的な話はよくある。。

Feature branch
- メインストリーム(trunk)があって、そこからbranchを複数作成し、並行して開発を進める方法。
- 最初のbranchからtrunkへのマージは容易。
- 次以降の人は競合が発生してしまい、凄く大変。マージだけでも大変だが、マージにより、他のブランチでの作業、自分の開発、既存動作に影響が無いようにしなければならない。
- Textual(単純なテキストとしての)mergeをサポートするツールはあるが、semantic(意味的な部分での)なmergeは無理。コードの可読性がどんどん下がってしまう。
- Integration(↑でいえば、マージ作業)について
- ↑でIntegrationは大変ということを書いたが、やらないという選択肢は無い。
- Integtationするまでの長さ(=branchを切ってからtrunkにマージするまでの長さ）とマージ時の苦痛は指数関数的に伸びる。
- 逆にしょっちゅうintegrationすべし！！
- ちょっとした変更をするたびにtrunkにmergeをする。
- 頻繁にintegrationをしておけば、最後の苦労が小さくなる & お互いに影響しあう変更をしていた！？みたいな時に早く気づける！！マージ後の動作確認がなくなるし、無理なmergeによるコードの質の低下を防げる。
- （リリースが何ヶ月後とかの開発は？？と思ったけど、そもそもAgileではTimeboxという一定の期間毎のリリースに向けて開発するという前提があるため、それが可能と思われる。）

Continuous Delivery (not only integration)
- ソフトウェアは製品として動作して、始めて意味を持つ。
- How do we tell if it's production ready??
- それを測るにはテストが一つの方法。
- ただし、自信を深めるためにテストをすればするほど時間がかかる。
- また、テストをつくること自体が大変な場合があることも確か
- テストの順序付けをして、必要に応じたテストを行う。
  - Compile + unit test
  - Functuonal test
  - Perfomance test
  - Production test
  - 全てを自動化すべし！
  - ex. Mingle ・・・色んなブラウザ上での動作テストを並列に行える。

Agile case studies and lessons learned Jez Humble（ThoughtWorks Inc.)

Why agile??

これまで何が問題だったのか？
- 市場に投入できるまでの時間が長すぎる。
- 各環境がややこしすぎる。
- 一度リリースされたプロジェクトが終わることは滅多にない。。
- 最近のスタートアップ企業の開発サイクルは凄く早い。ちんたらやってると、10年以内に喰われてしまう。
- Flickerは一日に10回リリースしている！！既存企業にそれができるか？
  - http://www.publickey1.jp/blog/11/devops.html
  - yahooに買収されたけど、開発手法はyahooよりもFlickrが優れているということでそのまま温存された。

導入事例　Guardian(イギリスの最大手ニュースサイト) http://www.guardian.co.uk/

2006年当時、ほとんど手作業でサイトを更新していた。
複数のレガシーなシステムが複雑に絡みあっていた。
サイトにちょっとした変更をするにも数週間単位。。
システムのリプレイスプロジェクトが発足。
- 数年単位
- 過去の別プロジェクトで失敗の経験があり、向こうの偉い人は若干否定的な見方。
- そんな中で、ただのリプレイスではなく、インタラクティブでダイナミックでソーシャルなサイトに作り変えるという方針のプロジェクト
- 最初の二週間は全体の方向性を検討。
- Travel section から手を付けた。LLを利用し、全面リプレイス。
- ８ヶ月かかった。
- 1UUあたりのページ閲覧数が10倍になった。→偉い人や他のメンバーの賛同を得やすくなる。
- このリリースで得たフィードバックを次のphaseに生かす。
- 最終的には22このリリースが行われた。

まとめ的な

Rapid , frequentなリリースがお客さんに支持される。途中途中で数字を残すことで、理解を得やすくなる。
Thoughtworksだけがアジャイルなのではなく、アジャイルがメインストリームになりつつある。
- 開発手法に関する企業アンケートによると、Agileが業界の37%でトップ。昨年から６ポイント増。ちなみに２位はこれといった定義のない開発手法ww。
しかし、アジャイルをはじめるのは簡単ではない。
- 組織が障害となる。遅い意志決定、部門間の矛盾etc..
- マネジメント、イノベーションのやり方を変えねばならない。
製品のValueを上げるには？
- Do Less.
- 作った50%以上の機能はほとんど使われていない。最も無駄なリソースの使い方。
- つくる前はどれだけ素晴らしいと思っていても、それは仮説に過ぎない。
- 毎日、Can I release now? If not, why not?? と問いかけ続けるべし。
- Steve Jobsも「You can't just ask customers what they want and then try to give that to them. By the time you get it built, they'll want something new」と言ってる。
イノベーションは単なるひらめきではない。
- ちょっとした面白いアイデアを考える→最小限の機能を盛り込んだ製品を作り、リリースする。→フィードバックを元に改良を加える。　の繰り返し。
- Continuous delivery
Testingというのは一つのphaseではない。
- Improve the process and build quality into the product in the first place.
- Testingというのは一つのphaseではない。いつも行われてなければならない。
- Qualityはテスターだけの責任ではなく、全ての人の責任。
- テスターによりqualityが確保されるわけではない。
- Qualityをみんなに可視化することがテスターの役割。
How to lead agile teams ?
- どのように動機付けられるのかを考える。
- お金だけではない。特にクリエイティブな仕事をする人にとっては。
- Autonomous, self-determined and connected to one another. これらが実現した時、人は充実感を得る。
アジャイルを可能にするには？
- Create autonomous , cross - functional product teams
- 大きな要素をたくさんのチームに分割する。
  - Amazonでは、レコメンドエンジン、ショッピングカート、閲覧履歴、、それぞれが独立したチームになっている。
Create feedback loops
- 様々なループが存在する。テスターと開発者、顧客からのフィードバックを含めた開発ループ etc..
Continuous improvement
- 振り返りがとっても大事。
- 改善するには何が必要かを考え続ける

ただでさえあまり知らない概念なのに、通訳つきの英語講演でちょっと辛いかもな〜と思っていたのですが、自分のような素人にもしっかり理解できる、すんばらしいプレゼンでした。ユーストも無いし資料も公開されていないみたいなのが、ほんと残念です。。
とくに、Plan drivenとAgileの比較の話は初めて聞いたけど、今までふんわりしていたAgileの概念がかなり腹落ちしました。

ただ、こういった講演を聴いたり本を読んだりして、いつもぶつかってしまうのは、今の環境で、１エンジニアの立場からはどうしたらいいんだろう？？ということ。Jezさんの講演の中でも組織が障害となりえますと言っていたけど、それで済ますのではなく、その辺に関する手法論がもっと色々提唱されてくるといいな〜と思ったりした。まあ、そんな悠長なこと言ってたら淘汰されますよって言われて終わりなのかもしれないけど。。
とりあえず、↓を図書館で借りてみた。