テストタイトルが入ります。テストタイトルが入ります。

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

開発スピード

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

1999〜2002 原始時代
2003〜2006 戦国時代
2007〜現在

Ruby on Rails 開発実績

ミサワ分譲ナビ(330navi.com)

330navi
45周年の節目に5年ぶりの全面リニューアル

物件紹介、管理を行うWebアプリケーションサイトのリニューアルプロジェクトをZUTTO株式会社様とデザイン担当の他社様との3社共同で行いました。

既存のシステムを踏襲しながら不要な機能を削除し、システムを物件の管理に特化させるリニューアルプロジェクトです。今回、修正の容易さやメンテナンス性の向上が求められたことにより、既存のコードは使わず、開発を迅速に行うためにRuby on Railsを採用しました。

スマートフォンやタブレットにも対応したいというご要望もいただきましたので、フロント側のデザインにはレスポンシブデザインを採用し、スマートフォン、タブレット、PC間で表示が切り替わるようにしました。今回、フロント側のデザインについてはデザイン専門会社が、動的な表示切り替えや管理ページ全般の実装については弊社が担当しました。

個別教師のトライFCシステム

トライプラス
個別指導塾フランチャイズ向け管理システム

TRGネットワーク様が提供する個別指導塾のフランチャイズオーナー向け基幹コンテンツ・マネジメント・システム(FCシステム)の再構築を行いました。

日々変化を繰り返す業務に適応するため、「多様な機能追加に耐えられるシステム」、「ユーザ増加によるサーバ増強が容易なシステム」、「業務拡大に対応できるスケーラブルなシステム」をコンセプトに、当初PHPベースで開発されたものをRuby on Railsにリプレースしました。

長期にわたるメンテナンスにおいては開発メンバが交代する可能性が生じるため、詳細なテストケースとテストプログラムを作成することで、メンテナンスの影響で以前作成したプログラムの挙動が変わってしまったり、エラーが発生したりすることのないよう努めました。

MANGA REBORN

MANGA REBORN
世界中のマンガ好きのためのマンガコミュニティサイト

弊社が運営するマンガ投稿翻訳コミュニティサイトは、8000人以上の翻訳者によってサポートされています。翻訳の実績は25万件以上、対応言語は47ヶ国語にのぼります。「世界中に漫画を届けたい」そんな漫画家様の想いを実現する、新しいサービスを提供しています。

国際化がシステム設計レベルから取り入れられており、単なるサイト文章の翻訳だけでなく、ファンによる漫画の翻訳を支援し、サポートすることができる所が他に無いオリジナル要素となります。

このサイトもRuby on Railsで開発しており、常に最新版に更新されています。

鳥取バスネット

鳥取バスネット
鳥取県内の路線バス・鉄道時刻表および乗り換え経路の検索アプリケーション

鳥取県内の路線バス・鉄道時刻表および乗り換え経路の検索を行うバスネットのリニューアルを鳥取大学工学部・知能情報工学科・計算機工学A研究室と共同で行いました。

バスネットのリニューアルに伴うデザイン変更に関する部分の開発を担当しました。

デザインに関してはリニューアルの主眼の一つでもあるため、デザインの専門会社に作成を依頼し、弊社では主にデザインを Ruby on Railsフレームワークのシステムに適用する部分の開発を行いました。

ある程度システムが出来上がった状態からフロント部分の実装を引き継いだため、既存機能への影響を確認しながら開発を進めました。

トラコレ

トラコレ
会員20万人のクーポンWebサイトのリニューアル

4年間の運用実績を持つ、既存会員20万人のWebアプリケーションサイトのリニューアルプロジェクトをライブミーム株式会社様と共同で行いました。

既存システムはPHPにより構築されていましたが、長年の拡張によってソースコードの行数が膨大になっており、サイトの拡張性が失われてしまっていました。本プロジェクトでは、Ruby on Rails最新版を採用し、大部分をワンソース・マルチユースなシステムに刷新。PC、ガラケー、スマホに対応しています。

さらに、サイトの大規模なリニューアルを行い、既存データを移行しながらシステムデザインを一新いたしました。

Matrix pfmgr

Matrix pfmgr
ゲーム開発プロジェクトの収支・工数管理Webシステム

株式会社マトリックス様の各ゲーム開発プロジェクトの収支管理、工数管理を行うWebシステムを開発しました。

分散し、煩雑化した既存のプロジェクトの収支管理システムをシンプルなWebシステムに統合するプロジェクトです。システムを統合する事により、入力の煩雑さやデータ集計の手間を削減することを目的としています。

機能拡張、修正をお客様自身も行いたいというご要望をいただきましたので、Ruby on Railsシステムを弊社と共同で開発できる体制を構築しております。

