鎌玉のよしなしごと

日々のよしなしごとをつぶやいているだけ。由無し言(とりとめもない話)か、良しな仕事(nice job!)かは、あなた次第。

デブサミ関西2012 午前の記録 #kansumi #devsumi

デブサミ

セミナー/勉強会は感想をブログにアップするまで終わらないというのが、業界*1の流儀であると考えているので、つれづれなるままに書いておきます。


デブサミは、前々から参加したかったイベントでした。
最新技術の動向をつかみたいというのもありますが、開発コミュニティの人たちが現場の課題をどのように乗り越えているかといった話を聞きたかったというのがあります。
昨年もデブサミ関西に申し込んでいたんですが、直前で会議が入ってしまい、泣く泣くキャンセルしました。


今年は、何とか徳島から海を渡って参加することができました。
実を言うと、四国島を出たのは1年ぶり。
奥さんが妊娠して第一子が誕生するといった1年で、この日まで遠出をしていませんでした。


では、走り書きしたノートを元に、自分の言葉で書き出してみます。
実際に語られた内容と異なっていたら申し訳ありません。

冒頭のあいさつ

翔泳社 取締役：岩切晃子 さん


デブサミ*2は、ベンダーロックインに対抗するために始めた。
当時は、自分の会社の技術者に、指定した開発技術しか使わせないといった鎖国の時代だったと思う。
とはいえ、ネットのおかげで新しい技術が出てきた時代でもあった。


会社の中で、技術が分かる人がいない、問題を解決する人がいないといった時代だった。
コミュニティの中で、会社を超えて何か勉強しないといけないんじゃないかという機運が高まっていた。
しかし、東京でも、イベントはベンダーによるセミナーしかなかった。
いろんな技術が集まったカンファレンスがない時代だった。


私には子どもがいない。
じゃあ、未来をどうしようかと思ったときに、開発者にかけようと思った。
開発者たちによる技術の革新が、よい未来をつくっていくことにかけようと思った。
会社、業界の方々も賛同してくれて、10年続けてきた。
自分が必要なものをつくろうと、デブサミをやってきた。


昨年の東日本大震災が発生したとき、関西の人や遠くにいる人がITでサポートしてくれたことを見た。
今まで、東京でだけ知恵を共有してきた。
それじゃ全然、日本よくならないなと思って始めたのが、デブサミ関西というイベント。


動機はHappyなものではないが、やっている本人たちはHappyなものにしたいと考えてやっています。


昨年のデブサミ関西は、私が、関西でこれをやったら受けるだろうと思うことをやった。
今回は、関西在住の有識者（実行委員会）の人たちと一緒に関西でやるべきコンテンツを考えてつくった。


リクエストをもらった中で、一番大きかったのは、今回、基調講演を行っていただく及川さんの話。
及川さんの、ものをつくっていくこと、そして戦う姿勢を、関西の仲間に届けたいというリクエストをいただいて、及川さんに来ていただいた。


学ぶということは遊ぶこと、遊ぶことは学ぶことだと、私は考えている。
デブサミは祭りだと、私がなぜ言っているかというと、祭りのように楽しんでいってもらいたいから。


皆さんが楽しまないと、祭りにならない。
つぶやいたり、講師の人に話しかけたり、本にサインをいただいたり、隣の人に話しかけたり、自分で祭りを盛り上げて、仲間を見つけて帰ってもらえたらと思います。

感想

さすがにデブサミの母と言われる岩切さん、熱い思いが伝わりました。
デブサミ開催の経緯については、以下をご覧下さい。
http://codezine.jp/devsumi/2012/gaiyo#detail
http://codezine.jp/devsumi/2012/gaiyo#about


昨年、東京以外で、まず開催されたのは、「東北の復興は東北から」を目的としたデブサミ東北。
togetter をまとめさせていただきました。
デブサミ2011東北【A会場/B会場】 #devsumi - Togetter


LT大会の模様は、別途 はてなダイアリーで、まとめさせていただきました。
デブサミ2011東北のライトニングトーク大会で、東北のコミュニティの力強さを感じた #devsumi - 鎌玉 大のよしなしごと


そして、次に開催されたのがデブサミ関西になります。
Developers Summit 2011 Kansai - Togetter
最後の方に「行きたかった」という私のツイートがありますが、今回、1年越しの思いがかなったわけです。

【S-1】Chromeのプロジェクトに学ぶAgileでScaleするソフトウェア開発手法

