一般社団法人 日本ニアショア開発推進機構

ニアショア開発の新しい仕組みを実現するTeleworks

今回は、一般社団法人 日本ニアショア開発推進機構のニアショア開発案件マッチングプラットフォーム「Teleworks(テレワークス)」について、代表理事の小林 ​​亮介氏とシステムの運用を担当している青柳 風太氏にお話を伺った。

一般社団法人 日本ニアショア開発推進機構は、今年で10期目になる団体であり、その名のとおり、ニアショア開発を推進させることを目的とした団体である。
略称として、「ニアショア機構」を使用されているとのことで、本稿でも以降「ニアショア機構」と呼ばせていただく。

「オフショア開発は中国、インド等でシステム開発することを指しますが、ニアショア開発は日本の地方都市で開発することを意味しています。
我々は名前の通り、ニアショア開発を日本に根付かせて広げていこうということで9年前から啓蒙活動している団体になります。」（小林氏）

ニアショア機構は、首都圏のエンジニアが足りない企業と、地方のエンジニアを抱えている企業を繋ぐ役割をしている。
地方の企業が首都圏の案件を獲得しようとすると、首都圏に営業所を設けたり、何度も出張しながら営業活動をする必要がある。
地方から営業に行く場合、時期によってはホテルがどこも満室で宿泊先が見つからなかったり、気象の影響で飛行機が欠航したり、新幹線が途中で運転見合わせになってしまい「列車ホテル」を利用せざるを得なくなったり等、遠距離ならではの苦労もある。
ニアショア機構のTeleworksを使えば、オンラインで営業活動ができるため、これらの営業にかかる費用、時間が節約できる。

また、案件ごとにニアショア機構の担当者がつき、提案から契約までサポートを行う。
誰でも案件を出したり応募できる公開された案件プラットフォームとは異なり、「認定ニアショアベンダー制度」にて認定された企業や、ニアショア機構の説明を受け、制度に賛同した企業で構成されているという利点がある。

Teleworksは、このようなニアショア機構のサービスを支援するシステムで、Ruby on Rails(以下Rails)で作成されている。
案件獲得までのフローの他、テレワーク派遣での稼働中に使える、派遣法に対応した管理ツールも提供している。

Teleworksで扱うRubyの案件

Teleworksに掲載される案件はJavaやC#が多いが、最近ではRubyも増えてきているそうだ。
以前はRubyよりもPHPの方が多かったが、今ではRubyの案件の方が多くなっているそうである。

例えばPHPなど他の言語の場合、プログラミング言語だけでなく、フレームワークまで指定して技術者を探す必要がある。
しかしRubyの場合、ほとんどの案件がRailsで、Rubyの技術者もほとんどRailsを知っているため、他の言語のようにフレームワーク等条件を絞っていくと該当者が減っていくという現象が起こりにくいという特長があるのだそうだ。

Railsで作成されたシステムの運用

次にTeleworksのシステムについて伺ってみた。
青柳氏はTeleworksの初期からの開発メンバーではなく、前任者から引き継いだシステムを運用しているそうだ。
本Ruby活用事例では、サービスの立ち上げから担当している方のお話を聞くことが多く、他の人が作ったサービスの運用をしている事例は少ない。
良い機会なので、他者の作ったサービスを運用する立場から見たRailsで作られたシステムの運用について、話を聞いた。

青柳氏はこれまで、Java、PHP、C#などのシステム開発経験はあるが、RubyやRailsで作られたシステムに関わるのは今回が初めてだそうだ。
そのような青柳氏であるが、このTeleworksと、他の社内のシステムを1人で管理しているとのことだ。
日々運用しているだけでなく、様々な改善も行っている。
今は他の社内システムとTeleworksを連携させようとしているところだそうだ。
TeleworksはHerokuを使用しており、社内のシステムの方はSalesforceを使用している。
「Teleworksを他の社内で利用しているシステムを連携させることにより、より使いやすくなると考え、社内システムとの連携をしようとしています。」（青柳氏）

