いよいよ入社して半年くらいになった。入社後、今まで色々なことが本当にたくさんあったが、その中でもまず一番記憶に残る新機能を具現について記録しようと思う。

現部署で担当しているサービス

配属された部署で担当しているサービスは色々あるが、一番大きな規模を占めるのが不動産アーカイブというサービスだ。サービス名からある程度分かったかも知れないけど、日本国内でLIFULLを経たすべての不動産の過去情報（賃貸、売買、土地等の相場、周辺駅等提供する情報が多様）をArchivingしておくことで、お住まいを探している人たちがより簡単に地域別不動産情報を得られるようにするデータベースの役割を果たし、情報不均衡を解消するサービスだ。

明確な事実ではないが、不動産情報を取得し得ようと検索してLIFULL　HOME'S(以下LH)にアクセスする人の半分程度は不動産アーカイブを通じて流入するという。そこで、部署で施策として提示されるSEO最適化やUI改善も、結局すべてLHサイトにユーザーが移る比率（普通、送客率という）を高めるための施策が中心になっている。私が、実装を務めた新機能もこのような流れで提案された施策だった。

実装したい新機能

ネットを通じて住みたい家を検索している人たちが一番見たがっているのが、多分その家の内外の写真になると思っている。私が実装した機能も不動産アーカイブに集まっている建物の各住戸の写真を集めて見せてくれる機能（通称ギャラリーページ）だった。各建物別にある複数の部屋、キッチン、トイレなどの写真を一ページに集めて見せる機能だった。

実装を開始する前に、機能仕様書を確認してDBの中身を確認するまではそんなに難しくない機能実装だと考えていた。単純に、各建物のIDと1:N関係である各住戸のIDを取得して、それと関連したイメージを持ってくるだけだった。また、paginationもないので、イメージが保存されているS3 BucketのURLを持ってくるだけで簡単な実装になると考えた。

プロジェクトSource codeに向き合う

そうやってスタートは非常に軽い気持ちで始めたが、その気持ちは長く続かなかった。基本的にMVCパターンとDIを導入していたが、長い間様々なエンジニアの手を経てきて今のコードになっていたため、実装に着手することは思ったほど簡単ではなさそうだった。

数多くの複数のファイルを見ながら、約7年という短いといえば短く、長いといえば長い間修正されてきた実際のProductのソースコードは、やはり規模が大きいという驚きと共に、一方ではこのように複雑な構造を持つコードをいつ全て把握するのかという心配が大きかった。

また、Back EndだけでなくFront Endも全て実装を担当する予定だったので、Routingをはじめ少しずつコードのあちこちをいじって、具現に必要なすべての構造を把握することまでに約2~3日間かかったようだ。

実装を完了してレビューしてもらう

それでも先輩たちにどうにか助けていただいて、約1週間にわたってFrontとBack Endの実装を完了した。しかし、本当に難しかったのは、その後にFrontとBack Endに分けて、2人の先輩エンジニアにソースコードレビューを受け始めてから始まった。自分では「画面がデザイン通りにちゃんと出てるから大丈夫かな？」と思っていたけど、私が作成したコードは既存プロジェクトの構造を全く考慮せずに私だけのスタイルで作成されていて、変数やメソッド名、さらにファイルの位置と名前なども既存プロジェクト構造に合わせて修正しなければならなかった。

そして新たに追加されたコードの安定性を担保するためのE2EとUnit test作成も必ずしなければならなかったので、テストコードを一回も作成したことがない私には、本当に大変な時間だった。今その瞬間にもデータをMock化するため書いたallowとandReturn、テスト値を確認のため書いたexptectとtoBeが頭の中をぐるぐる回っているようだ。（以降、シナリオテスト仕様書を作成することも簡単ではなかった··· )

このようにすべての機能を実現した結果、最後のApproveを受けてMergeになる直前のソースレビューの数は205個になっていた。 FrontとBack Endの両方を同時に実装したためレビュー内容が多かったものもあったが、上で言及した細かい修正事項が多かったため、ミスをしたり見逃した部分も本当に多かった。この時、初めて「機能実装で思ったよりコーディングが下手なのかもしれないな…」と感じて自慢していた自分自身を反省した。

実際にサービス中のプロジェクトに新機能を実装することで感じたこと

ソースコードを読んで構造を把握できる能力の重要性
機能実装に使用した約3週間の期間中、30~40%以上の時間を既存のソースコードを読むのに使用した。それにもかかわらずコード構造を自分勝手に分類してしまい、その構造を再び直すのにかなり多くの時間を使ってしまった。
テストの重要性
実装された機能はdevelopブランチにmergeされたらすぐ内部のテストサーバーに配布されている。そうなのにテストしてみようとした時に500エラーが起こってしまった。エラーが起こる理由が全くないのに起こっていて迷っている間に先輩エンジニアがJSのMinifyが問題かもと話してくれた。開発用サーバーで再確認してみたら、同じ500エラーが再現できた。（原因はMinifyパッケージとして使用しているuglife-jsがES6以上をサポートしていなかったからだ…）もし、これがテストサーバーの確認なしにすぐライブサーバーに配布されていたら。。。本当にひどい。。。
几帳面な確認がエンジニアから必要
機能実装を完了した後も無分別なFlow control文使用で起こったCognitive complexityを解消したり、イメージが1枚もないのにタイトルが出てくるバグを解消したりするため、約3つのPR程度を再修正作業を行った。ソースコードをレビューする人、アイデアを出した企画者、デザインを作成したデザイナーなどの多い人に数回ダブルチェックを受けたのに、結局問題が発生した。しかし、その状況ごとになぜその問題が発生したのか、一番よく把握できている人は結局私だった。その意味は機能実装を引き受けたエンジニアが几帳面にチェックすれば、仕事を2、3回とすることはないということだ。
機能実装の以外にも、ビジネス的にも考慮しなければならないところが多い
学生の時に一回も経験できなかったのがSEO最適化と顧客データ管理のような部分だった。今も実際に色んなユーザーから使われている不動産アーカイブのようなProductは、ユーザーデータを絶えず分析し、露出率を高めることで価値創出または収益を出すために存在する。そのために各ページに適切なTagや色んなCookieを追加し、Sitemapを生成する必要がある。ここで、LIFULLのエンジニア組織で中心する「技術で経営をリードする」というスローガンの意味が大きく響いたようだ。

結論

このように色々な苦難(?)を体験しながらある程度8~90%程度実装を終え、自らに賢者タイムを感じていた私に先輩社員がこのように新機能実装する機会自体があまりなくもあり、0から100まで実装することは私が務めても難しかっただろう。主にFrontとBack Endを分担して実装するが、初タスクで両方ともうまく具現したと言われて、

次はもっと頑張らなきゃ！！

と思った。今この感情を忘れないで、これから200日、300日以上根気よく勤勉にできるように努力しよう。