※この記事は、2025 Speee Advent Calendar14日目の記事です。 昨日の記事はこちら
こんにちは。Speee 24卒エンジニアの渋谷です。普段はDX事業本部で、不動産売却を希望するユーザー様とクライアント様のマッチングを支援するサービス「すまいステップ」の開発を担当しています。
2024年にすまいステップへジョインして1年半が経過しました。1年目は先輩が設計・issue分解した開発内容をリリースまで責任を持って取り組む日々でしたが、2年目になり、自分で設計・issue分解に取り組むようになりました。
この記事では、設計から携わるようになった半年間で学んだ、「動くだけのシステム」ではなく「価値のあるシステム」を設計するために必要な行動と考え方を、具体例を交えて紹介します。
実際の開発プロジェクトにおいて、チームがどのように意思決定を重ね、システム設計を進めていったのか、また、エンジニアだけでなくプランナーとどう協働したのか、そのリアルなプロセスをお伝えします。技術的な判断だけでなく、ビジネス要件とのバランス、将来の拡張性を考慮した意思決定を下すために、Speeeには業務領域の垣根を超えた議論を行える環境があることが伝われば幸いです。
取り組んだ課題: 32万レコードのログシステム設計
すまいステップの運用分析に用いるために、1日あたり約32万レコードのログを新規追加するシステムの設計を行いました。
課題1: 技術的負債を生むデータ構造
プランナーから要件の共有を受けた際、今後開発予定の機能と一部記録するログデータが重複していることが判明しました。さらに、カラム名やテーブル名が別々で記録する要件になっていたため、このまま実装すると同じ概念のテーブルを複数作成することになり、技術的な負債が生まれることが予想されました。
以下のようなテーブル構造になるイメージです。
Table Bのカラムname_bと、Table Cのカラムname_cが、名前は異なりますが、記録しようとしているログの役割は全く同じでした。今後の要件変更によってシステムを修正する際に、修正対象のテーブルの判断に迷ったり、両方修正する必要があり修正漏れが発生したりするなど、保守・運用コストが高まることが懸念されました。
課題2: 32万レコードによるパフォーマンス懸念
1日あたり約32万レコードという膨大な量のログを新規追加する必要があるため、単純にループで1レコードずつcreate・saveすると、CPU使用率・メモリ使用率が非常に高くなってしまいます。
このバッチ処理はKubernetes上の専用Podで実行されるため、他のサービスへの影響を考慮する必要はありませんでした。しかし、Pod自体のリソース制約と要求上の制約から以下のようなパフォーマンス基準を満たす設計が求められました。
パフォーマンス基準
- メモリ使用率を60%以下に抑える
- OOM KillerによってPodが削除され、バッチ処理が停止してしまうため
- CPU使用率を60%以下に抑える
- Podのパフォーマンスが下がり、実行時間が長くなってしまうため
- 実行時間を5時間以内に収める
- 毎日午前8時までにログ記録を完了させる必要があり、午前3時に実行を開始する想定のため
- SQLクエリ回数を極力減らす必要がある
しかし、いざ設計を始めるとなると、恥ずかしながらパフォーマンスを意識した設計をした経験がなく、そもそもどのように設計を進めればよいのか分からない状態でした。
課題解決のために実践した2つのアプローチ
アプローチ1: システムの理想状態を定義し、要件変更を提案
すまいステップのシステムとしてあるべき状態を定義し、その状態を実現するために変更したい要件を整理することで、エンジニアとしてのスタンスを持って、プランナーに要件変更の提案を行いました。
プランナーから共有された要件を満たすための設計をするだけではなく、エンジニアとして作りたい理想状態をスタンスとして示しながら、施策の目的を達成するための方法をプランナーと一緒に考えることで、同じ概念のテーブル(ER図のTable BとTable C)を統合することができました。結果として、保守・運用コストを抑えたシステム設計を実現できました。
言われたものをただ作るのではなく、将来の保守・運用を見据えたものを作る意識を持っていたことで、要件定義という上流の工程にまで関与し、技術的負債を防ぐことができたと感じています。
アプローチ2: フローチャートで設計を可視化し、チームでブラッシュアップ
「システムを設計する」と一言で言っても、フロントエンドから設計する、バックエンドから設計する、DBから設計するなど、選択肢は非常に多くあります。パフォーマンスも考慮しながら設計を進めるとなると、何をどのような順序で考えればよいのか分からず混乱してしまい、時間だけを浪費してしまいます。
そこで、以下のスライドを参考に、設計で持つべき観点と思考の順序を整理しました。
重要なのは、以下の2点です。
- 設計をコードベースで考えないこと
- システムの完成形から必要な要素を逆算すること
これらを意識してフローチャートを用いて設計を可視化しました。そして、可視化したフローチャートに対して、チームメンバーに以下の観点でレビューしてもらいました。
- CPU使用率・メモリ使用率を高めてしまうような処理は存在しないか (例: 大量データをSQLクエリで取得しメモリに乗せてしまっている)
- 処理時間が長くなってしまうような処理は存在しないか (例: バッチ処理の分割サイズが小さすぎてSQL実行回数が非常に多くなっている)
思考プロセスを事前に整理し、フローチャートで設計を可視化することで、チームメンバーに対して、今何をレビューしてほしいのかを明確に伝えることができ、効率的に設計をブラッシュアップしていくことができました。
得られた学び:「価値のあるシステム」を作るために
プランナーから提案されたものを実現するだけであれば、エンジニアとしてのスタンスは必要ありませんし、設計の難易度もそこまで高くないと思います。しかし、それではエンジニアとして「価値のあるシステム」は作れないと学びました。
「価値のあるシステム」とは、長期的に見て事業全体の価値を持続的に最大化していけるシステムだと考えています。価値を持続的に最大化するためには、最小の工数で多くの施策(issue)をリリースしていくことが必要です。そのためには、変更容易性が高く、影響範囲が局所化されている、シンプルなシステムを維持することが重要です。
プランナーはシステムの状況などを考慮しながら要件を定義するわけではないので、エンジニアはシステムの理想状態を守るためにスタンスを取らなければいけません。しかし、「スタンスを取る=プランナーと対立する」ということではありません。プランナーはビジネスサイドの視点から事業に対して価値を生む施策を考え、エンジニアは施策の目的を達成するために、システムの理想状態を守りながらさまざまな方法を模索し検討する。このように、プランナーとエンジニアが協働し「事業の価値を最大化させること」を共通の目標として仕事に取り組むことで、持続的に高い価値を事業にもたらすことができるのだと思います。
今回の設計を経て、エンジニアとしてバリューを出す部分は、「動くだけのシステム」ではなく「価値のあるシステム」を生み出すことだと改めて学びました。
おわりに
Speeeでは、エンジニア・プランナー問わず「事業成果を最大化させること」を共通目標としているため、エンジニアが提案した要件も積極的に取り入れ、より良い要件にしていくことを惜しみません。なので、開発という下流の工程だけでなく、上流の要件定義にまで関与し、目的を達成するための方法を模索していきたいという方には、非常にマッチしている会社だと思います!
Speeeでは一緒にサービス開発を推進してくれる熱い仲間を募集しています!
新卒の方はこちらより本選考に申し込みが可能です! キャリア採用の方はこちらのFormよりカジュアル面談も気軽にお申し込みいただけます!
Speeeではさまざまなポジションで募集中なので「どんなポジションがあるの?」と気になってくれた方は、こちらをチェックしてみてください!
