Developers Summit 2010 (初日) 私的不完全議事録 【DevSumi2010】

2 月 18・19 日に目黒雅叙園で行われた「Developers Summit 2010」に参加してきました。初日のプログラムで私が聴講したセッションの議事録を公開します。

例によって、発言をすべて拾っているわけではありません。特に、最後のセッション「アーキテクチャに憧れろ!」はテンポがよすぎて、かなりの部分を拾い損ねてしまいました。それでも雰囲気は伝わるかと思い、恥を忍んで公表します。

今年もデブサミを開催してくださった翔泳社さんに感謝の意を表します。

目次

• 【18-E-1】 SIer のこれからのソフトウェアを創る (市谷聡啓氏)
• 【18-C-3】 アジャイルテスト ─高品質を追求するアジャイルチームにおけるテストの視点─ (増田聡氏)
• 【18-C-4】ドッグフーディングとアジャイル開発 (大澤俊介氏)
• 【18-B-5】クラウドサービス Amazon EC2 を活用し「SKIPaaS」構築事例 (並河祐貴氏)
• 【18-E-6】RDB 入門 〜アプリケーション開発者が陥りやすい DB 開発の落とし穴〜 (磯辺信雄氏)
• 【18-B-8】アーキテクチャに憧れろ! (鈴木雄介氏・伊藤直也氏・小野和俊氏・江島健太郎氏)

【18-E-1】 SIer のこれからのソフトウェアを創る (市谷聡啓氏)

自己紹介

• DevLOVE、日本 XP ユーザグループスタッフ
• http://d.hatena.ne.jp/papanda0806/

DevLove

• 「開発は楽しい」──それを実感できる場を作り続ける
• 開発の楽しさを発見しよう、広げよう。開発の現場を前進させよう

事件──ウォーターフォール

• 工程の途中でプロジェクトが終了 (設計終了段階)
• たくさんのお金と時間、少しばかりの私の家庭的危機
• 顧客が手に入れたもの──大量の紙
• 環境の変化を止めることはできない。しかし、これがやりたいことなのか? 何をやりたいのか。ソフトウェア開発で何を実現したいのか
• 自分はかつて、公共性の高いシステムに携わった。今までできなかったことがソフトウェアでできるようになる! →ソフトウェアは社会を変える。ちょっとずつよくなる
• ちょっとずつが重なって、結構よくなる
• 顧客が手に入れた価値──大量の紙
• 現状の開発では、必要とされるソフトウェアの提供が困難
• 3 つ乗り越えるべきこと
• 現状のソフトウェア開発は変化に対応できない──契約
• ソフトウェア開発の価格に対する納得感がない──価格設定
• 必要なソフトウェアが必要なタイミングで手に入らない──プロセス
• 変化──外的変化と内的変化
• 外的変化──取り巻くものの変化。経済環境、政治環境など
• 内的変化──状況が進むことによって理解が深まり、分かっていなかったことが分かるようになる
• 手順の計画の限界
• 開発者も顧客も。変化は起こるべくして起こる
• ソフトウェア開発受託開発一括請負における変化とは?──仕様変更
• 「仕様変更は管理しよう」と言われる
• 変更管理は、ソフトウェア開発を安全に遂行するためのもの
• 仕様変更の世界……受注側は別料金と考え、発注側は固定料金と思っている
• 仕様変更管理なんて言っているウチは、変化を受け入れているとは呼べない

第2部 人月

• 人月、一括請負はよくできている
• 人月の世界で儲け続けることができるかもしれない、と思っていたが、価値には到達できない
• レビットのネジの穴「顧客はドリルがほしいのではなく、ネジの穴がほしいのだ」
• 開発コストは、価値に直接は結びつかない。ドリルの値段と穴の値段は直接結びつかない
• 顧客には分からないもので価値を決める。理解が得られるはずもない
• ソフトウェア自体には価値はない。ソフトウェアと利用者の間に価値が生まれる
• 価値が分からないまま、開発終了まで 1 年間。1 年後も用をなすのか?

プロセスの問題

• プロセスだけウォーターフォールからアジャイル的に変えても問題は解決しない
• 「後で使用を変える時、費用はどうしましょうか?」──答えられない
• プロセスの問題の前に価格設定の問題、その前に契約の問題がある
• ソフトウェアがもたらす成果に応じて価格を決める──パフォーマンスベース契約(経済産業省)
• 発注者と受注者が共同する世界。お互いが価値発見、価値向上のために知恵を出し合う世界
• 課題──成果を測るまで時間がかかる。1 年待つのか。顧客も開発も待てない
• ここでアジャイルの出番
• 利用も評価も短いサイクルで。フィードバックを早く
• IT だけの貢献(価値)を図るのは難しい。どこまでリスクを取れるかが肝(顧客と開発で互いにリスクを取る)。ソフトウェア開発の新しいビジネスモデルの確立をトライアル中
• ビジネスモデルとプロセスを分けない
• 現状を変え始めることは一人でもできる。しかし、組織の仕事を一人で変えるのは難しい。(最初から最後まで一人の仕事はない)
• 現状に踏み留まろうとする人の意識の問題
• 変化を起こすには、今までの前提を疑ってみる必要がある
• 自分はデブサミ 2007 がきっかけ。角谷信太郎氏のセッションを見た。「自分が信じるもののために生きる」(角谷氏)。
• デブサミやコミュニティは、気づくためのきっかけになる
• Life Hacks Press に「勉強会のすすめ」という記事があり、勉強会をしようと思った
• 内と外の温度差でうまくいかなかったが、周りの気温が上がるのを待っているほど人生は長くない
• 受動/能動と日常と非日常の 4 マトリックスで、今まで自分がいたのは受動的な日常。能動的な日常に行くためには、受動的な非日常→能動的な非日常という経路を取らざるを得ない
• 受動的な非日常……SKIP で普段はないコミュニケーションを育む
• 能動的な非日常……社内版デブサミで自分たちが向かいたい方向の確認
• 能動的な日常……社内勉強会。日常 = 仕事。日常で繋がる。日常を変える
• やりすぎるとマンネリ感がでるので、能動的な非日常と能動的な日常を行ったり来たりするようにする
• DevLOVE = 社外との接点(コミュニティ)を意図的に作りたいと思った
• コミュニティに行って得たものを現場に持ち帰って仮説を立ててやってみる。事例をまたコミュニティに持って行く→コミュニティワークバランス
• 現場もコミュニティも複数存在する。この業界全体が循環するシステム
• 期待どおりに行かなくて挫折するが、そこが始まり
• 自分が最初の一歩を踏み出したら、それを見た他の人の踏み出す勇気になる
• 自分が変われば、他の人も変わる
• 世界を変えるのは他の誰かではなく自分自身
• 信じるからこそ、仕掛ける

