「Developers Summit 2013」に参加しました ～其の弐～

2013/2/15(金)「Developers Summit 2013」に参加してきました。

公式サイト
http://event.shoeisha.jp/detail/1/

昨日は以下のセッションに関するメモと感想を書きました。
【15-C-5】ディシプリンド・アジャイル・デリバリー～エンタープライズ・アジャイル実践ガイド～

今日は以下のセッションについてメモと感想を書いてみる。

---

【15-A-7】ワンクリックデプロイ ～いつまで手でデプロイしてるんですか～

■アジェンダ
http://event.shoeisha.jp/detail/1/session/41/

■発表資料

ワンクリックデプロイ 〜いつまで手でデプロイしてるんですか〜 #devsumiA from Ryuzee YOSHIBA

■最初に書籍の紹介。吉羽さんが著者の一人となっている以下書籍が先日発売になったとのこと。

SCRUM BOOT CAMP THE BOOK (2013/02/13) 西村 直人、永瀬 美穂 他 商品詳細を見る

ちなみに、私はちょうど２,３日前にAmazonで買いました。
デブサミの書籍コーナーで買えば10%引きだったので、ちょと後悔。。。

■オレゴン大学の実験


参考：http://itpro.nikkeibp.co.jp/article/COLUMN/20080828/313626/
→　期待のマネジメントに失敗している。これが今の状況。（作ってみなきゃわからない状況）

■システムの機能の利用割合
　・まったくつかわないが45%
　・ほとんど使わないが19%

　→　合計64%が使われない。
　→　実際は、作成しようとする機能の1/3で良いことになる。（コストも期間も1/3でいける）

■「トヨタ生産方式」は名著。７つの無駄を定義している。　→　64%が、作りすぎの無駄。

トヨタ生産方式 (2012/09/14) 大野 耐一 商品詳細を見る

■例：上司からの依頼「カッコイイ資料を作ってくれ」
　→　加工の無駄
　→　普段の開発で無駄を無くしていかなければならない。

■不確実性コーン
　最初の時点の見積もりは当たらない。

■WFの問題
　時間がかかりすぎて、出来た頃には要求が変化している。そもそも要件が合っていないことがある。

■よく見かける光景
　・結合試験で重大な問題がでてくる
　・受け入れ試験でニーズ不一致が判明

　→　多くのリスクが後半になって顕在化する。顕在化した時点では取り返しがつかないのが従来型の欠点。

■アジャイルマニフェスト
　・顧客満足度を最優先
　・マーケットに製品を早期に投入して投資を回収し利益に結びつける必要がある

■最も価値をがあるものを作って、フィードバックを受けながらプロダクトを成長させていく必要がある。
　→　これらができていると「アジャイル開発ができている」と言える。

■平鍋さんの有名な記事
　アジャイルの「ライトウィング」と「レフトウィング」
　→　今日は「ライトウィング」について話をする。

■毎日何回も本番環境にデプロイできていると、お客さんに継続的に価値が届けられる。
　Amazonは一時間に1000回以上デプロイしている。

■自分たちのプロセスは自分達で進化させるしかない
　・製品そのものをアジャイルな状態に保つ
　・技術的負債を少なく保つ

■チームビルティングも大事だが、製品がよくならないとダメ。

■継続的デリバリーの原則
　１．ソフトウェアのリリースやデプロイのプロセスは繰り返し可能であり信頼性が高い必要がある。
　２．すべてを自動化する
　３．難解なことや苦痛なことを繰り返し行い自動化の方法を考える
　４．全てをソースコード管理システムで管理する
　５．完了は「リリースされたこと」を意味する
　６．品質を作り込む
　７．すべての人にリリースプロセスに対しての責任がある
　８．継続的に改善する


■継続的デリバリーの４プラクティス
　１．バイナリは一度だけビルドする
　２．すべての環境にデプロイするのに完全に同一のメカニズムを使う
　３．デプロイメントでスモークテストを実施する
　４．何か問題が起こったらラインを止める

