scroll スクロール wheel スクロール BPS BPS ruby Ruby on Rails php php icon-web-marketing Webマーケティング icon-design デザイン icon-manga 漫画翻訳 icon-epub EPUB 電子書籍 icon-app アプリ開発 icon-recruit 採用情報 local-menu MENU icon-arrow icon-check-board テスティング icon-file 開発するシステムの概要 icon-schedule 開発時期 icon-wallet 予算 icon-pc 使用環境 icon-pin 特殊な仕様 icon-mail お問い合わせ icon-pencil ENTRY icon-bottom-arrow icon-plus +

ACHIEVEMENT100例以上の Ruby on Rails 開発実績

Ruby on Rails の開発なら
実績豊富なBPSにお任せください

私たちは開業時の2007年から、ホームページ制作をはじめとする100例以上のさまざまな問題をサポートしてきました。また、W3CとかRWCといった、Webの未来を見据えた活動にも積極的に取り組んでいます。Ruby on Railsの最新バージョンへのご対応もBPSにお任せください。

実績
実績

主な取引企業様

Ruby on Rails 開発で関わった企業様の一部をご紹介します。

  • 家庭教師のトライ

    トライグループ 様

    カテゴリ基幹システム

    基幹業務に沿った業務支援システムを提供。各種情報管理、データの出力、データのインポートにも対応。さらに他システムとの連携にも対応。

  • 慶応義塾大学

    慶應義塾大学 様

    カテゴリスマホ連携APIサーバ

    機器情報登録システムを提供。UPnP経由で機器情報を取得し、バーコードを発行し、バーコードをAndroid端末で読み込んで登録するといった特殊なフローに対応。

  • 兼松コミュニケーションズ

    兼松コミュニケーションズ 様

    カテゴリ業務システム

    レンタルCDリクエストシステムを提供。FaceBook APIと連携し、FaceBook経由で情報のやり取りが可能。

  • サイバーエージェント

    サイバーエージェント 様

    カテゴリコンテンツ配信システム

    コンテンツ配信サーバを提供。DRMにも対応。さらにブラウザビューアにも対応。

  • 大手印刷会社

    大手印刷会社 様

    カテゴリ業務システム

    デジタルアーカイブシステムを提供。全文検索エンジンSolrを使い、大量のデータを高速で検索することを実現。

  • 東京大学

    東京大学 様

    カテゴリスマホ連携システム

    情報可視化システムを提供。位置情報と環境音をAndroidで収集し、Web上で地図上にマッピングといったAndroidとの連携に対応。

Ruby on Rails 開発実績

BPSのRuby on Rails 開発実績をご紹介します。

ADVANTAGEBPSでRuby on Railsの開発をする強味

Ruby on Rails のご要望にお応えします

以下の様なことでお困りでしたらお問い合わせください。

  • 既存システムがRailsで構築されているが、アップデートに対応できない
  • 自社で立ち上げるプロジェクトにおいて、要件定義や設計などにRailsのプロフェッショナルに参画してほしい
  • 自社システムが開発会社によってRailsで構築され、課題があるが解決策が見出せない

BPSの4つの強み

Ruby on Rails開発におけるBPSの強みをご紹介します。

  • 1

    プロジェクトオーナーシップ

    弊社の開発チームはお客様とのヒアリングを通じて「何のためのシステムか」を重視した開発を行います。機能面だけ見ると一見同じようなシステムに見えても、どのようなビジネスの中で使われるのか、利用者はどういう人がいるのか、システムの目的は何なのかによって作るべきシステムのあり方は変わってきます。 開発コストや利便性の観点から機能の追加だけでなく削除や代替手段のご提案も含め、技術的により良い方法があれば率先して提案することでより価値を生み出すシステムの開発を目指します。

  • 2

    多様なスキルを持つ少数精鋭志向

    プロジェクト開発チームは少なくて2名程度で、多くても10名を超えることはまずありません。システム開発には設計・デザイン・コーディング・インフラなど様々な役割が必要ですが、人数が増えすぎると管理するためのコミュニケーションコストが肥大化しがちです。
    弊社ではエンジニアごとの専門領域はもちろん、周辺領域も含めて広くカバーできるメンバで対応させて頂きますので「持ち帰って確認させて頂きます」となる機会をなるべくなくすようにしています。
    一方、少数精鋭志向でありながらも複数人での体制を組むことで、不慮の担当者の入れ替わり等が発生してもプロジェクト進行が止まらない体制を構築できます。

  • 3

    お客様のニーズに合わせた成果調整

    新規事業等で速度がとにかく重視されるプロジェクト、ドキュメントや開発体制の手厚さが重視されるプロジェクトなど、求められる成果物や納期、品質のトレードオフの重心は様々です。
    弊社は創業以来多くの受託開発案件の実績と経験がありますので、様々な要件に合わせて開発体制を構築することができます。
    スモールスタートを想定した新規事業のサービス開発では短い期間単位でのインクリメンタル開発で動く物を重視していくアジャイル方式、深い業務理解が求められる業務システム開発では事前に仕様書レベルでの整合性確認を行いながらドキュメント化していくウォーターフォール開発など、ニーズに合わせた進め方、成果物の作成に対応させて頂きます。

  • 4

    より良い技術を採用し、常に成長していくことによる効率化

    Web業界は技術やデザイントレンドの移り変わりが早く、エンジニアにも常に成長が求められます。
    弊社では常に新しい技術情報をキャッチアップしつつ、その技術がプロジェクトで利用可能かどうかを検討する活動を継続的に行っています。
    週1回定期開催の社内勉強会や[技術ブログTechRacho]を通じてインプット・アウトプットを継続的に行っていくことで、新しい技術の取り入れだけでなく長く実績のある技術のフォローアップもしています。
    古く実績のある技術から新しい技術まで含めた数ある選択肢の中で、その時そのプロジェクトに最も効果的な選択をすることが、効率の良い開発に繋がっていきます。

