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 +

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

Ruby on Rails とは

Ruby on Railsは、WEBアプリケーション開発のためのオープンソースのフレームワークです。フレームワークとは、アプリケーションの土台として機能するソフトウェアのことで、アプリケーションソフトを開発する際に必要とされる汎用的な機能をまとめて提供するものです。
Ruby on Railsは、「初期の開発速度」・「納入後の保守性」・「運用中の柔軟性」をバランスよく高い水準で維持できる開発フレームワークで、10年以上にわたり活発な開発が行われており、世界中で圧倒的な人気を誇ります。日本においても、スタートアップはもちろん大手企業での採用実績が増加しています。
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〜2010
普及期
フレームワークを使ったプログラミングが主流になり、Webシステム開発の体系化が進む。大規模システムや基幹業務システムにも軽量言語の採用が増加。弊社ではデファクトスタンダードとして信頼がおける開発手法であるRuby on Railsをメイン開発手法として採用

クラウドの普及とスマートフォンの台頭により、Webは新たなステージへ

2011〜2014
新時代の幕開け
スマートフォンの爆発的な普及により、Webに求められるものが変化。同時期にクラウド技術の活用も進む。Ruby on Railsではマルチプラットフォームに適した先進的な機能をいち早く標準搭載するなど、積極的な進化が続く。

時代の変化に対応できないフレームワークの淘汰が進むとともに、フロントエンド技術の進化が加速する

2015〜現代 バズワードとなったHTML5をきっかけに、Webのアプリケーションプラットフォーム化が進む。Ruby on Railsは新しいトレンドを常に取り入れて進化を止めない。

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

DEVELOPMENT BPSでRuby on Railsの開発について

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

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

統括・リーダー
3名
開発エンジニア
15名
インフラ・サーバーエンジニア
兼務3名(全員AWS認定エンジニア)
チーム編成のコンセプト

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

  • 実際に動くプロトタイプを素早く作成できる
  • 少人数での大規模開発が可能
  • 開発用ドキュメントの量が少なくて済む
  • ビジネスロジックと画面表示の実装に集中できる
  • 進歩が早く、新技術を取り入れやすい
Ruby on Rails開発における
弊社の技術について 新技術を積極的に取り入れることによる開発効率の持続的な改善!

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

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

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

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

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

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

プロジェクト開発業務
  • お客様へのヒアリング
  • 必要要件の洗い出し
  • システム設計
  • 必要工数の見積り
  • 初期全体イメージ設計(ワイヤーフレーム、サイトマップなど)
  • Ruby on Railsを使用した開発・実装・テスト
  • お客様との調整(詳細仕様の確認、必須な資料の請求、動作確認依頼など)
  • 開発進捗をお客様と共有(RedmineやGoogle Driveなどを使用)
  • ドキュメント作成
  • エンジニアの立場からシステム改善提案
WEBサイト・サーバー
保守業務
  • HTMLコンテンツ更新作業
  • 障害対応・復旧(サーバー障害・プログラムバグによる障害など)
  • お客様への連絡
プロジェクト
以外の業務
  • 社内で有用な技術の共有
  • 社内システム開発による業務改善
  • 社内サーバ作業による業務改善
  • TechRacho記事の執筆
Ruby on Rails開発には、さらに以下の作業も含まれます。
  • ワイヤーフレームからrapid prototyping(Bootstrap4などを使用)
  • デザイナが作成したデザインイメージの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の依存関係など)

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

豊富な主要開発メンバー

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

  • 森 雅智

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

    森 雅智 Mori Masato

    さらに詳しく

    IPA 2007年度未踏ソフトウェア創造開発事業共同開発者
    大学非常勤講師として8年間コンピュータサイエンスを担当
    Web開発経験15年以上
    テクニカルエンジニア(ネットワーク)
    AWSソリューションアーキテクト(アソシエイト)
  • 榊原 寛

    取締役

    榊原 寛 Sakakibara Hiroshi

    さらに詳しく

    慶應義塾大学 環境情報学部 非常勤講師
    慶應義塾大学 SFC 研究所 訪問上席所員
    W3C AC Representative
    多数の学会活動、セミナー講師、標準化活動などを経験
  • 馬場 孝夫

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

    馬場 孝夫 Baba Takao

    さらに詳しく

    Webシステム, モバイルアプリを含め総合的に担当
    技術士(情報工学)
    情報処理技術者試験(全区分)
    AWSソリューションアーキテクト(アソシエイト)
  • 福原 健吾

    Webシステム開発 マネージャ

    福原 健吾 Fukuhara Kengo

    さらに詳しく

    大手システム開発会社出身
    IT企業を上場に導いた実力者
    情報セキュリティ、内部監査
    自治体向けシステム開発
  • 誰か

    Webシステム開発 マネージャ

    伊藤 未吏 Ito Misato

    さらに詳しく

    製造業、金融業のシステム開発を多数経験
    情報処理安全確保支援士
WEB開発チームにとってのスキルの維持・育成

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

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

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

