月曜日までに考えておきます

ITネタとゲームネタ中心に興味のあること色々書きます。

Developers Summit2013に参加して来ました(二日目)

二日目にも行って来ました〜(´ω`)ノ

IMG_2452

自分的には後半のセッションが面白かったのでそっちに重点を置いてまとめました。

AmazonのDevOpsを支えるAWSクラウド

AWSの話。

  • コントローラブル
    • ビジネスレベルでのコントロール
    • コストを最初のオブジェクトと考える
  • レジリエント
    • 障害を例外として扱わず、最初から組み込む
  • アダプティブ
    • 最初から制約を考えず、あとから追加できるようにする
    • どこまでもスケールできる設計を心がける
  • データドリブン
    • すべてログを取る

Webが生み出し始めた世界

CROSSでも次世代Webのセッションがあって、同じ会社の尊敬する先輩が登壇したりもしてたのですが、プロトコルの技術的な話だったので、これもそんな話かな、と思って行ったらもっと社会的な話でした。

  • ユーザー参加型研究の世界を創りあげよう!=> ニコニコ学会β
    • 野生の研究科
  • ニコニコ超会議 2012/4/28, 29
  • メディアの普及と移り変わり
    • 新聞
    • ラジオ
    • テレビ
    • Web その次は?Webが一番になった後、新しい何かが来る。それがWebが生み出すもの。

Webの未来

  • 未来は必ずしも魅力的ではない(例:Twitter
    • 過去の人に説明して魅力が伝えられるのか。
  • Webがメディアの頂点に立ち、ユニミディウム化
  • HTTP/2.0(SOAP,REST,HTTPng,AJAX,SPDY)
  • 歴史は反復する
  • アラン・ケイからマクルーハンへ回帰する
  • VRの世界へ(Google Glassesのような)

モバイルファースト再考

  • モバイルファーストとは単に以下のようなものをつくることではない。
  • モバイルファーストとは

    • モバイル端末を起点にしたサービス戦略
  • モバイルの可能性

    1. カメラ
    2. 音楽
    3. GPS
    4. ジャイロスコープ
    5. NFC/FeliCa
    6. 3G/LTE
    7. Bluetooth
  • デザイン思考

    • まずはプロトタイプを作って、現場で実験と検証を行い問題点を発見。そこから具体的な改善を行うことを繰り返しながらチームで作る => アジャイル開発と同じ考え方
  • デスクを捨てよ、モバイルを使おう

    • 本当のユーザーを知ろう。
    • 実際にモバイル端末を使い倒そう。
    • 端末は自分で買おう
    • PC禁止DAYを設け、モバイル端末だけを使う日を設ける企業もある。

OSSで作る!クラウドサービス開発戦記 -クラウド・エヌ PaaSの挑戦-

資料:OSSで作る!クラウドサービス開発戦記 // Speaker Deck

登壇者の川口さん(@hamakn)とRuby友なので見に行って来ました。 NTTcomさんの製品紹介的な話かな、と思ったら、川口さんが大企業NTTコミュニケーションズ内でアジャイル開発を実行した体験談で、めっちゃ参考になる話でした。

ノベルティ赤いきつね Cloundn誕生秘話

CloundnというのがNTTcomさんの製品らしく(それすら知らなかった)、Cloudn(クラウド・エヌ)=> くらうどんって読めるよね、じゃあうどん入れようぜ→川口さん「おいバカやめろ」な話だとか。

前段

  • Clound Foundryとは
    • OSSのPaaS
  • PaaS(Platform as a Service)
    • アプリケーションさえ作ればあとはよろしく。
  • GitHub上にある。
  • Cloudn PaaSの利用事例
    • PinQA =>ステージング
    • LimeSurvey アンケート
    • intra-mart
  • 2013年03月 オンラインサインアップ開始予定

本題

chapter1(2011末)

この時期にやったこと

  • Clound Foundry
  • 単一ホストでの構築:ほぼ自動(chef_solo)
  • 複数ホストでの構築:だいぶ手動
  • デプロイスクリプトを作った。Capystranoを利用

  • チームの立ち上げ

  • 高頻度なupstreamの更新に対応できるチームを作る!

  • 参考にしたもの

    • アジャイルサムライ
    • 今そこにあるScrum
    • railstokyo
    • yokohama.rb
  • アナログボード/付箋紙によるタスク管理

  • フリーアドレス(デスクトップPC廃止)

  • Daily Scrum(09:45〜10:00)
  • 振り返り会(週1)
  • 計画ミーティング(月初)
  • ペアプロ用ディスプレイ => プラズマディスプレイ

  • Tools

ベータサービス開始

Chapter2(2012年春〜2012年秋)

  • upstreamへの追随
  • 顧客のPaaS導入サポート
  • Bugfix、機能追加、パッチの送付
  • 開発のやり方の検査と見直し
  • トラブル

  • 対策

    • Staging環境でしばらく様子を見る
    • ちゃんとupstreamのコードを読む
    • 問題が起きたらテストを追加する
  • 顧客へのPaaS導入サポート

    • そのままではPaaSで動かないことがある
    • platformを直すか、顧客の方に原因があるかを判断
  • 開発がわかってきた
    • Core Compatibleでありつつ、顧客の個別の要望にも答えられることを、我々の価値とする。
  • 問題もわかってきた
    • テストが増えたのは良いが、時間がかかる(slow test)
    • 属人化してきた
      • ○○さんじゃないとわからない
  • 物量作戦
    • JenkinsのSlaveを作って、テストを並列実行
  • 週に2時間、必ずペアで作業する
    • CodeReview
    • GithubのPull Request
  • IRC強化

振り返りに刺激を

Chapter3(今やっていること)

  • 隣のプロジェクトと連携する
  • 隣の人に火をつける

  • うまくいかない理由

    • 前提がたくさん違う
    • 発注、委託
    • 目標が違う
    • フロアが違う
    • ツールが違う
    • 管理職とは何だったのか => これなにがあったんだよ・・・(;◔ิд◔ิ)
  • コミュニティや本、資料でおすすめのやり方をまずやってみることでやってこれた

SQLアンチパターン - 開発者を待ち受ける25の落とし穴

登壇者:和田さん(@t_wada)

最近発売された、和田さんが翻訳された「SQLアンチパターン」の紹介も兼ねた講演でした。

[amazonjs asin="4873115892" locale="JP" title="SQLアンチパターン"]

もともと興味あったのですが、デブサミ会場では10%オフだったので買っちゃいました。 サインはもらいそこねた(´・ω・`)

