BPS株式会社JavaScriptを有効にしてください当サイトは、JavaScriptを有効にする事で、正しくご覧いただくことができます。2007年から続く100例以上開発実績がございます。トレンドを意識したWeb開発をお手伝い致します。Railsは、WEBアプリケーション開発のためのオープンソースのフレームワークです。フレームワークとは、アプリケーションの土台として機能するソフトウェアのことで、アプリケーションソフトを開発する際に必要とされる汎用的な機能をまとめて提供するものです。柔軟性」をバランスよく高い水準で維持できる開発フレームワークで、10年以上にわたり活発な開発が行われており、世界中で圧倒的な人気を誇ります。日本においても、スタートアップはもちろん大手企業での採用実績が増加しています。Railsを適切に導入すれば、フレームワークに集約された膨大なオープンソース資産の上にアプリケーションを構築することができ、それによってコード量を大きく減らすことができます。その代わり、それらの資産を活用するためにWEB開発の経験に加えてデータベースからネットワークやサーバ周りまでの広範囲にわたる知識が要求されるため「新規参入者にとってはハードルが高い」という問題があります。Railsを全社的に採用し、教育方法も確立されているため、高度なレベルで安定した開発を行うことができます。CoC※2の原則により、新規に書くコードを最小化し、最大限のスピードで開発できるように設計されています。弊社ではさらに、多くのライブラリとバージョン互換性のノウハウ、カスタマイズしたソースコード自動生成技術の採用により、標準的な機能を高速に開発できる環境を整えています。TDD※3により、変更に強いシステムを実現できます。活発に更新されているライブラリ群を利用し、最新のトレンドをいち早く取り入れることができます。運用の都合に合わせて、開発体制を柔軟に変えながら対応していくことができます。Framework、CakePHPといったデファクトスタンダードフレームワークが登場し、ライブラリも過渡期を過ぎて安定したことにより、一時的な成熟期へ2007〜2010普及期フレームワークを使ったプログラミングが主流になり、Webシステム開発の体系化が進む。大規模システムや基幹業務システムにも軽量言語の採用が増加。Railsをメイン開発手法として採用クラウドの普及とスマートフォンの台頭により、Webは新たなステージへ2011〜2014新時代の幕開けスマートフォンの爆発的な普及により、Webに求められるものが変化。同時期にクラウド技術の活用も進む。Railsではマルチプラットフォームに適した先進的な機能をいち早く標準搭載するなど、積極的な進化が続く。時代の変化に対応できないフレームワークの淘汰が進むとともに、フロントエンド技術の進化が加速する2015〜現代バズワードとなったHTML5をきっかけに、Webのアプリケーションプラットフォーム化が進む。Railsは新しいトレンドを常に取り入れて進化を止めない。「新規参入者にとってはハードルが高い」という問題があります。Railsを全体的に採用し、教育方針も確立されているため、高度なレベルで安定した開発を行うことができます。開発エンジニア15名インフラ・サーバーエンジニア兼務3名(全員AWS認定エンジニア)チーム編成のコンセプト弊社の準アジャイルな開発体制の基本となる思想は「アジャイルサムライ」に由来します。Railsという強力なフレームワークの特長は、アジャイルサムライが掲げる理想的な開発の具現化においてさまざまな点で有利に働きます。新技術を積極的に取り入れることによる開発効率の持続的な改善!新規参入の難易度が高い技術を長年メインで採用してきました。2011年以降、新規のWebシステム開発は原則Railsを用いて開発しています。2007年よりメイン技術として開発実績を積んできた結果です。著しく開発速度・品質を向上させることが可能です。以後の保守が比較的行い易い傾向にあります。情報収集と検証を常時行う技術力が強みです。数ヶ月も経つと状況が変わっていることも多いため、持続的な情報収集が欠かせません。弊社では積極的な情報収集を行い新技術の情報を集めると共に、検証を行っています。ライブラリのコードを解析してバグを修正するなどの対策を適宜行っています。Githubなどで情報公開を行っています。Railsコミュニティで大変好評を頂いています。Rails開発チームのエンジニアは基本的に担当するプロジェクトのすべてをケアします。「これは私の業務ではない」のような線引きは行いません。開発・実装のみならず、他のプロジェクトメンバーの仕事であっても、お客様側の業務内容であっても、気になる点がありましたら率先して相談いたします。Rails開発を含む以下の業務を担当します。Rails開発には、さらに以下の作業も含まれます。Railsは少人数での大規模開発が可能であり、エンジニアは全方位的に業務を担当するため、エンジニア一人あたりの裁量範囲が大きくなります。そのため、作業の分担・環境の構築がいつでもできるように常に開発用ドキュメントを整備しておく必要があります。Railsの長所の多くが失われるため、弊社では開発用ドキュメントの整備を必須作業としています。エンジニア個人のノウハウがドキュメント化されないまま、再現不可能な「秘伝のタレ」と化し、他のエンジニアが参加するときに障害となることのないように、秘伝のタレを管理し、開発者が確実に利用できるようにしなければなりません。Railsの特長はこの点においても有利です。Railsの開発ドキュメントとして定めており、これに従えばいつでも開発に参加できるよう、常に最新の状態に保つことを義務付けています。最小限記載されるべき情報は以下のとおりです。wikiやリポジトリ上の特定ディレクトリ、ファイルサーバーなど)Staging環境のURLとデプロイ方法アプリケーション固有の情報(gemの依存関係など)言うまでもなく、本番用パスワードなどの重要な情報はリポジトリに含めず、別途管理します。主要開発メンバーにはコンピューターサイエンスの修士号を取得し、慶應義塾大学で講師として現役で活躍する者が在籍しております。WEB開発チームにとってのスキルの維持・育成WEB開発の分野は日進月歩という言葉にふさわしく、1年も経てばすぐに陳腐化してしまう技術もあるかと思えば、ついこの間まではそんなに話題に上がらなかった言語やライブラリが突然再評価されることもあります。そんな中で質の高いアプリケーションやソフトウェアを開発していくには、常に新しい技術を追い続け,実際に試してみるというフットワークの軽さが何より重要です。一つの技術に特化して習熟することもエンジニアとして重要ですが、視野を広げて多くの技術を習得することもそれと同じくらい大事です。弊社ではエンジニア各自が自分のアンテナを磨き、新しい技術や手法を持ち寄って使ってみるといったことを積極的に行っています。新しい技術を採用することで開発速度や品質の向上が期待できますが、そこには常に安定性とのトレードオフがつきまといます。登場間もない技術には未発見のバグが含まれていることがあり、特定環境の組み合わせにおける不具合などに遭遇する機会も多くあります。そのため、実際のシステム開発で新しい技術を採用する際は、これらの技術的リスクを社内で吸収できるかどうかを検討した上で利用しています。はじめ、毎週複数の勉強会を開催しています。国内で知名度のないライブラリや正式リリース前のバージョンなどを含め、常に最新情報が集まる環境を構築しています。社内での技術情報交換は、フェイス・トゥ・フェイスはもちろんのこと、Slackのチャットルーム、食事しながらなどさまざまな機会で行われています。Rails開発におけるBPSの強みをご紹介します。プロジェクトオーナーシップ弊社の開発チームはお客様とのヒアリングを通じて「何のためのシステムか」を重視した開発を行います。機能面だけ見ると一見同じようなシステムに見えても、どのようなビジネスの中で使われるのか、利用者はどういう人がいるのか、システムの目的は何なのかによって作るべきシステムのあり方は変わってきます。開発コストや利便性の観点から機能の追加だけでなく削除や代替手段のご提案も含め、技術的により良い方法があれば率先して提案することでより価値を生み出すシステムの開発を目指します。多様なスキルを持つ少数精鋭志向プロジェクト開発チームは少なくて2名程度で、多くても10名を超えることはまずありません。システム開発には設計・デザイン・コーディング・インフラなど様々な役割が必要ですが、人数が増えすぎると管理するためのコミュニケーションコストが肥大化しがちです。ありながらも複数人での体制を組むことで、不慮の担当者の入れ替わり等が発生してもプロジェクト進行が止まらない体制を構築できます。速度がとにかく重視されるプロジェクト、ドキュメントや開発体制の手厚さが重視されるプロジェクトなど、求められる成果物や納期、品質のトレードオフの重心は様々です。弊社は創業以来多くの受託開発案件の実績と経験がありますので、様々な要件に合わせて開発体制を構築することができます。スモールスタートを想定した新規事業のサービス開発では短い期間単位でのインクリメンタル開発で動く物を重視していくアジャイル方式、深い業務理解が求められる業務システム開発では事前に仕様書レベルでの整合性確認を行いながらドキュメント化していくウォーターフォール開発など、ニーズに合わせた進め方、成果物の作成に対応させて頂きます。良い技術を採用し、常に成長していくことによる効率化Web業界は技術やデザイントレンドの移り変わりが早く、エンジニアにも常に成長が求められます。弊社では常に新しい技術情報をキャッチアップしつつ、その技術がプロジェクトで利用可能かどうかを検討する活動を継続的に行っています。[技術ブログTechRacho]を通じてインプット・アウトプットを継続的に行っていくことで、新しい技術の取り入れだけでなく長く実績のある技術のフォローアップもしています。古く実績のある技術から新しい技術まで含めた数ある選択肢の中で、その時そのプロジェクトに最も効果的な選択をすることが、効率の良い開発に繋がっていきます。お客様が求めているものをイメージ通りに実現するための工夫エンジニアが同席するだけでは足りないこと?お客様が本当に必要なものを開発することが難しいのは、思いのほか「考えていることを伝える」ことが簡単ではないからです。要件のヒアリングをエンジニアが行った上でさらなる工夫を加えています。作りながらお客様に確認いただくこと」ですが、短い開発期間の中でこれを行うには高い技術力が要求されます。Railsでのシステム開発実績に基いて準アジャイル開発を実現いたします。開発システムをある程度の大きさの機能に分割します。次に分割した機能を1〜2週間に1度程度の周期でお客様にご確認いただきます。イメージと全然違う」という状況を避けることができます。プロジェクト自体の納期や要求の変更に対して柔軟に対応することもできるようになります。ビジネス上の課題を把握した上で判断するさらに、弊社では既存のプロダクトを利用したり、既存のサーバ設定の組み合わせで同等機能を実現したりすることも選択肢に含めています。私たちは「無駄な開発」や「車輪の再発明」を行いません。既存のWordPressやEC-CUBE等のCMS、静的HTML等の組み合わせてシステムを構築することも可能です。弊社のエンジニアにご相談ください。その場合の制約条件などについても説明いたします。Rails標準開発環境です。標準であり、プロジェクトのポリシーによって異なります。Gitリポジトリ社内にGitLabサーバーを構築しています。Redmineなどを使用しています。RailsやRubyのバージョンプロジェクトでの指定に合わせます。新規プロジェクトであればその時点の最新安定版を使用します。原則としてgit-flowに準拠します。統合開発環境RubyMineが推奨されています。CIを活用し、自動テストとデプロイを行っています。コミュニケーション原則としてSlackを使用しますが、お客様とのやりとりにはメーリングリストやRedmineを使用することもあります。DBMSプロジェクトに依存しますが、MySQLまたはPostgreSQLがよく使われます。ともにAWS上に構築します。プロジェクトによってはオンプレミスサーバを含めた他の方法を採用することもあります。Railsのコーディングスタイルに準拠します。X上に開発環境を構築しています。Rubyはrbenvによりバージョン管理を行い、MySQLやMemcachedといったサービスはHomebrewを用いてインストールしています。エディタ、開発環境としてはRubyMineを用いています。RubyMineはメモリ消費の激しいIDEですが、非常に正確なコードハイライティング/フォーマッティング、便利なショートカット、SCM連携、ブレークポイントの挿入とステップ実行など、それを補ってあまりあるだけの利点があります。その他の環境については、基本的に各自の裁量に任されている部分も多いですが、ターミナルは標準ターミナルやiTerm、シェルにはbashやzshが使われています。システムによっては連携するソフトウェアがLinuxでしか動かないケースや、より動作環境を合わせるために本番環境と全く同じ環境を設定したいこともあります。FusionやVirtualBoxを利用し、VM上に環境を構築します。プロジェクトでは、基本的にRailsの最新版を利用しています。現在は4.0.2です。Rubyは2.1系列の最新安定版を利用しています。自動テスト環境を整備し、バージョンアップに追従できるように心がけています。DBはMySQLを標準で採用しています。希に、キャッシュ用としてmemcachedやTokyoTyrantを利用することがあります。自動テストにはrspecを標準採用し、必要に応じてcucumberを利用しています。これらはJenkinsで自動ビルド(コミットごと+毎朝)し、失敗時には担当者にメールが届くようになっています。resque)利用しています。デプロイは、capistranoを標準的に利用しています。capistrano-extを利用することで、ステージング環境、本番環境などに効率的に配信することができます。開発環境には、リポジトリへのpushを検知して自動デプロイする環境も構築しています。ほとんどのプロジェクトにはairbrake等のエラーレポートシステムを組み込んでいます(最近はオープンソースのerrbitに移行中です)。これにより、万が一本番環境でエラーが発生しても、即座に開発者にstacktrace付のメールが届くため、迅速な対応が可能になっています。ソースコード管理はすべてgitで行い、さらに運用ルールは基本的にgit-flowを採用しています。GitHubのオープンソースクローン、GitLabを社内で運用し、管理コストを省いています。issue管理は、redmineで行っています。Service)を採用しています。必要に応じてスケールアップ、スケールアウト可能な環境をご提供可能です。障害発生時の対応コストや日々のメンテナンスの容易性からも、特に理由が無ければAWSのご利用をおすすめしております。AWS以外にレンタルサーバ・オンプレミス型などをお考えの場合にも対応可能ですので、ご相談下さい。BPSはAWS認定パートナーとして登録されており、AWS認定技術者も複数名在籍しています。プロジェクトのニーズに応じた最適な構成をご提案いたします。※スケールアウトにはシステム側の対応が必要なため、大規模サイトをお考えの場合は事前にご相談下さい。通常のサーバ保守会社では手に余ることがあります。弊社ではサーバ構築から以後の保守・運用(死活監視・セキュリティアップデート・負荷モニタリング)までを自社スタッフで対応できるため、Railsサーバ運用のノウハウがあります。※ご予算に合わせて保守なし・構築済みのサーバを納品するなどの形式も選択可能です。CakePHP,Wordpress,Sinatra等のその他フレームワークについてもご相談下さい。Webサーバ以外の構築についても対応致します。DBサーバDNSサーバFTPサーバLDAPサーバProxyサーバメールサーバ監視サーバ構成管理を自動化し、構築作業の省力化Railsサーバは構築する多くのソフトウェアと連携する必要があり、ソースコードを置くだけで動作するものではありません。Code)し、属人性の排除とミスの軽減に努めております。弊社ではサーバの構成管理ツールにansibleを採用しております。※ご要望があればchefによる構成管理も可能ですサーバ監視ソフトウェアによる障害の検知と負荷対策サーバ監視ソフトウェアにnagios3を採用し、サーバの状態を監視しています。サーバに異常があった場合はお客様に連絡するとともにし、速やかにサービスが回復するよう努めています。サーバの負荷状態も監視していますので、サーバの負荷が高い状態が続いた場合に負荷対策のためのスケールアップ、スケールアウトの提案も実施しています。システムに合わせた最適なバックアッププランのご提案システムに応じて使用できる機能や負荷のかかる時間帯が異なります。必要なデータをどのくらいの間隔でバックアップするかも重要です。規模・構成に合わせたシステムバックアップ、データバックアップの提案と実施をしています。弊社では開発から運用までを担当しているのでより最適な提案が行えます。開発の流れ以下の流れで、開発を進めさせていただきます。お電話・メールにてお問い合わせくださいお問い合わせの際に以下の情報をお知らせください。お願いしたい内容などをお伝えいたします。高いものから開発を進めます。約20%を検収期間として定めます。ドキュメントを整備します。開発ご発注前の料金のお見積り開発内容と過去開発実績から、必要な人月(※)を試算いたします。開発内容を知るために、下記の情報をお伺いいたします。検討時点で既に手元にあるものや、決まっている情報、お答えできる範囲で結構です。秘密保持契約(NDA)などが必要な場合はお知らせください。使用環境PC・スマホ・タブレット・ガラケーから指定。独自の商慣習やビジネスフローなどに基づいた機能があれば。想定している機能の一覧またはその資料など(ラフな箇条書きで構いません)。システム環境RubyやRailsバージョン、データベースの種類とバージョン、システム環境における制限などの指定があれば。プロジェクトを予算内で成功させるために必要なことは何か?ムダな作業が開発コストに直結します。開発体制の工夫が必要です。要望を安請け合いする営業スタッフを通して開発者に伝えるからです。コードの書けるエンジニアが同席します。打ち合わせの場で判断しながら進めていくことが重要です。新しいアイディアや改善点の提案を、技術の裏付けを持つエンジニアが直接行うことにより、技術的な最適解をチーム全体で共有しながらプロジェクトを進めることができます。人を投入すればするほどムダが増大します。「作業が止まっている時間」の方が大きくなります。弊社では、営業スタッフを除き、システムの開発にはサーバ構築などの周辺作業も含めて1〜3名程度の少人数で開発を行っています。これによって開発スタッフ間で情報を素早く共有し、情報の齟齬を防いでいます。人数×期間(何ヶ月)=人月に基いてお見積りいたします。人月×人月単価=見積金額となります。※1ヶ月未満の対応については、人月単価を日割り計算します。新規開発の場合、人月単価を80~120万円前後に設定しています。規模や納期にもよりますが、多くの場合1名が専任で開発し、もう1名が計画や実装内容に漏れがないかを定期的に確認するという構成です。弊社のエンジニアは全員、フロントエンドのHTML/CSS/JS作成からバックエンドのプログラミング、データベース設計などWEBシステムに必要な作業を1人で行います。開発の進め方は、1~2週に1度程度の周期で打ち合わせを行い、弊社内で開発を行います(お客様の事務所での出向開発は行っていません)。打ち合わせ時には、開発進捗の報告、不明点の洗い出し、新規ご要望のヒアリング、優先順位付け(優先順位の変更含む)などを行い、逐次進捗を共有します。システム開発後の保守については、オプションで定常的なサービスの死活監視やシステムバックアップ作業などを月額料金にて承っております。開発で関わった企業様の一部をご紹介します。データの出力、データのインポートにも対応。様カテゴリスマホ連携APIサーバ機器情報登録システムを提供。UPnP経由で機器情報を取得し、バーコードを発行し、バーコードをAndroid端末で読み込んで登録するといった特殊なフローに対応。様カテゴリ業務システムレンタルCDリクエストシステムを提供。APIと連携し、FaceBook経由で情報のやり取りが可能。様カテゴリコンテンツ配信システムコンテンツ配信サーバを提供。様カテゴリ業務システムデジタルアーカイブシステムを提供。全文検索エンジンSolrを使い、大量のデータを高速で検索することを実現。様カテゴリスマホ連携システム情報可視化システムを提供。位置情報と環境音をAndroidで収集し、Web上で地図上にマッピングといったAndroidとの連携に対応。弊社では出向など、お客様の環境への常駐・出向勤務はお受けしておりません。お問い合わせ、サポート応対については原則営業時間内にて行っております。ついては別途ご相談ください。関してよくあるご質問にお答え致します。どんなクライアントの開発を請けていますか?さまざまな規模のお客様と仕事を行っております。会社概要を参照ください。これまでの開発・導入実績はどのくらいありますか?直近1年間で、約80件前後のシステムを納入いたしました。エンジニアは何人くらいいるのですか?社員数40名の会社で、うち7割ほどが開発しています。(2018年4月)発注の目安となる単価はどのくらいですか?1人月あたり80~120万円を目安に設定させて頂いております。1名が開発に集中し、もう1名が計画や実装内容に漏れがないかを定期的に確認する構成です。人月単価の変動条件は、以下のとおりです。開発の規模や期間はどのくらいかかりますか?見積の例を教えてください以下の事例を参考にしていただけます。5人月BPSで開発することの強みは何ですか?下記に関連したシステム開発は特に多くの実績とノウハウがあります。RailsによるWEBシステム学習塾、教育関連のシステム特に以下の領域を得意としています。決済を要するシステム(国内外の決済システムをサイトに導入した経験がございます)高速化を必要とするシステム(アクセスの多いサイトの負荷分散など)引き継ぎ(他システム会社からリファクタリングを目的とした移行または設計・作り直し)JavaScriptを多用するシステムTDDを必要とするシステム下位バージョンのRailsで開発したプログラムを上位のバージョンに移植すると、Railsのバージョンが下位のものと上位のものとでは構造が異なるため、互換性の不具合等が発生する場合があるのは本当でしょうか?つまり、アップデートする場合に、プログラムの修正が必要となるのでしょうか?はい。changes(後方互換性のない変更)が行われることがあります。一例としては以下のタイミングで大きな変更が行われています。2.2.2以上が必須化。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により構築されたシステムのセキュリティを担保するには、1年に1度程度、他の保守と組み合わせてバージョンをあげることが最も確実です。メジャーバージョンアップが現状では年に1度程度発生しているためです。バージョンアップした場合の工数は再構築をした場合と同じ位必要なのでしょうか。バージョンアップに必要な工数を判断するには、2つのポイントがあります。ポイント1ポイント1は、現状システムのバージョンとバージョンアップするシステムのバージョンの差がどれだけあるかです。中規模、などになります。中〜大規模の工数は、システム再構築時の半分から同程度、になってきます。ポイント2ポイント2は「テストコード」の有無とその品質です。テストコードとは、システムの機能が当初意図した通りになっているかを確認するためのプログラムです。あるボタンをクリックした際、どのような挙動になるかを自動で確認することができます。テストコードが整備されている、という意味は、発注時の要件が自動確認手段として用意されているかどうか、と同じ意味になります。説明した工数をかなり圧縮することができます。5.2などのバージョンアップを行なう場合でも、かなり大規模な作業になると考えられます。開発したシステムを誰でもアクセス可能なサービスとして公開する場合、前述の通り、バージョンアップが比較的多くなるため、テストコードの整備はかなり重要になってきます。予算の都合などの関係で、バージョンアップをすぐに行なうことが困難な場合、アクセスできる人を制限するなど、不特定多数によるアクセスを絞り込みながら、テストコード・インフラ・運用体制の計画を立てるという方法も考えられます。アクセスするユーザーの全体像が把握できないとこれ以上の考察は難しいのですが、セキュリティに関する懸念がある場合、今後の方針を決めるにあたり上記のような対処療法も視野に含めておきたいところです。「テストコード」についてお尋ねしたいと思います。Railsや昨今の開発言語では「テストコード」も開発することが主流のようなのですが、直接サービスの機能に寄与しないテストコードの開発に時間とリソースを費やす理由が分かりません(または、上長を説得することが難しい)。テストコードをなぜ記述するのか、どのくらいのコストがかかるものなのか、テストコードを書かずに開発費用を圧縮する方法はないのかなど、教えてください。請負開発では納品後検収を行いますが、その際のテストコードの品質についてどのように評価すれば良いのでしょうか。テストコードはサービスを維持・改修・運用していく中での障害リスクを下げ、継続的なリリースをサポートするために必要です。「テストコード」はアプリケーションそのものをテストするプログラムですが、それ自身がプログラムである以上、開発コストがかかることは事実です。一度テストコードという形で書かれたテストはCIサーバによって自動でテストできるようになります。開発しているシステムが、リリース時に一度きりテストすれば良く、二度と改修を行わないという性質のシステムであればあるいはテストコードを書かないという選択肢もあるかもしれません。ビジネスをサポートするシステムでは二度と改修を行わないという可能性は極めて低く、どんなに「変わらない」と思っていても、運用を開始してみると様々な理由で改修が必要になるものです(元号の変更や新しい税金の導入があるかもしれませんし、セキュリティ上の都合、はたまたカード決済におけるPCI-DSS対応の様な国による指導かもしれません)。プログラムを修正した場合、そのプログラムの修正がどこまで波及するかを正確に認識することは難しいため、リリース前にテストが行われることが一般的です。この際、全ての機能を人力でテストするとなると、リリースの度に膨大な人的工数がかかってしまいます。大きなシステムの場合は人力での全件テストにはとても時間がかかるため、テストをしている内にまた次の改修が必要になってしまうという状況に追い込まれてしまうことがあります(当然、改修があればそれまで行ってたテストはやり直しになります)。こんな時、テストコードがあることで、リリースに当たってのテストの何割かを自動化することができ、リリースサイクルをより早く、少ない工数で回していくことができるようになります。テストコードのもう一つの側面は、改修時のミスの自動検知です。昨今ではサービスの立ち上げから終わりまで、同じ開発者が全仕様を把握してフルコミットしてくれるということは稀で、少なくとも複数人で開発し、場合によっては何らかの事情で開発者や開発会社をスイッチしなければいけないということがあります。システム開発では「100%完璧に記述された仕様書」を作ることは不可能で、仮にそんな仕様書があったとしてもそれを呼んで解釈する開発者の認識が100%正確とは限りません。開発者は仕様書を読みつつも足りない部分を都度確認したり、自分の経験・世間一般の常識やベストプラクティスで補完したりしながら開発していくのですが、どうしてもそこには齟齬が生じます(私見ですが、特に海外オフショア開発ではこの齟齬が大きくなる様に感じます)。したときにテストコードには「この機能はこう動くことを期待する」という開発時の情報が記述されており、そのコードはコンピュータが実行可能であるため人による解釈の違いが起こりません。プロジェクトに途中参加するシステム全体を把握していない開発者がいたとしても、正しくテストコードが書かれていて自動テストが実施されていれば、開発者が間違ったプログラムを書いてしまった時点で気付くことができます。早い段階でミスを検知できるということは無駄な工数を削減できるということにも繋がるため、結果として改修に必要なコストが小さくなるというメリットが得られます。最後に、テストコード開発にかかる工数や品質についてですが、これについてはプロジェクトの性質や利用可能なリソース(予算・人員)・求められる速度感によって異なってきます。一度使ったきりで二度と使わない単純なキャンペーンサイトのようなものであれば人力テストも苦ではないので書かないという選択肢もあるかもしれませんし、システムの中でクリティカルな部分(決済処理や外部システム連携など)のみ記述することで少しでも初期開発の工数を圧縮したい、システムの全てが重要で些細なミスも許されないので全ての機能について網羅的に記述したいなど、プロジェクトによってどこまでのテストが求められるかは異なります。一般には予算や開発期間とのトレードオフになることが多いですが、BPSではこういったご相談にも乗らせて頂くことが可能です。Railsに関する技術情報を発信していますが、それ以外にも個人的なテーマなども随時扱っています。弊社エンジニアのスキルの参考になると思われますので、ご覧ください。自分が困ったことは、他のエンジニアも困っていることが多いものです。弊社では技術ブログ「TechRacho」での情報発信や、社外勉強会の主催なども行っています。言われることですが、自分で情報を発信してみると、説明のために理解の浅かった部分を掘り下げざるを得なくなり、非常に勉強になります。Rails部門で第9位にランクインしました。システムエンジニアリングへ入社、システムエンジニアとして10年間CADの開発に従事。NEC本社へ出向、自治体向けの電子入札システムの開発に携わる。平成18年にエンタメ系モバイルサイトを運営する福岡のIT企業、株式会社アイフリークと出会い福岡にUターン、システム部門担当の取締役として経営に参画。その翌年に達成したJASDAQ(当時、大証ヘラクレス)上場に大きく貢献。平成21年から情報セキュリティ・内部監査担当の執行役員として上場企業に必要な内部統制構築に尽力。平成28年09月にBPSにジョイン。データベース設計、プロジェクト管理・推進、調達マネジメントを行う。平成27年08月にBPSにジョイン。