弊社ではRailsコミュニティで高い知名度を誇る週刊Railsウォッチ をはじめ、毎週複数の勉強会を開催しています。まだ国内で知名度のないライブラリや正式リリース前のバージョンなどを含め、常に最新情報が集まる環境を構築しています。 また社内での技術情報交換は、フェイス・トゥ・フェイスはもちろんのこと、Slackのチャットルーム、食事しながらなどさまざまな機会で行われています。

BPSの4つの強み

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

  • 1

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

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

  • 2

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

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

  • 3

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

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

  • 4

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

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

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

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

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

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

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

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

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

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

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

Ruby on Rails の標準開発環境

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

Gitリポジトリ
社内にGitLabサーバーを構築しています。
プロジェクト管理
プロジェクトに応じ、GitLab issue /Backlog / Redmineなどを使用しています。
RailsやRubyのバージョン
プロジェクトでの指定に合わせます。新規プロジェクトであればその時点の最新安定版を使用します。
Gitブランチの運用
原則としてgit-flowに準拠します。
統合開発環境
RubyMineが推奨されています。
CIサーバー
主にGitLab CIを活用し、自動テストとデプロイを行っています。
コミュニケーション
原則としてSlackを使用しますが、お客様とのやりとりにはメーリングリストやRedmineを使用することもあります。
DBMS
プロジェクトに依存しますが、MySQLまたはPostgreSQLがよく使われます。
サーバ環境
多くの場合Dockerを利用し、開発環境・本番環境ともにAWS上に構築します。プロジェクトによってはオンプレミスサーバを含めた他の方法を採用することもあります。
コーディングスタイル
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で行っています。

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

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

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

BPSはAWS認定パートナーとして登録されており、AWS認定技術者も複数名在籍しています。プロジェクトのニーズに応じた最適な構成をご提案いたします。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ruby on Rails 開発の流れ

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

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

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

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

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

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

ご発注〜開発

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

検収、納品

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

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

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

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

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

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

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

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

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

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

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

Ruby on Rails開発見積りにおける人月計算と人月単価について

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

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

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

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

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

主な取引企業様

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

  • 家庭教師のトライ

    トライグループ 様

    カテゴリ基幹システム

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

  • 慶応義塾大学

    慶應義塾大学 様

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

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

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

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

    カテゴリ業務システム

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

  • サイバーエージェント

    サイバーエージェント 様

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

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

  • 大手印刷会社

    大手印刷会社 様

    カテゴリ業務システム

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

  • 東京大学

    東京大学 様

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

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

Ruby on Rails開発を
ご発注いただく際の注意点
  • 弊社では出向など、お客様の環境への常駐・出向勤務はお受けしておりません。
  • お問い合わせ、サポート応対については原則営業時間内にて行っております。

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

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

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

どんなクライアントの開発を請けていますか?
さまざまな規模のお客様と仕事を行っております。近年の取引先については 会社概要を参照ください。
これまでの開発・導入実績はどのくらいありますか?
直近1年間で、約80件前後のシステムを納入いたしました。
エンジニアは何人くらいいるのですか?
社員数40名の会社で、うち7割ほどが開発しています。(2018年4月)
発注の目安となる単価はどのくらいですか?
1人月あたり80~120万円を目安に設定させて頂いております。 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を必要とするシステム
下位バージョンのRailsで開発したプログラムを上位のバージョンに移植すると、Railsのバージョンが下位のものと上位のものとでは構造が異なるため、互換性の不具合等が発生する場合があるのは本当でしょうか?
つまり、アップデートする場合に、プログラムの修正が必要となるのでしょうか?
はい。ご推察の通りです。 Railsはマイナーバージョンが上がる毎に比較的大きなbreaking changes(後方互換性のない変更)が行われることがあります。 一例としては以下のタイミングで大きな変更が行われています。
  • 3.0 -> 3.1: Asset Pipelineの導入によるCSS、JSファイルの扱いの抜本的な変更
  • 3.2 -> 4.0: メジャーバージョンの更新にふさわしい大幅な変更多数
  • 4.0 -> 4.1: リモートscriptタグに対するCSRF保護の追加
  • 4.2 -> 5.0: Ruby 2.2.2以上が必須化。その他多数の細かい変更
  • 5.0 -> 5.1: WebpackのサポートにともないAssetの扱いが大幅に変更
こうした大きな変更が概ね1〜2年おきに行われるため、Railsのバージョンアップには慎重な調査と対応が必要になります。 対応コストの都合上アップグレードしないという選択肢もありますが、昨今のWebシステムではRailsに限らず新たな攻撃方法や脆弱性が開発・発見されるため、どちらにしてもセキュリティ情報は追いかけていく必要があります。
BPSではこうしたRailsのアップグレードに関するご相談や調査・依頼も承っておりますので、お気軽にお問い合わせ下さい。。