【18-C-3】 アジャイルテスト ─高品質を追求するアジャイルチームにおけるテストの視点─ (増田聡氏)

はじめに

自己紹介

• IBM グローバル・ビジネス・サービス テストマネジメント
• 「ソフトウェアテスト PRESS Vol. 2」(2005、技術評論社)
• 『プロジェクトマネジメントハンドブック』(2009、オーム社)
• 『実践アジャイルテスト』(2009、翔泳社)──本日のセッションのきっかけ

本セッションの概要

• 『実践アジャイルテスト』の原書『Agile Testing』の内容は実践的である
• 日々考えていることの答えやヒントが書かれていた
• セッション概要
• アジャイルテストとは、アジャイルチームにおけるテストのこと
• アジャイルテストの 4 象限について
• テストの視点から、アジャイルテストの実践的なポイントや高品質を追求するチームの紹介

皆様にお伝えしたいこと = 高品質を追求するアジャイルチームにおけるテストの視点

1. アジャイルテストは、高品質なソフトウェア開発に重要な役割を担っている
2. アジャイルテストは、ビジネスメンマなた技術面の軸とチームを支援する目的か製品を批評する目的化の軸による 4 象限の分類で説明される
3. アジャイルテストのプラクティスがある (チーム全体アプローチ、自動化など)
4. これからアジャイルテストに取り組むチームへのアドバイス

アジャイルテストとは

従来型のテストの視点

• V 字モデル
• 標準 (IEEE など)
• テストタイプ、テストレベル
• インシデント管理
• テストケース作成

メソドロジーとは

• プロセス記述 (WBS)
• ガイド
• 作成物サンプル

アジャイルテストの 4 象限

     自動と手動           ビジネス面               手動

        ┌──────────┬──────────┐

        │                    │  探索的テスト      │

        │  機能テスト        │  ユーザビリティテスト

        │  ストーリーテスト  │  ユーザ受け入れテスト

        │  プロトタイプ      │                    │

チームを│  シミュレーション 2│3                   │製品を

支援する├──────────┼──────────┤批評する

        │                   1│4                   │

        │単体テスト          │ パフォーマンス/負荷テスト

        │コンポーネントテスト│ セキュリティテスト

        │                    │ 「〜性」テスト     │

        │                    │   (...bility test) │

        └──────────┴──────────┘

       自動                 技術面                 ツール

テストの視点から

高品質を目指すチームのプラクティス

1. チーム全体のアプローチを取る
• プログラマと一緒に座り、自ら会議に参加
• 問題をチーム全体の問題としてとらえる
2. アジャイルテストの考えを採用する
• 継続的によりよい方法を探す
• よい本やブログ、記事を読み、新しいアイデアやスキルを身につける
3. 自動リグレッションテストを適用する
• 自動リグレッションテストはチームの仕事。テスターだけの仕事ではない
• シンプルに始める。自動スモークテストや自動単体テストだけでも効率化される
4. フィードバックを与え、受ける
• フィードバックはアジャイルの中心的な価値
• 反復計画会議と振り返りに十分な時間を掛けて改善する方法を探る
5. コアプラクティスの基礎を築く
1. 継続的インテグレーションをする
2. テスト環境を管理する
3. 技術的な負債(Technical Debt: 未解決の技術的課題の累積)を管理する
4. 段階的に作る
5. コーディングとテストは一つのプロセスとする
6. 各プラクティスの相乗効果を図る
6. 顧客と共同作業する
• テスターはまとめ役になる
7. 広い視野を持つ
• 現在のストーリーがビジネスの重要なスキームに合うか評価できるようにする

アジャイルテストへの移行

1. 文化的なチャレンジ
2. チームの運営のチャレンジ
3. プロセス移行のチャレンジ

文化的なチャレンジ

• 組織の文化 → 味方を増やす
• 適応のための阻害 → 継続する
• 変革の導入 → 小さな成功を収める
• 管理職の期待 → 管理職の世界観の共有
• 変化は簡単ではない → 体験させる

チーム運営

• チームの構成 → 役割分担は必要
• 物の準備 → 作業環境、ツールも必要
• 人材 → どのような人物がふさわしいか
• チームの立ち上げ →情報共有、目的共有

プロセス移行

• 軽量プロセスを探す → できることから始める
• 指標を設定する → プラス思考になれる指標を設定する
• 欠陥の追跡をする → ナレッジベースとして使う
• テスト計画書を作成する → 先のことを考えるとリスクが浮かび上がる
• 既存のプロセスとモデル → 従うべきプロセスもある

最後に、アジャイルプロセスサポートツール「Rational Team Concert」の紹介がありました。

【18-C-4】ドッグフーディングとアジャイル開発 (大澤俊介氏)