CONTACT

BPSへRuby on Rails に関するお問い合わせはこちらから
気軽にお問い合わせください

お問い合わせはこちら

Why Ruby on Rails ?なぜ、Ruby on Rails なのか。

Ruby on Rails とは

Ruby on Railsは、WEBアプリケーション開発のためのオープンソースのフレームワークです。フレームワークとは、アプリケーションの土台として機能するソフトウェアのことで、アプリケーションソフトを開発する際に必要とされる汎用的な機能をまとめて提供するものです。
Ruby on Railsは、「初期の開発速度」・「納入後の保守性」・「運用中の柔軟性」をバランスよく高い水準で維持できる開発フレームワークで、海外ではすでにスタンダードになりつつあります。日本でも楽天やニフティ、カカクコムなどの有力企業が次々とRuby on Railsを採用しており、クックパッドや食べログのようにRuby on Railsを全面的に採用している企業や、富士通や日立グループのようにRuby on Railsを採用した大手システムインテグレーターも出現しています。
Ruby on Railsを適切に導入すれば、フレームワークに集約された膨大なオープンソース資産の上にアプリケーションを構築することができ、それによってコード量を大きく減らすことができます。その代わり、それらの資産を活用するためにWEB開発の経験に加えてデータベースからネットワークやサーバ周りまでの広範囲にわたる知識が要求されるため「新規参入者にとってはハードルが高い」という問題があります。弊社ではRuby on Railsを全社的に採用し、教育方法も確立されているため、高度なレベルで安定した開発を行うことができます。

Ruby on Rails の優位性

開発スピード

Ruby on Railsでは、徹底した DRY※1と CoC※2の原則により、新規に書くコードを最小化し、最大限のスピードで開発できるように設計されています。弊社ではさらに、多くのライブラリとバージョン互換性のノウハウ、カスタマイズしたソースコード自動生成技術の採用により、標準的な機能を高速に開発できる環境を整えています。

保守性

DRY原則と TDD※3により、変更に強いシステムを実現できます。スケールアウトも容易で、リリース後の追加開発・仕様変更にも効率的に対応できます。

柔軟性

世界規模で活発に更新されているライブラリ群を利用し、最新のトレンドをいち早く取り入れることができます。また、運用の都合に合わせて、開発体制を柔軟に変えながら対応していくことができます。

※1. DRY : Don't Repeat Yourself

※2. CoC : Convention over Configuration

※3. TDD : Test Driven Development

Ruby on Rails Other Framework
プログラミングの歴史における Ruby on Rails
1999〜2002
原始時代
開発言語
Perl, PHP(3,4)、JSP
問題点
冗長で拡張性のないコードが量産されたため管理コストが高い

PEAR、CPAN といったサービスや、パケージ管理システムである rubygems、mojavi、agavi、Maple、Ethnaといったフレームワーク登場によりプログラミングは戦国時代へ

2003〜2006
戦国時代
開発言語
Class対応したPHP4,5
問題点
多数のライブラリ、フレームワークが登場したが、いずれも熟練度が低く、まだデファクトスタンダードが存在しないため安定的な開発が難しい

Symfony、Zend Framework、CakePHPといったデファクトスタンダードフレームワークが登場し、ライブラリも過渡期を過ぎて安定したことにより、現代のプログラミング環境へ

2007〜現代 フレームワークを使ったプログラミングが主流になり、その中でもデファクトスタンダードとして信頼がおける開発手法であるRuby on Railsを弊社のメイン開発手法として採用

ただしRuby on Rails にも「新規参入者にとってはハードルが高い」という問題があります。弊社ではRuby on Railsを全体的に採用し、教育方針も確立されているため、高度なレベルで安定した開発を行うことができます。

お客様が求めているものをイメージ通りに実現するための工夫

エンジニアが同席するだけでは足りないこと?

お客様が本当に必要なものを開発することが難しいのは、思いのほか「考えていることを伝える」ことが簡単ではないからです。弊社では要件のヒアリングをエンジニアが行った上でさらなる工夫を加えています。

準アジャイル方式で「開発状況・進捗」がわかる

要件を実現するのに重要なのは「作りながらお客様に確認いただくこと」ですが、短い開発期間の中でこれを行うには高い技術力が要求されます。弊社では、2007年から培ってきたRuby on Railsでのシステム開発実績に基いて順アジャイル開発を実現いたします。

