入社して間もない新人がWebアプリケーションの再構築プロジェクトをリードするためにまずやったこと

はじめまして。

今年の6月にネクストイノベーション株式会社(以下弊社)に入社したWebエンジニアの大山と申します。

私が弊社に入社してすぐ、弊社が運用しているサービス「スマ診」のアプリケーションを再構築して大幅リニューアルするプロジェクトが始動し、私も参加することになりました。
現在このプロジェクトにはWebアプリに2名、iOS, Androidアプリに2名と計4名のエンジニアがアサインされています。私は現在Webサーバサイドの開発をメインに担当していますが、プロジェクト初期からWebフロントエンドやインフラの設計のみならず、サービス全体の設計にも積極的に関わってきました。

そこで今回は「入社してすぐ、システムをイチから作り直すプロジェクトに参加することになったWebエンジニア」が、まずはじめに何をやったのかについて簡単にお話させていただきます。

ちなみに、アプリケーションを「再構築」することになった経緯について説明するのは今回のテーマに合わないため割愛していますが、弊社CTOのこちらの投稿に目を通していただければ、ある程度お察しできるのではないかと思います。気になる方は是非お読みください。

アプリケーションを再構築するにあたってはじめにやったこと・やらなかったこと

「アプリケーション再構築プロジェクト」に参加することになった私は入社して間もない新人です。つまりサービスの仕様や運用プロセスについての理解度が他のメンバーと比較して全くない状態です。とはいえ、既存の仕様を把握しているデザイナーの方が新しいUIのワイヤーフレームを作成していたので、フロントエンドの開発にはすぐにでも着手することは可能でした。
しかし、Webサーバサイドの仕様については全く固まっておらず、詳細な仕様を取り決めるためにすぐ動ける人間が私しかいないという状態でした。なので私は早急に現在稼働中のサービスの「いま」を知るために動くことを選択しました。
このプロセスを進めるにあたってはじめに個人的にやったこと、やらなかったことがあったので紹介します。

やったこと

やったことは以下の2つです。それぞれの詳細はこの後に説明します。

1. 社内にいる全メンバーとコミュニケーションを取る
2. サービスの運用に関するフィードバックをもらう

1. 社内にいる全メンバーとコミュニケーションを取る

まずはじめにやったことは、社内の全メンバーとコミュニケーションを取るよう努めることです。
この段階で積極的にコミュニケーションを取る際に優先すべきことは、「自分のことを知ってもらう」よりも「相手のことを知る」でした。どのような人がこの会社とサービスに携わっているのか、どのような領域を担当しているのかなどを早めに把握しておく必要がありました。なぜなら、ある特定の問題を解決するために誰を巻き込むべきなのかが判断できるからです。
これにより、何かわからないことがあったとき、そもそも誰に聞けば正しい答えが返ってくるのかもわからないという状態に陥ることは阻止できるようになりました。

2. サービスの運用に関するフィードバックをもらう

次に現在稼働中のサービスの運用を担当しているメンバーに、運用に関するフィードバックをもらいました。サービスを利用しているユーザからのフィードバックも含みます。
特に、マイナスのフィードバックを中心にもらうようにしました。「この仕様のせいで運用が大変だ」「はじめは必要だと思って追加してもらった機能、今は全く使っていない」「複数のユーザから同じ箇所についての問い合わせがきている」…などなど。
アプリケーションを再構築するとはいえ、現在稼働しているサービス仕様の大半は継承します。その中には、そのまま継承したら結局使いにくいアプリケーションのままになってしまう仕様が混入しています。ですがそれを開発チームだけでは判別できなかったりします。
予め運用メンバーからフィードバックをもらっておいたことにより、「この機能は実装しなくていい！」「この部分の仕様は思いっきり変更してしまおう！」なんてことをサクッと決断できるようになりました。

やらなかったこと

次に意図的にやらなかったことが1つだけあります。エンジニアなのにまじ？と思われるかもしれませんが、「稼働中のアプリケーションのソースコードにしっかり目を通す」ことです。
もちろんソースコードを開発PCに入れ、軽く目を通したり、実行してみたりしようとはしました。ですが、アプリケーションの再構築のための参考としてちゃんと確認したのはデータベーステーブルの構造だけでした。(Railsが分かる人にしかわからない表現ですが db/schema.rb だけしっかりチェックしました。)
それほどデータベーステーブルの構造というものはアプリケーションの仕様に直結しているものです。その他のロジックがどう実装されているのかについて理解することは、この段階においては全く必要ありませんでした。

Webアプリケーションを再構築する際の技術的な選択

入社してすぐ「アプリケーション再構築プロジェクト」に参加することになった私はどうにか現在稼働中のサービスの「いま」を知り「これから」をイメージできるようになりました。
その結果、再構築するWebアプリケーションに対して以下のような技術的選択を行いました。

Webサーバサイド

既存のアプリケーションはモノリシックな構造で構築されています。しかし、今回のような破壊的な仕様変更がいつ訪れてもおかしくないです。引き続きモノリシックで構築すれば、またどこかで破綻する可能性が十分にあります。
そういったコストを避けながら爆速で成長し続けるために、今回からモノリシックではなくマイクロサービスという形でサービスを構築することにしました。
フレームワークは引き続きRuby on Railsを採用。マイクロサービスということもあり、Hanamiも検討していましたが、知見が無いため今回は採用を断念しました。
現在はRails5.2のAPIモードで構築された5つのマイクロサービスを立ち上げ、順次開発を進めています。

Webフロントエンド

今回からiOSとAndroid向けネイティブアプリの本格的なリリースが決定しており、サーバサイドではネイティブアプリ用にJSON APIを実装する必要があります。このJSON APIをそのままWebアプリケーションのフロントエンドでも使用できれば実装コストを削減できるうえ、よりよいUI/UXをWebアプリケーションからでも提供できるため、React.jsベースのSPA(シングルページアプリケーション)を採用しました。SSR(サーバサイドレンダリング)対応などにも考慮した結果、Next.jsを使用して開発中です。
Next.jsの導入奮闘記は別のエンジニアが担当してくれる予定です。(無茶振り)

インフラ

AWSを利用します。現在稼働しているアプリケーションはEC2インスタンス上で稼働していますが、次に新しく構築されるWebアプリケーションの各サービスはすべてDockerコンテナ化され、ECS+Fargateで稼働させる計画です。
ECS+FargateやDevOpsについては知見が集まり次第、別途記事を作成して投稿できればいいなーと思っております。

まとめ

入社してすぐ「アプリケーション再構築プロジェクト」に参加することになったWebエンジニアの私がまずはじめにやったことは、ディレクターっぽいことを自発的にやる、でした。
今回のテーマ的に、あたかも私だけがディレクションを行っていたかのような内容になってしまいましたが、実際には開発チーム含め社内メンバー全員がこのようなプロセスに積極的に取り組んでいます。
それぞれが担当する領域に縛られず、メンバー全員が積極的にコミュニケーションを取っており、一丸となってよりよいサービスを私達全員で発信していくのだという強い志を持って活動しております。
今回はこのことをエンジニア的な味付けをしつつ伝えようと頑張ってみましたが、なんかオチが雑になってしまいました！
次はもっと技術的な内容を投稿する予定です！お楽しみに！

ネクストイノベーションではエンジニア募集中です！！！