アトラシアンのミッション──a different kind of software company

• よい製品を手頃な価格で提供
• 軽量なソフトウェア、just enough な機能
• ある会社のツールでは全体の機能の 10% しか使われていないが、アトラシアンのツールは 75% の機能が使われていたという調査結果もある
• 伝統的なセールス部隊なし (製品自体が営業マン、口コミ)
• エコシステム(パートナー、デベロッパーの支援)
• 伝統的なサポート、課題管理システムの公開
• オープンソースコミュニティ等に 12M ドル以上のライセンス寄付

アトラシアンのソフトウェア開発

• 2001 年、アジャイルマニフェスト制定
• 2002 年、アトラシアン創立

ショートリリース

• 市場動向をつかみやすい
• アジャイルを強要

チームにとってのメリット

• チームの士気向上
• 適度な緊張
• バグ修正に時間を使う
• 無理をしなくて済む

ドッグフーディング

• FAIL FAST──早く失敗すれば早く回復できる
• 社内ユーザーからのフィードバック。200 人のテストユーザーがいるようなもの
• 素早いフィードバックが重要

パブリック JIRA

• http://jira.atlassian.com/

Good から Great へ「クォーターごとのリリース」を目指す

• 98 日サイクル
• 準備期間: 作業・回答すべき質問
• イテレーション期間: 作業・回答すべき質問
• アトラシアンのイテレーション期間は 2 週間単位
• バーチャルインデックスカードを使用

コードレビュー

• 同僚にコードを見てもらうと、2 つのうちのどちらかが起こる
• 説明しているうちに自分で気づく
• 同僚が気づく
• formality による区分 (上の方ほど formal)
• inspection
• team review
• walkthrough
• peer deskcheck, passaround
• ad hoc review
• 教育効果
• ピアレビューの障壁
• エゴ
• 熟練デベロッパーによる支配
• レビューではなくプレゼンになってしまう
• 問題発見ではなく、問題解決ディスカッションになってしまう
• コードレビューの障壁
• スケジュールや場所の確保
• 地理的に分散したチーム
• プロセスにかかる経費
• コードレビューツール利用のメリット
• ミーティングの調整、記録など管理者の負荷を最小限にできる
• 入力する時間があり、記録に残るので、非建設的なコメントがされにくい
• 非同期で実施できる
• 透明性がある
• 結論: よいツールはレビューの質と量を向上
• アトラシアンではオンラインコードレビューを活用
• five tips for agile code reviewers
1. レビューするコードに関連する課題を読む
2. コード変更の構成を見る
3. 機能が動作しているか確認する
4. 変更を自身で行うことを考えてみる
5. レビュー終了時、提案リストをまとめ優先順位を付ける
• tips by Wojtek
• 頻度: できるだけ頻繁に。「継続的コードレビュー」
• スケジュール: 1 日の最初、最後あるいはお昼
• 誰が?: 同僚が一番。次に Tech Lead
• 何人ぐらい?: 2〜4 人で十分。ときには1人でも
• ワークフロー: できるだけシンプルに
• 測定方法: それほど気にしない。少なくとも最初は

人の部分

• ダニエル・ピンク「やる気に関する驚きの科学」より
• 20 世紀的な報酬──狭い範囲でしか機能しない
• If then 式の報酬──クリエイティビティを損なうことも
• 高いパフォーマンスの秘訣──内的な意欲
• 人への投資
• 社員が誇れる会社

【18-B-5】クラウドサービス Amazon EC2 を活用し「SKIPaaS」構築事例 (並河祐貴氏)

自己紹介

• 並河 祐貴
• TIS 株式会社
• http://d.hatena.ne.jp/rx7/ ── Amazon EC2 について日本一詳しく紹介しているブログ(だと思う)
• ツイッターは @namikawa
• 『クラウド Amazon EC2/S3 のすべて』が 2009/11/5 に日経 BP 社より発売。2,940 円

Amazon EC2/S3 とは

• Amazon.com 社の提供する IT インフラのクラウドサービス
• サービスの特徴
• ロードバランサや監視など、運用に必要となるサービスが揃っている
• 初期費用無料、1 時間/1GB 単位での従量課金 ($0.085〜/1h)
• 高い稼働率保障 (EC2: 99.95%、S3: 99.9%)

Amazon EC2/S3 のメリット

• インフラの準備にかかる期間を大幅に短縮できる
• 稼働状況に応じてサーバの増強・縮退ができる
• インフラの運用管理にかかるコストを削減できる
• 世界中にセンターがあり、災害対策にも対応できる
• VPN により自社内ネットワークのリソースとして利用できる

短納期・低コスト・高セキュリティ

Amazon EC2/S3 が利用されている事例

• THe New York TImes
• 数 TB の過去記事を S3 に保存
• NASDAQ
• 過去の株式市場データを S3 に保存
• SmugMug
• オンラインフォトストレージ、50TB以上の画像データを S3 に保存
• ANIMOTO
• スライドショー作成サービス。
• Twitter
• 画像等の配信に S3 や CLoudFront を利用
• eco ideas net
• パナソニックが運営
• クックパッド
• ログ解析用のバッチシステムで EC2 を利用
• ウェブポ
日本郵便と提携し、構築されたオンライン年賀状作成ツール、年賀状シーズンのみ数十台規模の EC2 や S3 などをフル活用
• SKIPaaS

弊社事例 SKIPaaS

• SKIP(社内 SNS)を SaaS で提供
• 2008/7 より提供開始、商用で 1 年半以上の運用実績
• 数十台規模の EC2 サーバーで稼働

Amazon EC2 の採用

