見出し画像

ラクビル株式会社の開発フロー・技術スタックを全公開します #採用

shio⑅ᵕ_ᵕ̩̩ƪ

こんにちは、shioです。
ラクビル株式会社の代表取締役兼CTOをやっております。

一緒に働く仲間を探しているので、弊社のエンジニアリングがどんなものなのかを全て公開したいと思います。ピンと来た方は是非ご連絡ください。

プロダクト

とはいえ、事業内容を簡潔に紹介しておきたいと思います。

最初のプロダクトとして、事業用不動産オーナーさん向けの、業務効率化&経営改善ツールを作っています。

UIイメージ

事業用不動産とは要するにオフィスビルや倉庫などのことで、マンションのような住居用不動産と対になるものだと思ってください。

ビジネスモデル

SaaS(Webアプリ)で月額制です。めちゃくちゃ分かりやすい。

これ以上書くことがない

思想

会社全体としての我々のミッションは、社名の通り「不動産に関わる全ての人・業務が『ラク』になり、本質的な部分にリソースを割けるようになる社会」です。

その中で我々エンジニアチームに課せられた使命が3つあります。
これは、僕自身のポリシーを全面的に反映しています。

スケーラブルな開発をすること

できるだけad-hocな開発をしないこと。もちろんリファクタリングは避けて通れないが、常に先を見据えたプロダクト開発をすること。暇さえあればすぐに斧を研ぎ続けること。

個人が圧倒的成長すること

開発が単に自身の既にあるスキルを消費するだけにならないこと。新しい技術や触れたことのないツール、兼ねてから試したかったロジックを積極的に採用し、会社を自身のスキルと市場価値を高める場とすること。

プロダクトをより良いものにすること

上流から来た要件にただ応えるだけではなく、時に疑い、プロダクトの価値を高める方法を模索し、提案し、実現していくこと。仕様はビジネスサイドから降ってくるものではなく、開発側とBizサイドで話し合いながら共に作り上げていくものである。

これら3つのポイントに共感していただける方であれば、技術力は後から幾らでもついてくると思います。

開発フロー

ここからは、具体的にどういうフローで我々がプロダクトを作っているかを紹介します。こういうのって何故かあまり公開されていないので、個人的には他社さんがどうしているのかかなり気になります。みなさんぜひ教えてください。

大まかには、以下のようなステップで要件定義からタスクに分割されていきます。

1. ビジネスユースケース・システムユースケース定義(Biz)
2. ドメインモデル会議
3. UIラフ
4. Domain会議/Schema会議
5. 開発
6. フィードバック

ビジネスユースケース・システムユースケース定義(Biz)

弊社ではRDRAの考え方に基づいて用件定義を行なっています。

RDRAは最初から全て忠実に行うと膨大な量になります。アジャイル開発のために、まずは要件・要望・要求を書き出して、システムの輪郭を掴みます。
(そもそもプロダクト開発は「やってみないとわからない」ものなので、用件定義は開発と並行して修正され続けるべきであり、最後まで「完成しない」ものだと思っています。)

システムユースケース: ユーザーの1挙動くらいの粒度

ここでは、Notionにビジネスユースケースとシステムユースケースを洗い出すことで、BizからDevにプロダクトが満たすべき条件のイメージを共有します。

ドメインモデル会議

miroでドメインモデルを殴り書きする

上で決まったユースケースに対応するため、エンティティの洗い出しを行います。弊社ではDDDを採用しています。

この段階でDevサイドへのドメイン知識のインストールや、ロジックが複雑になる部分の設計のアイデア出しなどを行います。

UIラフ

雑なUIラフ

ドメインモデル会議と並行して、雑なワイヤーフレームをFigmaで作成します。ボタン等での遷移とどんな情報が表示されているのかが主眼です。

Bizとの議論のたたき台になるほか、PoCのためのユーザーへのヒアリングにも役立ちます。

