9月14日から16日の3日間，札幌市産業振興センターにて札幌Ruby会議2012が開催されています。3日間に渡り，随時レポートをお届けします。ここでは最終日3日目の内容をレポートしていきます。

今回のイベントには，世界中からRubyistが参加しています。

本日の，ぬRubyKaigiは朝の段階で次のようなセッションが予定されています。ぜひこちらの内容も確認してみてください。

柴田博志さん「Rubyの世界の継続的デリバリ⁠」⁠

Rubyで実装されたWeb日記システム，tDialyのコミッターの一人として知られる柴田博志さんによる発表です（スライド等はこちら⁠）⁠。柴田さんは現在，株式会社paperboy&co.に在籍し，技術基盤整備エンジニアとして働いています。仕事の内容については2日目のLTで発表されたantipopさんのスライドを参照してくださいとのことでした。

このセッションではスライドの途中に唐突に柴田さんオススメの北海道名物の写真などが挟まれており，継続的デリバリーのプラクティスと柴田さんのオススメが同時に楽しめるお得感あふれる内容でした。柴田さんは紋別のカニのオブジェや八雲町のハーベスター・八雲などがオススメだとのことです。

継続的デリバリー

はじめに柴田さんは継続的デリバリーについて話しました。アジャイル宣言の背後にある原則の冒頭に"顧客満足のために価値あるソフトウェアの継続的デリバリー"が大切で，それが最優先事項であるという一節が含まれているということを紹介しました。

また，書籍「継続的デリバリー」のことについて触れ，大変良い本で，継続的デリバリーが何故大事なのかという理由が示されていることや，その際に使うことのできるプラクティスが数多く取り上げられていることを紹介しました。ただ，この書籍は大変ページ数が多いため読むのはすごく疲れたとのことです。

そして，この書籍「継続的デリバリー」から3つのエッセンスを紹介しました。

意識が低くても大丈夫な仕組み

継続的デリバリーを実現するにあたって大切なこととして，最初に"意識が低くても大丈夫な仕組み"を構築することを挙げました。

継続的デリバリーの第一歩は継続的なテスト実行であり，自分の意識が低い状態になったときでも自動的に，かつ，やろうと思わなくてもテストを実行できる仕組みを取り入れることが大切だと言います。これには，guard，Jenkinsやtravisなどを使用します。

paporboy&co.ではmaglicaという仕組みがあって，Jenkinsのひな形のようなものを作って仮想マシンごとコピーできるようにしているそうです。こういった継続的テスト環境は開発をはじめる前の段階で仕組みを作っておくのがよいということでした。

なぜ最初に作るのが大事かという理由として，品質というのはソフトウェアの本体が持っているものであり，それを向上させるには毎日植物を育てるように手入れをしていくしかないからだと言います。

また，"walking skeleton"というプラクティスでも最初に動く骨格を作ること，例えばCIであれば最初のテストを書いてそれをCIで回す仕組みを作り，そこを起点にテスト，実装，CIの繰り返しを作ることが大切だと指摘しました。

build pipelineの自動化

サービスなど作ったものを世の中に出すには，単体テストや受け入れテスト，プロビジョニング，デプロイメントなど数多くの作業が必要です。継続的デリバリーではこのような作った物を世の中に出すための一連の作業をbuild pipelineと呼んでいます。

このbuild pipelineにはテスト以外の作業がいくつかあり，そのテスト以外の作業こそ機械にやらせようと柴田さんは言います。なぜなら設定ファイルやプロビジョニングの作成に関するミスというのは影響範囲が広く，最悪アプリケーションそのものが動かなくなることがありえるためです。

これにはRailsであればchef，capistranoなどのツールを使用するとよいと言います。paperboy&co.ではwebistranoというツールを使っており，これは履歴が取れるのがよい点です。ただし，いくつか問題点もあるため，現在paporboy&co.で作り直しているそうです。

サイクルタイムの短縮と継続した価値の提供

開発者からユーザーに届けるまでの時間をサイクルタイムと呼びます。これをどのように縮めていくか大切で，そのための考え方をいくつか紹介しました。