• 社内ベンチャーが SaaS 事業を短期間で立ち上げ
• サービスインまでのスピード感──利用申請から数分でコンピューティングリソースを利用開始できる(最近は要審査?)
• 初期投資が不要──従量課金制のため、インフラのコスト(在庫)が発生しない
• API での操作と高い自由度
• 操作はすべて API 経由で即時実行、ストレージとの容易な連携
• 既存のアプリケーションが改修なしで稼働
• OS イメージのカスタマイズなど、多くの仮想化技術の恩恵を享受できる

Amazon EC2 の基本機能

• AMI(Amazon Machine Image)──Amazon EC2 で利用できる仮想 OS イメージ
• Key Pairs──リモートログイン時に必要となるキーの生成 (秘密鍵・公開鍵)
• Security Groups──仮想サーバへのアクセス制限(ファイヤーウォール)を実施

カスタム AMI の活用

1. ベースとなる OS を起動
2. 内容をカスタマイズ(アプリケーションのインストールなど)
3. カスタマイズ済み OS をイメージ菓子、AMI として保存(バックアップ)
4. 保存された AMI をもとに、仮想サーバの複製を実施(リストア)

スケールアップ

• AMI / Amazon EBS の活用
• システム領域は AMI にバックアップ
• データ領域は Amazon EBS に配置

実運用する上での課題とその対策・ポイントについて

1. ネットワーク面の課題

• Web ページがもっさりと表示される
• コンテンツのダウンロードが遅い

対策

• Web ページ内で参照するファイルが多いと体感速度低下
  
  →Amazon CloudFront の活用、もしくは国内に静的コンテンツ配信用のサーバーを併設
  
• 以下注意点が許容できるのであれば CloudFront がオススメ
• 初回アクセス時の通信速度が遅い
• キャッシュされたデータの生存時間が最低 24 時間
• HTTPS でのコンテンツ配信に非対応

Amazon CloudFront

• CDN (COntents Delivery Network)サービス
• S3 に配置されたコンテンツを高速配信
• 日本にもキャッシュサーバ有り
• キャッシュサーバの料金は各国で異なる
• 日本では $0.095〜0.221/1GB
• 1000Mbps、1000reqs/sec にも耐える
• SSL には非対応

2. ストレージの選定

ストレージ設計

• EC2 周辺には 3 種類のストレージが存在
• 仮想サーバのローカルディスク、EBS、S3
• 注意点
• 仮想サーバのローカルディスクは、サーバを停止させると内容が消滅する
• EBS は、1 ボリュームあたりの利用容量に上限がある
• ロスとしたくないデータの保持については EBS の利用が必須。EBS で大容量のデータを扱う場合は、ソフトウェア RAID でカバー
• EBS は仮想サーバの停止や障害に左右されない
• EBS ではバックアップしやすいスナップショット機能もある
• SKIPaaS でのストレージ
• EC2……基本的に変更しないシステムデータ
• EBS……アプリケーションで扱うデータ(ファイル、DB)、ログデータ等
• S3……バックアップデータ、カスタム AMI

3. バックアップの実際

バックアップ設計

• システムバックアップは AMI 化 (S3 へ)
• 必要に応じて Amazon EBS を利用
• データバックアップは S3Sync (rsync ライクな S3 との同期ツール)を利用して S3 へ

4. メールサーバ運用の課題

EC2 でのメールサーバ運用の課題

• EC2 インスタンスで利用される IP アドレスの一部がスパムメールの DUL に登録されている
• spamhaus.org
• mail-abuse.com (maps)
• スパムメールの判定に、DNS 逆引きチェックが行われるケースがあるが、EC2 ユーザはそれを設定できない
• 174.129.xxx.xxx → ec2-174-129-xxx-xxx.compute-1.amazonaws.com

EC2 インスタンスでの DNS 逆引き設定

• Developer Forum にて、AWS のスタッフが β なサービスとして DNS 逆引き設定を受付
• メールサーバのログ等から、スパムリストに引っかかっているかを確認し、spamhaus や maps に対して解除申請を実施

5. オペレーションミスの影響範囲

本番環境用とテスト環境用のアカウント ID 分離

• EC2 では本番環境と同一の環境を生成しやすいメリット
• ただし、AWS 要の ID が一つの場合、テスト環境向けの操作が本番環境へ影響を与えるリスクがある
• テスト環境のインスタンスを停止させるつもりが……
• 秘密鍵を共有していたが、ステージング環境から誤って流出……

6. EC2 インスタンスの障害

障害が発生した際に確認できるリソース

• AWS Service Health Dashboard
• AWS Developer Community Forum
• AWS Premium Support (有償)

EC2 仮想サーバの障害事例

• アクセスできなくなった際の復旧パターン
• 自然復旧
• API 経由でのリブート
• AWS サポートスタッフによる復旧
• その他
• ユーザ側による別インスタンスへのマイグレーション
• AWS 側による別インスタンスへのマイグレーション
• ケースは様々だが、対応フローを準備しておき、手動でのマイグレーションで復旧できる算段を組んでおく。AWS Permium Support (有償)も活用するとよい

EC2 で構築・運用してみて

• 何も設備を持たない状況から約一ヶ月でのサービス立ち上げを実現
• 安定したクラウドサービス
• 当初より価格も下がってきた
• リモートでハードウェア保守を実施するイメージ
• ハードウェアやファシリティ、ネットワーク面のお守り(心配)をしなくなった
• OS より上のレイヤーはユーザーが責任を持って運用しなければいけない
• バックアップ、セキュリティパッチ適用、HTTP 死活問題、スケールなど
• サービス使用の特性・注意点を押さえて、オプションサービスの選択や設計・運用をする必要がある

【18-E-6】RDB 入門 〜アプリケーション開発者が陥りやすい DB 開発の落とし穴〜 (磯辺信雄氏)

