プロダクト開発の体制変更と再始動

おてつたびでエンジニアをしている川尻です。
遅くなりましたが、2024 年もよろしくお願いいたします。

おてつたびは、「お手伝い」と「旅」を組み合わせた造語で、人手不足に悩む事業者と知らない地域を旅したい人をつなぐ人材マッチングサービスです。

おてつたび｜お手伝いをしながら、知らない地域を旅する

前回の投稿からかなり経ってしまいましたが、、前回の投稿から組織体制とプロダクト開発が大きく変わったので、今回はそのことと、今後チャレンジしたいことを述べたいと思います。おてつたびのプロダクトや開発に興味ある方の参考になれば幸いです。

組織体制の変更

まず、PdM とデザイナーのポジションを作り、ビジネスと開発のブリッジとなるプロダクトチームを発足しました。

背景

創業当初からビジネスと開発チームに分かれて、要求・要件定義は一緒に議論しながら作り、デザインもフレームワークの UI コンポーネントを使用する程度で、専任がいない領域はお互いがカバーし合う体制でした。
しかし、プロダクト規模が大きくなり、社員も増えるにつれ、さまざまな制約が課され、課題も複雑化していましたが、本質的な問題を特定し切れず後手の対応や表面的な解決になってしまい、プロダクトのデザインも担当者の判断による実装で、統一性が失われていました。
そのような局所的で表面的な対応の結果、本質的な課題解決ができておらず、システムもツギハギでプロダクトの品質低下を招く状況に陥りました。

プロダクトチーム発足

これ以上の同じ体制での継続は困難と判断して、それまで不在だった PdM とデザイナーのポジションを作り、ビジネスサイドから課題や要望を受けて、本質的なソリューションを提供するプロダクトチームを発足しました。これにより、曖昧だった工程の役割と責務が明確になり、各メンバーも専門領域に専念できる体制に変わり、アウトプットのクオリティと作業効率が上がりました。
課題も局所的ではなく、全体を物事を捉えて見るようにしたことで、点が線となり、根本解決や本質的なソリューション提供ができるようになったことで、プロダクトの品質向上にも繋がりました。
また、時間的な余裕も生まれたことで、それまでできなかったユーザーヒアリングも実施して、ユーザーの声もしっかり反映できる体制になったことも大きいと思います。

エンジニアとしては、デザイナーが Figma でプロダクトデザインのルール策定や UI コンポーネントの共通化を進めてくれたことで、認識の相違がなくなり、開発効率が格段と上がりました。

システムリプレース

前項のプロダクトの局所的な対応によるツギハギなシステムに陥ったことで、技術負債も多く抱えることになり、今後のスケールが困難になったため、システムもリプレースすることに決定しました。

技術負債

特に深刻だったのが、プログラムの品質低下でした。例を上げると、複数のユースケースのロジックが 1 つのクラスや処理に内包されていることで、不必要な依存を生み、関連機能の予期せぬ不具合が発生したり、同じ動作を行うロジックが、フロントエンドとバックエンドに別言語で散財していることで、保守コストが高まったり、などなど、ルールが順守されていない、チーム内の共有不足が原因で問題が発生していました（ある画面内の機能の追加が、同じ実装ボリュームでも、当時の半年前は 2 週間でできていたのに 2ヶ月要するようになっていました）。
また 5 年の変遷の中でフレームワークもいくつか混在してカオスな状態で、あらゆる側面で複雑なシステムでした。
これ以上の維持は厳しく、同じシステムで改善に取り組むことも既存の制約を大きく受けるため困難だという結論に至り、新しいシステムに移行する決断を下しました。

技術選定

まず技術選定から再度行いました。当時は Ruby on Rails と React を使った API 通信による SPA 開発がメインでしたが、前述のロジックがフロントエンドとバックエンドに散財していたり、i18n の言語ファイルも機能によって別々に散らばっていたりと二重管理しているものがいくつかありました。また、システム規模が大きくなっことでデバッグやパフォーマンスチューニングもフロントエンドとバックエンドでそれぞれ実施するため実装コストが単純計算でも 2 倍以上に膨れ上がっていました。このような中で今の技術と設計で果たしてスケールできるのか再度検討する必要があると思い、改めて選定し直すことにしました。