まず開発システムをある程度の大きさの機能に分割します。次に分割した機能を1〜2週間に1度程度の周期でお客様にご確認いただきます。開発状況を短いスパンでお客様に把握いただくことにより、最終段階になって「イメージと全然違う」という状況を避けることができます。

チェック回数が増える分お客様のご協力が必要となりますが、プロジェクト自体の納期や要求の変更に対して柔軟に対応することもできるようになります。

ビジネス上の課題を把握した上で判断する

さらに、弊社では既存のプロダクトを利用したり、既存のサーバ設定の組み合わせで同等機能を実現したりすることも選択肢に含めています。私たちは「無駄な開発」や「車輪の再発明」を行いません。既存のWordPressやEC-CUBE等のCMS、静的HTML等の組み合わせてシステムを構築することも可能です。まずは弊社のエンジニアにご相談ください。その場合の制約条件などについても説明いたします。

Ruby on Rails開発における
弊社の技術について新技術を積極的に取り入れることによる開発効率の持続的な改善!

新規参入の難易度が高い技術を長年メインで採用してきました。

2011年以降、新規のWebシステム開発は原則Railsを用いて開発しています。2007年よりメイン技術として開発実績を積んできた結果です。
Railsを使ったシステム開発は、従来の開発言語・フレームワークに比べて著しく開発速度・品質を向上させることが可能です。また、フレームワークレベルでエンジニアごとの癖を吸収できるため、以後の保守が比較的行い易い傾向にあります。

情報収集と検証を常時行う技術力が強みです。