ケーススタディ 1: システムが止まった

• スタンドアロンで稼働する POS システム
• 数百台規模で展開
• 一日当たり数台が特定の処理でフリーズ
• テスト環境で同じ処理を行っても再現しない

そこで……

• すべての端末で詳細なログを取るように設定
• 現象が発生した端末からログを回収

原因

• ある処理がトランザクション分離レベルを Read Committed に設定
• このシステムでは Read Uncommitted が前提
• マルチスレッドプログラムでコネクション・プーリングを使用
• 後続の読み込み処理に Read Committed に設定されたスレッドが割り当てられた
• 実行中のトランザクションによってブロック
• 画面遷移ができなくなり、Commit にたどりつけず操作不能に

問題点と解決策

• .NET の仕様
• プールされているコネクションは、直前に使用された時の分離レベルを継承する
• 解決策
• 処理開始・終了時に必ず分離レベルの設定を行う
• トランザクション分離レベルを十分に理解しよう。ただし RDBMS によって実装の仕方が違う

ケーススタディ 2: プログラムのパフォーマンスが出ない

• 月別の売上件数を表形式に表示する処理のパフォーマンスが出ない
• 切り分けをしてみると、DB に接続している時間が長い……SQL が遅いのでは?

そこで……

• 実行された SQL のログを分析
• カラムごとに集計の SQL が実行されていた!
• SELECT COUNT(*) AS CNT FROM tab01 WHERE nen = '2003' AND tsuki = '1'
• 列単位に集計するように修正
• SELECT nen, tsuki, COUNT(*) AS CNT FROM tab01 WHERE nen = '2003' GROUP BY tsuki, nen ORDER BY tsuki, nen
• さらに全体を一度に集計するように修正
• 要求仕様を単純に SQL に置き換えるのは危険
• この例では 12×9 回の SQL が実行されていた
• 修正後は 1 回の SQL + 結果セットからのフェッチ
• 効率のよい SQL を検討する

ケーススタディ 3: View を使っているのだがパフォーマンスが出ない

• View は非常に便利だが、使い方によっては気づかずにパフォーマンスを低下させることがある
• 単純にテーブルを JOIN している View はそれほど問題にならない(ベーステーブルへの適切なインデックスは必要)
• sum、avg、count、max、min 等の集合関数や、union, intersect, except 等の集合演算子は注意が必要
• 大量データを集約するような View はコストがかかる
• View を使ってパフォーマンスが出ない簡単な例
• 以下のような View を作成
  
  create view View_sum as
  
  select region, sum(quantity) as qty from orders group by region
  
• 以下のような select 文を実行
  
  select region, qty from View_sum where region = 'West'
  
  View が評価された後に where 条件で抽出されるため、order テーブルは全件抽出される
  
• View を使わないと……
  
  select region, sum(quantity) as qty from orders
  
  where region = 'West'
  
  group by region
  
• orders テーブルから where 条件で抽出されたローだけが集約されるため、View を使った場合より高速
• マテリアライズドビューという解決方法もある
• 実データを保持するのでパフォーマンスがよい
• 集合関数・集合演算子を使用するような View と親和性が高い
• オプティマイザに自動的に使用を判断させることも可能。SQL 文を変更せずにパフォーマンスの向上が見込める
• 注意点
• Refresh の管理が必要
• 実データを保持するための領域が必要

ケーススタディ 4: マルチコア CPU が有効利用されていないようだ

• CPU のマルチコア化に伴い、RDBMS もマルチ CPU 構成を有効に利用するようなアーキテクチャを実装してきている
• クエリ間並列処理
• 複数接続からのクエリ要求を別々のコアに分散実行
• クエリ内並列処理
• 一つのクエリ内の処理を別々のコアで実行
• 並列インデックススキャン・並列ソート等
• 負荷の高い SQL を複数投入してみたが、コアの一つしか CPU 使用率が上がらない

そこで……

• ディスク I/O がボトルネックになっていることが考えられる
• キャッシュサイズを増やす
• 速度の速いディスクを採用する
• データベースの配置を複数の物理ディスクに分散する

【18-B-8】アーキテクチャに憧れろ! (鈴木雄介氏・伊藤直也氏・小野和俊氏・江島健太郎氏)

鈴木  今日の回の経緯を簡単に。去年秋に『ソフトウェアアーキテクトが知るべき 97 のこと』という本を訳したが、日本人に何本かエッセイを書いてもらおうと企画し、僕が尊敬しているアーキテクトを自分を含めて 8 人選んだ。今日はその中の 4 人で話をしたいと思う。自己紹介をしてもらいながら、普段触れているアーキテクチャ、失敗したアーキテクチャ、未来の話などをしていただきたい。

伊藤  株式会社はてなの伊藤です。はてなをご存じでない方は手を挙げて……知っている人 100% ですね。目新しいアーキテクチャを使っているというよりは、基本の三層構造でやっている。所々、検索エンジンだけはサブシステムとして分かれているとか、はてなブックマークとはてなダイアリーを疎結合にするために内部で API でつなぐなどの工夫をしているが、想像どおりの作り方をしている会社だと思う。自分は最近では社員が増えたのでマネジメントをしているが、そもそも何を次にやるかということを管理している。最近は「うごメモはてな」ではてなスター欲しさに子供が人力検索はてなに押し寄せてきて、質問に対して 「分かりません!」と回答して(会場笑い)。単純にシステムの面倒を見ると言うより、コミュニティの動向を見る仕事。

江島  株式会社バンカクの江島です。パッケージビジネスをしていて、販売で渡米した後ウェブに転向、Lingr などをリリースしたけれど去年の夏に引き揚げ、今は iPhone のゲームのバックエンドを作っている。Lingr だとブラウザだけでプッシュ技術を実現する Comet を世界に先駆けて出した。今は iPhone 同士の通信ということで技術的チャレンジが多い。UDP で TCP のプロトコルを実現するとか。