引き継いだシステムのバージョンアップ

青柳氏が担当になって早々、バージョンアップを行ったそうだ。
元々稼働していたHerokuの環境が古かったため、使用していたバージョンのサポートが終了してしまい、Herokuのバージョンアップをする必要があったからである。
Herokuをバージョンアップすると、RubyやRailsのバージョンも上げる必要がでてきた。
最終的に、Rubyは2.2から2.7に、Railsは3.2.22から6.0にアップデートしたとのことである。
これだけ一気にバージョンアップしてしまうと、動かなくなる部分も出てきたそうだ。
「実作業は開発会社の人にお願いしたのですが、変えなきゃいけない部分が多かったようです。
データベース周りのコードはすべて書き直したようです。」（青柳氏）

また、引き継いだシステムはテストが動かなくなっていたそうで、まず、そこから直したそうだ。
「最初はテストも作っていたけど、改修を加えるうちにちゃんと動く状態ではなくなっていたようでした。
そこで、まず、単体テストを全部作ってから、段階的にバージョンアップして直していくという手段を取りました。」（青柳氏）

また、バージョンアップとあわせて、デプロイ環境も整えた。
その結果、エンハンスも容易にできるようになり、画面の変更など軽微な修正は、青柳氏自身で対応しているとのことだ。
「簡単な修正であれば自分でもできます。
デプロイ環境が半自動化されているので、ストレスなくできています。
修正を行う時間以外にかかる時間少ないため、取り掛かりやすいです。
私自身、Rubyのシステムって直接関わったことも、面倒を見ていたこともないのですが、それでも、すごく気軽に関われているかなと思います。」（青柳氏）

運用時に感じたRubyの良さ

今回、Rubyで作られたシステムに関わるのは初めてだったにもかかわらず、大きな問題が起きることもなくアップデートすることができた。
さらにその後の細かい修正は自身で行っているとのことである。
他の言語で作られたシステムを経験してきた上で、初めてRailsのシステムに関わってみて感じた「Rubyの良さ」について伺ってみた。

「自動化や、ソースの管理からデプロイまでの流れは、他の言語と比べるとスタンダードが定まってるといいますか、あまり何を使うか迷わなくて済むように感じています。
こうすれば簡単にできるよっていう、先人の足跡みたいなのがあるっていうのが良いなと思います。
フレームワークにしても、Rubyというと、ほぼRailsだったりすると思うんですけども、他の言語の場合だと、フレームワークをどれにするかというところで結構時間がかかったりするので。」（青柳氏）

高負荷に耐える必要があったり、応答速度などのシビアなシステム要求がある場合は、個々に作り込みが必要になるかもしれないが、そうでなければ、標準的なやり方が決まっていて、その通りにすれば使えるシステムができるというのもRailsの魅力的なところだそうだ。

「システムの要求が、負荷に耐えなければならないとか、たくさんの人が使うとか、部分的にガチガチにセキュリティで守らなければならないとか、そういうシステムの側に力を入れなければならない場合は、色々こだわらなきゃいけない部分って出てくると思います。
しかし、そうでない場合、これを使えばいいよっていう情報があるということは、すごく良いことだ思います。」（青柳氏）

さらに、困った時もインターネット上で調べれば解決策を見つけることができ、1人でも十分に業務をこなせているそうだ。
Ruby活用事例では、これまでいくつかの事例で、新しいサービスを迅速に立ち上げるのに「Railsのレールに乗った開発」が有効であったことを紹介していただいているが、本事例では、初めてRailsで作られたシステムを任されたエンジニアにとっても「レール」に乗りやすく、レールに乗ることができれば「やさしい」システムになることを紹介していただき、改めてRailsの万能さを感じることができた。

※本事例に記載の内容は取材日時点（2021年9月）のものであり、現在変更されている可能性があります。