Skip to main content
Ruby on Railsで変わる
   エンタープライズ
     開発の現場

 株式会社万葉 大場寧子
2009.4.9 QCon Tokyo 2009
Ruby on Rails
✓知っている

✓ 使ったことがある

✓ 自社システム

✓ 受託開発案件
今日のテーマ

   Railsを
エンタープライズで
  普通に使う
Railsの採用
•本当に使える?

• メリット

• リスク

• 成功させるコツ
自己紹介

•大場寧子

• Award on Rails
 2006 大賞

•株式会社万葉
小槌
アカウント間で連携する
   Web家計簿
Rails歴
•2006∼2009

• 15人くらいまでのチー
ムで開発

•
SNS、旅行、EC、業務
系など
逆引きクイック
 リファレンス

  • RoR開発の実践逆引き辞典
  • 毎日コミュニケーションズ
  • 532p
  •3675円
2つの視点

•経営者

• プログラマ
ビジネス寄り

•JavaからRubyへ

• 元々軽量言語が好き
だったわけではない
Railsは本当に
  使える?
プログラマの主張

Rubyは
 楽しい
警戒される

楽しい = 怪しい
リスク
リスク

•Ruby大丈夫?

• エンジニア確保?

• 楽しいだけじゃ困る
楽しさとリスク
•
楽しくない言語Xに
関するリスク

•
楽しい言語Yに関す
るリスク
楽しさとリスクは
あまり関係ない!
楽しさの前に

•楽しさは結果である

• 結果には理由がある
理由は
つながっている
経営者がRailsを
使う3つの理由
早いリリース

•約束されている

• 期待できる
早いリリースの実現度
 スキル
  &    成功
ノウハウ



        失敗

        システムの規模・複雑さ
早いリリースが
  期待できる理由


•コード量が少ない

• コンパイルを待たない
コードが少ない

•Rubyの特徴

• 人間志向

• 型宣言なし
Rubyは柔軟


•壁を迂回しない

• 本質を書くだけ
ある種の言語
悲観的
  性悪説
高い堅牢な壁
Rubyの風景
楽観的
性善説
 自由
Railsは
少ないコードで
  書ける
Railsとコード量

•豊富な機能

• 規約の活用

• DRY
DRY
•Don t Repeat
Yourself

•
同じことをあちこち
に書かない
Ruby     Rails
•   打鍵数が少ない

• 把握すべきコードの絶
対的文字数が少ない

•   時間的に有利!
コンパイルを
     待たない

•
書いたコードがそ
のまま実行される

•すぐ確認できる
コンパイルを
 待つのは辛い

•思考の中断

• 待ち時間にほかのことを
始める
集中がとぎれる

  •  フロー状態

  • 中断されると、再開
    に15分かかる
Tom DeMarco & Timothy Lister Peopleware - 2nd
        Edition Productive Projects and Teams
Rubyなら
•最小限のコードで

• 素早く確認しながら

• 動くものが早く出来
上がる
ビジネス価値

•すばやく立ち上げる

• プロトタイピング
安く開発
本当に?


•   ある程度YES
安く開発の成功度
 スキル
  &
       成功
ノウハウ


        失敗

        システムの規模・複雑さ
少人数での開発
     少人数でも
  開発体制、手順と
 Railsの組み合わせで
大規模開発に匹敵できる
誤解

Javaで作るのと同じように
 Rubyで作ったら安くなる
安さの源
 Ruby、Railsの生産性
 Railsのコストパフォーマンスを追求
 プログラマが楽しい
 単価




 ※注)脳内イメージです
Railsの生産性は、
ある種の領域で高い
イメージ
 Railsの恩恵    コスト




よくある要件      完璧さ
変更に強い
変更に強いことの
  ビジネス価値

•ニーズへの素早い対応

• 小さく始めて育てる

• システムの寿命を長く
変更に強い理由

•Ruby

• Rails

• 文化
Ruby

•
変更を阻害する壁が
低い