鈴木  江島さんは Lingr 時代に肩書きを「フィロソフィスト(哲学者)」にしていたが、今と当時との違いは。

江島  方向性を示すということからそういう肩書きにしていたが、大した意味はない。

小野  エンタープライズのパッケージベンダーをしている。ブログやツイッターの発言からしてネットゲームの運営会社や酒屋さんだと勘違いしている人がいるが、間違いです(笑)。SI を一切やらないというポリシーで、ライセンスビジネスだけでやってきている。伊藤さんはマネジメントだが、僕はプログラミングの比率がどんどん上がってきている。アーキテクチャでは、Swing で GUI、Silverlight をやったり。古典的な MVC は長くやっている。最近はクラウドの話が非常に多い。安い、運用の自動化だけではなく、データの即時一貫性などはまさにアーキテクチャの部分。

鈴木  小野さんが普段触れているアーキテクチャとしてのゲームには触れなくてもいいか。

小野  WoW は何千人が同時にログインしていても動作がスムーズで最高のプログラムだと思う。

鈴木  この時点でお互いに聞いておきたいことは。

伊藤  今回はクラウドが前面に押し出されたデブサミなので、会場の皆さんにクラウドの話をぜひ。

小野  2009 年は「クラウドが疑問から関心に変わった年」、2010 年は「関心から受容に変わる年」。グーグルがクラウドだというのと、企業システムがクラウドにというのは全然違う話。今年に入ってから企業や大学のシステムがクラウドでという話はとても増えてきている。

江島  コスト意識が強くなってきている?

小野  コスト、運用自動化、それからパラダイムの変化。今まではできなかったことができるようになったことに対する期待感。

鈴木  今までできなかったことができなくなるという不安は。

小野  一番みんなが気にしているのは、人のスキルの話。DB の設計はあのオヤジに聞けば、という職人的な人が、ゼロスタートしなくてはいけない。これからどう変わっていけばいいのかで抵抗感があり、「それって実質使えないんじゃない」という発言になる。

江島  直也さんがクラウドについてどう思っているのか聞きたい。

伊藤  今まで自前でやってきた中でジレンマに感じる。自前が強みだった時代は確実にあった。その見極めをしていかなくてはというのが正直なところ。どこを残してどこをクラウドに移行するのか。自分たちでクラウドを構築できる可能性も含めて考えないといけない。

小野  今からゼロから何かを始めるとして、クラウドの利用も検討するか。

伊藤  もちろん。スケーラビリティの確保でかなり苦労したので、クラウドに任せた方がいい。

鈴木  Lingr はクラウド上で? 前は自前?

江島  CNet や SIx Apart も利用しているデータセンターでやっていた。そのデータセンターは Bay Bridge のたもとにあった。でも所詮アメリカなんで品質が低くて、酔っぱらったオジサンが線をパン! と切って全部落ちちゃった(笑)。

鈴木  今移植してみて何の不都合もない?

江島  ないですね。

鈴木  過去を振り返ってみて、これは失敗したなって言う経験を、話せる範囲で。

伊藤  昔の MVC フレームワークがメジャーになるかならないかの頃、自前のフレームワークをはてなで持っていた。そこまで MVC を正しく理解できていなかった頃に見よう見まねで作ったので、そのせいで今でもそのフレームワークで作ったアプリの設計がいまいち。すべての根本になるアーキテクチャはしっかり作らないと後で苦労するなと。フレームワークは後で作り直して、新しいプログラムはそっちで作っているが、レガシーなシステムだからと言って止めるわけにも行かないし、少しずつ設計を変えていくという苦労がある。

鈴木  リファレンスになる物がなかったというのは、知識の問題か。

伊藤  そうだと思う。Struts などはあったが、アーキテクチャとしてそれが正しいかどうかと言う判断が付かなかった。二度目に作ったアーキテクチャは確信を持って作れたが。

江島  1 つはコミュニケーション。アーキテクチャというものを持って仲間内でグランドデザインを共有する道具だと思うのだが、失敗はたくさんある。うなずきあっていながら全然違うことを考えていたとか。スケールにしても想像の世界なので、オーバーコミットして複雑なコードをたくさん埋め込んでしまって減らすこともできず、超高価なフレームワークになって自分の首を絞めるとか。

鈴木  事前にアーキテクチャに関して議論をしていく上での工夫は。

江島  シンプルに始める。要らないものは初めから入れない。将来必要になるかもと言うものは無限にあるが、プライオリティは「今必要な物」。そうでないものは手を出さない。

鈴木  「入れた方がいいかも」って心が揺れる瞬間があると思うが、そのときに立ち止まるためにやっていることは。

江島  個人の感覚だと思う。そこで合意できないことは多い。想像で言っているので。難しい問題だと思う。合意しやすい点として「シンプルにしていけばあとあとラクだよね」。

小野  ウチはデータ連係なので、標準化されたものをつかっているのだが、エスペラントのようなもの(いろいろなもののいいとこ取り)を作って失敗した。今持っているもの、当たり前の物から離れすぎていると受け入れられない。理想に走りすぎると失敗する。すべてのデータは XML で表現されている、美しい一貫した世界でやったことがある。美しいのだが、パフォーマンスが悪い。今まで 30 秒で終わった処理が 10 分かかってはダメ。結局、そこは全面的に変えた。そこだけ標準化されていなくてもいいというふうに作り替えた。エンジニアの美徳も、大きくやり過ぎて痛い目にあった。

鈴木  標準的で美しいアーキテクチャの魅力ってありますよね。

