ランサーズ(Lancers)エンジニアブログ > SRE > ランサーズのリモートワーク化の歴史

ランサーズのリモートワーク化の歴史

kanazawa|2020年12月10日
SRE

SREチームの金澤です。
Lancers(ランサーズ) Advent Calendar 2020 10日目の記事になります。

今年はコロナ渦で急遽リモートワークをすることになりましたが、
それほど混乱せずにリモートワーク環境に移行することができまいた。

ランサーズ自体、「時間と場所にとらわれない働き方の実現」というのが、創業当初からテーマになっていましたので、社内環境も常にリモートワークを見据えて準備していたことがうまく行った大きな要因になっています。

「時間と場所にとらわれない新しい働き方を創る」という入社当時のビジョンを、社内レベルでも実現させたいと考え、社内環境も常にリモートワークを見据えて準備していました。

このブログでは、ランサーズのリモートワーク化の歴史について話していきたいと思います。

金澤入社当時の環境(2013/11頃)

ランサーズは2008年創業の会社です。
最近のスタートアップは、ほぼすべての業務フローをクラウドサービスで整えているため、リモートワークしやすい環境にあると思います。
しかしながら、ランサーズに関しては私が入社した2013/11の時点では、リモートワークを行うにあたり壁となる環境や業務フローが残っていました。

・PC環境
・ほぼ全員デスクトップPC、
・開発環境
・社内にある開発サーバーにログインして開発
・社内サーバー
・リポジトリ用SVNサーバー
・外からVPNでリモートでログインできるのは一部の人だけ
・情報共有用Redmineサーバー
・ファイルサーバー

私自身、インフラエンジニアとして入社しており、社内サーバー周りも見てきましたが、この頃はまだリモートワークの体制が整っていませんでした。

リモートワーク環境構築の方針

リモートワーク環境を構築するにあたり、以下の方針で進めてきました。

・新規に購入するのはノートPCのみにする
・開発もノートPC内で完結できるようにする
・新しい社内用サービスはクラウド版を採用する
・社内サーバーはいずれは完全に撤廃する
・社内へのVPNを作らない
・社内LANに入れても何も得るものがない状態にする
・社内のみに限定していたアクセスはプロキシサーバーを通す

ノートPC化

新規に購入するものはノートPCにする。
今後デスクトップPCは購入しない。

開発環境のリモート化

クラウドサービスへの移行

・SVN
・Github
・Redmine 情報共有
・Confluence
・Googleドキュメント
・弥生会計
・勘定奉行(Azure上で構築)

社内サーバーのクラウド化

社内サーバーは2019年中に全てAWSに移行しておきました。
※今思えば、この時に完遂しておいて本当に良かったと思います。

※AWS移行の詳細は以下のブログを参照

8年間お疲れ様でした!社内サーバーをAWSに移行したお話

上記で紹介したサーバー以外にも、以下のような社内サーバーもありました。

・社内DNSサーバー
・Route53に移行
・社内メールサーバー(開発環境用)
・各PCのMailのモックコンテナに移行
・社内ファイルサーバー(Tera Station)
・Googleドライブに移行

ちなみに、サーバーを社内のビルで運用すると、年1回のビルの保守点検で停電が発生するので、その対応をする必要があります。
ランサーズが入居しているビルは毎年5/4に停電があるのですが、GW中の停電はなかなか辛いものがありました。
この対応がなくなっただけでもかなり楽になりました。

分析SQLの発行環境

社内からAWS上のDBに対して、分析用途でSQLを発行できる仕組みを整えていましたが、

リモートワーク化により、社内にとどまらず発行する必要が出てきました。

古典的ですが、phpMyAdminを導入しました。
phpMyAdminは専用のコンテナも提供されており、ECS Fargateで運用しています。
https://hub.docker.com/r/phpmyadmin/phpmyadmin/

リモート用プロキシサーバーの構築

クラウド化したサービスは、原則、二要素認証の設定を必須にしますが、サービスによっては二要素認証をサポートしていないものもあります。
(例えば、先ほど述べたphpMyAdminの画面など)

そのようなサービスは、今までは社内からのみアクセスを許可していましたが、リモート主体となってからは、認証つきプロキシサーバーを経由してアクセスさせるようにしました。
プロキシサーバーからのアクセスにのみ許可することで第三者からのアタックを防いでいます。

リモート槍

リリースの重複を防止するために、リリース時に槍を持つ文化がありましたが、

リモート主体となり、それができなくなったため、Slackで仮想槍を持つ仕組みを作りました。

最後に

実際にリモートワーク主体で業務を行うようになりましたが、
特に弊害もなく、むしろ開発部においては、リモートワークの方が効率が良い場面も多いと感じてきました。

特に、

・会議室が要らない(集まるロスもない)
・画面共有の手軽さ

などの場面でリモートワークの優位性を感じています。

まだ、通常業務において希に出社が必要な場面にも遭遇しますが、現在、全社的に物理業務の撤廃に取り組んでおり、出社が必要な業務が完全に撤廃される日もそう遠くないと感じています。