MNTSQ(モンテスキュー)株式会社 ソフトウェアエンジニアの沼井です。 普段はRailsでのバックエンド開発をしつつ、Elasticsearchによる全文検索処理やインデクシングまわりの開発にも取り組んでいます。
私は現在、 Thinkpad X1 Carbon (2021年版)にUbuntu 20.04をインストールして開発を行なっています。MNTSQ社以前の経験も含めると、業務でのUbuntu使用経験は3年以上あります。 テック系スタートアップの、とりわけWebサービス・スマホアプリの開発シーンでは、macOSユーザーが99%(※個人の感想です)ということもあり、macOS以外の環境を(使いたくても)使うことが難しいと思っている人も多いと思います。 本記事では、業務でのUbuntu利用の実情・課題・メリットなどを共有したいと思います。
TL; DR
- テック系スタートアップにおけるソフトウェア開発という部分に限れば、Ubuntu環境も十分実用的なラインだと思う
- 会社における普段の業務、という広い観点では、思わぬ落とし穴はやはりある
- macOS以外の環境での開発可能性があることで、多様性の観点で中長期的なメリットはあるかもしれない
そもそもなぜUbuntuなのか
弊社ではリーガルテック分野のSaaSを開発しており、Webのバックエンド・フロントエンドを担うエンジニアは基本的にmacOSを使用しています。 そんな中でUbuntuを使っているというのは、よっぽど思い入れやこだわりがあるから...というわけではなく、私自身がUbuntuに慣れていて扱いやすいから、という理由が大きいです。
私はいくつかのソフトウェア開発会社を経験してきたのですが、.NETアプリを開発するチームでは Linuxサーバとの連携機能のためのシェルスクリプト開発を担当し (他にやる人がいなかったので)、Railsバックエンドを開発するチームではサブで動いているVB.NETシステムを開発する (他にやる人がいなかったので) 等、エッジケースを担当することが多くありました。 結果として「macOSでWeb系開発する」という典型ケースの経験が少なく、Windows or Linuxのいずれかを使用する経験を多く積んできたため、可能なら自分が慣れていて生産性の高いOSを選択したいという気持ちがありました。
とはいえ、チーム全体の環境統一による生産性向上のほうが優先されるべきという判断がされれば、それに従ってmacOSを使っていたと思います。結果的には、弊社も含めていままでに所属した会社では「Ubuntuを使ってもいいよ」と受け入れてもらえたので、いまに至っています(ありがたい)。
Ubuntuで会社の業務をおこなえるか? : 実情と課題
最近は「Ubuntuで開発環境構築してみた」系のテックブログ記事も増えていますが、「実務で」「継続的に」使えているのか? あるいはやっぱり無理だったのでmacOS (あるいはWindows) に結局戻すことになってしまうのでは? 等気になる人はいると思います。
以下では自分の経験に沿って、Ubuntuの普段の業務利用のあれこれを解説していきます。主にMNTSQ社での経験を中心としますが、以前の職場での経験も踏まえて書きます。
PCの選定
業務用PCは、一貫して Thinkpad X1 Carbonを使用しています。
スペック:
これまで複数世代のX1 Carbonを使ってきましたが、Ubuntuのインストールでうまく行かなかったことはなく、安定して使えています。Lenovoが公式で互換性を確認しているLinuxディストリビューション一覧を出してくれているので、それを確認するのがよいでしょう。
リリース直後の機種は、上記リストにすぐには掲載されないので、リリース直後の機種でUbuntuをインストールするのはリスクが伴うため注意です。 (過去の実績から、X1 Carbon含むメジャーな機種でUbuntuに対応しないことはほぼない、と思っていますが)
開発用にそこそこのスペックのCPU、メモリサイズを選びやすいことや、軽量で持ち運びやすいことも、X1 Carbon選定の理由です。
開発まわり以外
社内で使うシステム・サービスの多くはWeb化されている
SaaSやスマホアプリの開発をしているテック系スタートアップの場合、業務で使用するシステム・サービスの多くはWebに対応したもの(概ねSaaS利用)が多いと思います。 そもそも社内のITエンジニアはほぼmacOSを使うこともあり、Windowsを使用するBiz側との混在状態を考えると、Windowsデスクトップ環境が必須となるようなシステム・サービスの選定自体がなされにくいと思われます。 弊社でも同様で、ほとんどの業務システムはWebに対応しています(下記例)。
弊社の利用サービスでWebに対応しているもの:
- 人事総務システム
- 勤怠管理システム
- 採用管理システム
- ビジネスコラボレーション (Google Workspace)
- ビデオチャット (Google Meet、Zoom、Microsoft Teams 等)
- など
(Web版もあるが) デスクトップアプリケーションを使用しているもの:
- Slack
Webでまかなえない部分に多少のリスクあり
とはいえ、Webでまかなえない部分というのも少なからずあり、それらについては「入社/チーム配属時は気づかなかったけど、あとから直面して問題があることに気づく」リスクが存在するように思います。
典型的には以下です:
- デバイス関連 (ネットワークプリンタ、Bluetooth機器、指紋認証など)
- VPN/リモートデスクトップサービス
デバイス接続については、典型的なデバイスへの接続は、そこまで大きな問題にはならない印象です。 ネットワーク上のプリンタへの接続は、さすがに現代のLinuxでは簡単に (Ubuntu 20.04であれば「設定」アプリから) 行えます。 印刷オプションの詳細設定や印刷の質にこだわらなければ、利用も問題ありません。 Bluetooth機器についても、マウスやスピーカーへの接続などを行なうことはもちろん可能です。BluetoothマネージャーとしてはBluemanを使用しています。 Ubuntu 20.04ではだいぶ安定してきた印象ですが、それでもたまに接続がうまく行かず(検出はされるが、ペアリングが失敗する等)、試行錯誤をすることもあります。
私が使用しているBluetooth機器:
- マウス: エレコム M-XGM10BBBK
- スピーカーフォン(会議室設置): Jabraシリーズ
また、指紋認証についても、 X1 Carbon 2021年版とUbuntu20.04 の組み合わせでは、「設定」アプリの「ユーザー > 認証とログイン」から簡単に行えるのは驚きでした。じつはこの指紋認証をセットアップしたのが最近なので、最初からできたのか、最近のドライバやOSのアップデートでできるようになったのかは未確認です。
VPN/リモートデスクトップサービスについては、入社直後には不要だったけど、いざ必要になったとき(たとえばリモートワークのとき等)に設定する、ということが少なからずあると思います。その段になって「Linuxは対応していません」ということになると辛いです。 幸いなことに、いままでの会社では、LinuxOSでも使用できるサービス(例: VPNなら、OpenVPN互換) を使っていたため、ここはなんとかクリアできました。ただし、Linux向けの手順書が会社で用意されていることはまず無いので、自分で公式マニュアルを読んで設定することは必須です。
そういう意味では、このあたりはチーム・会社に入る前に事前に確認するのがよいと思います。(リスクになりえる箇所を事前にすべて洗い出して確認するのは難しいですが...)
社外との相互運用性は課題
社外との相互運用性において一番大きいのはやはり、顧客と Microsoft Office (Word、 Excel、 PowerPoint)のファイルをやりとりする場合でしょう。 Ubuntuでの代替案としては、Office365 (Web版) を使用するか、LibreOfficeあるいは Google Workspace (Document、 Spreadsheet、 Slide)での互換表示を使用する、あたりでしょうか。 私は社内での開発がメインの業務であり、顧客と直接Officeファイルをやり取りすることがほぼないため、今のところ大きな問題にはなっていません。
ブラウザはOSよりもブラウザ間の差異のほうが問題になる
ブラウザについては、Google Chromeを使っていれば、OSの差異でトラブルになることはほぼない印象です。 私がメインで利用するブラウザはFirefoxなのですが、Firefoxを使っているせいで問題になることのほうが多いです。近年はFirefoxのサポートを明示的に、あるいは暗黙的に行わないWebサービスも増えているため、Chromeを使うほうが安心でしょう。といいつつ、Firefoxの「ツリー型タブ」拡張に10数年慣れ親しんでいることもあり、私はFirefoxを使っています(作者のPiroさん、いつもありがとうございます)。
余談ですが、Ubuntu上のFirefoxについては、直近ではsnap版で不具合がいろいろ発生しているという逆風もあるようです。 (そういえばSlackクライアントも、snap版だと過去に日本語入力に問題があったので、debパッケージからインストールしています。 参考記事: Ubuntu18.04LTSでSlack日本語入力が出来ないときの対処方法 - Qiita )
なお、Microsoft EdgeにもLinux版があり、2021年末に正式リリースされています(併用しています)。Edge for Linuxを使っている人はかなりの数奇者かもしれません。
開発まわり
標準的な開発ツールはどのOSでも概ねカバーされている
普段は以下のようなツールで開発を行なっています:
- IDE: RubyMine
- Editor: Visual Studio Code
- Terminal: Hyper
- その他: Git、docker、docker-compose、aws-cli など
標準的な開発ツールについては、macOS、 Windows、Ubuntu それぞれに対応しているか、あるいは各OS専用だけれど十分に使い物になるものがあるため、特に問題はないと思います。
エッジケースでは各OS専用ツールが有用な場合も
Visual Studio Codeは標準機能も拡張機能も充実しているため、たとえばテキストファイルのdiffの表示やバイナリ表示、CSVのテーブル表示、GitリポジトリのGUI管理など、ひところは専用のツールがあったようなものが概ねVisual Studio Codeでまかなえるようになってきています。そのため、Ubuntuも含めてOSを変えても同じように利用できるのは便利なところです。
私が使っているVisual Studio Code拡張の例:
- バイナリ表示: hexdump for Visual Studio Code
- Git: GitLens、Git History
- CSVのテーブル表示・編集: Edit csv
とはいえ、エッジケースでは「あるOSでしか動かないけど便利なもの」もあります。たとえば大容量テキストファイル(なんらかのCSVやログファイル等) を扱いたい場合は、Windows向けであるEmEditorなどが有用だと思います。 一般に、大容量テキストを扱う場合に、Visual Studio CodeやIntelliJ系IDEの拡張機能などだとつらくなるケースが多いように思います。その場面では、あるOS上での専用ツールが勝る場合がありそうです。
一番大事なのは、開発しているソースコードを扱えるか
一番大事なのは、チームで開発しているソースコードやその周辺スクリプト・ツールがUbuntuで動作するのかどうかであり、Web系の開発においては、経験的には以下がポイントとなります:
(1) docker、 docker-composeで開発環境を構築する手順になっているか
dockerを使用してれば、コンテナ内での動作については基本的には問題になることは少ないです。 数少ない問題としては、 Docker for Mac に依存する箇所でひっかかる部分(下記例)があり、これについては個別に対応する必要があります。
- コンテナ内で作成されたファイルがroot権限になる場合、ボリュームマウント時のホスト側でもファイルがroot権限になるため、編集・削除などに支障がでる問題
- 対処法はいくつかあり。参考記事: dockerでvolumeをマウントしたときのファイルのowner問題 - Qiita
- host.docker.internal を開発環境で使っている
上記のような課題はあるのですが、 Docker for Macに比べると、ボリュームマウント時のI/O速度が問題になることが少ないため、性能面で苦痛に感じることは少ないです。 数年前に経験したRailsアプリ開発プロジェクトでは、macOS環境より私のUbuntu環境のほうが、rspecの実行時間が4倍速いということもありました。(ただし、 Docker for mac + virtiofs という最近登場した構成に対しては、この差はいくらか縮まっているでしょう)
(2) コンテナの外(ホスト側)で動作するスクリプトがどれくらい多いか、どれくらいmacOS依存になっているか
macOSで開発しているチームが書いたbashシェルスクリプトは、当然ながら各コマンドのオプションの指定などがmacOS依存になる(BSD由来のコマンドオプション) ため、Ubuntuで動かないことは「まれによく」あります。
これについてはシェルスクリプトを眺めて気付けることはほぼないため実行 => エラー発生 => 修正 を繰り返す必要があります。 修正は、 unameでOS判定して分岐するか、どちらでも動くようにオプション指定の仕方や利用コマンドを変える、の2つが典型的な方法です。
このようなmacOSおよびDocker for Mac依存の箇所の調査・対応でつまづいたり時間を浪費するのは、チームにとって新しい価値を生み出せていない時間になります。そのため「macOS利用者しかいないエンジニアチームに最初に入る時」は、ここの対応は緊張感をもってスピード対応をすることを心がけています。 (最初に完璧に直すより、開発にクリティカルに影響する部分から優先順位をつけて対応するのがよいでしょう。いずれにせよ、追加/変更に継続的に追従する必要はあるので)
まとめ、あるいは語りきれなかったこと
現時点での私の状況をいうと、Ubuntuで普段開発していてとくに問題になる所はなく、慣れているOSでスムーズに開発できており、その(個人的な)メリットを享受できています。その点では実用的なラインに達していると言えます。
とはいえ、改めてまとめてみると、インストールしてから業務が軌道に乗るまでにいろんな課題を解決し、乗り越えていく必要があるなあ、というのを再認識しました。
最後に、ここまでで触れてこなかったいくつかのトピックについて取り上げてみます。
Windows11 + WSL2 Ubuntu構成の可能性について
Windows11 + WSL2 には、弊社SREの二宮同様に可能性を感じており、開発以外(VPNとかデバイス接続とか)のトラブルをWindows側で回避しつつ、開発はWSL2 Ubuntu側で行なうというハイブリット構成は魅力だなと思います。
Visual Studio CodeにはRemote Development拡張があり、 IntelliJ系IDEにもJetBrains Gateway というリモートOS上で開発する機能があるため、Windows側のGUIを使いつつWSL2 Ubuntu側で開発をすることはかなり現実味を帯びてきているように感じます。 とはいえ、同僚のエンジニア曰く、 JetBrains GatewayでUbuntuにIDEバックエンドを入れたときのGUI(Windows側)の応答速度はまだまだ厳しいとのことでした(逆にVisual Studio CodeのRemote Developmentのほうは十分イケてる、とのこと)。 RubyMine派の私は JetBrains Gateway を使いたいですが、 まだ軽く触っただけで本格的な開発には使ってないので、今後の検証課題としたいと思います。
なお、WSL2 Ubuntu側にRubyMine本体をインストールし、WSLg で接続する、またはWSL2側へリモートデスクトップ接続をする形も試したことがあるのですが、こちらも動作がまだまだ重かったなという所感です(マシンスペックにも依存するでしょうが)。
性能問題については(ハード・ソフトともに) 時間が経てば改善していく可能性が高いので、今後に期待というところです。
macOSが使えない場合の代替手段になるというメリット(多様性の担保)
以前の職場でのWeb開発の経験になるのですが、あるとき社外ベンダーの多数のエンジニアに開発プロジェクトに参加いただいたことがあり、ベンダーのエンジニアの開発用マシンがほぼWindowsだったことがありました。その結果、私が開発環境を(自分のために)Ubuntu対応させておいたことにより、ベンダーのエンジニアの方々にもスムーズにWindows10 + WSL2 Ubuntuで開発してもらうことができました。 結果論ではあるのですが、複数の選択肢(多様性)があったことによるメリットの享受といえるかもしれません。
弊社においても、一部の開発メンバーのMacBookのスペックの問題(メモリ容量が8GB)で開発が厳しい状況だったのを、メモリサイズの大きい (16GB) Windowsマシン (WSL2 Ubuntu) に乗り換えて開発している、という事例があります。