伊藤  XHTML とか。ウチはやっぱりユーザーさんがいて、多様な環境にいるので、常にイレギュラーなことが起こる。なので、あまり美しいとか言っていられないというのもある。PC ユーザが大半だったところに DSi ユーザーが流れ込んできた時は、「とりあえず」見られるようにした。

小野  iPad が Flash をサポートしなかったのも同じような話。理想を求めているという意味ではそうなんだけど。

鈴木  Google が IE6 をもうサポートしないとか。

伊藤  Windows もそうですし、言語もそうだけど、アーキテクチャより後方互換性を取ることで市場を獲得したものって多いと思う。ウチの会社に優秀なエンジニアがいて、彼は Ruby が好きなのだが、最初 Perl で書いていたのに一週間で「Perl はヤダ」と言って Ruby で書くようになった。今、彼の作ったサービスは誰もメンテできずに使われなくなった。

鈴木  MS が後方互換性に対してとても気を遣っているのに評判が悪い一方、Apple は過去のバージョンは切り捨てるがユーザーフレンドリーじゃないということではない。

江島  標準とは「枯れたデファクトスタンダード」。こうあるべきだという所から入ってみんなこれを使え、となると失敗する。

鈴木  ユーザーの声を聞く、というのは、問い合わせがあるからやろうということか。敢えて日本の携帯を使っているのもそういうことか。

伊藤  それはある。僕のチームには 10 人いるが、僕以外はみんな iPhone。誰かが携帯を使わないとユーザーの気持ちが分からなくなる。本当は iPhone が欲しいけど、ガラケーを使い続けている。若いエンジニアが「これからはこのアーキテクチャです!」と言って今まで自社で使っていたアーキテクチャを否定するとイラッと来る(会場笑い)。そこを「自分が否定されたように感じるから」ということでカッとなるのではなく、キチンと説明できるようにならないといけない。

小野  アーキテクチャが崩れていると、チームマネジメントがよくてもリカバリーできない。そこにはすごくこだわっている。

鈴木  アーキテクチャのの凝りっぷりに、「なんでこんなの残したんだろう」って。

伊藤  デザパタを覚えた頃の苦い経験。シングルトンクラスとか言って、タダのグローバル変数とか(会場笑い)。

小野  言葉と同じで、デザインパターンも使って覚えるというのはある。それを適用しようとしているソフトウェアのライフサイクルがどのくらい長いかというのが見極めるポイント。自社のメイン製品です、というような製品で実験されると会社がつぶれる(笑)。ライフサイクルが短い製品で試してもらう。新しく覚えた四字熟語をいきなりパネルディスカッションで使わず、友達との会話で使うような。

江島  そういう場を作ることは意識している?

小野  小さなプロジェクトはある。そう言うところで工夫してもらう。

鈴木  この 1、2 年で注目しているアーキテクチャと、今の技術じゃとうていできないけどできたら面白いなと思うアーキテクチャは。

江島  モバイルは面白いなと思う。スマートフォンはネットに常時接続されたポケットに入る端末。ルールが変わってくるなと思う。その中での新しいコミュニケーション、エンタテインメントで面白い仕掛けができると思う。例えば携帯電話は電話よりもデータ端末として使っている。現実世界とのインタラクションがもっと密になる。実際に見えている物にオーバーレイして、新しいユビキタスな世界観に合わせたアーキテクチャ、システムの作り方が根本的に違ってくる。CPU パワーが分散しているのでうまく使うというのが僕の中での大きなテーマ。

小野  「reCAPTCHA」がすごく面白い。キャプチャはもともとは BOT と人間を区別するためのものだったが、reCAPTCHA は OCR で機械が判定できなかった文字を人間が判定する。文字を 2 つ並べて、前者は読める文字、後者は読めない文字。(suno88 注: 小野さんによる reCAPTCHA の説明は割愛します。ご興味のある方は、秋元さんのブログに「reCAPTCHA - キャプチャを利用した人力高性能 OCR」というエントリーがあるのでご一読ください) スマートフォンが分散したグリッドコンピューティングだとエジケンが言ったが、reCAPTCHA はグリッドヒューマンコンピューティング。遊んでるだけのように見えるけれど発言してるとか、難しい問題を解いているとか、そういうのが面白い。

伊藤  いい流れですね(笑)。アーキテクチャというとシステムに着目しがちだが、社会的なアーキテクチャが明確なレイヤーとして存在する。ツイッターが今までのウェブサービスと違ってどうしてみんなが使うかというと、コミュニケーションとしてのアーキテクチャがあるから。一方で、グーグルは技術で検索エンジンを作り、技術的なアーキテクチャは得意だが、社会的アーキテクチャは不得手だ。技術的に解決する分野はプレイヤーが出そろっている。一方、社会的アーキテクチャは専門的にも体系的にも確立されておらず、余地がある。

鈴木  マクドナルドの椅子が座り心地が悪くて冷房がキツいのは客の回転率を上げるためという都市伝説があるが、これもアーキテクトの意志だと思う。管理、コントロールだ。善か悪かは難しい。

伊藤  それを常に日々考えている。はてブは 2008 年 12 月にリニューアルしたが、それ以前は IT 系の記事が上がってくる場所と認識されていた。リニューアル後は「IT に偏っている」という声が聞かれなくなった。それは、トップに IT 系の話題をたくさん出さないようにしたから。それがだんだん浸透してくると、相乗効果で非 IT のユーザーも入ってくる。善か悪かというと、結果的によければ善。道徳的な話にもなってくる。グーグルの広告位置も同じ話。

江島  政治家がやっているような制度設計みたいなことをサービスでやっているんだという印象。SI のジレンマは、作って終わり。その後の人の動きを見ていないので学ぶ機会を失っている。