はじめにコミットステージという考え方を挙げていました。これはビルドパイプラインにのせる塊の単位です。この塊はユーザーストーリーの単位にするのがよく，その理由としてはユーザーストーリーより細かい単位にした場合，それがユーザーに届いた時に，ユーザーは何が変わったかわからないためとのことでした。

その他にもコードレビューなど自動化できないものについても許容してプロセスに組み込むことや，すべての開発，CI，デプロイ情報のフィードバックを1箇所にあつめること，継続的に改善を行なっていくことが大切だとも言及しました。改善のための銀の弾丸はなくて，壊れた部分は自分が直すということを，毎日やることが大切と話していたことが印象的でした。

最後に自動化にあたっての壁ということについても話をしており，データベースのマイグレーションの自動化についてはどうしても自動化できないし，今は自動化しないほうがよいと述べていました。もしここを自動化してうまくいっている方法があれば知りたいとのことです。

今までに紹介してきたことを実践することで，素早くコードに価値をのせ，世の中の人に届けることができるようになると締めくくりました。

向井ジョニーさん「コードについて語るときに我々の語ること」

冒頭，開発者の文化を観察した，冒険者風の教授の報告から始まりました。彼は，開発者の風変りな活動の中心には，いつもコードと呼んでいるものがあることを発見したそうです。

ドキュメンタリー風のアイスブレイクから始まった，Pivotal Trackerで働く向井ジョニーさんの発表です（スライド等はこちら⁠）⁠。

人類学という視点

向井ジョニーさんは人類学を勉強してきたそうです。人類学の視点でプログラマ，コードを眺めてみると，どのような視点が得られるでしょうか。このセッションはその問いに端を発して広がっていきます。

文化とは

人類学とは，どういう学問でしょうか。文化を研究する学問である。と彼は言います。それでは文化とは何でしょうか。知識や信仰，規範，法などが混然一体となったものであり，「⁠私たち（We⁠）⁠」という概念を形づくるものであるようです。文化が「私たち」と「彼ら」という関係を作り出すのです。

文脈とは

「私たち」が共通で持っている認識を文脈と呼びます。文脈というのは，言いかえると，「⁠私たちが世界というものをどのように受け止めているか」という認識のことであるようです。

ジョニーさんは例として，薄い青と濃い青を示しました。これらはどちらも青ですが，ロシア語ではgoluboyとsiniyという違う色として受け取られると話します。つまりこの色に関して，私たちとロシア語を使う人たちの間には異なる文脈があり，それが異なる文化を形成しています。

誰が文脈をつくるか

先ほどの例のように，文脈は私たちの認識を形づくっています。では，その文脈はどこから生まれたものでしょうか。

何か新しいことを考えているとしましょう。そのとき，私たちは既存の文脈を組み合わせて考えをまとめています。考えをまとめると，私たちは新しいことに対して名前をつけたり，意味を与えたりして，新な共通認識として使います。つまり，私たちが新しい文脈を作っています。

まとめると，文脈は私たちを形づくりますが，同時に私たちが文脈を作っているのです。つまり，文脈と私たちは相互に作用している。と，ジョニーさんは言います。

コード

さて，ここにコード（code）を当てはめてみましょう（We codeですね⁠）⁠。

コードとは何でしょうか。ジョニーさんによると，コードというのはプログラマの文化や文脈の多くの部分に存在し，プログラマの活動の大部分にかかわってくる大切なもののようです。

そしてまた，「⁠コードとはコミニュケーションである」とも言います。コード自身は何かをするわけではなく，コードをコンピューターに渡したり，コードを書く人と読む人がいたり，読む人同士が話しあったりすることで役にたつツールであると。

どのようなコードを書くか選ぶとき，私たちは問題の考え方，解き方，伝え方を選んでいると，ジョニーさんは指摘します。私たちは，どの言語でどんなコードを書くかを選んだ時点で，これから解こうとしている問題の文脈をどうやって表現するかを決めているというのです。

コードについて語るときに我々の語っていること

最後に，ジョニーさんはコードについて語るときに我々の語っていることは，価値やコミュニティ，選択，文化などの文脈であると述べていました。そして，「⁠100年後，もしかしたらコードという形は今とは変わっているかもしれない。それでも人々は問題を解決するために活動しているだろうし，そのときでも人々の間で文脈については語られているだろう」とまとめました。