なぜ人工衛星開発スタートアップで元ウェブ系エンジニアが快適に働けているのか

あけましておめでとうございます。都心でも雪が降るなど、寒い日が続きますがみなさんいかがお過ごしでしょうか。id:koba789 です。

今回は、アークエッジ・スペースが一体どんな雰囲気の会社なのかについて元ウェブ系エンジニアの私の主観でご紹介します。

株式会社アークエッジスペースの成り立ち

まずは時間を私が入社する前まで巻き戻しましょう。経緯を遡ると、現状を説明しやすくなります。

株式会社アークエッジスペースは主に東京大学中須賀・船瀬研究室出身のエンジニアによって作られた会社です。必然的に、今の会社の文化も研究室の影響を多分に受けています。

また、ここでいう「エンジニア」は機械系のエンジニアであってソフトウェアエンジニアのことではありません。よって、いわゆるハッカー的な文化は中心的ではありません。

しかし興味深いのは、ソフトウェア企業的な文化を取り入れたいという動きがあるということです。しかもこの動きは会社の一部にだけあるわけではなく、CEO を含めて会社全体に広く存在します。

創業メンバーの中に、ソフトウェア企業での勤務経験がある id:meltingrabbit や、組込ソフトウェアだけでなく機械学習などの経験もある柳田がいたことがこれらの動き・文化の発端になっているようです（入社前なので伝聞です）。

元ウェブ系エンジニアへのオファー

次に私の経歴を軽く説明させてください。

前述のとおり、アークエッジ・スペースは工学系の研究室をルーツとする会社ですが、私はソフトウェアエンジニアです。

しかも組込系というわけでもなく、データセンター内あるいはウェブブラウザ内で動作するソフトウェアを開発するのが得意な、いわゆるウェブ系のソフトウェアエンジニアです。前職ではビッグなデータをなんとか処理するようなミドルウェアを書いたりしていました。

そんな私がアークエッジ・スペースからもらったオファーは次のようなものでした。

Rust で人工衛星のフライトソフトウェアを書いてみたくないですか？
そもそも情報システムのクソな部分をいい感じにしてくれませんか？

1つ目についてはわかりやすいので説明不要でしょう。いや、ツッコミたいところはたくさんあるのでサラッと流すにはもったいないのですが、ここではサラッと流すことにします。

引っかかるのは2つ目です。わざわざ強い言葉を使うからには何か大変なことが起きている気がしますよね。私もそう思いました。ああこれはいろいろやることがあるぞ、と。

幸いそういう仕事は嫌いではないので、おもしろそうだなぁと思ってオファーを受けました。情報システムが破滅しているなんていうのは、どんなスタートアップにもあることです。それが機械系のエンジニアを中心に創業された会社ならなおさらだと思いませんか。

家具家電付き物件

出社初日。「よーし整地からやってくぞ」という意気込みで気合いを入れて出社した私を待ち受けていたのは想像通りの荒野……ではありませんでした。

オンボーディングはサクサク進み、各種アカウントが発行されます。Google Workspace, Slack, GitLab, esa.io。なんか聞いていた話と違います。

DASH 島やるから来てよと言われて来てみたら家具家電付きの物件に通された気分です。拍子抜けと言ってもいいでしょう。

なんだ、だいたい全部揃ってるじゃないかと思って GitLab や Slack を眺めてみると、なんともいえない違和感があります。なんか、なんかぎこちない……いまいちツールを使い切れている気がしないのです。それ Slack の長ーいスレッドじゃなくて Issue でやったほうが便利だよ、みたいなやつです。

ここに弊社のおもしろいポイントがあります。創業メンバーは勘の鋭い人ばかりです。調べればわかる程度のことはだいたい既にわかっているのです。しかし、経験をしないとわからないものについては試行錯誤をする時間が必要です。もちろん試行錯誤さえすれば答えにたどり着けるでしょうが、専門である衛星開発に追われていて、情報システムの使い方を模索するための時間がありません。

ベストプラクティスは、わかっている人間が実践して周りはそれを真似するのが手っ取り早いものです。私の役目は、「家具家電付き物件でいつも通り暮らすこと」になりました。

空っぽの AWS アカウント

家具家電付きと形容しましたが、いくらか足らないものもありました。そのひとつが、社内ツールを自由にデプロイできる環境です。

ツールを作ることで仕事のやり方を定義し、不要な意思決定やルーチンワークを減らしていくのがソフトウェアエンジニア的な暮らし方です。また、ソフトウェアはより簡単に使えることでより多くの人に使ってもらえますし、より多くの人に使ってもらってこそより多くの価値が出ます。そのための形態として、ウェブアプリケーションは最適です。

御託はこれくらいにして、とにかくデプロイ環境です。使い慣れている AWS を使いたいと思い、上長の柳田に相談してみました。するとほぼ空っぽの AWS アカウントの管理権限をもらえました。

よく見ると、中身は空っぽなのに AWS Control Tower と AWS SSO と AWS CloudTrail の設定が済んでいます。家具家電付き物件ここに極まれり。料理しないのに調理器具がバッチリ揃ったキッチンです。

t3.medium 程度の EC2 インスタンスが1つあれば、とりあえず社内ツールをデプロイするには十分です。しかし、EC2 をそのまま使って手作業で環境構築するのでは片手落ちです。

IaC や GitOps といったコンセプトはソフトウェアエンジニア以外には馴染みの薄いアイデアです。コードであれば OSS の実装を読むことで学べますが、インフラの設定が OSS になっているケースというのは稀ですから、実際に現場を見てみないとわからないことが多いコンセプトでもあります。

どうせならこれらのコンセプトを説明するデモンストレーションとしてこの機会を活用したいと考えました。AWS のリソースは terraform で管理し、EC2 には k3s をインストールしました。k3s へのデプロイは Argo CD を用いて GitOps で管理しています。

なお、そろそろ k3s を卒業すべきな程度には利用が拡大しているのですが、それはまた別のお話。

GitHub への移行

GitHub や GitLab というのは、ただのリモート Git リポジトリサービスではなくコラボレーションのためのサービスである、というのは今更説明することではないでしょう。しかし、私が入社した当時のアークエッジ・スペースでは GitLab 上のコミュニケーションはあまり活発ではありませんでした。

先述の通り、原因のひとつは使い方のベストプラクティスがわかっていないことだと分析しました。ベストプラクティスを示すために私が「いつも通り暮らす」のであれば、慣れているサービスを使うが理想的です。不慣れな状況で無理に暮らそうとしてもミイラ取りがミイラになるだけです。

もうひとつの原因として、そもそも GitLab 自体が使いにくいという問題もありました。GitLab は GitHub と比較すると動作が遅く、その一点だけでも Issue を気軽に立てようという気力をじわじわと削いできます。これから Issue でのコミュニケーションを活発にしようしている中で、この問題は深刻でした。

GitLab を利用していた主な理由は、創業メンバーの出身研究室が GitLab を利用していたという経緯によるものです。GitLab にしかない機能に強く依存しているわけではなかったため、GitHub への移行を決めました。

GitLab から GitHub への移行というと大仕事のように思えますが（私もはじめはそう思いました）、私が「GitHub に移行したいなぁ」と漏らしてから会社としての意思決定まで5日、実際に使い始めるまでは2週間というスピードでした。当然そのあとの移行作業にはそこそこの時間がかかったのですが、この記事を執筆している時点ではなんと移行を完了しています。

この移行作業については id:sksat の尽力がありました。関係者が多い中で円滑に移行をするための工夫などは別途記事にしてくれると思います。