小野  ビジネスというか、お金の流れが変わってきている。最近は、最初は無料で使ってみて、使いにくければ終わり。基本的なユーザビリティの整備が遅れている。企業システムでもクラウドでちょっとお試ししてもらうというようにすれば、試されて比べられるようになる。

伊藤  ソーシャルウェアのようなものを作ったとして、人の流れをコントロールするのは誰の仕事? デザイナー?

小野  そこはコンサルタントはいない領域。UI にもコンサルがいるが、一般的なユーザビリティのコンサルでしかない。

伊藤  体系的な知識というのは確実にあるので、自任している人はコンサルになれるかも。

小野  ソーシャルウェアのデザインで成功した人がアドバイスするというの人が出てくると面白いと思う。一方で、流れが変わったサービスというのを私たちは触れている。そういうのに慣れてくると、全体のレベルが上がってくる。各企業でコンサルのような人が育ってくるのでは。

伊藤  ゲーム会社にはそういう人が育っていそうだ。RPG が面白そうだってことを思いついた人は凄いと思う。

小野  「ブラウザ三国志」って知ってますか。僕が始めたばかりの頃は「こんなのに誰がお金を払うんだ」と思ったが、翌月に 23,000 円払っていた。ビジネスは何に対してお金を払うのかが明確だが、ブラウザ三国志ではそれが曖昧。人の感情を刺激するやり方が変わってきた。ゲーム業界はその辺を取り入れていけば面白いと思う。

伊藤  めちゃめちゃカモにされてるじゃありませんか(笑)。

小野  お金を払って気持ちよかった(笑)。

鈴木  スーパーマリオ Wii は 4 人で進めるのが面白いという友人に「ほかに面白い点は」と聞くと「いや特に……」と言う。よく観察していると、最初はゲームが簡単だから喧嘩しながら進められるが、だんだん難しくなると協力せざるを得なくなる。難しいところを協力して進めて兄弟が仲直りする。任天堂の考えは凄いなと思う。

伊藤  任天堂はゲームの設計はデザイナーがやっているらしい。

鈴木  個人の資質の話になると思うが、センスの善し悪しは話していて分かるか。

伊藤  ユーザーに感心がある人はセンスがあることが多い。エンジニアリングが得意という人と、サービスが得意という人は分かれる。どっちも、という人はあまりいない。

江島  メンタリティが違うというか、共存できない。両方足を突っ込むのがしんどい世界だと思う。

小野  友達でゲーム会社の社長をやっている。スーパーマリオがジャンプするプログラムをゼロから作らせるとその人の実力が分かるらしい。あのマリオのジャンプはものすごく計算されている。

鈴木  社内で入社試験とかテストとか考えたことあります?

伊藤  入社時にプレゼンテーションはしてもらう。2〜3 週間かけて自社のフレームワークを使ってプログラムを作り、先輩からボコボコにされる演習があるが、そこでウチの設計、アーキテクチャを覚えてもらう。そのうち、作ってきたものでその人の適性が分かるようになった。

小野  ひとつはコーディング面接。エンジニアのレベルのバランス感覚はそこで分かる。ウチはペアプロをよくやっているが、ペアプロで「ここでこのデザパタを使いたい」と言われても「後で読みにくいよね、変えにくいよね」と。その判断基準は情報。ペアプロはその情報を自然に提供する場でもある。情報によってバランス感覚が蓄積されることもある。6 ヶ月ペアプロだけというペアプロ原理主義をやったことがあるが、結果的にはよかった。マニュアルを書くのもペアプロ。最初半年くらいやっていれば、あとは同じ感覚で仕事ができるようになる。

江島  同じチームのメンバーは優秀なので、入る時点でリリースしたプロダクトがある。ペアプロは苦手。疲れません?

小野  疲れるけど、カッコつけるでしょ? いつもなら普通に終わらせるところを「今回はこんなことをやってみるか」とやって、それがうまくいったり。

鈴木  ペアプロで設計がキレイになりませんか。

小野  それはある。ウチはキーボードに張り付いていなくてもいいので、ホワイトボードに「ペアホワイトボードライティング」(笑)。

伊藤  一貫性は一人に任せるのが一番いいが、ペアプロではそれがゆらぐことがある。センスのいい人にフレームワークを作らせて、その後でペアプロをする。

小野  ウチでは対等でないペアプロ。ベテランと新人とか。いいメソッドの名前を競争で決めさせるとか(笑)。ゲーム性を取り入れて。

鈴木  みんな価値観が似てると思った。この 3 人を選んだ基準は、僕を含めてややナルシスト(笑)。ブログに書かずにいられない自分。プラス、エンジニアリングが分かってて、コードだけじゃないこだわりがある人。そう言う人は、大きな意味でのアーキテクチャが分かっている人だと思う。会場からの質問があれば。

suno88  「こういうものがほしい」と思ったら、既存のものを探すか、それとも真っ先に手を動かして作るか。

小野  「あるものを使ってないものを作る」というのが自分の考えなので、あるものを利用する。

江島  同じく。ビジネスは付加価値の世界だから、すでにあるのにそれを利用しないということは考えられない。

伊藤  費用対効果を考えると、フレームワークを作るには一ヶ月くらいだから、自分は作らせる。自分たちで作ったものは自分たちでコントロールできるのが強み。「こういうことをやりたいが、できるか」という場面で、できるできないが即答できる。

鈴木  伊藤さんの言い分も分かりつつ、最近のフレームワークは多様性を認める方向で作られている。

江島  作られていない車輪はまだたくさんある。例えば、1 分未満の間隔で自動実行させるには cron ではできない。そういうホワイトゾーンのような場所は結構あると思う。

あと 1 人、会場からの質問が出ましたが、あえなくここでパソコンのバッテリーが上がってしまいました。どなたか補足をお願いします。