業務アプリということもあり、リッチなUIよりも中心機能の実装が優先されたため、WrapBootstrap を利用してデザインにかかる工数を削減することを選択しました。

また、業務で必要な情報を取得する検索クエリを担当者自身がGUIで自由に作成・実行できる機能を作成しました。

弊社エンジニアへのご相談は下記フォームよりいつでも行うことができます。
お気軽にお問い合わせください。

お問い合わせはこちら

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

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

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

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

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

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

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

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

弊社エンジニアへのご相談は下記フォームよりいつでも行うことができます。
お気軽にお問い合わせください。

お問い合わせはこちら

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

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

プロジェクトの姿

右図は、システム開発の業界では有名な「プロジェクトの姿 – 顧客が本当に必要だったもの」という図から抜粋したものです。

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

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

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

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

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

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

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

弊社エンジニアへのご相談は下記フォームよりいつでも行うことができます。
お気軽にお問い合わせください。

お問い合わせはこちら

Ruby on Rails開発における弊社の技術について

新技術を積極的に取り入れることによる開発効率の持続的な改善!

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

2011年以降、新規のWebシステム開発は原則Railsを用いて開発しています。2007年よりメイン技術として開発実績を積んできた結果です。

Railsを使ったシステム開発は、従来の開発言語・フレームワークに比べて著しく開発速度・品質を向上させることが可能です。また、フレームワークレベルでエンジニアごとの癖を吸収できるため、以後の保守が比較的行い易い傾向にあります。

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

Railsとその周辺ライブラリ技術は数ヶ月も経つと状況が変わっていることも多いため、持続的な情報収集が欠かせません。

