こんにちは、Software Engineerのt-poyoです。これはestie Advent Calendar 2021 20日目の記事です。
私は株式会社estieの事業のひとつである「estie pro」を担当するチームで開発をおこなっています。
estie proはサービス開始してから2年程度になりますが、多くの方々にご期待をいただき、近日いわゆる「0→1(ゼロイチ)」のフェーズを抜けられるという感覚があります。
今回は年の瀬ということもあり、経緯を振り返りつつ、チームが抱えるイシューを整理しながらご紹介していきたいと思います。
0→1から1→10, 組織と要求の変化
イシューのご紹介の前に、私が入社以降観測してきた、チームをとりまく環境の変化を簡単に振り返ります。
黎明期は「短期の個人戦」
私がestieに正式入社したのは2020年の3月からで、当時の社員は8名でした。
当初から「チームで開発する」というよりは「個人の能力で切り拓く」文化が色濃い組織だったと感じています。それは「ジブンドリブン」というValueにも現れています。
能力の高い個人が業務の境目なく事業に寄与することで、estie proは成長し、多くの企業様に導入していただけました。
事業の成長に伴い「中長期のチーム戦」が可能に
事業が成長した(ユーザーと投資家からの期待が高まった)ことで、開発チームを取り巻く環境と要求にも以下のような3つの変化が出てきました。
- 多様な顧客セグメントに対して、より深い価値を提供したい
- 各種予算のスパンが大幅に伸び、機能開発に関しても数ヶ月先のロードマップを作れるようになった
- 社員が少しずつ増え、取り組む課題の専門性を上げられるようになった
エンジニアとしては嬉しいこと尽くめではありますが、同時にイシューも生まれています。その中から厳選した3つをご紹介したいと思います。
①バックログの透明性を上げたい
「歩くバックログ」PdM中村の指揮
estie proの黎明期においては、開発チームのバックログは実質、PdM(プロダクトマネージャー)中村の頭の中にのみありました。
開発チームの中で唯一の社員が中村、他メンバーは業務委託という状態でスタートし、チーム内で仕様を揉むなどの時間を取れなかったためです。
チケットの優先度、仕様なども基本的に中村が先導して決め、それをチームで実装していくという体制でした。
この体制のままサービスは大きく成長するのですが、振り返ると下記のようなメリットがあったと思います。
- スプリントの枠にとらわれない即時の方向転換(顧客の声の反映)
- ミーティングの時間を取れない業務委託メンバー中心でも開発が可能
不動産業界とエンジニア、両方の経験を持ち合わせている中村だからこそできる離れ業でした。
プロセスを磨いてスケーラブルな開発へ
前述の体制のまま1年ほど開発を進め、サービスが成長するなかで、以下のような要求が生まれてきました。
- 「0→1」を成功させる方法論を社内の他事業に展開したい
- 同じ「estie pro」の中でも、顧客セグメントに対応した複数の開発チームを作る可能性がある
- バックログに透明性がないことで増えるコミュニケーションコストを減らしたい
このような要求は開発チームが拡大した/できる証拠でもあり、ご期待をいただけた結果でもあるため、嬉しいことです。
JIRAを用いたバックログ管理、ロードマップとバックログの紐付け、フレームワークを用いたバックログアイテムの優先度の定量化、などに日々取り組んでいます。しかし、ナレッジや人員の不足による手探り感はまだまだ否めません。
②他事業のTO BEの姿を考慮した全体設計
estie社内にはestie proだけではなく事業や機能が複数存在します。
個々の事業は機能的には違いますが、全体としては「産業の真価を、さらに拓く」というゴールは一緒です。
その過程で何も検討せず、例えばモノリシックなリポジトリに全ての新規事業を足していくとすれば、開発スピードの低下・セキュリティ面の問題・テスタビリティの低下などが起こることは目に見えています。
現状で起こっている事態は以下のようなものになります。
- 同じリポジトリに複数の機能が入ることでリリースが競合することがあり、機能あたりのリリースの頻度が低下する
- バックエンドがRailsモノリシックとなっており、スピードを出すには継ぎ足しで機能追加せざるを得ない構造から、DBの実態とドメインモデルを切り離すことが出来ず開発が難航する
- 既に構築したデータレイクのレコードを用いて新しいサービスを作りたい時、データの利用手段が限られる為多くの工数がかかってしまう
こういった事態を解決し将来的に避けていくため、エンジニアチーム全体で、時には外部の専門家の力も借りながら、全体のアーキテクチャを見据えた議論を週次でおこなっています。
まだまだ構想段階に過ぎず作っては壊しを繰り返していますが、自分が所属するチームの機能開発だけではなく、全体を見渡しながら設計の議論をすることで得られるものも多くあります。何より夢が膨らむものです。
③より多くのブレインで、深い課題を解きたい
estie proは不動産運用のプロに向けた業務の効率化・高度化を支援するサービスです。
平たく言うと「不動産業務のDX」が目指すところではあるのですが、そのDXは、不動産業界の方々が長きにわたって育ててきた文化やノウハウへの理解・配慮なしには実現できません。
社内に蓄積したこれらのドメイン知識はドキュメントとしての蓄積こそあれ、それらを体系づけてモデリングし・実装に落とし込む営みはまだ始まったばかりという感覚があります。
あまり詳細に書くことはできませんが、不動産データを「検索し、閲覧できる」だけではなく「複数のデータを組み合わせる」「ユーザーが本当に欲しい情報を探し当て、提示する」という価値を提供していくのがこれからのフェーズです。
国内の不動産の商習慣に配慮しながら解かれた前例のない課題を見つけ、モデリングをおこなう作業はエンジニア冥利に尽きますし、考え抜いた結果シンプルなモデルが完成する瞬間の喜びは何にも代えがたいです。
しかし、この作業は非常に時間がかかりますし、少人数で取り組んでいると「様々な経験をもった沢山のメンバーと一緒に考えられたら良いものができそうなのに」と思うこともしばしば。
もっと多くの仲間を引き入れて、「3人寄れば文殊の知恵」でこの道を切り開きたいと考えています。
おわりに
いかがでしたでしょうか。イシューといえば聞こえはいいものの、「ここに手が回っていない」「この知識が足りない」というのを書くのはすこし気恥ずかしい気分でもあります(笑)。
何はともあれ、忙しいながらも楽しくやっております。少しでも「自分が活躍できるかも！」と思った方は是非一度、カジュアルにお話ししましょう。
t-poyoとゆるく喋りたい人はこちら。
CTO岩成が会社全体の技術的イシューに言及している記事もありますので、気になった方は是非読んでみて下さい。
長くなってしまいましたが、ここまで読んでいただきありがとうございました。良いお年を。