Google エンジニアリング シニアエンジニアリングマネージャ : 及川 卓也 さん


AgileでScaleするって、ルー大柴が使うような、よく分からないタイトル。
デブサミ2011で行った『クラウド時代のソフトウェア開発』の再演を行って欲しいと言われた。
これは、一般的に言われているソフトウェア開発が、ここ5，6年でクラウドと呼ばれているものに特徴されるような、ユーザーの希望にどう答えるか、開発にどう生かす/学ぶのかという2つの観点からの話だった。


同じ話をしても面白くないので、今日は担当しているChromeを例にとって話をする。
Chromeを知らない人は手をあげて。


まっちゃだいふく さん 「(^o^)／」


後ろの人…。
後で学んでください。
(もちろん、全国で情報セキュリティ関連の勉強会を開催されている
まっちゃだいふく さんがChromeを知らないわけがありません)


クライアントであるChromeの開発においても、クラウドのエッセンスを詰めて行っていると考えている。
今日は、一般的な大規模ソフトウェア開発の手法、クラウドの登場でどうなったか、Chromeのプロジェクトに見るオープンソースプロジェクトの今という順番で説明する。


まず、大規模ソフトウェアの歴史を振り返る。
20年前からコンピュータ、ソフトウェア開発をやっている。
当時の大規模開発と言えば、緑の窓口や銀行の勘定系オンラインシステム*3といった社会インフラを支えるシステムで、大人数が関わっていて、プロジェクト自体が複雑なものだった。
そこで適用されていたのが、ウォーターフォール。


Plan(企画) → Design(設計) → Implementation(開発) → Stabilization(テスト、品質向上といった安定化) → Release(リリース) → Planに戻る


通常は、縦に書くが、あえて円で書いてみた。
というのは、1回で終わるのは極めてまれで、リリース後の不具合改善や機能追加要求で次のサイクルが回ることが多かった。


100人、1000人といった大規模開発で考えなければいけないのは、人の管理。
今ではそんな話は聞かないが、Microsoftにいた当時*4、Windowsは品質が悪い、バクだらけと言われていた。
しかし、メーカーが出す山ほどの周辺機器や、サードパーティが出す数え切れないほどのアプリ、会社内のみで使用するインハウスの捉えきれないほどのアプリに対する互換性を求められ、あれだけ対応したのは、すばらしいこと。
私にとって、アポロ計画を実行しているんじゃないと思うぐらい、非常に緻密なものだった。


多くの人に使われるものには、コントロールが必要となってくる。
そこで、必要となるのが工程管理。
ガントチャート。最も私が嫌いなもの。
だが、Chromeでもガントチャートを使用している。


ウォーターフォールは必ずしも悪いことではない。
各工程で何をやっておくかということを決めておくことが大切。
ぶれないということが非常に重要。
工程の中で何をやるのか、何をもって終了するのかということをあらかじめ決めておかないと、ぶれてしまう。


プロジェクトには、いろんな人がいる。
プログラマ/デザイナ/テスト担当者、社外の人もいるかもしれない。
工程の終了時点で、全員あるいは各リーダーに集まってもらい、全部をチェックして、はじめて次の工程に進む。
何をもって終了するのかという要件（イグジット・クライテリア、Exit Criteria とも言う）を満たしているかを確認する。


スケジュールにシビアになるのはもちろんであるが、それに負けないぐらい、事前に決めた何をもって終了するのかという要件を大切にする。
そうしないと、ぶれてしまって、本来、達成しようと思ったことができなくなってしまう。


実際には、大規模な開発では、全員で開発するのは難しいため、サブチームに分ける。
どれくらいの人数かはチームにより異なる。
Gooleでは、できるだけチームの人数は少なくしている。
5人から多くても10人、15人。
それぐらいでないと、チーム内でのコミュニケーション・コストが発生し、不必要なミーティングやドキュメント作成が必要となってしまうため。
また、各チームに権限を委譲し、チーム内での開発手法は任せている。
だから、チーム内ではアジャイル手法もありだ。
チームで情報を共有し、他のチームのやり方が良ければ、それを模倣することをしている。
チームの独立も大切であるが、情報を共有することで生産性を高めるということをGoogleはやっている。


ぶれないようにするためには、何を目的として開発しているかという、Thema（テーマ）が必要。
ぶれてしまったら、製品・サービス・アプリケーションとしてのまとまりが欠けてしまう。