Railsとその周辺ライブラリ技術は数ヶ月も経つと状況が変わっていることも多いため、持続的な情報収集が欠かせません。
弊社では積極的な情報収集を行い新技術の情報を集めると共に、検証を行っています。もし利用中のライブラリに問題があれば、ライブラリのコードを解析してバグを修正するなどの対策を適宜行っています。公開可能な内容については弊社開発ブログ(https://techracho.bpsinc.jp/Githubなどで情報公開を行っています。

アプリケーションだけでなくサーバ構築・保守も一括でご提供

AWSを使ったスケールアウト可能なサーバ環境のご提案!

弊社ではお客様向けのサーバー環境にAWS(Amazon Web Service)を採用しています。これによって、障害耐性が向上するだけでなく、必要に応じてスケールアップ、スケールアウト可能な環境をご提供可能です。
サーバのレンタル費用の面だけでなく、障害発生時の対応コストや日々のメンテナンスの容易性からも、特に理由が無ければAWSのご利用をおすすめしております。AWS以外にレンタルサーバ・オンプレミス型などをお考えの場合にも対応可能ですので、ご相談下さい。

※スケールアウトにはシステム側の対応が必要なため、大規模サイトをお考えの場合は事前にご相談下さい。

Railsサーバーの構築・運用のノウハウを社内に蓄積しています

Rails自身が絶えず進化し続けていることもあり、Railsを使ったWebアプリケーションの保守は通常のサーバ保守会社では手に余ることがあります。弊社ではサーバ構築から以後の保守・運用(死活監視・セキュリティアップデート・負荷モニタリング)までを自社スタッフで対応できるため、Railsサーバ運用のノウハウがあります。

※ご予算に合わせて保守なし・構築済みのサーバを納品するなどの形式も選択可能です。

Railsサーバ以外についてもご相談下さい

Railsサーバ以外にもCakePHP,Wordpress,Sinatra等のその他フレームワークについてもご相談下さい。

Webサーバ以外の構築についても対応致します。

  • DBサーバ
  • DNSサーバ
  • FTPサーバ
  • LDAPサーバ
  • Proxyサーバ
  • メールサーバ
  • 監視サーバ
構成管理を自動化し、構築作業の省力化

Railsサーバは構築する多くのソフトウェアと連携する必要があり、ソースコードを置くだけで動作するものではありません。

弊社ではサーバ構築をプログラミングによりコード化(Infrastructure as Code)し、属人性の排除とミスの軽減に努めております。

弊社ではサーバの構成管理ツールにansibleを採用しております。

※ご要望があればchefによる構成管理も可能です

サーバ監視ソフトウェアによる障害の検知と負荷対策

サーバ監視ソフトウェアにnagios3を採用し、サーバの状態を監視しています。

サーバに異常があった場合はお客様に連絡するとともにし、速やかにサービスが回復するよう努めています。

サーバの負荷状態も監視していますので、サーバの負荷が高い状態が続いた場合に負荷対策のためのスケールアップ、スケールアウトの提案も実施しています。

システムに合わせた最適なバックアッププランのご提案

システムに応じて使用できる機能や負荷のかかる時間帯が異なります。

また必要なデータをどのくらいの間隔でバックアップするかも重要です。

規模・構成に合わせたシステムバックアップ、データバックアップの提案と実施をしています。弊社では開発から運用までを担当しているのでより最適な提案が行えます。

DEVELOPMENTBPSでRuby on Railsの開発について

弊社WEB開発チームについて

弊社のWEB開発チーム編成をご紹介します(2014年2月現在)

統括・リーダー
2名
開発エンジニア
5名
インフラ・サーバーエンジニア
専属1名、兼務2名
チーム編成のコンセプト

弊社の準アジャイルな開発体制の基本となる思想は「アジャイルサムライ」に由来します。Ruby on Railsという強力なフレームワークの特長は、アジャイルサムライが掲げる理想的な開発の具現化においてさまざまな点で有利に働きます。

  • 実際に動くプロトタイプを素早く作成できる
  • 少人数での大規模開発が可能
  • 開発用ドキュメントの量が少なくて済む
  • ビジネスロジックと画面表示の実装に集中できる
  • 進歩が早く、新技術を取り入れやすい

Ruby on Railsエンジニアの業務範囲

既に述べましたように、弊社のRuby on Rails開発チームのエンジニアは基本的に担当するプロジェクトのすべてをケアします。「これは私の業務ではない」のような線引きは行いません。開発・実装のみならず、他のプロジェクトメンバーの仕事であっても、お客様側の業務内容であっても、気になる点がありましたら率先して相談いたします。 一人のエンジニアは、Ruby on Rails開発を含む以下の業務を担当します。

プロジェクト開発業務
  • お客様へのヒアリング
  • 必要要件の洗い出し
  • システム設計
  • 必要工数の見積り
  • 初期全体イメージ設計(ワイヤーフレーム、サイトマップなど)
  • Ruby on Railsを使用した開発・実装・テスト
  • お客様との調整(詳細仕様の確認、必須な資料の請求、動作確認依頼など)
  • 開発進捗をお客様と共有(RedmineやGoogle Driveなどを使用)
  • ドキュメント作成
  • エンジニアの立場からシステム改善提案
WEBサイト・サーバー
保守業務
  • HTMLコンテンツ更新作業
  • 障害対応・復旧(サーバー障害・プログラムバグによる障害など)
  • お客様への連絡
プロジェクト
以外の業務
  • 社内で有用な技術の共有
  • 社内システム開発による業務改善
  • 社内サーバ作業による業務改善
  • TechRacho記事の執筆
Ruby on Rails開発には、さらに以下の作業も含まれます。
  • ワイヤーフレームからrapid prototyping(Bootstrap3などを使用)
  • デザイナが作成したデザインイメージのHTMLコーディング、画像切り出し
  • 既存システム・連携システム対応
    • 使用調査 / 把握
    • 移行仕様検討
    • 移行スクリプト作成
  • 機能開発 / テスト
  • staging / 本番サーバの整備、deployスクリプトとdeploy手順の作成
  • 開発をスムーズに引き継ぐための資料作成(READMEなど)
開発ドキュメントこそ命

Ruby on Railsは少人数での大規模開発が可能であり、エンジニアは全方位的に業務を担当するため、エンジニア一人あたりの裁量範囲が大きくなります。そのため、作業の分担・環境の構築がいつでもできるように常に開発用ドキュメントを整備しておく必要があります。適切なドキュメントがないとRuby on Railsの長所の多くが失われるため、弊社では開発用ドキュメントの整備を必須作業としています。

エンジニア個人のノウハウがドキュメント化されないまま、再現不可能な「秘伝のタレ」と化し、他のエンジニアが参加するときに障害となることのないように、秘伝のタレを管理し、開発者が確実に利用できるようにしなければなりません。開発用ドキュメント量が少なくて済むRuby on Railsの特長はこの点においても有利です。

弊社の場合、リポジトリのREADME.mdをRuby on Railsの開発ドキュメントとして定めており、これに従えばいつでも開発に参加できるよう、常に最新の状態に保つことを義務付けています。最小限記載されるべき情報は以下のとおりです。

  • Rubyやrailsのバージョン情報
  • DBMSの種類とバージョン情報
  • 開発環境の構築手順
  • 開発資料や運用情報があれば、その場所(Redmine wikiやリポジトリ上の特定ディレクトリ、ファイルサーバーなど)
  • Staging環境のURLとデプロイ方法
  • アプリケーション固有の情報(gemの依存関係など)

言うまでもなく、本番用パスワードなどの重要な情報はリポジトリに含めず、別途管理します。

プロジェクトを予算内で成功させるために必要なことは何か?

ムダな作業が開発コストに直結します。まず開発体制の工夫が必要です。

弊社はエンジニア自身がヒアリングします!

プロジェクトでトラブルが発生するのは、要望を安請け合いする営業スタッフを通して開発者に伝えるからです。弊社では原則として、ご発注頂いた後の要件調査やヒアリングを含む全ての打ち合わせにおいて、コードの書けるエンジニアが同席します。

お客様のアイデア・ご希望が「技術的に可能かどうか」「容易に可能かどうか」を打ち合わせの場で判断しながら進めていくことが重要です。新しいアイディアや改善点の提案を、技術の裏付けを持つエンジニアが直接行うことにより、技術的な最適解をチーム全体で共有しながらプロジェクトを進めることができます。

1〜3名程度の少人数開発

WEBシステムの開発では、人を投入すればするほどムダが増大します。「齟齬のない情報共有」は高度な作業ほど多くの手間を要し、人数が増えた分「作業が止まっている時間」の方が大きくなります

弊社では、営業スタッフを除き、システムの開発にはサーバ構築などの周辺作業も含めて1〜3名程度の少人数で開発を行っています。これによって開発スタッフ間で情報を素早く共有し、情報の齟齬を防いでいます。

豊富な主要開発メンバー

主要開発メンバーにはコンピューターサイエンスの修士号を取得し、慶應義塾大学で講師として現役で活躍する者が在籍しております。

  • 森 雅智

    システム設計・開発、
    サーバ管理・保守 担当

    森 雅智Mori Masato

    さらに詳しく

  • 馬場 孝夫

    Androidアプリ開発、
    Webシステム開発 担当

    馬場 孝夫Baba Takao

    さらに詳しく

WEB開発チームにとってのスキルの維持・育成

WEB開発の分野は日進月歩という言葉にふさわしく、1年も経てばすぐに陳腐化してしまう技術もあるかと思えば、ついこの間まではそんなに話題に上がらなかった言語やライブラリが突然再評価されることもあります。

そんな中で質の高いアプリケーションやソフトウェアを開発していくには、常に新しい技術を追い続け,実際に試してみるというフットワークの軽さが何より重要です。一つの技術に特化して習熟することもエンジニアとして重要ですが、視野を広げて多くの技術を習得することもそれと同じくらい大事です。弊社ではエンジニア各自が自分のアンテナを磨き、新しい技術や手法を持ち寄って使ってみるといったことを積極的に行っています。

新しい技術を採用することで開発速度や品質の向上が期待できますが、そこには常に安定性とのトレードオフがつきまといます。登場間もない技術には未発見のバグが含まれていることがあり、特定環境の組み合わせにおける不具合などに遭遇する機会も多くあります。そのため、実際のシステム開発で新しい技術を採用する際は、これらの技術的リスクを社内で吸収できるかどうかを検討した上で利用しています。

社内での技術情報交換は、フェイス・トゥ・フェイスはもちろんのこと、SkypeのWebチャットルーム、食事しながらなどさまざまな機会で行われています。

Ruby on Rails の標準開発環境

以下は2014年2月時点における弊社のRuby on Rails標準開発環境です。あくまで標準であり、プロジェクトのポリシーによって異なります。

Gitリポジトリ
社内にGitlabサーバーを構築しています。
プロジェクト管理
RedmineまたはGoogle Drive上のスプレッドシート共有を使用しています。
RailsやRubyのバージョン
プロジェクトでの指定に合わせます。新規プロジェクトであればその時点の最新安定版を使用します。
Gitブランチの運用
git-flowに準拠します。ただし他に開発者がいない場合はfeatureブランチを作成せずに直接developにpushすることもできます。
統合開発環境
RubyMineが推奨されています。
CIサーバー
社内にJenkinsサーバーを構築してあり、Gitlabと連携して自動テストが実行されます。
コミュニケーション
Skypeでのプロジェクトチャットルームやメールを使用します。お客様とのやりとりには専用のメーリングリストを設置します。
DBMS
プロジェクトに依存しますが、MySQLまたはPostgreSQLがよく使われます。
テスティング
RSpecを標準として使用します。
コーディングスタイル
Ruby on Railsのコーディングスタイルに準拠します。
MacでのRuby on Rails開発環境例

森 雅智の場合(2013年2月更新)

ソフトウェア環境

Mac環境では、既にUNIXシェル環境が充実しているため、Mac OS X上に開発環境を構築しています。

Rubyはrbenvによりバージョン管理を行い、MySQLやMemcachedといったサービスはHomebrewを用いてインストールしています。

エディタ、開発環境としてはRubyMineを用いています。RubyMineはメモリ消費の激しいIDEですが、非常に正確なコードハイライティング/フォーマッティング、便利なショートカット、SCM連携、ブレークポイントの挿入とステップ実行など、それを補ってあまりあるだけの利点があります。

その他の環境については、基本的に各自の裁量に任されている部分も多いですが、ターミナルは標準ターミナルやiTerm、シェルにはbashやzshが使われています。

一方、システムによっては連携するソフトウェアがLinuxでしか動かないケースや、より動作環境を合わせるために本番環境と全く同じ環境を設定したいこともあります。その際にはVMWare FusionやVirtualBoxを利用し、VM上に環境を構築します。

弊社内でのMac利用率は30%程度ですが、チーム開発ができるという条件の下に、各自の最も効率の良い開発環境を構築し、更新を行っています。

利用技術等

新規プロジェクトでは、基本的にRailsの最新版を利用しています。現在は4.0.2です。Rubyは2.1系列の最新安定版を利用しています。自動テスト環境を整備し、バージョンアップに追従できるように心がけています。DBはMySQLを標準で採用しています。希に、キャッシュ用としてmemcachedやTokyoTyrantを利用することがあります。

自動テストにはrspecを標準採用し、必要に応じてcucumberを利用しています。これらはJenkinsで自動ビルド(コミットごと+毎朝)し、失敗時には担当者にメールが届くようになっています。その他、メジャーなgemを中心に(例:devise, paperclip, resque)利用しています。

デプロイは、capistranoを標準的に利用しています。capistrano-extを利用することで、ステージング環境、本番環境などに効率的に配信することができます。また、開発環境には、リポジトリへのpushを検知して自動デプロイする環境も構築しています。

また、ほとんどのプロジェクトにはairbrake等のエラーレポートシステムを組み込んでいます(最近はオープンソースのerrbitに移行中です)。これにより、万が一本番環境でエラーが発生しても、即座に開発者にstacktrace付のメールが届くため、迅速な対応が可能になっています。

ソースコード管理はすべてgitで行い、さらに運用ルールは基本的にgit-flowを採用しています。GitHubのオープンソースクローン、GitLabを社内で運用し、管理コストを省いています。issue管理は、redmineで行っています。

WindowsでのRuby on Rails開発環境例

馬場 孝夫の場合(2012年7月更新)

ハードウェア環境

PCが遅いと、Rails開発はかなり苦しいです。私はわがままを言ってかなり良いPCを使っていますが(Core i7-3770K, 32GB RAM, SSD)、specの実行が以前の2倍になって満足です。

社内を見渡しても、メモリ8GB未満のPCは絶滅に向かいつつあるようです。次はHDDブートを撲滅したいです。

また、開発職ならマルチディスプレイは必須です。私は3~4枚を気分で使い分けますが、たまに諸事情からノートPCを横に置くので、最大6画面で作業しています。さすがに机が狭い。30インチWQXGAと20インチUXGA縦を横に並べると、ドットピッチが綺麗に揃うのがポイントです。サブディスプレイにSkypeやターミナルを並べておくと、通知が1カ所に集まって便利です。

入力デバイスはRealforceとSlimBlade Trackball。これしかありません。特にRealforceは、全キー30gタイプです。以前は45gだったのですが、指が痛くなったので買い換えました。トラックボールと合わせ、非常に指にやさしい環境が構築されています。

ソフトウェア環境

開発環境は、各自が最も使いやすいものを利用します。

私はWindowsユーザなのですが、Windows上のRails構築は手間と互換性の面でベストでは無いと判断し、VM上のUbuntu Desktopを利用しています。最近はRubyInstallerなども流行っているようですが、MongoDBやmemcachedを使うこともあるため、Linuxの方が簡単です。BPSでは、本番運用サーバとしてUbuntu Serverを標準採用しているので、日頃からUbuntu上で開発することで、無駄な環境依存問題を排除しています。

IDEはRubyMineを利用しています。これは、主にコードフォーマッターが優秀で、Rubyの複雑な構文を解釈し、適切なインデントやホワイトスペースを設定してくれるので気に入っています。これが無いと「インデントを修正」というコミットが増えてしまうんですよね。あとは、vimのキーバインドが自然に使えるのはかなり助かっています。

Ubuntu上のX(普段はXfce)で作業する場合と、Samba経由でマウントしWindows上のRubyMineで作業する場合があり、これは現在試行錯誤中です。前者の方がデバッガが使えたり機能的にはベターなのですが、後者の方がATOKで入力できるのと、Ctrl+Altを押す必要が無いのでキー操作が1回分楽です。

IDEは基本的にコードフォーマッター用に利用し、SCMの操作やコードの検索などは、ターミナルから利用しています。これは、単に慣れの問題もありますが、日常的にRails本体のソースを検索するにはコマンドの方が都合が良いから、というのもあります。Rails開発の際は、Railsのソースリポジトリを手元に置いておくと、何かと便利です。

ORDER受注から納品までの流れ

Ruby on Rails 開発の流れ

以下の流れで、開発を進めさせていただきます。

お電話・メールにて
お問い合わせください

お問い合わせの際に以下の情報をお知らせください。

  • プロジェクトの目標・目的 / 開発規模 / 開発時期
  • 参考にしたサイト、システム、事例など

初回ヒアリング
〜お見積り

御社または弊社にて、BPSの紹介とともに開発費用および期間のお見積りのために必要な情報をお伺いいたします。費用・期間・参加人数・御社側でお願いしたい内容などをお伝えいたします。

ご発注〜開発

発注後、優先順位の高いものから開発を進めます。
1~2週間ごとに報告を行い、品質をご確認いただきながら、 必要に応じて優先順位や仕様の調整を行います。

検収、納品

開発期間の約20%を検収期間として定めます。
検収期間中は微調整を行いながら設計書などの ドキュメントを整備します。

Ruby on Rails 開発ご発注前の料金のお見積り

開発内容と過去開発実績から、必要な人月(※)を試算いたします。
開発内容を知るために、下記の情報をお伺いいたします。検討時点で既に手元にあるものや、決まっている情報、お答えできる範囲で結構です。
秘密保持契約(NDA)などが必要な場合はお知らせください。

開発するシステムの概要
システムの目的、今回の開発の目標、使用するユーザについて、など。
開発時期
希望開始時期、完了時期、その理由など。
予算
希望価格、上限など。
使用環境
PC・スマホ・タブレット・ガラケーから指定。
特殊な仕様
独自の商慣習やビジネスフローなどに基づいた機能があれば。
機能一覧
想定している機能の一覧またはその資料など(ラフな箇条書きで構いません)。
システム環境
RubyやRailsバージョン、データベースの種類とバージョン、システム環境における制限などの指定があれば。
Ruby on Rails開発見積りにおける人月計算と人月単価について

Ruby on Rails開発では、御社のシステムを開発するために必要な人数×期間(何ヶ月)=人月に基いてお見積りいたします。

人月×人月単価=見積金額となります。
※1ヶ月未満の対応については、人月単価を日割り計算します。

新規開発の場合、人月単価を100万円前後に設定しています。
規模や納期にもよりますが、多くの場合1名が専任で開発し、もう1名が計画や実装内容に漏れがないかを定期的に確認するという構成です。
弊社のエンジニアは全員、フロントエンドのHTML/CSS/JS作成からバックエンドのプログラミング、データベース設計などWEBシステムに必要な作業を1人で行います。

開発の進め方は、1~2週に1度程度の周期で打ち合わせを行い、弊社内で開発を行います(お客様の事務所での出向開発は行っていません)。
打ち合わせ時には、開発進捗の報告、不明点の洗い出し、新規ご要望のヒアリング、優先順位付け(優先順位の変更含む)などを行い、逐次進捗を共有します。

システム開発後の保守については、オプションで定常的なサービスの死活監視やシステムバックアップ作業などを月額料金にて承っております。

Ruby on Rails開発を
ご発注いただく際の注意点
  • 弊社では出向など、お客様の環境への常駐・出向勤務はお受けしておりません。
  • 作画やアートディレクションについては、協力会社様と連携して行っております。
  • お問い合わせ、サポート応対については原則営業時間内にて行っております。

※通常の営業時間外の保守・緊急対応・復旧作業などについては別途ご相談ください。

Ruby on Rails に関してよくあるご質問(FAQ)

Ruby on Rails に関してよくあるご質問にお答え致します。

どんなクライアントの開発を請けていますか?
さまざまな規模のお客様と仕事を行っております。近年の取引先については会社概要を参照ください。
これまでの開発・導入実績はどのくらいありますか?
直近1年間で、約80件前後のシステムを納入いたしました。
エンジニアは何人くらいいるのですか?
社員数20名の会社で、うち17名が開発しています。(2014年2月)
発注の目安となる単価はどのくらいですか?
1人月あたり100万円となります。 1名が開発に集中し、もう1名が計画や実装内容に漏れがないかを定期的に確認する構成です。人月単価の変動条件は、以下のとおりです。
  1. 難易度の高い目標のコミットメントが条件に含まれる場合 (例:主要ページの高速化を依頼いただき、対策前の表示速度が3秒で、設定目標が1秒以内とする)
  2. 進捗管理の打ち合わせが週1以上のペースで行われる場合、優先順位などの変更が週1以上のペースで行われる場合
  3. 弊社が特に伸ばしたい技術要件が含まれている場合
開発の規模や期間はどのくらいかかりますか?見積の例を教えてください
以下の事例を参考にしていただけます。
  1. 例1)デザイン(PSD)がある状態でのクラウドファンディングサイト構築: 2人月
  2. 例2)モバイル向けQ&Aサイトの構築:1.5人月
  3. 例3)7年ほど運用していたECサイトのフルデザインリニューアルとCMSの大幅機能追加と専用デザインのモバイル版開発: 30人月
  4. 例4)不動産物件を管理・紹介するサイトの構築: 2人月
  5. 例5)フランチャイズ店舗のオーナーと従業員の給与を管理する基幹システムを業務フローの変化にあわせて再構築: 12人月
  6. 例6)社内向けプロジェクトの収支管理システムの構築(会計システムなどとの連携含む): 5人月