本の構成について

  1. 論理設計
  2. 物理設計
  3. クエリ
  4. アプリケーション

の4つの部に分けて記述

アンチパターンとは

  • べからず集
  • あるある集

だけではない。 理由、禁を破って良いケースについて書かれている。 問題の解決を意図しながらも、しばしば他の問題を生じさせてしまうような技法を指している。

  1. 名前
  2. 目的
  3. アンチパターン
  4. アンチパターンの見つけ方
  5. アンチパターンを用いても良い場合
  6. 解決策

この本の本当にすごいところはパターンに名前をつけたこと。

本書で紹介されているアンチパターンの1例:ナイーブツリー

階層構造において、常に親のみに依存するテーブル設計(parent_idのような) どれぐらい深くなるかがわからない。

解決策

パスツリー解析など・・・

Rubyだとancestryというgemを使って解決したなぁ、半年ほど前。

ワンクリックデプロイ ~いつまで手でデプロイしてるんですか~

人が深夜に手動でデプロイしたり、デプロイ時にトラブルが発生したりして必死に直すのはやめて、素早く楽にデプロイしましょうという話。 サービスによっては1日10回以上のデプロイを行うところがあるし、Amazonは1日1000回超のデプロイを行うこともあるらしい。

ウォーターフォールでよく見かける光景

  • 要件定義 ~ 設計 => 順調
  • 開発 => 遅れてるけど何とかします(;´Д`)
  • テスト => あばばばばば
  • リリースできた? => ヽ(゚∀。)ノウェ

※表現及び顔文字は私の独断と偏見です。

アジャイルの範囲

よくある光景

運用者:てめーもっとちゃんとアプリ作れ 開発者:運用で何とかすんのがあんたらの仕事だろ 企画とかマーケティングとか:あの〜、ビジネスのことを。

=> 自分たちのプロセスは自分たちで進化させるしかない

継続的デリバリー

[amazonjs asin="4048707876" locale="JP" title="継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化"]

  • ソフトウェアの自動化
  • 難解なことや苦痛なことを繰り返し行い自動化の方法を考える
  • すべてをソースコードとして管理?
  • リリースされたことが完了
  • 品質を作りこむ
  • すべての人にリリースプロセスに対しての責任がある。もっというとプロダクトに
  • 継続的に改善する
  • 継続的デリバリーの4プラクティス
  • バイナリは一度だけビルドする
  • すべての環境にデプロイするのに完全に同一のメカニズムを使う
  • デプロイメントでスモークテストを実施する
  • 何か問題が起こったらラインを止める

テスト自動化

  • アジャイル開発に於いてはテスト自動化は必須
  • アジャイルかどうかに関係なくソフトウェアのライフサイクルを考慮する必要がある。
  • 自動化されたテストの損益分岐点

  • 問題は早めに解決する

  • 早く見つけて速く直す

テストしてないものを目を瞑ってリリースしてはいけない

自動テストに求められる特性

  • 繰り返し可能
  • 独立性
  • 自己検証
  • 簡単実行
  • テストの実行時間を短く、依存関係を少なく
  • 自信のない箇所をテスト
  • 問題は実装箇所に近い所で見つける

完了の定義

  • 完了の定義を作り、何を持って出荷可能かを定める
  • 全部を短い間隔でできれば頻繁にリリース可能

CIの活用

  • CIアンチパターンの例
    • 頻繁にコミットしない
    • テストコードを書かない
    • 様々な種類のテストをまとめて行なっている
    • ビルドの失敗に気づかない
    • ビルドに失敗しても放置している
    • ビルドの失敗に気づいても、修正コード以外のコードをコミットする
    • CIが落ちても何も通知しない
    • CIサーバのリソースが貧弱
    • ビルドが肥大化して結果が出るまで時間がかかる
    • 本番環境やステージング環境と大幅に環境が異なる
    • コードの静的解析

設定情報のバージョン管理

  • 環境によって異なる設定値が書かれた設定ファイルもバージョン管理する
  • 開発環境用、ステージング環境用、

  • どの断面でも再現可能か?

  • リリースした際に、前のバージョンに即座に戻せるか?

  • マイグレーション

    • データベーススキーマの管理
    • データベースのスキーマの状態とリリースの状態をひもづける

環境構築自動化

chefやpuppetを利用

  • 手動でやるのにそもそも時間がかかる
  • 数が増えれば単純作業の繰り返し
  • 設定やインストールの自動化
  • あとはデプロイする
  • 本番環境と開発環境の各バージョンを合わせる

  • クラウドの利用、自動化と仮想化は相性が良い

  • 環境構築自動化の敷居の低下

ゼロデプロイ

  • プロジェクト最初にデプロイするものをデプロイする
  • プロジェクトの間、ずっとデプロイスクリプトを使うことで、プロセスがテストされ続ける。
  • デプロイが失敗した場合にロールバックできるようにする。
  • デプロイが途中で失敗した場合、その先を手動でやらない。

  • データベースの不可逆な変更を避けるようにアプリケーションを作りこんだほうが良い場合が多い

プロセス

テストが通ってからリリースできるまでの日数、当日、1日、2日、一週間、それ以上でそれぞれ挙手させる。 システムトラブルが起きた対策リリースができるまでの日数は?

後者<前者 であるならば、今のリリースプロセスには組織的なムダがある。

=> あるあるすぎるわこれ。

組織のアジリティを高める

まとめ

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

アジャイルサムライって当たり前になるのかな?

日本のマスターセンセイ西村直人さんと、アジャイルを用いて仕事を進めている3名の若手エースによるセッション。

西村さんのおはなし

当たり前になるにはは2つ

  • 実際にやる
  • 成果を出す

導入を妨げる:組織、ビジネス構造

まずやってみる

  • 15分たってプロジェクトの話をする
  • 直近一週間の自分たちの計画を考える

うまく行っていれば、周りへの影響、広がりがある。

妨げる要因と本当に向き合うときがやってくる

一番うまく行かなかった話

  • 進捗が見えないと言われた => よく聞いてみるとExcelがないということだった。

成果が出たと思った時

  • かつてはリリースすることが成果だったが、今はちがう。
  • 一億の売上があるとして、不健康な開発体制だったらそれは成果なのか。
  • チームを成功させる。
  • 自分が休んでも朝会、振り返りをやってくれる => ( ;∀;) イイハナシダナー

やってみてダダスベリしたプラクティス

  • ペアプロ => ある程度スキルが要るらしい
  • 振り返りは概ね良かった。
  • 朝会、二人でやってたら何やってんだお前ら?って言われたby西村さん => (;^ω^)

ちょっと悲しかったこと

アジャイルプロセス自体は顧客価値を届けられる可能性を高めるものですし、登壇者の皆さんも素晴らしい人たちでした。 ただ、質問の中でアジャイルの可能性を疑うようなものがあったときに、それをディスった感じのツイート、リツイートがあったのが残念でした。 既存プロセスを変えていくのだから、今までと異端なことをしなければならないのに、その姿勢じゃ理解を得られないんじゃないかなぁ、と思いました。 それに、アジャイルコミュニティの中でアジャイルを疑う人=異端な人を排除しようとするのは、ウォーターフォールプロセスの中でアジャイルプロセスを広めようとしている自分=異端な人がいつもしている経験なんじゃないの?と思って、結局立場が変わるとみんな同じなのかなぁ、と昨日の受付の時の事も思い出して涙を流さずには(略)

あくまで成果を上げるためのものなので、盲信する宗教になっちゃダメだと思うんですよね。 疑って、問題や不安を見つけて、改善していく。そう考えずに、その疑ったり不安を感じるのがおかしい!っていう考えは、アジャイルの人が一番苦手であろう、大企業病でガチガチに固まったプロセスおじさんと同じだと思うんですよ。

というようなことを感じて、モヤモヤしたまま終わってしまいました。

あと、勉強会やコミュニティでよく一緒になって親しくさせてもらってる人たちはそんな中でも前向きなツイートしてて、この人達はやっぱり気持ちの良い人たちだなぁ、と思えたのは良かったと思います。

Action

西村さんから、デブサミを受けてやろうと思うことを隣の人に話してください、というイベントが最後にあったので、「ソーシャルコーディングやります」と言いました。

おまけ

お昼はインド料理屋でカレー食べました。

IMG_2450

SQLアンチパターンとRUNNING LEAN買いました。 IMG_2454

Running Lean ―実践リーンスタートアップ (THE LEAN SERIES)

Running Lean ―実践リーンスタートアップ (THE LEAN SERIES)