Developers Summit 2011 (2 日目) 私的不完全議事録 【devsumi】
2 月 17 日(木)・18 日(金)の 2 日間にわたって、今年も目黒雅叙園にて「Developers Summit 2011 (デブサミ 2011)」が開かれました。
今年は私用で初日は参加できませんでしたが、2 日目に参加したセッションについて議事録を取りましたので、公開します。
例によって、すべての発言やスライドの文字を拾ってはいません。漢字の誤変換なども含めて何かおかしな所があれば、コメント欄やブックマークコメント、ツイッターなどで教えてください。よろしくお願いします。
目次
- [18-A-1] ハッカー中心の企業文化を日本に根付かせる (よしおかひろたか氏)
- [18-B-2] 第三者作成ソースコードに埋もれている不具合を暴け! (高石勇氏)
- [18-D-4] Expression Blend + SketchFlow で始める RIA 開発──開発者向けセッション (大西彰氏)
- [18-A-5] 前例のないソフトウェアを作る! コミ Po! 開発秘話 (小野知之氏・田中圭一氏)
- [18-A-6] Ameba Pigg Backend Practice (桑野章弘氏・根本英明氏)
[18-A-1] ハッカー中心の企業文化を日本に根付かせる (よしおかひろたか氏)
- スライドが SlideShare にアップロードされています。
- このセッションの議事録は、開始 20 分後から記録されています。ご了承ください。
DEC
DECのエンジニアリング文化
- ミッドナイトプロジェクト (スカンクワークス)
- 業務とは別に、予算人員などを確保せずに独自に行うプロジェクトのこと
- 業務時間の 10〜20% くらい(目安)を業務外の作業に宛てることが黙認されていた(むしろ推奨されていた)
- Google の 20% ルールのようなもの
- 社内コンピュータネットワーク (E-net) ※当時、イントラネットという言葉はなかった
- すべてのコンピュータがひとつのネットワークで結合していて、スタンドアロンでは使わなかった。80 年代では特殊なこと
- 情報共有が自然発生
- VAX Notes/社内コンピュータネットワーク
- ありとあらゆることが議論されていた
- 開発中の製品情報、バグ情報、サポート情報
- 業務に関係あることないこと、何でも。開発日誌なども
- 暗黙的にも明示的にも価値観を共有
- 管理よりも自由、自主性の尊重。「言われたことをやる」のではダメ
- 言葉にすると薄っぺらいが、実際にやってみると大変で、言われたことだけやっているほうがはるかにラク
- なんでもやってみる
- 情報の共有
- エンジニアリングの会社
統制の手法
- 功利的統制──給料やボーナス、地位
- 強制的統制──あからさまな権力、力関係
- 規範的統制──組織の価値観、イデオロギー
- 今の疲弊した組織は規範的統制に活路を見いだそうとしている? 「どうせ勤めるなら同じ価値観を共有しているところで働きたい」という労働者の考えがある
- ブラック企業は相当あるが、ブラックな手法では規範的統制の組織には勝てずに市場から撤退していくだろう
すぐれた民族誌
- 『超マシン誕生』
- 『闘うプログラマ』
- 『i モード事件』
- フィールドワークは冒険だ。帰還したエスノグラファーは英雄だ。──『洗脳するマネジメント 〜企業文化を操作せよ』
- TEC という架空の会社が出ているが、これは DEC をもじったもの
ハッカー中心の企業文化
- ハッカーとは
- コンピュータ技術に精通した人(辞書的定義)
- ちょっとした技巧(ハック)を操る人
- 社会を変えた人
- (なんでもかんでもハッカー?)
- 技術を実際に使って、何かをやって、変えてみる。行動するエンジニア
ハッカー倫理
- スティーブン・レビー『ハッカーズ』で次のように記している
- コンピュータへのアクセス、加えて、何であれ、世界の機能の仕方について教えてくれるものへのアクセスは無制限かつ全面的でなければならない。実地体験の要求を決して拒んではならない。
- すべての情報は自由に利用できなければならない
- 権威を信用するな──反中央集権を進めよう
共通の価値観
- コンピュータによって社会をよくする
- 管理より自由、反権威的
- ラフなコンセンサスと動くコード
- 許可を求めるな。謝罪せよ
事例: Yahoo に起きてしまったこと
- http://d.hatena.ne.jp/lionfan/20100815
- (Yahoo の問題は)簡単に儲かりすぎてしまったことと、ハイテク企業になろうという強い意志がなかったことだ。
- どんな企業にはハッカー中心の文化が必要となるのだろう? ──「よいソフトウェアを必要とするすべての企業」
- Yahoo が発見したように、このルールが適用される領域は、ほとんどの人々が思っているより広い
- DeNA も最初は外部にシステム制作を依頼していたが、間違いだったと(南場社長が)気づき、今ではすべて内製している
ハッカー中心の文化
なぜ必要か
- ハッカー中心の企業文化のほうが、自分には心地よいから(利己的な理由)
- その他の理由は、偉い人に説明するための理屈。
どうハッカー中心文化を作るか
技術者として
- オープンイノベーションの時代
- 技術は会社のものではない、社会のものだ
- 社会をよくしていくという価値観
- コミュニティという道具
勉強会の法則
日本で根づかせるために
質疑応答
- 「暗黙知」のところで「情熱や仲間が必要」とあったが、そういうものを持っていない仲間と働いている場合は。
→あなたがデブサミに来たのがその第一歩。見回してみると自分では孤独ではないということを知る。会社の温度の低さは共通で、それを知った上で勉強会のような形式知、ニンジン型アプローチで「これを知っていると生き残れる」のような、半分騙すような感じで、半径5m以内でやっていく。この場で質問するのは非常に勇気が要ることだが、あなたは質問した。ほかのみなさんも、会社に帰ったら自分ができることから始めてほしい
- 人の流れ(エンジニアがよい場所を求めて現在の職場を去ってゆくこと)について、思うところがあれば。
→仕方のないことだと思う。本当かどうか、勉強会参加禁止のような会社があるらしいが、企業の防御策としては魅力的な職場作りしかない。いくらガチガチに縛っても、会社を鎖国することも国を鎖国することもできない。いい環境に人が移動するのは仕方ないと思う。答えになっていないかもしれないが、もし自分のチームのエンジニアが会社を辞めたいと言ったら、「まあ 3 年はガマンしろ」はアンチパターン。それは、自分が十分な環境を提供できなかったことを知るきっかけだ
[18-B-2] 第三者作成ソースコードに埋もれている不具合を暴け! (高石勇氏)
会社概要
- 2002/11 設立(日本支社設立 2007/12)、従業員数約 165 名
- 本社 = サンフランシスコ、販売拠点 = サンフランシスコ、ボストン、イギリス、日本
- 全世界で 1,000 社以上に導入
- 事業内容: ソースコード解析ソフトウェアの開発、販売および保守サービス
Coverity は不具合のない完全なソフトウェアを目指します
- 医療や宇宙開発、国家機関など、安全性・確実性・信頼性が求められるソフトウェアに導入
- 組込市場での静的解析ツール市場シェア No.1 (35%、第 2 位の製品のシェアは 12〜13%)
静的解析ツールで可能なこと
- コードを静的解析し、バグやセキュリティ脆弱性を発見する
- 利点
- 開発サイクルにおける問題点の早期発見
- 後工程になるほど修正が大変になるので、初期段階で見つける
- テスト環境が不要
- 動的解析は実機やテスト環境が必要だが、静的解析ではそのような投資は不要
- 不具合のある箇所の特定
検出される不具合の種類
なぜ静的解析が必要か?──ソフトウェア開発の深刻な課題
- 複雑になるコードの管理
- 日々肥大化する開発コスト
- ソフトの不具合が与えるビジネスへの影響
- 開発スケジュールの遅延
- ソフトウェア・サプライ・チェーンにおける品質の担保
課題 1: 複雑なコードの管理
- ソースコード開発行数のトレンドは、2009年 = 22 万行、2010 年 = 45 万行、2011 年 = 100 万行(予測)
- 1 ページに 50 行印刷するなら、100 万行のコードは 2 万ページ。100 ページ/日とすると 6 ヶ月以上かかる
課題 2: 肥大化する開発コスト
- 出荷後のバグを修正するには開発時の 30 倍のコストが掛かる
- 開発時には覚えているのですぐに修正できるが、出荷後には忘れられるので工数がかかる
課題 3: ソフトの不具合が与えるビジネスへの影響
- 例: JR システムの不具合、銀行のオンライン系……
課題 4: 開発スケジュールの遅延
- 48% のプロジェクトで納期遅れが発生
課題 5: ソフトウェア・サプライ・チェーンにおける品質の担保
- 全世界に分散したチームおよびサードパーティのサプライヤーの使用には、新たなレベルのソースコードの把握と管理方法が必要
- サプライ・チェーン中のオープンソースの比重
- 2012 年までに、80% 以上の商用ソフトウェアパッケージに OSS が含まれることになる (ガートナー)
Coverity Scan──2010 オープンソース品質評価レポート
- OSS の品質評価に照準を絞った最大規模の官民共同研究プロジェクト
- 2006 年にコベリティと米国国土安全保障省の間で開始
- 6100 万行以上の OSS コードを解析
- http://scan.corerity.com/
- レポート出力内容:
事例: Android カーネル
- Android カーネル 2.6.32 のテスト
- 「コベリティ・インテグリティ・レベル 1」を達成 (バグ密度が 1,000 コード行当たり 1 以下。OSS 平均値より優秀)
- 合計不具合数: 369
- 高リスク不具合: 88 (システムクラッシュまたはセキュリティリスクの原因となる可能性)
- Android 固有のコードの一部に、Linux に比べて 2 倍の不具合密度
- Coverity としての対応:
導入実績
- 日本では 70 社以上に導入されている
デモ──Android カーネルの解析結果
- 障害のレベルなどで絞り込み
- ソースコードの該当部分の表示
- 別のユニットから呼ばれている部分もインライン表示
- 不具合のレベルや担当者などをその場で割り振ることが可能
ビルド & テストの自動化
- ソースコードをチェックアウト
- ビルド・解析の自動化 (Hudson、CruiseControl などの外部ツールとの連携も可)
- 検出された障害をレビュー
- ソースコードの修正とチェックイン
- 障害の対応状況確認
[18-D-4] Expression Blend + SketchFlow で始める RIA 開発──開発者向けセッション (大西彰氏)
開発プラットフォームとしての .NET
Expression Blend 4 とは
- WPF、Silverlight、Windows Phone 7 の画面デザインツール
- 初期のプロトタイプから完成品の作成までをカバー
- ベクターグラフィック中心の画面
プロジェクトの種類
- Silverlight プロジェクト
- Windows Phone プロジェクト
- WPF プロジェクト
- 一つのツールで RIA、Smartphone、Desktop に対応
メディア系に強い Silverlight
- 動画……ツールボックスから MediaElement コントロールを貼り付けて、URL を指定するだけ
- 静止画……Image コントロールを貼り付けるだけ
- アニメーション……Storyboard オブジェクトで管理。Flash とは異なり、好きなタイミングで再生が可能
ビヘイビアー
- アプリケーションがユーザーにどう応答するかをデザインするための部品で、オブジェクトにドラッグして利用(コーディング不要)
ユーザーエクスペリエンスを考慮
- エンドユーザーのゴールを意識したアプリケーション設計
- 目的に到達するのに迷わない
- 間違った入力ができない
- 操作トラブルが起こらない
- インタラクションデザインを行ってから詳細設計へ
SketchFlow
- 画面を線で繋ぐだけで画面遷移を定義
- 作った画面遷移を見るにはブラウザーと Silverlight だけがあればいい
- フィードバックをその場ですぐに受けられる
- 表示画面にスケッチして保存できる
- 実体はテキストファイルなのでメールでも送れる
- チーム開発にも対応
- 一度 Visual Studio で開いて、Team Foundation Server に接続
- サンプルデータ機能
- コントロールに表示するダミーデータを生成して表示
- Word にエクスポートすることで、プロトタイプからドキュメントを自動生成
Expression Blend が必要な側面
Expression 4 試用版
[18-A-5] 前例のないソフトウェアを作る! コミ Po! 開発秘話 (小野知之氏・田中圭一氏)
コミ Po! って何?
- まったく絵を描かなくても、気軽にポッとマンガが作れちゃう! 夢のコミックシーケンサー
- (紹介ビデオ上映)
コミ Po! のたまご
- ソフトウェア会社社員兼マンガ家 田中圭一
- サラリーマンとの二足のわらじを 20 年
ウェブテクノロジとは
- グラフィック系ソリューションを中心としたソフトウェア会社
- http://www.webtech.co.jp/
- 独自の減色エンジンの開発
- OPTPiX imesta シリーズ
- コンシューマーゲーム向け開発ツール
- OPTPicture シリーズ
- 携帯電話向け画像変換ツール
- 携帯端末ごとに最適なサイズに画像を最適化
時代の流れ
新規事業への挑戦
基本構想
- ゲーム会社時代の企画 (約 10 年前)
- 絵の描けない人にもマンガが描けたら面白い
- 3D データでマンガを作る
- ここ 5 年くらいで、手書き風の 3D 画像が台頭してきた
- データをいくつ用意すればいいのか
- 国語辞典に載っている全ての単語を 3D 化する必要がある? 何億円あっても足りない
- 解決の糸口: マンガ家・田中圭一
- 多くの人が親しんでいるのは学園マンガではないか?
- とりあえず学園マンガのデータを作って、おいおい裾野を広げていこう
プロトタイプの完成
- (コミックシーケンサー、略して「コミシク」のデモ版を実行して見せる)
- これを人に見せることで、ようやく「ああ、こういうものが作りたいのね」と分かってもらえた
- 2009/1 社内公開
- これを以て開発の本格スタートが決定した(2009/4)
試行錯誤の連続
- ターゲットが定まらない
- 想定される使い方が定まらない
- 使いやすい UI が決まらない
- 前例のないソフトだから!
仕様の確定
- 1 年以上の試行錯誤を経て、2010/6 にようやく確定
- ターゲット・想定する使い方を仮定
- 絵が描けない人でも使えるように
- メールとウェブくらいしかパソコンを使わない人
- マニュアルなんて見ないよね
- 印刷して同人誌なんていうコアなユーザーは少ないだろう。ウェブに載せるために作る
使いやすい 7 つの理由
- よくあるソフトを手本にする
- パクるということではなく、オーソドックスな UI や操作性を真似る
- カーソルにしゃべらせる
- マウスカーソルの形状を変える
- 左クリックと左ドラッグ
- 多くのパソコンユーザーは左クリックと左ドラッグだけで操作したがるので、主要な操作をここに集約した UI
- コンテキストメニューの活用
- もう少し使い込んでくると、とにかく右クリックしたがる。右クリックすれば、今できる操作が出てくるようにした
- 配置を考える
- 目線の移動や操作の流れを考え、グループ化やボタンなどの配置を決めていった
- アクセラレータキーへの対応
- 中上級者向けの気の配りかた。Ctrl + Z でアンドゥ、Ctrl + C でコピーなどの当たり前の機能がないと、融通が利かないアプリケーションになる。マニュアル不要になるよう、メニューなどにアクセラレータキーを表示する
- 高度な機能は小さく
- とっつきやすく、奥が深いアプリケーションのためには重要な点。高度な機能はあまり自己主張せず、奥の方に入れておき、慣れた人が気づくようにする
使いやすさの追求
- ツール開発会社としての経験
発売後の反響
- 発売後に分かる本当のニーズ
- 萌えキャラを求めるオタクのニーズが大きいだろうと思っていたが、会社のプレゼン資料に使うなど一般利用者の声が大きかった
- 要望に応えるため、今でも発売直前のような修羅場が続いている。しばらくこの状態は続くだろう
- 実装の優先順位決め
- 思ったことが直接伝わる
- ツイッターなど、ネットワークからの声が直接届くので、それをもとに対応できる
- Vector プロレジ大賞 Final 2010 年最優秀作品賞受賞
コミ Po! で「つくる」楽しみ
- マンガをつくるよろこびの提供
- マンガをつくることがいかに楽しいか、いかに可能性が広がるかを知ってほしい
- 新しい表現方法の提供
- 世界に向けて日本文化の発信
- 現在、英語版を開発中
[18-A-6] Ameba Pigg Backend Practice (桑野章弘氏・根本英明氏)
- スライドが桑野さんのはてなダイアリーにアップロードされています。
自己紹介 (桑野章弘氏)
- 桑野章弘
- サイバーエージェントでアメーバピグの運用・構築を担当
- ブログ: id:akuwano
- Twitter: @kuwa_tw
アメーバピグって?
- 2D アバターサービス
- 着せ替え
- ペット
- カジノ
- 2009/2/19 オープン (明日で2周年)
- 会員数 600 万人
アメーバピグのアーキテクチャ: 全体構成
- 通常の Web アプリケーションは Web・AP・DB の 3 層構造
- アメーバピグ
- FrontEnd……Web + AP サーバ、Socket サーバ
- BackEnd
- Storage サーバ……ユーザの Flash データの保存など
- DB サーバ……ユーザー/エリアなどの状態データ
- KVS サーバ……ユーザー/エリアなどの状態データ (現在はなし)
アメーバピグのデータストア
- 運用するうちに一番大きく変わった部分
- サービス当初は自作 KVS を仕様・運用
- 現在は MySQL のみで運用 (前面にキャッシュあり)
データストアのプラクティス
- バックエンドに依存しないモデル
- 正確な負荷テスト! 差分テスト!
- プロダクトの選定基準
バックエンドに依存しないモデル
- サービスの開始はスモールスタート
- 最初は流行るか分からない
- 将来的なことを考えるとスケールアウトの仕組みは欲しい
- 負荷がいきなり 10 倍になっても上手く動くかは分からない
- 同じものを使っていくわけにはいかないことも
- アメーバピグの場合、前述した自作 KVS「NDI」
- オープン当初は機能面で大きなメリットがあった
- スケールアウトの仕組み (AutoBalancing)
- キーのソートが保証される = KVS でありながらレンジ取得が可能
- MySQL 側に保証されたデータが存在(MySQL からのデータの再構築機能)。これによる運用側の安心
- 2010/7 に入り、データ増大による DB→KVS 再構築時間も長期化、遅い時には数時間かかるように→KVS 廃止
- IndexPersister
- アメーバピグのデータ取得部分の仕組み
- データストア部分が抽象化されているため、労力を掛けずに切り替えが可能
- いざという時に、すぐに他のプロダクトに移行できるようにしておく
- でも、そんなこと言っても怖い
正確な負荷テスト! 差分テスト!
- テストデータでいくらやっても不安はぬぐえない……
- 正確な負荷テストが選定の後押しをする
- ピグの負荷テスト用フレームワークを作成
- 実サーバーでデータ操作のログを取得
- 操作ログを元に負荷テストを実行
- 置換前には本番での差分テストを実施
- KVS & RMDBS の両者に書き込みを行い、差分をチェック
- 確認←→修正のフェーズを 2 週間以上、毎日繰り返し
- チェック方法も複数実施
- 書き込み時のデータチェック (両者の書き込みデータが正しいか(静的))
- 書き込み後のデータチェック (両者の書き込みデータが正しいか(動的))
- 読み込み時のデータチェック (両者の取得データが正しいか(動的、全体の 1/1000 をランダムに))
プロダクトの選定基準
- 今回は MySQL + FusionIO という構成を取っている
- 分散 KVS でやっていた頃と比べるとコストは掛かっている
- 事業として、サービス視点を重視する
- 理想的なプロダクトかどうか
- 実現性、実現工数が高いかどうか
- たとえ泥臭くても、理想形に近く、実現性が高いものを選択するのが事業への貢献
- 目に見えない運用コストを考える
- データストアのプロダクト選定基準
- 今の形はデータストアとしての理想形とは思っていない
- MySQL というプロダクトは他と比べて格段に安定していた
- 適材適所の考え方
- 安心できないプロダクトは部分的から適用
- FusionIO の選定基準
- 使わなくてもできた
- ただ、使わなければサーバ台数がふくれあがっていた
- 運用コスト改善は見えないけれど重要
- 実際にテストしての信頼性の高さ
まとめ
- 柔軟なプロダクトに対応するための仕組みを用意することで、事業・システムの未来が開ける
- 最後まで確認したそのもう一歩先を確認することが、安定したシステム改善に必要
画像ストレージ構築・運用編
自己紹介 (根本英明氏)
- 画像ストレージシステム、ピグ・ブログ・モバイルゲームを担当
- ハードウェア周りが多少得意
アメーバピグと画像ストレージ
- メインはブログのユーザ画像ストレージ
- 2008/10 リリース
- 当初は鬼の不安定さ
- 障害件数多数、データロストも
- 過去最も夜中に起こされ、過去最もデータセンターで作業した、とっても印象の悪いシステム
- なぜリリースしたか
- 当時のストレージが 70% 以上埋まっていた
- ハードウェア選定・検証まで 2 ヶ月しか取れず
- 可能な限りの検証を実施
- 苦節 2 年で安定化させることができた
どのくらい捌いているか
- Traffic……3 GBPs
- 投稿容量……約 120 GBPs/日
- 2008/10……20GB、2009/12……60GB、2011/1……120GB 超
- アクセス数……約 3〜4 億/日 (ユーザー画像)
ストレージ構築の実践プラクティス
- コンポーネントを列挙する
- 怪しい部品は交換する
- 思い切る
- 複数対策同時進行
ストレージ構成
障害内容
- Server-RAID 間の通信断
- FS 破壊
- データロスト
- 突然 HDD を認識しなくなる
安定化まで
- サーバ改善
- RAID カード改善
- ケーブル改善
- Enclosure 改善
- HDD 改善
サーバ改善
- リリース当初……DELL PE R200 を利用 (DELL 推奨構成での利用ではない) →障害超多発
- 全コンポーネントを列挙して調査
- RAID Controllerの定格温度: 55 ℃、動作環境: 70 ℃台
- DELL R200→R300 に交換したら、温度が 50 ℃台に
- コンポーネントは列挙して調べまくること
- その後、諸々の対策を打つも、HDD を認識しなくなる障害は直らず
- 最後は HDD の総入れ替え
- 1TB × 8 台× 16 セット = 144 台
- やりたくない……
- 入れ替えたら超安定
- 怪しい部品は交換する、思い切る
苦労した点
- 安定化するまでの道のり
- 動作確認が難しい
- 16 セットのサーバーがあったので、複数対策同時進行
質疑応答
- データロストは完全にロスト?
→バックアップを取ってはいたが、1 時間ごとくらいだったので、30 分くらい分ロストしてしまった
- 費用対効果はどのような形で意志決定されるのか?
→FusionIO については、負荷テストの結果を現場から上げていって「こういうものを使いたい」とマネージャーに伝えた。それに対して稟議を上げるようなプロセスはなく、自信があるものであれば許可が出る。ほかの案件についても、最初数台購入して動作確認後、安定しそうだという確証後、「いけます」という表明をして決済が下りている