BPSで開発することの強みは何ですか?
下記に関連したシステム開発は特に多くの実績とノウハウがあります。
  • EPUBを扱うシステム
  • 電子書籍を販売、表示するシステム
  • AWS、Ruby on RailsによるWEBシステム
特に以下の領域を得意としています。
  • 決済を要するシステム(国内外の決済システムをサイトに導入した経験がございます)
  • 高速化を必要とするシステム(アクセスの多いサイトの負荷分散など)
  • 引き継ぎ(他システム会社からリファクタリングを目的とした移行または設計・作り直し)
  • JavaScriptを多用するシステム
  • TDDを必要とするシステム
Ruby on Railsは、Rubyが言語(Excelで言うとVBAのようなもの)で、「on Rails」がExcel(フレームワーク)と考えればよいでしょうか?
この理解で問題ございません。 ただし、厳密に記述するならば、Ruby ->「Excel そのもの」、on Rails ->「見積書など、色々なボタンが組まれているテンプレート」になぞらえられます。Ruby は言語そのものに相当し、良く使われる Ruby の書き方をまとめたものが、on Rails に相当します。なお、Ruby on RailsはしばしばRoRまたは Railsと省略されます。
下位で開発したプログラムを上位のバージョンで実装すると、Railsのバージョンが下位のものと上位のものとでは構造が異なるため、互換性の不具合等が発生する場合があるのは本当でしょうか?
つまり、アップデートする場合に、プログラムの修正が必要となるのでしょうか?
はい。ご推察の通りです。 たとえば、3.0.5 は、すでにセキュリティサポートが切れている状態ですので、バージョンアップをお勧めいたします。
【脆弱性に関する記事】
https://www.oiax.jp/rails/zakkan/how_to_apply_rails_security_updates.htmlを参照ください。
3.0系Railsのバージョンでセキュリティホールがある場合、セキュリティを担保するにはバージョンアップしか方法は無いのでしょうか。
基本的に、バージョンアップが必要になります。 現在、バグが発生した場合にRails 開発者たちによって対策が行われるバージョンは3.2.x と 4.0.x になっており、3.0 系で発見されたバグは対策が行われない状況です。いくつかのバグは手作業で対策可能ですが、システムを健全な状況に保つことはかなり難しい状況です。Rails により構築されたシステムのセキュリティを担保するには、1年に1度程度、他の保守と組み合わせてバージョンをあげることが最も確実です。1年に1度としているのは、Rails のメジャーバージョンアップが現状では年に1度程度発生しているためです。
バージョンアップした場合の工数は再構築をした場合と同じ位必要なのでしょうか。
バージョンアップに必要な工数を判断するには、2つのポイントがあります。

