こんにちは、CTOの小林です。株式会社kickflowではクラウドワークフローのkickflowというサービスを運営しています。今日は、このkickflowを支える技術スタックについてご紹介したいと思います。kickflowの開発環境に興味のある方や、これから新規サービスを立ち上げようとしている方の参考になれば幸いです。
技術スタックをまとめた図はこちら
バックエンド
kickflowのバックエンドはRuby on RailsをAPIモードで使用しています。バージョンは最新の7系に追従しており、Rails 7から導入されたActiveRecordの暗号化機能など積極的に新機能を採用しています。また、バックグラウンドジョブには定番のSidekiqを使用しています。
テストにはRSpec、静的コード解析にRubocopを導入しています。単体テストのカバレッジは90%を超えており、機能開発時には対応するテストを書く習慣が根付いています。committee-railsを使ってAPI仕様書として公開しているOpenAPIのスキーマを元にAPIのレスポンスの構造の検証などもRSpecの中で行っています。
フロントエンド
フロントエンドにはVue.jsのフレームワークであるNuxt.jsを採用し、Single Page Application (SPA)として開発しています。また、プログラミング言語にはTypeScriptを使用しており、Vue.js 2のOptions APIによるコンポーネントの型付けを行っています。UIフレームワークにはVuetifyを使用しています。Nuxt 3とVuetify 3の正式版がリリースされたら、バージョンアップとともにComposition APIへの移行に着手する予定です。
テストにはJest、コードフォーマットにはESLintとPrettierを導入しています。バックエンドとは異なり、フロントエンドのテストはVueのコンポーネントから切り離した純粋なTypeScriptの関数などに対してのみ書かれているのが現状です。現在Storybookの導入を検証中で、今後はコンポーネント単位での自動テストや、より動作確認がしやすくなる環境整備に取り組む予定です。
インフラ
インフラにはHerokuを採用しています。kickflowは「プラットフォームや外部サービスに任せられることは全部任せて、コアとなるサービス開発に集中する」という思想で技術選定しており、コンテナ以下をプラットフォームに任せられるPaaSから選定しました。現状Herokuのおかげで運用を限りなく省力化できていて助かっているのですが、将来的にインフラ費用削減などでAWSやGCPへ移行する可能性は残してあります。アプリケーションは12 Factor Appに従って設計されているほか、例えばHerokuのアドオンの利用は最小限にとどめているなど、他のIaaSに移行しやすい状態を維持しています。
IDaaSにはAuth0を採用しています。こちらもプラットフォームにできるだけ任せる方針から認証機能の実装を外部のサービスに任せたいのと、SAMLやMFAなど認証に関する要件の複雑化が予想されたため、それらの機能を高速かつ安全に開発するために導入しています。
他には、下記のようなサービスを使用しています。
- データベース: Heroku Postgres
- キャッシュ: Heroku Redis
- ファイルストレージ: Amazon S3
- CDN: CloudFront
- 検索: Elastic Cloud
- メール配信: SendGrid
- プッシュ通知: Firebase
- データ分析: BigQuery
- エラー監視: Sentry
- ログ管理・モニタリング: Datadog
- インシデント管理: PagerDuty
- CI/CD: CircleCI, GitHub Actions
開発ツール
ソースコード管理にはGitHubを使用しており、Pull Requestベースで開発しています。タスク管理やバグ報告にはJIRAを使用しているので、Issuesはほとんど使用しません。
プロダクトマネジメントツールとしてflyleを導入しています。セールスやカスタマーサクセスのメンバーが顧客からの要望をこちらに登録してくれるので、バックログを顧客の要望と紐付けて管理することができます。kickflowでは顧客からの要望数と内容に基づいて開発優先度を決めているので、こうしたツールを導入することでより客観的に優先度を判断できています。
エディタ・開発環境には指定はありませんが、RubyMineを使っている人が多いです。希望者には会社からライセンスの提供もあります。
その他、業務ではSlack、esa、Google Workspace、Zoom、Figmaなどを使用します。kickflowは全員リモートワークなのでSlackでのテキストコミュニケーションが中心ですが、直接話した方が早いときはSlackのハドルを使うことも多いです。
最後に
以上、簡単ではありますがkickflowの技術スタックをご紹介しました。 また、本記事では紹介しきれなかった使用技術・サービスを含む技術スタックは以下のサイトでも公開しています。 www.whatweuse.dev
今後それぞれの技術分野についてより詳細に解説したブログを書いていく予定ですので、そちらも是非ご覧ください。
最後に定番の宣伝になりますが、kickflowではエンジニアを絶賛募集中ですので、この記事を読んで興味を持っていただけたら以下のリンクより是非ご応募ください。お待ちしております!