アーキベースの技術スタックを大公開！Ver.2＆テクノロジーチームカルチャー紹介

こんにちは！アーキベースの渡邉です。

弊社の技術スタックの第２段についてご紹介します！

今回は前回記事より更新された技術スタックと技術の詳細、エンジニアチームの体制・カルチャーなども紹介したいと思います。

以前の技術スタック紹介記事

• https://www.wantedly.com/companies/archibase/post_articles/314744

アーキベースでは「情報・技術プラットフォームを提供し、住環境の持続的発展に貢献する」をミッションとし複数の事業を展開しております。

テクノロジー部門では、事業チームと密接に連携して事業を推進するため、新規事業を立ち上げるために様々な開発をしております。

具体的には以下のプロダクトやシステムを開発しています。

• 建職バンク求人サイト
• 建職バンクDB（スカウトシステム）
• ケンラクシリーズ (Saasプロダクト)
• その他
• • 社内向けデータ連携・検索システム
  • Webのデータ収集システム
  • 社内DB分析サーバ管理・運用
  • メディアなどのサーバー管理・運用

上記開発を進める上で、利用している弊社技術について説明します !

バックエンド

ほとんど全てのWebサイトやプロダクトでRuby on Railsを利用しています。一部簡易的なシステムにおいてサーバーレス構成でnode.js、GAS、pythonなどを利用しています。

Railsを利用しているのは、アーキベースの最初のWebアプリケーションである建職バンク(求人サイト)が、Railsで構築されていたのが大きな理由です（創業初期の頃のエンジニアの方がRailsで開発）。

ケンラクシリーズのアプリケーションにおいてもRailsを利用しています。求人サイトのRailsのノウハウを流用しつつ、ビジネスの仮説と検証をスピード感持って進められることが大きなメリットです。

また、初期に開発したプロジェクト以外では、クックパッドのエンジニアの方が開発されたridgepoleをDBスキーマ管理として取り入れています。運用上のメリット・デメリットはありますが、今の開発フェーズでは１ファイルで管理することができるridgepoleは非常に便利に感じています。

その他、RailsをAPIモード・GraphQL APIでVueとデータ通信するSPAのアプリケーションなども開発しています。REST APIと比べ、GraphQLによりエンドポイントの管理が楽になって良かったこともありますが、REST API比較でのデメリット以上のGraphQLのメリットを活かしきれていないところもあるので、開発チームとして理解を深め、今後も頑張っていくところかなと思っています。

なお、SPAを採用した理由はSPAの最大のメリットであるパフォーマンスを活かすためです。滞在時間の長いアプリケーションなので、実装が大変ではありますが、ユーザー体験重視で技術選定をしました。

今後もRails中心の開発をしていくのか、他の言語・フレームワークを取り入れるかはその時の体制やプロジェクトによって変化させていくこといなりそうです。

フロントエンド

フロントエンドではVue.jsを採用しています。古くから開発しているプロジェクトでは主にVue2を使い、バックエンドの項で述べたSPAはVue3を利用しています。

Vueを選択しているのは学習コストの点からです。まだまだ少人数の開発チームなのでReactなど、他のフレームワークの利用が難しく、Reactが得意なメンバーが揃ったら将来的に導入することもあるかもしれません。

Vueを使って部分的なページでpropsだけで状態管理するアプリケーション（求人サイト）などもあれば、Vuexを利用してゴリゴリ開発しているプロダクトもあります。

また、Typescriptの導入も初期の頃から検討していましたが、経験・自信のあるメンバーがおらず、学習コストが高いため初期導入は諦めました。型定義があるとミスを防げたよね、という場面もいくつか遭遇しており、いずれは再度導入を検討したい話もしているところです。

またRailsアプリケーションの中で、少しJavaScriptを使いたい、という場合ではjQueryを使うときもあります。

話が変わりまして、CSSについてはScssをBEM記法でコーディングすることが多いです。プロジェクトによっては Tailwind CSSなどのフレームワークを使っているものもあります。

インフラ

弊社はAWSをメインインフラとして利用しています。

初期の頃は環境構築がお手軽にできるAWSのPaasのElastic Beanstalkを利用していましたが、現在では全てのアプリケーションにおいてECSに移管しました。

Elastic Beanstalkを利用していた頃は、トラブル時の対応やログ・バージョンの管理などが大変だったり、ebextensionsに慣れておらず、苦労することが多かったのですが、ECS本移管により運用が非常に楽になりました。また、Terraformでインフラをコード化することで管理コストを下げるようにしております。

システム運用についても様々な取り組みをしており、Prometheusでサーバ監視、ErrBitによるエラー収集・分析、各イベントのslack通知、自動サーバ再起動など、サービスを安定的に運用する仕組みを入れています。

また、生産性向上のためGithub actionsでCI/CDを導入しています。masterブランチにマージ後、自動ですぐにデプロイが実行できるので便利です。デプロイ間のPRマージ差分を含めてReleasesを自動作成するようにもしています。

デザイン

アーキベースには2022年4月時点でデザイナーは在籍していません。各エンジニアが開発時にデザインと実装含めて進めております。幸い社内や業務委託の方にデザインが得意なエンジニアもいまして、スムーズに要件定義〜リリースまで進められていると思います。

具体的なツールとしてはFigmaを利用しています。

求人サイトなどのC向けのサイトでは、マーケティング部門・事業部門と協力して、ABテストなどによる検証を徹底してUI/UXの改善サイクルを回しています。各部門から目標や計画などを共有していただいており、共通の目標に向かってエンジニア側は開発を推進しております。

現状、ケンラクシリーズのプロダクトは、機能面での仮説・検証等に比重をおいているフェーズでありますが、ユーザーが増えた際にはUI・ビジュアル面でのインパクトも大きくなってきますので、今後の体制が変わるかもしれません。

テクノロジーチームカルチャー

アーキベースのバリュークレドは6つあるのですが、チームメンバーで話をして整理した３つを紹介します。

Change forward

• 自身の限界を決めない、世の中のビジネスやテクノロジーの変化・進化のスピード以上に組織と個人が成長し続ける。

Inside Out

• 自身の考えを積極的に示し・自走する。

Be the best

• 顧客に対して・社内に対して・自分達に対して開発の価値が何か考え続ける。
• お互いを尊重し成長し合える関係をつくり、チームとして成果を出す。

上記に加えて開発チームとしては日々の業務で個人が以下を意識することを重視しています。

• 徹底的な自動化・効率追求
• • 繰り返し作業や非効率な事に気づいて自動化し、浮いた時間で機能開発・施策の実装に時間を使う
• QCDを考え続ける
• • 開発目的に照らし合わせてコードの品質、コスト(有料ツールなども)、開発スピード等のバランスを考え最適な選択肢を考える
• ノウハウの共有と展開
• • メンバー同士・プロジェクト間をまたいで日々共有し同じ問題と解決方法でなるべくハマらないようにする（車輪の再開発を防ぐ）

色々とリストアップしましたが、日々の業務に忙殺されて私自身できていないことも多いです。しかしながら、Change forwordし続け日々個人も組織も成長し続けていきます。

プロジェクト横断で品質高く開発を推進するエンジニア、マーケティング部門と施策推進するエンジニア、インフラ・サーバ環境を自動化・超効率化するエンジニア、MVPを超高速で立ち上げるエンジニア、各人が強みを発揮してアーキベースの開発は成り立っております!

以上です!

次回のエンジニア記事では個々のプロジェクトの詳細やビジネスチームとテクノロジーチームの連携体制などのご紹介もできればと思っています。

アーキベースのテクノロジー部門に興味のある方はぜひご連絡ください!