弊社では積極的な情報収集を行い新技術の情報を集めると共に、検証を行っています。もし利用中のライブラリに問題があれば、ライブラリのコードを解析してバグを修正するなどの対策を適宜行っています。公開可能な内容については弊社開発ブログ(http://techracho.bpsinc.jp/)Githubなどで情報公開を行っています。

弊社エンジニアへのご相談は下記フォームよりいつでも行うことができます。
お気軽にお問い合わせください。

お問い合わせはこちら

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

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

AWSのVPCイメージ

弊社ではお客様向けのサーバー環境にAWS(Amazon Web Service)を採用しています。これによって、障害耐性が向上するだけでなく、必要に応じてスケールアップ、スケールアウト可能な環境をご提供可能です。

サーバのレンタル費用の面だけでなく、障害発生時の対応コストや日々のメンテナンスの容易性からも、特に理由が無ければAWSのご利用をおすすめしております。AWS以外にレンタルサーバ・オンプレミス型などをお考えの場合にも対応可能ですので、ご相談下さい。

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

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

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

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

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

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

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

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

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

ansibleロゴ

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

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

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

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

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

nagios画面

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

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

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

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

munin画面

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

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

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

弊社エンジニアへのご相談は下記フォームよりいつでも行うことができます。
お気軽にお問い合わせください。

お問い合わせはこちら

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

チーム編成

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

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

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

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

一人のエンジニアは、Ruby on Rails開発を含む以下の業務を担当します。

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

Ruby on Rails開発には、さらに以下の作業も含まれます。

  • ワイヤーフレームからrapid prototyping(Bootstrap3などを使用)
  • デザイナが作成したデザインイメージのHTMLコーディング、画像切り出し
  • 既存システム・連携システム対応
  • 使用調査 / 把握
  • 移行仕様検討
  • 移行スクリプト作成
  • 機能開発 / テスト
  • staging / 本番サーバの整備、deployスクリプトとdeploy手順の作成
  • 開発をスムーズに引き継ぐための資料作成(READMEなど)

チーム編成のコンセプト

チーム編成のコンセプト

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

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

開発ドキュメントこそ命

ドキュメントこそ命

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

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

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

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

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

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

スキルの維持・育成

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

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

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

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

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

弊社技術ブログ「TechRacho」では、主にRuby on Railsに関する技術情報を発信していますが、それ以外にも個人的なテーマなども随時扱っています。弊社エンジニアのスキルの参考になると思われますので、ご覧ください。

自分が困ったことは、他のエンジニアも困っていることが多いものです。弊社では技術ブログ「TechRacho」での情報発信や、社外勉強会の主催なども行っています。よく言われることですが、自分で情報を発信してみると、説明のために理解の浅かった部分を掘り下げざるを得なくなり、非常に勉強になります。

なお、このTechRachoは、TopHatenarにおいてRuby on Rails部門で第9位にランクインしました。

部門別ランキング - rails

豊富な主要開発メンバー

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

森 雅智

森 雅智
Mori Masato

担当
システム設計・開発,サーバ管理・保守
対応言語
Ruby, PHP, Java, bash, C/C++など
資格
情報処理技術者試験テクニカルエンジニア(ネットワーク)
論文(一部)
  • モバイル端末におけるアプリケーション動作時間予約機構“, 森雅智など, 情報処理学会DICOMO,2010,
  • P-Survive: Application-oriented Life-time Reservation System for Battery Powered Devices“, Masato Mori, et. al., AEWUC2010 Finland, 2010
  • P-Survive: Process level energy reservation for networked sensing systems”, Masato Mori, et al, INSS 2008, Japan
外部研究実績
  • 2007 年度 IPA 第 I 期未踏ソフトウェア創造開発事業共同開発者: ユビキタスネットワークブラウザの開発と展開”
  • 2011 年度慶應義塾大学博士課程学生研究支援プログラムモバイルノードのためのアプリケーション別資源管理システムの構築”
馬場 孝夫

馬場 孝夫
Baba Takao

担当
Androidアプリ開発、Webシステム開発
対応言語
C/C++/C#/Objective-C, Java, PHP, Ruby, Python, Visual Basic/VBA, HTML5/CSS/JavaScript
資格
  • 情報処理技術者試験
    • データベーススペシャリスト[2012年]
    • ネットワークスペシャリスト[2011年]
    • システムアーキテクト[2009年]
    • システム監査技術者[2009年]
    • テクニカルエンジニア(情報セキュリティ)[2007年]
    • 情報セキュリティアドミニストレータ[2006年]
    • ソフトウェア開発技術者[2006年]
  • Ruby技術者認定試験
    • Ruby Association Certified Ruby Programmer Gold
  • 第二種電気工事士
フレームワーク経験
CakePHP, Ethna, Ruby on Rails, ZendFramework, Django, WordPress, EC-CUBE, jQuery, DoJo toolkit, prototype.js

techracho

弊社エンジニアへのご相談は下記フォームよりいつでも行うことができます。
お気軽にお問い合わせください。

お問い合わせはこちら

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のソースリポジトリを手元に置いておくと、何かと便利です。

弊社エンジニアへのご相談は下記フォームよりいつでも行うことができます。
お気軽にお問い合わせください。

お問い合わせはこちら

Ruby on Rails 開発の流れ

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

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

  • プロジェクトの目標・目的 / 開発規模 / 開発時期
  • 参考にしたサイト、システム、事例など
初回ヒアリング〜お見積もり

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

発注〜開発

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

検収、納品

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

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

開発内容と過去開発実績から、必要な人月(※)を試算いたします。

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

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

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)

  • どんなクライアントの開発を請けていますか?
  • さまざまな規模のお客様と仕事を行っております。近年の取引先については会社概要を参照ください。
  • これまでの開発・導入実績はどのくらいありますか?
  • 直近1年間で、約80件前後のシステムを納入いたしました。
  • エンジニアは何人くらいいるのですか?
  • 社員数20名の会社で、うち17名が開発しています。(2014年2月)
  • 発注の目安となる単価はどのくらいですか?
  • 1人月あたり100万円となります。1名が開発に集中し、もう1名が計画や実装内容に漏れがないかを定期的に確認する構成です。人月単価の変動条件は、以下のとおりです。
    1. 難易度の高い目標のコミットメントが条件に含まれる場合 (例:主要ページの高速化を依頼いただき、対策前の表示速度が3秒で、設定目標が1秒以内とする)
    2. 進捗管理の打ち合わせが週1以上のペースで行われる場合、優先順位などの変更が週1以上のペースで行われる場合
    3. 弊社が特に伸ばしたい技術要件が含まれている場合
  • 開発の規模や期間はどのくらいかかりますか?見積の例を教えてください
  • 以下の事例を参考にしていただけます。

    例1)デザイン(PSD)がある状態でのクラウドファンディングサイト構築: 2人月

    例2)モバイル向けQ&Aサイトの構築:1.5人月

    例3)7年ほど運用していたECサイトのフルデザインリニューアルとCMSの大幅機能追加と専用デザインのモバイル版開発: 30人月

    例4)不動産物件を管理・紹介するサイトの構築: 2人月

    例5)フランチャイズ店舗のオーナーと従業員の給与を管理する基幹システムを業務フローの変化にあわせて再構築: 12人月

    例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 は、すでにセキュリティサポートが切れている状態ですので、バージョンアップをお勧めいたします。

    【脆弱性に関する記事】

    http://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 でのアプリケーション開発でもテストコードを作成します。テストは人力で行なうこともできますが、自動化することによって確認漏れを減らし、短時間のうちにテストを行なうことができるようになります。

    このテストコードがどれだけしっかり作られているかに応じて、バージョンアップやシステムの品質に影響が出ます。予算の関係などでテストコードを十分に準備できない場合、作り直したソフトウェアの確認作業の手間が著しく増加することもあります。