我々はいったい何をつくろうとしているのかということを、チーム全員で共有することが大切になってくる。


東芝がつくった世界初の日本語ワードプロセッサーの開発を例にする。
誰も見たことがないものをつくるので、最初にテーマを決めておかないと、ぶれてしまう。
東芝のワープロのテーマは、単純なコンセプトでなければ覚えてくれないため、3行で表現した。
最初に発売したJW-10では、そのテーマを実現出来なかったが、ベストセラーとなったRupoでは実現できた。
これは、最初に決めたテーマを妥協しない形で持っていたため。


テーマをキチッと分かりやすく作り、チーム全員で共有しておくのが、ぶれないためのテクニック。


次に、大規模でサブチームごとに開発をしていて、課題となってくるのが、Branch(構成管理)について話す。
少人数ではメインブランチのみで良かった。また、開発系と保守系に分けることもできた。
しかし、1000人、10000人という単位になると、1つのブランチで管理できない。
統合するポイントを決めておき、メインブランチに戻す。
Microsoftでは、"Check In Window"と呼ばれる厳密な管理をしていた。
毎日、定時に開始されるデイリー・ビルドも行っていた。


テストでは、"Bug Bush","Find It!"と呼ばれる一定の期間を確保するテストを行うことが多い。
あえて開発を止め、みんなでバグを叩く。
バグの傾向をモニターし、対応する。
最後の方の工程で重要となるのが、バグがあっても勝手になおさせないという厳しい姿勢。
これは、よかれと思って修正したものが、大規模開発では副作用を起こして他のものを動かなくさせるということが非常に多くあるため。
優先順位の低いものは直さない。
簡単にクラッシュするものや、セキュリティに問題があるもの以外は直さないといったようにハードルをあげる。


過去のリリースにおいては、極めて高い完成度が求められた。
失敗が許されない。リコールは許されない。
アップデートは、提供者にとっても、ユーザーにとっても、ともにコストが高いため。


クラウドでは、どうなったか。


クラウドにおいては、デバイス側のソフトウェアの更新は不要。
クラウド側の更新により、ユーザー全員の環境が最新版となる。
Gmail、Google Map、Google+、facebook、twitterなど。
語弊があるので強調しておきたいが、品質に対する考え方が異なる。
クラウドの品質で大切なのは、サービスがリリースされた後にダウンさせないこと。
リリースした後に、長期休暇に入るなんてヤバい。