•   読みやすく書ける
Rails
•   DRY

• どこに何が書いてある
べきか決まっている

•   DBの管理がしやすい
RDBのくびき
 からの解放
文化

•変更を嫌がらない

• どんどん変える

• 進化が早い
ただし
特性を活かすか
  殺すかで
結果が変わる
ほかのメリット
•環境構築が簡単

• エンジニアが育つ

• カスタマイズできる

• 複雑なものを作るのに向く
環境構築が簡単
•フルスタック

• DBツール、テストの
仕組み、ログ、国際化
etc
これだけ

> rails MyApp
エンジニアが育つ
     Railsには
   開発に関して良い
     とされる
   プラクティスが
   詰め込まれている
Railsを学ぶと

良いとされている
開発の考え方を
 同時に学べる
エッセンスの例
•MVC

• DRY, CoC

• O/R Mapping

• TDD, BDD
カスタマイズ

 フレームワークに
  不満があれば
 自分でカスタマイズ
複雑なものを
作るのに向く
軽量言語の
一般的イメージ
•手軽

• 簡単なもの向き

• 複雑なものは無理
Rubyは

•オブジェクト指向

• 構造化しやすい

• 複雑化に耐える
イメージ
コスト




             複雑さ
メリットの1つ


•   プログラマが楽しい
ポール・グレアム

素晴らしい仕事をするには、それをするのに
無理をする必要がないほどに好きなことを何
か見つければいいからだ。


      「How to Do What You Love - 好きなことをやるには」
         http://www.naochan.com/deprecated/2006/01/19/
情熱
Rails のリスク
Railsのリスク

•高負荷

• 可用性

• 速度
工夫できる

•分散

• shared-nothing
方式
COOKPAD
頻繁な
バージョン
 アップ
ついて行く?

•作業が発生

• 新しい不具合

• 知識が固定化しない
困る点
•
日本語の書籍や情報
が追いつかない

•
プラグインが死亡する
リスク
エンジニアの
  調達
認定試験

•Ruby技術者認定試験

• 2007年10月に開始
Rails活用のツボ
取捨選択
•80%達成で満足する

• レールに乗る

• こだわりは追求する
戦略的な選択
 Railsの恩恵    コスト




よくある要件      完璧さ
開発手法
•   アジャイル

• リズミカルに積み上
げる

•   テスト駆動開発
レイヤーで
担当者を分けない
レイヤーで分けると

•設計する人
•実装する人
 •ビジネスロジックを書く人
 •画面まわりを書く人
•テストする人
せっかく
Railsなのに
Railsでは

•設計と実装が地続き

• 行ったり来たりする

• それが効率的
レイヤーごとに
 分断するのは
  大きなロス
どうするか
•   機能で分担

• 全員、設計からテスト
まで担当

•   すべて他人と共有
開発体制の例
•ペアで開発する

• 4人くらいまでを1ユ
ニットとして、ユニット
を増やす

•担当を固定化しない
文化

•良い名前をつける

• コードをDRYにする

• 多様性
名前づけ
•時間をかけてよい

• 皆で決める

• もっといい名前が
あったら変える
DRY

•日常的に目指す

• 2回目が重要
多様性
•
強制はRubyの柔軟
性・楽しさを殺す

•
方向を決め、やり方
には多様性を持たせる
変更しやすくする

•DRY

• 名前

• 適切なところに書く

• シンプルなほうを選ぶ
変更しやすくする

•適切な単体テスト

• 変更を歓迎する文化

• git, SVN等を使う
変更しやすくする
•リリース工程の自動化

• 継続的インテグレー
ション

•   CruiseControl
リスクへの
 目配り
パフォーマンス
•セッションの使い方

• キャッシュを意識する

• ActiveRecord

• 分散
情報の入手
•書籍

• インターネット

• 英語で調べる

• コミュニティ参加
バージョンアップ




ついていく
バージョンアップ
•速くなる

• コードが少なくなる

• 最新の技術

• 最新の考え方