ポイント1

ポイント1は、現状システムのバージョンとバージョンアップするシステムのバージョンの差がどれだけあるかです。例えば、Ruby 1.9 -> Ruby 2.0 は中規模程度の工数、Rails 3.0 -> 3.1 は大規模。Rails 3.2 -> 4.0 は中規模、などになります。中〜大規模の工数は、システム再構築時の半分から同程度、になってきます。

ポイント2

ポイント2は「テストコード」の有無とその品質です。
テストコードとは、システムの機能が当初意図した通りになっているかを確認するためのプログラムです。例えば、あるボタンをクリックした際、どのような挙動になるかを自動で確認することができます。
テストコードが整備されている、という意味は、発注時の要件が自動確認手段として用意されているかどうか、と同じ意味になります。
テストコードがしっかりと整備されている場合、バージョンアップが原因で挙動が不安定になる部分の検知を容易に行なえるため、ポイント 1 で説明した工数をかなり圧縮することができます。
もしテストコードの整備が不十分な場合、例えば Rails 3.2 -> 4.0などのバージョンアップを行なう場合でも、かなり大規模な作業になると考えられます。

Rails で開発したシステムを誰でもアクセス可能なサービスとして公開する場合、前述の通り、バージョンアップが比較的多くなるため、テストコードの整備はかなり重要になってきます。
もし、予算の都合などの関係で、バージョンアップをすぐに行なうことが困難な場合、アクセスできる人を制限するなど、不特定多数によるアクセスを絞り込みながら、テストコード・インフラ・運用体制の計画を立てるという方法も考えられます。
アクセスするユーザーの全体像が把握できないとこれ以上の考察は難しいのですが、セキュリティに関する懸念がある場合、今後の方針を決めるにあたり上記のような対処療法も視野に含めておきたいところです。