【脆弱性に関する記事】
https://www.oiax.jp/rails/zakkan/how_to_apply_rails_security_updates.htmlを参照ください。
XXX系Railsのバージョンでセキュリティホールがある場合、セキュリティを担保するにはバージョンアップしか方法は無いのでしょうか。
基本的に、バージョンアップが必要になります。 現在、バグが発生した場合にRails 開発者たちによって対策が行われるバージョンは4.2.x、 5.0.x、 5.1.x、 5.2.x となっており、それ以前の4.1、4.0系や3.x 系で発見されたバグは対策が行われない状況です。いくつかのバグは手作業で対策可能ですが、システムを健全な状況に保つことはかなり難しい状況です。 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 4.0 -> 5.2などのバージョンアップを行なう場合でも、かなり大規模な作業になると考えられます。

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

「テストコード」についてお尋ねしたいと思います。Ruby on Railsや昨今の開発言語では「テストコード」も開発することが主流のようなのですが、直接サービスの機能に寄与しないテストコードの開発に時間とリソースを費やす理由が分かりません(または、上長を説得することが難しい)。
テストコードをなぜ記述するのか、どのくらいのコストがかかるものなのか、テストコードを書かずに開発費用を圧縮する方法はないのかなど、教えてください。
また、請負開発では納品後検収を行いますが、その際のテストコードの品質についてどのように評価すれば良いのでしょうか。
テストコードはサービスを維持・改修・運用していく中での障害リスクを下げ、継続的なリリースをサポートするために必要です。

「テストコード」はアプリケーションそのものをテストするプログラムですが、それ自身がプログラムである以上、開発コストがかかることは事実です。 しかし、一度テストコードという形で書かれたテストはCIサーバによって自動でテストできるようになります。 もし開発しているシステムが、リリース時に一度きりテストすれば良く、二度と改修を行わないという性質のシステムであればあるいはテストコードを書かないという選択肢もあるかもしれません。 しかし、ビジネスをサポートするシステムでは二度と改修を行わないという可能性は極めて低く、どんなに「変わらない」と思っていても、運用を開始してみると様々な理由で改修が必要になるものです(元号の変更や新しい税金の導入があるかもしれませんし、セキュリティ上の都合、はたまたカード決済におけるPCI-DSS対応の様な国による指導かもしれません)。
プログラムを修正した場合、そのプログラムの修正がどこまで波及するかを正確に認識することは難しいため、リリース前にテストが行われることが一般的です。 この際、全ての機能を人力でテストするとなると、リリースの度に膨大な人的工数がかかってしまいます。 そして、大きなシステムの場合は人力での全件テストにはとても時間がかかるため、テストをしている内にまた次の改修が必要になってしまうという状況に追い込まれてしまうことがあります(当然、改修があればそれまで行ってたテストはやり直しになります)。 こんな時、テストコードがあることで、リリースに当たってのテストの何割かを自動化することができ、リリースサイクルをより早く、少ない工数で回していくことができるようになります。

テストコードのもう一つの側面は、改修時のミスの自動検知です。昨今ではサービスの立ち上げから終わりまで、同じ開発者が全仕様を把握してフルコミットしてくれるということは稀で、少なくとも複数人で開発し、場合によっては何らかの事情で開発者や開発会社をスイッチしなければいけないということがあります。
システム開発では「100%完璧に記述された仕様書」を作ることは不可能で、仮にそんな仕様書があったとしてもそれを呼んで解釈する開発者の認識が100%正確とは限りません。 開発者は仕様書を読みつつも足りない部分を都度確認したり、自分の経験・世間一般の常識やベストプラクティスで補完したりしながら開発していくのですが、どうしてもそこには齟齬が生じます(私見ですが、特に海外オフショア開発ではこの齟齬が大きくなる様に感じます)。
こうしたときにテストコードには「この機能はこう動くことを期待する」という開発時の情報が記述されており、そのコードはコンピュータが実行可能であるため人による解釈の違いが起こりません。 プロジェクトに途中参加するシステム全体を把握していない開発者がいたとしても、正しくテストコードが書かれていて自動テストが実施されていれば、開発者が間違ったプログラムを書いてしまった時点で気付くことができます。 早い段階でミスを検知できるということは無駄な工数を削減できるということにも繋がるため、結果として改修に必要なコストが小さくなるというメリットが得られます。

最後に、テストコード開発にかかる工数や品質についてですが、これについてはプロジェクトの性質や利用可能なリソース(予算・人員)・求められる速度感によって異なってきます。 一度使ったきりで二度と使わない単純なキャンペーンサイトのようなものであれば人力テストも苦ではないので書かないという選択肢もあるかもしれませんし、システムの中でクリティカルな部分(決済処理や外部システム連携など)のみ記述することで少しでも初期開発の工数を圧縮したい、システムの全てが重要で些細なミスも許されないので全ての機能について網羅的に記述したいなど、プロジェクトによってどこまでのテストが求められるかは異なります。
一般には予算や開発期間とのトレードオフになることが多いですが、BPSではこういったご相談にも乗らせて頂くことが可能です。

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

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

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