結果的には Ruby on Rails を引き続き採用して、フロントエンドは Hotwire と Tailwind CSS を採用しました。スタートアップのような少人数での開発において Ruby on Rails を使うメリットは大きかったので、継続することにしました。具体的なメリットは DHH や他の方の記事で多く語られているので割愛します。今回大きく変わったのはフロントエンドでした。再検討する中で、React を使ってまで、フロントエンドで複雑なことを行いリッチにする必要がある機能がプロダクト内でほとんどなかったことが大きく（バックエンドから受け取ったデータを表示することがほとんどだった）、バックエンド中心で JS は必要な箇所のみ局所的に実装することが理想な姿だという結論に至りました。またバックエンド中心にすることで、i18n やパフォーマンスチューニング等の課題も全てバックエンドに集約できるため対応コストを下げることも繋がりました。タスクの実装日数で見ると当時の 3 ~ 4 割ほど短縮できています。
今回 React は廃止することにしましたが、フロントエンドはバックエンドに乗っかるような設計にしているので、今後フェーズが変わりフロントエンドで複雑な要件が問われるようになった際には再度導入できる柔軟な対応を行いたいと考えています。

設計と実装ルール

次に取り組んだことは新しいシステムの設計と実装ルールの体系化でした。形骸化したり散財していたドキュメントを整理して、ルールの遵守と設計の工程を挟むことを徹底しました。
ドキュメントやルームは作って終わりだと形骸化する恐れがあるため、オンボーディングでの使用、変更点を逐次チーム内で共有、人間で見切れない範囲は Linter や Audit ツールを追加導入して検知できる環境と体制を構築しました。
またロジックの切り出しや共通化はプロダクトチームが作成した要件とデザインを元に実施することで、最適化も図りました。

リプレース

さて、ここまで実装準備ができた後に、新システムでの開発を開始しました。ただし、今と同じ UI/UX でのリプレースではなく、今まで蓄積された課題や要望を反映した新しいデザインでリニューアルを進めています。
プロダクトチームが中心となり、今後の新機能の展開も視野に入れた上で、一から要件定義とデザインを作成を行い、仕様とデザインが出来上がった順に、実装に入るフローで、完成した順に随時リリースも行う予定です。

インフラと DevOps のオートメーション

アプリケーションは無事構築できましたが、インフラと DevOps にも課題がありました。主に、マニュアル運用によるヒューマンコストとミスオペレーションのリスク、運用の属人化によるブラックボックス化で、物が出来ても、入る箱が不安定な状態でしたが、これらはオートメーション化で解決を図りました。

リリースは GitHub Actions を介して ECS へデプロイすることで完全自動化、スケールアウトは ECS と Serverless v2 (DB) をオートスケーリングにすることで、他のメンバーでも対応できるようにしました。
この結果、エンジニアの対応コストがほとんどなくなり、安全にデプロイや増強ができるようになっただけでなく、Hotfix や突発的なアクセスの増加にも素早く対応できるようになりました。エンジニア自身もアプリケーション開発により時間を割けるようになりましたし、オートスケーリングの恩恵で、コストも最適化され、利用料金の削減にも成功しました。
今後は、セキュリティ周りの向上や CDK の導入も進めていきたいと考えています。

最後に

長々となりましたが、改めて振り返ってみると 2023 年もいろいろとやったなと思いました。問題がプロダクトと組織の両方に溢れ出していたので、一時はどうなるかと思いましたが、上手くリセットして再始動できたことは大きなターニングポイントでした。

今後に向けて

2023 年はスケールに向けた土台を作り再始動できたので、2024 年からはプロダクト価値をブーストしたいと考えています。まだまだやりたいことは山ほどあり、新機能の構想やアイデアも蓄積されているので、リプレースしたところから、並行して新機能の実装も進めて、おてつたびの新たな価値の創出にも取り組んでいきたいと思います。

おてつたびで働きませんか？

おてつたびでは一緒に働く仲間を大募集中ですので、興味を持たれた方は採用ページをご確認ください。
特にエンジニアを募集中なので、社会や地域課題の解決に興味ある方やこれから大きくなるサービスプロダクトに関わってみたい方は是非🙌
日本各地にある本当にいい人、いいもの、いい地域がしっかり評価される世界を一緒に創っていきましょう！

おてつたび 採用情報 | Notion