theN

## プロジェクト概要と課題 観光関連の顧客を持つ企業様（B社）の空き室マッチングサービスの構築に携わりました。2020年はコロナ禍ということもあり、観光業を始めとした多くの業種が経済的な打撃を受けました。 B社様では、経済的被害を受けている顧客に向けて、会議室や空室、部屋などを貸し出しを行う空き室マッチングサービスを企画立案されました。 そこで私が所属する企業にてシステム構築を行うこととなりました。　 ## プロダクトアーキテクチャ B社様は実績のある大手の企業であり、どちらかといえば保守的な企業です。これまでの案件でも安全性の高い、いわゆる枯れた技術や言語を使って実装をおこなっていました。 ですが今回のこの案件ではB社様社内でも挑戦的なプロジェクトと位置づけられており、新しい技術を取り入れた開発をしたいとのことでした。そういった経緯もあり、また元々私が興味があり、趣味プログラミングとして利用してきたサーバレス構成を使ってみたいと考えました。まず私の会社で上司、チームに向けて提案を行い、ぜひ使ってみようとのことでB社様に実際にサーバレス構成での提案を行うこととなりました。 フロントエンドはVue.js（Nuxt.js）を使い、バックエンドはPythonをLambdaで動かしました。APIはGraphQLも検討しましたが、REST APIを採用しました。 ## フロントエンド開発での技術検討 この案件フロントエンドは2名で開発を行いました。その際にVue.jsを使用しましたが、Vue.jsのフレームワークであるNuxt.jsも合わせて採用しました。Nuxt.jsはサーバサイドレンダリング（SSR）を実現するフレームワークとして有名ですが、今回は社内業務システムという特性もありSEO対策のためのSSRは必要ではありませんでした。私はSSRでははなくNuxt.jsのファイル構成が決められている点に着目し、チーム開発の際にガイドラインとなる、という点からNuxt.jsを採用しました。 ## 開発の際に困ったこと 開発は順調に進みましたが、フロントエンド開発の際に障害となった点が3つありました。 1. コンポーネントの設計時間が少なかったこと 1. バックエンドとのAPI仕様が揺らいだこと 1. バックエンドの開発が遅れていたこと 以下にそれぞれの障害となった点について述べます。 ### 1. コンポーネントの設計時間が少なかったこと Vue.jsやReactではコンポーネント単位での開発が可能ですが、今回の案件では納期が短かったこともあり、コンポーネントに分離した設計を行うことができませんでした。結果として大きめのコンポーネントとなってしまいましたが、業務システムということもあり、最大ではページごとに分離されたコンポーネントとすることで依存性を少なくしました。 ### 2. バックエンドとのAPI仕様が揺らいだこと バックエンドの開発はPythonとLambdaで行われました。フルスクラッチでの開発だったためにAPI設計もイチから行うこととなり、バックエンドチームが主体となりAPI設計を行いました。 プロジェクト全体での開発期間は約9ヶ月でしたが、開発初期よりバックエンドチームのAPI設計を開始し、その設計に沿った形でフロントエンドを構築していました。しかし実装が進むに連れ、設計を見直さなくてはならないことが何度か発生しました。 API仕様が変わってしまうとフロント側でもその差異を吸収する必要があり、修正作業が多く発生しました。途中までは修正に追われていたのですが、APIとの結合部分を専用のファイルとして切り出して共通化し、抽象化した結果のみをコンポーネントと戻すことにしました。そうすることで変更が合った際には具体化された結合部分だけを修正し、フロントのコンポーネント部分への影響を小さくしました。 ### 3. バックエンドの開発が遅れていたこと 今回のプロジェクトではAPI設計についてもバックエンドチームが行っていたため、バックエンドの開発が遅れてしまいました。フロントが先行して実装する部分が多かったため、作業待ちとなってしまうことも発生しました。 その後APIが出来上がってからフロントを実装していたのですが、そうするとどうしてもプロジェクト全体に遅れが生じてしまい、フロントエンドがその遅れを取り戻すためにカバーしなければならない、という状況になっていました。 フロントエンドチームに負荷がかかってしまったため、なんとか改善できないかを話合った末、フロント主導でのモックサーバの構築を行いました。API設計ができた段階でモックサーバを構築し、そこにむけて結合を実装し、バックエンドの実装が終わったらモックから実際のAPIに切り替え最後に調整を行う、という工程としました。そうすることでフロントが手待ちとなることが減り、プロジェクト全体では進行の遅れについて、ゼロにはなりませんでしたが、遅れが少なくなりました。 ## プロジェクトを通して学んだこと 今回の案件ではサーバレス構成への取り組みを行いました。直接的にはサーバレスへのデプロイ等は行っていませんが、利用者の増加によるスケールアウトを前提とした構成を行うことができました。 フロントとバックエンドが完全に分離された構成だったため、サーバレス構成でも違和感無く開発を行うことができ、フロントエンドエンジニアとして学ぶことの多い案件でした。

## プロジェクト概要と目的 大手企業様のメディアサイトシステムの構築に携わりました。 既に多くの顧客がいらっしゃる企業様でしたが、さらなる顧客の獲得、また企業のブランドイメージ向上のためのメディアサイトで、多数のライターさんが記事を有益な記事を書き、配信するというサービスでした。 ## 技術的背景とチーム、私の役割 フロントエンド、バックエンドをそれぞれフルスクラッチで開発し、フロントはReactで構築しました。 バックエンドはRDBとPHPで構成されており、パートナー企業さんが担当されました。 バックエンド、フロントとの結合はREST APIで行いました。テーブル数が20 ~ 30ほど、API数が約20個でした。 フロントのReactではNext等を使わず、React RouterやReduxといったバニラの機能により構築を行いました。 フロントのコンポーネント数は約40個でした。 私はフロントのReactのプログラミングを担当しました。 フロントエンドは3人ほど、バックエンドは5人ほどの規模で、私はフロントエンドで多くのコードを書きました。 ## チームでのルール、サーバ、フロントの連携 フロントのチーム開発だったため、チーム内コーディング規約を始めとしたガイドラインを定め、チームメンバーでそれに従い開発を行いました。 元々社内にはReactのコーディング規約がなかったたため、OSSでのコーディング規約等を参考に社内での規約ルールを統一化しました。 開発での連携はGitLabを使っており、チームではCIを使った自動デプロイなども組み込みました。私はバックエンド、CI等には直接携わっていませんが、間接的な相談、多少のコード修正、フロントからのインターフェースの調整等を行いました。 ## 工夫した点 チームではGulpをつかったビルド、SaSSのコンパル等を行っていました。元々社内で共通のGulpファイルをベースにプロジェクトごとに使っていましたが、直近で大幅なバージョンアップがあり、共通のGulpファイルが使えなくなってしまいました。 Gulpに関する情報は国内でアップデートがされておらず、このプロジェクトのために新しいGulpファイルの書き直し、過去の技術的負債となっていたコード排除を行いました。また個人的にES6を扱ってみたかったという点からES6による記述に改めました。 チームから好評をもらい、その後はこのプロジェクトだけではなく、社内の別プロジェクトでも利用されていきました。 ## このプロジェクトを通じて 結果的にサイトをリリースし、企業様にとって良いサービスを提供することができました。 技術的な内容はもちろんですが、顧客企業様のバックグラウンドやビジネスゴールなど、業務全体を通じて大変多くのことを学ぶことができ、私自身がエンジニアとして成長できたと実感し、感謝しております。