Ruby on Rails Web開発

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

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

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

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

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

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

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

• DBサーバ
• DNSサーバ
• FTPサーバ
• LDAPサーバ
• Proxyサーバ
• メールサーバ
• 監視サーバ

構成管理を自動化し、構築作業の省力化

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

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

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

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

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

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

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

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

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

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

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

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

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

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

開発するシステムの概要

システムの目的、今回の開発の目標、使用するユーザについて、など。

開発時期

希望開始時期、完了時期、その理由など。

予算

希望価格、上限など。

使用環境

PC・スマホ・タブレット・ガラケーから指定。

特殊な仕様

独自の商慣習やビジネスフローなどに基づいた機能があれば。

機能一覧

想定している機能の一覧またはその資料など(ラフな箇条書きで構いません)。

システム環境

RubyやRailsバージョン、データベースの種類とバージョン、システム環境における制限などの指定があれば。

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

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

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

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

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

１〜３名程度の少人数開発

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 に関してよくあるご質問（FAQ）

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

どんなクライアントの開発を請けていますか？

さまざまな規模のお客様と仕事を行っております。近年の取引先については 会社概要を参照ください。

これまでの開発・導入実績はどのくらいありますか？

直近１年間で、約８０件前後のシステムを納入いたしました。

エンジニアは何人くらいいるのですか？

社員数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）７年ほど運用していた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ではこういったご相談にも乗らせて頂くことが可能です。