クラウド系のアプリにおいても、開発のサイクルはウォーターフォールと同じ。
何が違うかというと、サイクルが非常に短いこと。
ローンチ＆イテレート(リリース、そして反復）と説明するが、これはGoogleの中ではDNAのようにエンジニア全員に伝わっている言葉。
Facebookのマーク・ザッカーマンも「はじめから完璧さを求めない」と言っている。
リーン開発という言葉も最近ある。

リーン開発の本質 ソフトウエア開発に活かす7つの原則

リーン開発の本質 ソフトウエア開発に活かす7つの原則


要は、小規模なものをまずリリースして、それに対するユーザーの反応を見ながら、改良していくことにより完成度をあげていくということ。
完成度とは、ユーザーの希望にあうかどうかということ。
今の世の中、ユーザーが何を求めているか分からない。
小さく出して、大きく育てる。
仮説と実証プロセスを繰り返していく。


クラウド系のアプリの特徴で「永遠のβ」がある。
ユーザーにとって、バージョンは関係ない。
製品の改良は、非常に小さなリニアな形が行われているため、バージョンをユーザーは気にしない。


Chromeのプロジェクトに見るオープンソースプロジェクトについて説明する。


Chromeは、Webに暮らす人に最適なWebブラウザを目指して開発された。


Chrome登場前、firefoxはがんばっていたが、IEはなかなかバージョンアップしなかった。
当時は、情報の受発信中心で、静的な情報のやりとりのみであった。
しかし、Google Mapの登場で、動的な情報のやりとりを行えるようになり、Webはアプリのプラットフォームとなった。
そして、Chromeを開発した。
また、Webブラウザの下のOSがWebに最適化されていないため、Chrome OSも作成した。
今年に入り、AndoroidやiOSにもChromeを提供している。
詳しくは、Chrome Time Machine ( http://www.google.com/intl/en/chrome/timemachine/ ) を参照。


Chromeは、クラウドアプリケーション。
Gmailと同じように、バージョンアップという概念をなくしたい。


Chromium(クロミアム)というオープンソースのプロジェクトがある。
Chromeとの違いは、ロゴ/クラッシュレポート送信機能/第3者がライセンスをもっているビデオやオーディオのコーデックなどである。
Chromiumの中身は、他のオープンソースプロジェクトの成果物。
・Webkit … Appleの開発者が中心に開発しているレンダリングエンジン
・V8 … Googleの開発者が中心に開発しているJavaScriptエンジン
・skia … Andoroidで使用されているグラフィックエンジン


Ohloh という、オープンソースプロジェクトを紹介しているサイトで状況が書かれている。
http://www.ohloh.net/p/chrome
Chromeは、コメントが少ないと書かれているが、余計なお世話。
使用技術にC/C++の割合が多いが、実際にはJavascriptやHTMLがもっと多いはず。


オープンソースとクラウドの課題について話す。
クローズドな開発は、ソースやビルドの管理が厳密な管理ができた。


オープンソースのプロジェクトには、異なる組織から開発に参加できる。
そのため、異なる価値観や異なったゴールを持つ人が参加する。


クラウドは、デプロイメントコストや更新コストは低い。
しかし、リリースサイクルが長い。


これらを解決するのは、まずは『テーマ（開発方針）の共有』。


Chromeには、Simple/Speed/Security/Stability（堅牢性）というテーマがある。
最近では、Stylish、(同期のための)Sign inも言われている。
Chromeの開発では、これらは厳密に守られている。
Core Product Principlesに書かれている原則をまず読まなければ、開発に参加できない。
スピードに影響をあるものはコミットできない。
また、ユーザーにできるだけ設定をさわらせないように、メニューのプリファレンスの項目も少なくなっている。


Chromium開発では、チームの中の役割について工夫している。


リポジトリに書き込み権限にあるCommitterには、自分のことだけを考えている人はなれない。
プロジェクトの成功のための『良き市民』でないとCommitterにはなれない。


また、ソースを査読するReviewerという役割がある。
レビューされていないソースはコミットできない。
ソースにあるOWNERSファイルに各Reviewerの名前が記されている。


Chromium開発には、Google社内のMLではなく、社外のMLを使用するように徹底されている。
議論ではIRCがよく使用される。
詳しくは、http://www.chromium.org/developers を参照。


世界中から24時間、開発者が参加しているため、厳密なビルド管理ができない。
そのため、ビルドは徹底した自動化を行っている。


Buildbotを使用し、コミットされたものは自動的に行うようにしている。
このとき、最低限のテストも実行され、コミットされたコードがテストに通ったかどうか分かるようになっている。


また、Chromium開発では、Google社内やボランティアのテスト担当者がいる。
テストの作成は、基本的にパッチをSubmitする開発者自身が責任を持って行う。
テストが通らなければ、パッチをアップロードできない。
副作用で動いていたところを動かなくするリグレッションを犯さないようにする。
このとき、パッチを全プラットフォームでビルドし、自動的にテストを行うBotである Try Server で確認する。
レビューに出す前に自分で確認できるようになっている。


自動化ばかりでなく、人が介在することも重要。
Sheriffという、ツリー（ソースリポジトリの集合）の状態を健全に保つこと役割がある。
Sheriffは、タイムゾーンごとに1名が『ローテンション（原文ママ）』で担当する。
Gardenersと、コンポーネントの監視を行い、リグレッションが発生しないように、最新バージョンを取り込む役割もある。
Google社内では、SheriffやGardenersは、ビルドコップ（警官）と言われている。
全開発者がローテーションで役割分担している。


ブラウザ（クライアントソフトウェア）としてのソフトをクラウド的にするために、みなさんに評判が悪い「自動更新」を行っている。
賛否両論はあるが、ユーザーは最新の安全・安心のソフトウェアを使え、開発者は最新版をターゲットにすることができる。


また、リリースサイクルを見直した。
Chromeのバージョン4までは、リリースするのに13週かかっていたが、いろんなところをパイプライン的にオーバーラップさせることで6週まで短縮した。
短縮することで、新機能を無理やり押し込まなくても、次のリリースに回せるようになった。
皆さんは、自分がお使いのChromeのバージョンを言えますか？
分からなくなっている人が多いと思います。
それぐらい、ユーザーにバージョンを意識させないような状態になっている。


皆さんに特にお伝えしたいのは、『徹底的な自動化』と、『優良な市民』ということ。
Googleの社員は自動化をするのが好きであるが、自分たちで何かできないかとプロジェクトを健全に発展させていくチームとしての考え方も非常に大切にしている。
現在までに紹介したツールは最初はなかったが、みんなに使いやすいようにツールがつくられてきた。


最後に、オフィスの様子を紹介する。
オフィスでは、いつもビルドのダッシュボードを見られるようにしている。
また、OSごとにBuild Orb*5を用意し、ビルドが成功したら緑、失敗したら赤を光らせるように可視化するようにしている。
たいへんだけど、少しでも楽しんで出来るようしている。


GoogleがChorme開発で体験していることは『間近にある現実』であり、皆さんのプロジェクトもこういう状況になってきているのではないか。
開発を社外に出したり、オフショアにより時差が出てきたら、（今までのクローズドな開発とは異なってくるため）人ごとではなくなるでしょう。
そのときに、クラウド的な開発手法を活かしたスケーラビリティを考えていただいたり、スケーラビリティのための徹底的な自動化とともに、（これが一番重要ですが）チーム・メンバーがプロジェクトを健全に発展させていくことの大切さについてのコレまでの説明が、少しでも皆さんのお役に立てればいいと考えている。

感想

日本屈指のエヴァンジェリスト（伝道師）と言われている及川さんの講演を実際に見ることができて感動。
レッドツェッペリンのTシャツ着ているし、写真以上に若い印象を受けました。
実は、3列目の及川さんのすぐ前で聞いていました。


ウォーターフォールは必ずしも悪いものでなく、Exit Criteriaを決め、短いイテレートを繰り返していけば、完成度（ユーザーの満足度）を高めていけるという話には感銘を受けました。
現在、長年連れ添ったFirefox*6からChromeに移行中なのですが、頻繁なバージョンアップによる自動更新*7に辟易していました。
ですが、ChromeがGmailと同様のユーザーにバージョンを意識させずに細かい機能アップを図っていく戦略を取っているということを聞き、感心しました。


テーマ（開発方針）をチーム全員で共有するという話。
徹底的な自動化を計るという話。
開発者はプロジェクトの発展に力を注ぐ『優良な市民』たれという話。
いずれも、大切で重要な話を聞くことができました。


講演後に、会場前で"Ask the Speaker"という講演者への質問コーナーが出来ていたので、及川さんの共著である『100人本』を書籍販売コーナーで購入して、サインを貰うべく列に並びました。

100人のプロが選んだソフトウェア開発の名著 君のために選んだ1冊

100人のプロが選んだソフトウェア開発の名著 君のために選んだ1冊


※及川さんの最近の著作と言えば、以下の本ですけど、こちらは電子書籍版を購入したので…
挑まなければ、得られない Nothing ventured, nothing gained. (インプレス選書)

挑まなければ、得られない Nothing ventured, nothing gained. (インプレス選書)


名前を告げると、及川さんは「会いたかったよ」と言って、暖かい手で握手をしてくれました。


@kohsei @takoratta ラブ〜

実は、及川さんや岩切さんがスタッフをされている Hack For Japan の活動に賛同、応援していて、ネット上では繋がった仲だったのです。
Hack For Japanの活動については、後で詳しく述べたいと思いますが、活動を知った経緯などについては 第1回 Hack For Japan のオンライン・アイデアソン振り返り - 鎌玉 大のよしなしごと を参照してください。


また、『100人本』にサインをしていただきました。
Chromeを知らないと言った まっちゃだいふく さんは、サインを断られていました。


及川さん、またお目にかかれる日を楽しみにしています。

続きは、後日

では、想定以上に長くなったので、いったん、ここでアップします。


ちょうど、togetterの方も午前でまとめています。
デブサミ関西2012 午前のまとめ #devsumi #kansumi - Togetter


また、冒頭のあいさつと、及川さんの講演内容は以下で見ることができます。（残念ながら、今はもう見えなくなっているようです）
Ustream

*1:どこの

*2:今年でちょうど、10年目です

*3:第三次オンライン、大惨事オンラインとTypoしてガクブルした

*4:前職では、Windows Vistaの日本語版および韓国語版の開発統括されていました

*5:Build OrbはArduinoで作成されている http://www.instructables.com/id/Arduino-Orb-Build-Warden/

*6:その前はSlepnirを使用

*7:firefoxも同じようになったけど