Ruby on Railsに関する最新情報

弊社運営のTechRachoより転載

2015年08月14日

[プレスリリース]DMM.comさまにBPSの自社商材「超縦書」を採用していただきました。

いつもTechRachoを読んで頂いているみなさん、こんにちは。BPSの開発以外担当第二号のGenkiです。(第一号は社長です)この度、プレスリリースを発表いたしましたのでご報告です。こうやってプレスリリースを大々的に打つのは、実は初めてだったりします。そして、BPSには広報専門の担当者がおりませんので、詳しい方是…

2015年04月16日

夢溢れる製品開発事業と安定した受託開発事業を比較してみた。2014年度振り返り。

西新宿を拠点とするシステム開発会社の雑用係長、渡辺です。外で営業チックなことをしている時間と社内で開発ディレクションしている時間が丁度半々くらいです。上記の画像は本物です。青が請求、緑が入金、橙が支出です。具体的な数字がなくて恐縮なのですが、上半期に比べて下半期の収­­­益は例年約2倍です。上半期は…

2015年02月09日

CapistranoでGitのサブディレクトリ以下をデプロイする

備忘録を兼ねてメモ。 Gitのサブディレクトリ以下とは、例えばこんな構成です。 通常であればRailsアプリがGitリポジトリ直下にありますが、 複数のRailsアプリがあるなどしてデプロイしたいアプリがGitリポジトリのサブディレクトリ以下にある場合です。<pre>repogitory/ ├── user # エンドユーザー向けのRails…

2015年01月17日

人と仕事のバランスって難しいなあ。いろいろ解決してないけど来週、大阪にいってまいります。会える方…

上手く立ちまわってそうに見える人の話をきいては、この人はやりがいや楽しさ作って仕事できてるんだろうなあ、と羨ましく感じつつ、僕も自分の会社のメンバに同じように思ってもらえてるかなあ、といった不安を感じることがあります。会社を万全に状態にしていないという自覚があるのと、気にしている時点で自分のタス…

2015年01月08日

あけましておめでとうございます。今年もよろしくお願いいたします。

いつも弊社およびTechRachoを応援くださり誠にありがとうございます。おかげさまで2014年も乗り越えることができ、2015年早々ドタバタしております。新しい目標に向かって進むのと、新しい体制を構築するのを同時にやろうとすると、いつもより少し緊張しますね。計画性が足りないのか、案件ごとのビジネス感覚が弱いのか…

2014年12月22日

[翻訳] Ruby on Rails 4.2 リリースノート + Rails アップグレードガイド

こんにちは、hachi8833です。Ruby on Rails 4.2 リリースノート大方の予想どおりクリスマス直前になってRails 4.2がリリースされましたので、早速リリースノートを翻訳しました。Ruby on rails 4.2 リリースノート以前TechRachoでRails Guide日本語版をご紹介したときはGitリポジトリにむき出しの状態でしたが、現在はht…

2014年11月05日

挑戦しないと失敗も成功もしないんだなと感じた2014年度前半~エンジニア20人の会社が投資してみてうま…

皆さまこんばんは。BPS渡辺です。“しゃっちょでもこのくらいコード書けるんだからもっとがんばれよ!”という激励が社内であったと聞いて、うちも先輩風ふかすやつがでてきて嬉しいなと感じる反面、微妙に心を痛めています。・・・皆さま含めて沢山の方々のおかげで今年もなんとか生き延びることができました。本当にいつ…

2014年10月15日

HTML + CSS + JavaScript で簡単に導入できるdatetimepicker の比較

最近MBA 買ったんですけど、ずっとドザーだったので全然慣れないshibuso です。トラックパッド使うと指が痛くなって泣ける…。さて、今回は無料で公開されているdatetimepicker についてまとめたいと思います。datetimepicker と聞いてピンと来ない人は、フォームをクリックするとカレンダーが表示されて、そこで日時を選…

2014年10月10日

弊社共同主催のEPUB+DRMソリューションセミナーのお知らせ(10/10[金])

<div>~EPUBによる電子書籍配信を検討している事業社様の課題解決に~DRMによる安全なEPUB配信を実現するサービスの紹介現在電子書籍のフォーマットとして利用が拡大している「EPUB」をコンテンツ配信ビジネスに導入するためには、EPUB制作、閲覧、著作権管理等、それぞれのソリューションを用意する必要があり、手間や…

2014年10月08日

Railsで大きなファイルを扱う際のポイント

Railsで大きなファイルを扱う際のポイントをまとめてみました。前提大きなファイルとはだいたい100MB~10GBくらいのファイルをダウンロード・アップロードするのを想定することにします。数MB程度だと、特別な工夫なしでもそれほど問題になりません。10GBを超えてくると、気をつけるべき点が変わってくるかと思います。…