Domain会議/Schema会議

更に並行して、それぞれのエンティティの型を詰めるDomain会議を行います。上記ドメインモデル会議ではほとんど依存関係しかなかったところを、プロパティの一つ一つまで書き出します。

そのまま使える形で書いていく

弊社はAPIがGraphQLなので、基本的にはここもGraphQLで記述しています。

その後、フロントとバックエンド主導でSchemaを決めていきます。
基本的なCRUD以外に必要なクエリを洗い出します。ビジネスロジックの部分はBEが吸収し、FEは表示と入力に徹するという思想のため、View用のクエリなどもここで出しておきます。

ここまで終われば、あとは各エンジニアが並列して作業できます。

開発

ここはひたすら作業をする段階です。

UI: デザインを完成させる
BE: まずはAPIを生やし、後で中身を実装する
FE: コンポーネント作る→動くシステムを作る→スタイルを調整する

基本的にはSlackでコミュニケーションをとり、同期して作業する必要があればGoogle Meetを繋ぎます。

フィードバック

一通り機能が完成すると、僕を含めたBizサイドから怒涛のフィードバックが来ます。まだ最初のプロダクトをリリースしていないのですが、リリースすればユーザーさんからもたくさんフィードバックが来ます。片っ端から倒しましょう。

技術スタック

ここまで読んでいただきありがとうございます。残るはあと少しです。
ここからは我々が採用している技術たちを紹介します。

正直この図を作るのが一番楽しい

フロントエンドはNext.js、バックエンドはKotlin、APIはGraphQLです。プラットフォームはAWSにしました。理由は「使ったことがなかったから」です。
設計思想としては、ビジネスロジックはバックエンドが吸収し、フロントエンドは入出力に専念する、というのがあります。

スケーラブルな開発のために、立ち上げ時からCI/CDやIaCを入れています。テストは書ける時に書いていますが、忙しいとエイヤでデプロイしがちです。人手が欲しい。
そういえば、Reactのコンポーネントテストのために「APIがschemaだけあって実装されていない時は自動でMockデータを生成する」というのをメンバーが作ってました。テストデータ作るのも手間ですからね。すごい。

ドキュメントとプロジェクト管理は全てNotionに統一しています。また、稼働・進捗報告や日々のコミュニケーションは全てSlackで行われます。稼働した際にどこを見ていいかわからないというのを防ぐためです。

それから、月・木の朝に1時間定例ミーティングをしています。スケジュール確認や情報共有だけでなく、メンタルチェックを行なっています。フルリモートなので気を抜くとすぐ病みます。気をつけましょう。


募集要項

現在、開発メンバーは自分含め2人に加え、パートタイムの2人に手伝ってもらっています。

しかしまだまだ人手が足りません。我々はWebサービスを売っているので、基本的にサーバー代と人件費ぐらいしか掛かりません。逆に言えば、この会社の財産は「コード」と「人」なんです。

新卒・中途・学生は問いません。唯一、自身のスキルに貪欲な人がハマると思います。

フルタイム

職種: フロントエンド・バックエンド
業務内容: プロダクト開発・保守対応
必須条件: フロントエンド又はバックエンドの実務経験
就業時間: 完全フレックスタイム制
職場: オフィスができるまでフルリモート オフィスができたら考えます
報酬: 月20万〜

パートタイム

職種: フロントエンド・バックエンド
業務内容: プロダクト開発
必須条件: フロントエンド又はバックエンドの実務経験
就業時間: 完全フレックスタイム制 週2相当〜
期間: 約半年〜
職場: オフィスができるまでフルリモート オフィスができたら考えます
報酬: 成果報酬制

気になった方、まずカジュアル面談しましょう。情報交換だけでも大歓迎です。TwitterでもYOUTRUSTでもInstagramでもFacebookでもLinkedinでも何でもいいのでご連絡お待ちしております。


この記事が気に入ったらサポートをしてみませんか？