「テストコード」についてお尋ねしたいと思います。Rubyでは他の開発案件ではあまり聞かない「テストコード」が存在するようですが、テストコードの品質をどのように判断すれば良いのでしょうか。
テストコードにも設計書の作成が必要なのでしょうか。
テストコードは大きく分けて、シナリオテストとユニットテストがあります。

シナリオテストとは、文字どおりシステムをある使い方に沿って利用できるかどうかをテストする手法です。例えば、あるページにおいて「ボタンAを押すと、Bという結果が表示されること」というシナリオになります。
ユニットテストとは、プログラムの内部メソッド(→関数と大体同義)毎に、メソッドの入力とその出力をテストするための手法です。専門的な表現になりますが、例えば、int hoge(int i)という関数がある場合、i に数値を入力して想定どおりの値が返り値として返されるかどうかを確認します。
シナリオテストについては、開発時の要件にマッチしたシナリオがどれだけ記述されているかを確認する必要があります。シナリオテストの品質を定量的な数値としてとらえるのが難しいので、文章として把握していくことになります。
ユニットテストについては、coverage (カバレッジ) 率で表現します。システムに存在するメソッド・関数の何 % に対してテストが設定されているかという値であり、機械的に算出できます。
テストコードは、web であるか他のソフトウェアであるかどうかにかかわらず、品質を担保するために準備するのが一般的です。
例えば、PHP でのシステム開発や Java でのアプリケーション開発でもテストコードを作成します。テストは人力で行なうこともできますが、自動化することによって確認漏れを減らし、短時間のうちにテストを行なうことができるようになります。
このテストコードがどれだけしっかり作られているかに応じて、バージョンアップやシステムの品質に影響が出ます。予算の関係などでテストコードを十分に準備できない場合、作り直したソフトウェアの確認作業の手間が著しく増加することもあります。

技術ブログ「TechRacho」について

弊社技術ブログ「TechRacho」では、主にRuby on Railsに関する技術情報を発信していますが、それ以外にも個人的なテーマなども随時扱っています。弊社エンジニアのスキルの参考になると思われますので、ご覧ください。
自分が困ったことは、他のエンジニアも困っていることが多いものです。弊社では技術ブログ「TechRacho」での情報発信や、社外勉強会の主催なども行っています。よく言われることですが、自分で情報を発信してみると、説明のために理解の浅かった部分を掘り下げざるを得なくなり、非常に勉強になります。
なお、このTechRachoは、TopHatenarにおいてRuby on Rails部門で第9位にランクインしました。

TechRachoは、TopHatenarにおいてRuby on Rails部門で第9位にランクイン