morimorihogeです。某新聞沙汰になったゲームと違ってゴ魔乙は当初からガチャの確立明示はしてたり、☆5の使い魔がインフレで相対的に弱くなったりしないあたり、割とCAVEは良心的だなと思いました（小並感
最近Railsの記事を書いていないことに気づいたので、ここ最近のRails受託開発案件の傾向について書いてみようと思います。Railsエンジニアを目指す人や、今後Rails案件を増やそうと思っている開発会社さんなんか向けの内容です。
弊社＆僕の位置づけ
観測範囲が僕の周りだけなので、まずは僕自身が普段どのような環境でRails案件と関わっているのかを軽くまとめておきます。
弊社の規模感など
今年で9期目の開発会社です。Webシステム開発の事業は当初から続いていますが、5年前くらい？（Rails 3.0.0のリリースくらい）にPHP開発メイン -> Rails開発メインになりました。
メンバはほとんどがエンジニア、または元エンジニアで、SESや常駐対応は基本的にお断りしています（もちろん案件によって打ち合わせや現地作業で事務所外で働くことはあります）。
社員数は大体20名前後で、お互いの顔と名前が一致させられる人数です。最近増資して規模拡大といった話もありますが、そのあたりは弊社代表渡辺の記事を見て頂くのが良いと思います。
事業としては電子書籍関連部門とWeb開発部門がありますが、前者は自社製品開発、後者は受託開発メインになります。僕がいるのは後者のWeb受託開発部門ですね。
僕の立ち位置
僕自身は創業メンバーではなく、学生時代にフリーランス外注として会社と付き合い始め、そのままいつの間にか中の人になってて古参になっていたという流れです。今ちらっと眺めていたら7年目くらいの様でした。もうそんなにいるのか（遠い目
現在の役割としては、Web開発部門のリーダーとして各種案件に関わっています。ただ、小さい会社＆Rails開発自体が少人数で行うことが多いことから、プロジェクトによって窓口対応・ディレクション・開発・インフラ諸々なんでも必要そうな所の穴埋めをする形で入っているのが現状です。
最近は窓口や仕様調整などの上流寄りの仕事をすることが立場上多いですが、普通にRailsのコードを書くこともあります。
また、元々ジェネラリスト的なスキルセット持ち（物理・クラウドサーバ〜開発・窓口全部やってきた）なことから、新規のWeb開発案件については僕が直接ヒアリングしに行くケースが多いです。最終的に受注に至らなかった案件についても見積・調査まではするため、入ってくる案件相談の数自体はそれなりの数になるかなと思います。
営業チャネル
人脈経由でのご相談ももちろんありますが、最近のWeb開発案件では弊社Webサイトからのお問い合せがメインです。弊社開発体制については弊社HPのRailsページに諸々まとめています（2〜3年くらい更新してないので流石にそろそろ更新しないとですね）。
ここ最近の案件傾向の変化
では、最近の案件傾向に触れていきたいと思います。
大きな企業からの相談が増加
数年前に比べると、確実に大きな会社からの相談が増えたように感じます。中小企業からの相談も引き続きありますが、これまではRailsを使っていなかったような企業からの問い合わせが来る様になりました。
これは弊社がおかげさまで有名になってきたというのもあるのかもしれませんが、RubyWorld Conferenceにここ数年出席していても感じることなので、市場傾向としても間違っていないと思います。
大きな企業の担当者様から直接ご相談を頂くこともありますが、間接的にいわゆる孫請け外注の相談を受けるケースでも中間に入っているSIerがRailsを指定（または使っても良いというOKが出ている）されているケースが見られるようになってきました。
この辺りからもRailsは「新しいモノ」から「実用に値する選択肢」として受け入れられ始めているなー、という感想です。
保守関連の相談が増加
Railsというと以前は新規開発や既存システムの作り直し案件という、実質ソースコードはスクラッチから開発する案件が多かったのですが、ここ最近は既に運用しているRailsシステムに関する相談が増えたように思います。
ご相談に至る経緯はお客様によって様々ですが、大体以下のようなケースに当てはまります。
※特定のお客様を対象にしたわけではなく、本当に↓のケースに当てはまるものが多いです
- 昔作ったRailsシステムをずっと運用してきたが、セキュリティ上のリスクや追加開発の困難さの観点からRails/Rubyのバージョンをアップグレードしたい
- 既に他社に依頼して開発・運用を続けてきたが、諸々の事情（コスト・担当者の入れ替わり・対応速度面など）で開発会社を乗り換えたい
- 元々社内で趣味的に一部の従業員が業務改善に作ってきたシステムがいつの間にか社内業務のコアシステムとなったが、正式な開発チームが社内にいるわけではないので何かあったときのためにきちんとした保守体制を構築したい
流れとして感じるのは、Railsが流行り始めの頃に構築されたシステムがそろそろ風化してきており、きちんと保守してこなかったものにガタが来始めたという印象です。
一般的なWebシステムの耐用年数は大体3〜5年くらいだと考えると、手応えとしてしっくりくるのでそういうことなのでしょう。
業務に密接に結びついた仕様が複雑な案件の増加
Railsは元々scaffoldベースの高速開発の印象が強かったこともあってか、以前までは割と分かりやすいscaffoldに落とし込める案件（index/show/new-create/edit-update/destroyでほぼ足りる）が多かったのですが、最近はより複雑なUI設計や複雑な要件を求められることが増えたと感じます。
また、そういった複雑なケースを求められるのは業務システム系のものが多いため、実装上の仕様が複雑なだけでなく、お客様の業務フローや利用環境とのすり合わせが必要になってきます。インターネットに接続できないというネットワーク条件で動かす必要があってCDNが使えなかったり、動作しているサーバの手前のコンテンツフィルタの認証を通すためにHTTPヘッダ内のデータを参照・書き換えする必要があったりといわゆる「普通のスタンダードなRailsシステム」でない案件が増えた印象です。
ただ、こういった複雑だったりセキュリティ要件が厳しめのシステムというのはそれだけお客様のコアな情報にアクセスするシステムということでもあるので、いわゆるエンタープライズに近い領域にもRailsが使われる様になってきたという裏返しなのかもしれません。
エンジニアへ求められるスキル傾向
前記に上げた案件の変化に伴い、エンジニアに求められるスキルの変化について挙げてみます。Railsエンジニアなので、Rails tutorial等は当然クリアし簡単なWebサービスくらいなら一人で作れる、というエンジニアを前提としています。
古めのRails/Rubyを触れる知識とスキル
世の中はRails 5.0が出るぞーという状況ですが、数年前のRailsシステムを触ったり更新する案件では未だにRails 1系や2系、Rubyは1.8系といったレガシーなコードに触れる機会があります。
#findメソッドに「:conditions => 〜〜」とか書いてあるコードを「おおぅ・・・」と呻きつつ何をやってるか調べたり、最新のRailsスタイルに書き直したりすることができると、割と重宝されます。
弊社では、流石に古すぎる＆テストもドキュメントもない状態の大きめRailsシステムをアップグレードするのは厳しいので作り直しをご提案するケースが多いですが、小さめのシステムだったり、コストがかかってもアップグレードしたいというご要望を頂く場合はRailsのアップグレードガイドを見ながらチマチマ更新していったり、左右に旧・アップグレード中システムを並べて動作確認、といった開発をすることもまれにあります。
流石に今更古いRailsを新たに勉強するのはモチベーションが上がらないと思いますが、需要は確実に存在する分野なので、他のRailsエンジニアとの差別化要因にはなるかもしれません。
RailsやHTTP/Webサーバ、文字コード等に関する深めの知識
社内インフラの様な特殊環境を要求されるシステムだと、普通のRailsのconfiguration程度では実現できない様なことを求められることがたまにあります。そういった際にはRails自体にモンキーパッチを当てたり、手前のnginxやapacheレベルで事前加工してみたりという対応する必要があります。
他にも、業務システムは未だに文字コードがCP932（WindowsのShiftJIS）だったりするケースが多いので、UTF-8に変換・CP932に再変換するときの変換できない文字問題に引っかかったり、外部システムの為に謎の固定長データを生成してやったりする必要があるなど、普通のRailsシステムでは触らないような問題に立ち向かう必要があります。
業務系のシステムなどの経験が長いエンジニアなら大丈夫でしょうが、最近のWeb系開発からエンジニアになって、普段からスタンダードなRailsシステムしか触っていない様なエンジニアはこういった泥臭い部分にも目を向けてみると、スキルの幅が広がるのではないでしょうか。
SIer的なドキュメントの読み書き・ヒアリングスキル
案件やお客様に依存する部分がとても大きいのですが、いわゆるSIer的な「XX設計書」「XX計画書」「XX報告書」といったものを求められることが出てきました。
弊社では明らかに必要のなさそうなドキュメントについては極力作成をお断りするようにしていますが、別途見積の上で作成を引き受けることもあります。
正直実質1〜3人程度で開発していることが多いRailsシステム開発で、今後更新される見込みのないこういった書類を書くのは苦行だなあ、と思うことが多いのですが、そういったドキュメントの中にも必要だな、と思うものは確かにあります。
外部システムとの接続点のAPI仕様書やバッチ同期するファイルのデータ使用・同期スケジュール仕様、バッチの前後関係と障害時の影響範囲などはサボると後の保守をするエンジニアが苦しむことになるので、面倒でも最低限は作成した方が良いでしょう。
また、既存の他システムとの連携が発生するシステムでは、他社のエンジニアとの仕様調整なども必要になってきます。相手がRailsのような比較的新しい技術やWeb界隈のノリに近しい人なら良いですが、ガチガチの業務系なエンジニアを相手に話をしないといけない時には、お互いの文化の違いも認識しつつヒアリング・調整していく必要が出てきます。
いわゆるSIer用語で言う「SE（えすいー）」的な動きができるエンジニアはあちこちを見ていても不足している印象なので、好きか嫌いかはともかく、やろうと思えばできる程度にはできる様になっておくと食いっぱぐれないのではないかと思います。
まとめ
以上、狭い観測範囲ではありますが、昨今の受託開発におけるRails案件の傾向と、エンジニアへの要求スキル傾向をまとめてみました。
ここに書いた様な内容に当てはまらない、いわゆるRailsらしい案件のご相談も頂きますので、以前まではあまりなかった領域の案件やスキルがRails界隈に出てきているよ、という程度に考えてもらえれば良いと思います。
そんな弊社で働くことに興味のあるエンジニアはこちらの採用ページからからお問い合せ下さい :)。
また、Rails関連の案件相談については弊社お問い合せページから問い合わせて頂ければまずはお話を伺わせて頂きます。