ここで「バイナリは一度だけビルド」の意味がよくわからなかったのでググッたら吉羽さんの記事がヒットしたｗ

[Agile]継続的デリバリの8つの原則
http://www.ryuzee.com/contents/blog/4172
わかりやすい解説付き。

■あたりまえだが、テストを自動化しなければならない
　→　テストできてないとデプロイはできない。
　→　アジャイルじゃなくてもテスト自動化は必須。
　→　小規模リリースのたびに手動でテストすると、コードベースが大きくなるにつれてテストコストが膨らむ。

■どういうところを自動化するか？
　→　自動化されたテストの損益分岐点を考える必要がある。
　→　２、３回の手動テストやると損益分岐点を交差することがほとんど。

■問題は早めに解決する。早く見つけて早く直す。

■デプロイのたびに人手でテストするのは無理。なので、自動化が必要。
　→　テストしていないものを目をつぶってデプロイしてはいけない。
　→　清水の舞台から飛び降りるようなリリースはするな。そうならないための仕掛け作りが重要。

■アジャイルテストの４象限
　・単体テストとコンポーネントテストは自動化する。
　・探索的テストあたりは人手を使うしかないでしょう。

■自動テストに求められる特性
・繰り返し可能
・独立性
・自己検証
・簡単検証

■何をもってデプロイしてよいかの、完了の定義が必要。
　→　完了の定義を作り、何をもって出荷可能かを定める
　→　全部を短い間隔でできれば頻繁にリリースできる。
　→　こーゆうのをやるのにXPのプラクティスを利用すればよい。

■CIサーバ
　・プロジェクトの初期での段階でコードがなくても構築する
　・コードのメトリクス取得や静的解析は初期から継続的に実施

■CIアンチパターン
　・頻繁にバージョン管理システムにコミットしない
　・CIでテストを通すために手作業の準備が必要
　・本番環境やステージング環境と大幅に環境が異なる
　・etc


■ソースコードのバージョン管理
　・コードの共同所有の原則への理解（あなたのコードだからいじりません、はダメ）
　・リリースした際に、前のバージョンに即座に復元できるか（DB含む）
　・etc

■DBスキーマの管理
　データベースのスキーマの状態とリリース状態を関連付けることによって再現可能にする

■ソースコードを使ってマイグレーションを行う。
　→　設定じゃなく規約

■環境構築の自動化
　・Chef ・・・ Ruby製のシステム管理ツール。環境構築の自動化に使える。

■VagrantのSandobox機能で、何度も環境の変更をrollbackできる。

■ゼロデプロイ
　・プロジェクト最初に、デ（プロイするものがなくても）デプロイを自動化する
　・デプロイが失敗した場合にロールバックできるようにする

■組織のアジリティを高めないとダメ。変化をしないとゆるやかに死ぬ。

■まとめ
・ビジネスのために継続的に継続的に成果を届ける
・そのためにはAgileなやり方が必要
・テスト自動化は必須
・常に出荷可能な状態を保つ
・デプロイや環境構築も自動化
・改善をずっと続ける

---

★感想：
聴講時に取ったメモに加え、講演スライドの写経も兼ねて書いてみた。
私も今の仕事で、Jenkinsを使って自動ビルドと自動単体テストを実行してて、Subversionと連携させてます。
なので、この話は自分の仕事に直結してて大変興味深かったです。
特に「コレはいい！」と思ったトコは太字下線にしてます。

吉羽さんの講演は以前、アジャイルサムライ横浜道場の特別編でもお聞きしましたが、話に説得力がありますね。
前回の時は「改善しようとする態度重要」という言葉が印象的でした。

今の仕事で自動化が不完全なところがあるけど忙しさを言い訳にして放置プレイにしている部分もあるので、反省。。。

ちょと時間がとれたら、徹底的に自動化してみたいと思いました。手を動かすこと重要。

大変役立つ講演を聴講できてとても満足なヒトトキでした。