ID:52037さん

# プロジェクトの概要 当時は、引越し見積もりサービスの改修をメインで行っていたのですが、引越し見積もりサービス以外にも、ピアノ買取、ガス、電気など、関連するサービスが多く、改修が常に大量に存在している状況でした。 時には、１週間で並行して5つの施策を開発するようなこともあり、開発のスピードをあげることが重要でした。 しかし、開発体制などに関してはあまり改善活動が行われておらず、無駄な工数が多くかかっていました。 そのため、引越し見積もりサービスの​開発効率向上の取り組みとして開発体制の改善を行い、チームの工数を減らせないか自動化に取り組み、長期的に運用する文化を作る努力をしました。 当時は、新卒一年目かつエンジニア経験が全くない状態だったので、あまり技術的なアプローチで解決できたことは多くなかったのですが、自分にできることを常に意識していました。 # 抱えていた課題 - 開発時のコミュニケーションに関する課題 - 他部署との連携不足による手戻り作業の発生 - 口頭での情報共有が多用されること認識齟齬の発生、など - 保守や業務改善系のタスクに割ける工数がない - リリース前の動作確認が全て人力で残業が多発 # 課題に対するアプローチと結果 上記の課題を整理し、下記３つのアプローチを取ることにしました。 - 他部署との情報整理の仕組みづくり - 長期的な利益のための保守運用を意識したチームの意識改革 - チームの工数削減のためのリリース前のテストを自動化 ## 他部署との情報整理の仕組みづくり ### 具体的な課題 当時は、バックエンドエンジニアとフロントエンジニアが異なる部署に配属されており、改修を行う際には部署間を超えたコミュニケーションが必須でした。 また、当時は担当者によって報連相の方法にかなり差異があり、また無駄も多かったため、認識齟齬が多発していました。 例: - 企画者が仕様をGoogleDocsにまとめて展開しているが、追加仕様を口頭やチャットで連絡され、Docsに追記しない - 仕様変更が一方の部署のエンジニアにしか連絡されない - 仕様が伝言ゲームで伝わってくるため、基本的に正しい情報がわからない ### 解決策 仕様や作業進捗の共有の伝達の手段をスプレッドシートに限定することで、情報が散らばらないようにするという取り組みを実施しました ### 結果 これまで口頭でやりとりしていた内容を、スプレッドシートに記載するようにチームとして情報を統一することで下記のメリットが生まれました。 情報の抜け漏れなどのミスの抑制 非同期的なコミュニケーションが可能になり、相手がその場にいなくても共有したいことをとりあえず記載するということができるようになった。 報連相の方法が統一化されたため、混乱が生じにくくなった ## 長期的な利益のための保守運用を意識したチームの意識改革 ### 具体的な課題 古くから運営されているサービスが多く、リファクタもあまり行われていなかったため、レガシーなコードや、全くリーダブルではないコードが多数存在していました。 下記はその一例です。 - 1つのコントローラに1000行以上のコード - 同じロジックが複数箇所に存在する - 大量にネストしたif文 - 実際の振る舞いと異なる命名 - 大量のTypo - テストコードが存在しない このようなコードが原因で、開発の効率低下や不具合の発生を招いていました。 ### 解決策 「保守の工数をもらうための交渉」と「開発と並行してリファクタリングを行う取り組み」を行いました。 **保守の工数をもらうための交渉** そもそも保守に工数を割くという文化があまり無い状態で、長期的な利益のためよりも、すぐに効果がありそうな事業系の開発が優先されてしまう経営上の課題があるように感じていました。 そのため、保守の重要性を訴え、保守工数をもらうための交渉を行いました。 交渉した結果、表向きは理解してもらえたが、「保守よりも優先して実装してほしい」という前置きで事業系の開発依頼をされることが多く、偶然施策が少ない時にしか保守の取り組みが行えませんでした。 **開発と並行してリファクタリングを行う取り組み** リファクタリングしたい箇所を事前に洗い出しておきました その付近を改修するような施策が発生した際に、併せてそのリファクタも行うように積極的に提案し、実施していました。 ### 結果 チームに長期的な利益のための保守運用の重要性を理解してもらうために、説得や説明を行っていたのですが、なかなか文化に根付かせるところまでできませんでした。 ただ、保守として工数が確保できなくても取り組めるところから少しずつリファクタを実施した結果、コードの可読性などを多少改善できました（少なくとも、1000行を超えるような関数は削減できた）。 このリファクタから、どんなコードでも諦めずに粘り強く取り組む根性は身についたように思います。 ## チームの工数削減のためのリリース前のテストを自動化 ### 具体的な課題 引越しサービスには10種類(5つのドメイン x アクセスデバイス[PC/SP])のLPが存在しています。 それぞれのLPのフォームが共通のロジックを用いていながら全て仕様が異なるため、全LPの動作チェックを行う必要がありました。簡単なCVテストだけでも最低10回CV、細かなバージョン違いを考慮する場合50以上の導線が存在するにもかかわらず、これら確認作業が全て人力で行われていました。 そのため、これらのフォームの確認作業を自動化する取り組みを提案し、課題の解消に取り組みました。 ### 解決策 Cypressを用いてE2Eテストの導入に取り組み、リリース前のCVテストを自動化しました。 デバイスによって異なるテストを行う必要があるため、UA毎に異なるテストを実行するような仕組みを用意したことが工夫した点です。 こちらが、当時まとめた記事です。 https://qiita.com/m-otsuka/items/c321eb284c3356d804b4 ### 結果 主要なフォームのCV確認をE2Eで行えるようになった。 当初は、CIに乗せる予定だったのですが、当時の自分の技術的な知識不足や工数不足によって、手動でE2Eテストを走らせる運用になってしまいました。 また、頻繁にLPOやEFOが行われる状況であったため、E2Eテストが通らなくなることが多々あり、そのメンテナンスに工数が避けないという問題が新たに発生してしまいました。 ただ導入するだけで満足するのではなく、その後の運用の環境まで整えることが重要だということがこの経験で得ることができました。

# 抱えていた課題 引越しの予約サービスの引越し見積もり金額の概算を行うAPIは、長期間リファクタが行われておらず、下記の課題が生じていました。 コードの可読性が低く、読み解くだけでも工数がかかる 影響範囲が理解しづらく、不具合が多発 APIのレスポンスが遅く、サイトパフォーマンスが低下していた。 PHP(Version 5), Symfony(Version 1.4)という公式のサポートが切れたバージョンが使用されている。 変数にどのような値/型の変数が入っているか、解読が難しい テストコードが書かれていない そのため、このAPIをリプレイスするというプロジェクトが実施されました。 # 課題に対するアプローチ リプレイスでは、下記を採用しました - Golangを採用 - クリーンアーキテクチャの採用 - テスト駆動開発（TDD） ## Golangを採用 採用理由 - 静的型付け言語であり、エラー検出がしやすい - 文法がシンプルで習得が容易かつ表記のばらつきが小さい - 処理が高速で、並列処理も書きやすい Golangを導入して一番恩恵を感じるのは、コンパイル時にエラーに気づける点です。 また、テストやベンチマークのパッケージが標準で含まれている点も、テストコード作成の敷居を下げてくれていたように感じます。 文法の学習に関しては、想定よりも苦労しました。 基本的な文法の習得は容易ですが、Golangらしいコードを書くためにはそれなりに学習が必要だと感じました。 ## クリーンアーキテクチャの採用 既存のシステムではSymfonyを用いていたため、MVCに基づいて開発を行なっていました。（自分が初めてコードを読んだ時には、すでにMVCはタコ殴りにされていたが。） リプレイスでは、あえてこれまで触れたことのないクリーンアーキテクチャを採用することで、今後のアーキテクチャの選択肢を広げようとしていました。 リプレイス初期は、クリーンアーキテクチャのメリットを感じることはあまりなく、むしろ想定の1.5〜 2.0倍の工数がかかってしまっている印象でした。 その要因は、クリーンアーキテクチャがMVCと比較してコードが冗長になりやすく、また、依存性逆転の原則など直感的に理解しづらい要素が多いことだと分析しています。 また、クリーンアーキテクチャに厳密に従えないケースが多く、結局依存は外部に向いてしまうなんちゃってアーキテクチャになってしまうことも多々ありました。 ある程度開発が進み、クリーンアーキテクチャの冗長性に慣れ、多少の独自性を受け入れた段階でようやく開発スピードが伴い始めたのですが、このプロジェクトを期限内にリリースすることだけを考えれば、慣れ親しんでいたMVCを選択すべきでした。 引越し新サービスの立ち上げの際には、この時の経験を活かし、クリーンアーキテクチャでスムーズに開発できたので、知識を蓄えるという点では成功しました。 ## テスト駆動開発（TDD） テストコードが存在せず不具合が多発していた既存のシステムを反面教師として、リプレイスではテストコードをしっかりと作成することを重要視していました。 そのため、リプレイスでは開発手法としてTDDを取り入れました。 初期はTDDに則って開発できていたのですが、リプレイス後半においてはリリース締め切りに追われ、テストコードの作成を省力するという事態に陥ってしまいました。 テスト文化を根付かせるためには、個人の意識づけだけではなく、明確にルールを設けたり、lintなどのツールを入れたりして、テストを無視できない環境にする必要があるということをここで学びました。 # 結果 想定よりも開発に工数がかかってしまったことを理由に、リプレイスプロジェクトはリリースされることなく終わってしまいました。 開発が遅延した理由は、Golangやクリーンアーキテクチャの習得に至るまでに工数がかかったことに加えて、開発の体制にも問題がありました。 リプレイスプロジェクトは既存サービスの業務と並行して進めていたため、リプレイスの開発時間中に既存サービスの関して問い合わせが飛んでくるなど、開発に集中しづらい環境になってしまっていました。 リリースまでやりきれなかったことはとても悔しかったですが、ここで学んだ知識が次のプロジェクトに活きています。

# プロジェクトの概要 WEB上で完結できる引越し見積もりサービスを目標に立ち上げられたプロジェクト。 ## 抱えていた課題 半年以内にリリースするという期限がありました。 ## 課題に対するアプローチ - 締め切りが近くかなりハイスピードな開発が必要であったため、要件を達成するために、フレームワークやツールの技術選定を慎重に行なった。 - 慣れていない技術に対して、チーム全体で成長するために勉強会を定期的に実施/参加しました - Frontend Talks(フロントエンドに関して、発表/議論する会) - コンポーネント設計について - storybookの活用法について、など - Backend Talks(バックエンドに関して、発表/議論する会) - Golangでのテストの並列化について ## 使用技術について ### バックエンドの使用技術について - Golang - gin - PostgreSQL - GraphQL, Hasura - Firebase #### GraphQL、Hasuraの採用 バックエンドAPIの開発工数の削減のためにGraphQL、Hasuraを採用しました。 GraphQL、Hasuraを活用することで、基本的なCRUD処理に関しての開発をスキップできたことは、かなりメリットに感じました。 **GraphQLのよかったこと** 1つのリクエストで複数のリソースを取得できるため、通信回数を抑えることができた。 クエリで必要なデータだけを取得できる データの型をschemaで定義しているため、クライアントとサーバーで型のズレが発生しにくい **Hasuraのよかったこと** - 低コストでGraphQLサーバを構築できる - PostgreSQLサーバーさえあればすぐに使える - GraphQLのN+1問題に標準で対応済み - テーブルを作成すれば、SELECT, INSERT, UPDATE, DELETEなど基本的なAPIが自動生成される - ページングや集計も行える - フロントエンドの開発を始めることができる - 認証・認可処理の実装の手間を省ける - REST API も作成できる - GraphQLのschemaをエクスポートできる - フロントとのschemaの連携がしやすい **失敗したこと、苦労したこと、挫折したこと** ビジネスロジックが複雑な場合、Hasuraが自動生成したAPIが利用できないことが多い。 結局mutationを自作することになり、Hasuraによる工数削減のメリットを享受できない。 HasuraにはQuery Cachingをサポートしていたが、セッション変数を用いてクエリやユーザーの権限周りに処理を行っていたので、利用できなくなってしまった。 ### 設計について 過去のリプレイスの時に採用していた、クリーンアーキテクチャをここでも採用しました。 ### 開発体験の向上について リプレイス時の反省を活かし、テストコードを書く文化を根付かせようとする動きを積極的に行ないました。 - テストコードのないコードをレビューで弾くことを徹底 - テストの書き方について勉強会を行った - linterの導入(並列化されていないテストを弾く) ## フロントエンドについて ### フロントエンドの使用技術について - Type Script, React, Next js - Relay, GraphQL #### React.js, Nextjsを採用 このプロジェクトより前のプロジェクトでも用いておりノウハウをそのまま活用できると判断し、React.js, Nextjsを採用しました ### 課題 当時、フロントエンドをメインで担当しているエンジニアの人数が少なかったことが課題でした ### 解決策 フロントエンド側の開発に自分も参加できないか提案したことをきっかけに少しずつフロントエンド側の開発にも携わるようになりました。また、React.jsに触れたことのないエンジニアもいたので、定期的な勉強会を実施していました。 積極的に手を上げ機会を掴んだ結果、TypeScriptやReact.jsなど現在では基本的なことは一通り理解できるようになりました。 加えて、バックエンドをやってきた知識を生かして、Hasuraからデータを取得、対象のコンポーネントまでにデータを渡したりAPIからのデータ取得、加工周りのロジック、一部コンポーネントの設計など活躍の機会が広がりました ## まとめ これまで基本バックエンドの担当だったのですが、このプロジェクトからは人員の関係でフロントエンドのタスクにも携わるようになったことで、バックエンドとフロントエンド双方を考慮する視点を持つことができました。 また、フロントとバンクエンドともに自分にとっては新しく触れる技術ばかりだったので、学ぶことが多く大変でしたが、とても成長できたように感じます。

引越し新サービスのリリース後は、自分の技術分野の幅を広げるため、データ分析、機械学習の業務に志願しました。もともと機械学習に興味があり、機械学習に関して独学したりKaggleにチャレンジしてみたりするなど将来に向けた取り組みを行っていました。 独学の内容 - 統計、機械学習、ビッグデータなどの本を合計8冊読んだ - kaggleのコンペに参加 - 参加したコンペ https://www.kaggle.com/competitions/tabular-playground-series-may-2021 - 結果、上位31% - (いつかもう一度チャレンジして、次はメダルをとりたい） これらの取り組みが認められ、データ分析/集計/機械学習周りの担当を任されました。 ## 代表的な取り組み ### 受注の可能性が高いユーザーの要素の発見 ユーザーの引越し情報の中から、ガスや電気の切り替え勧誘の成否に影響する特徴量を見つけ出す取り組みを行いました。 具体的には、下記のことを行いました。 - ユーザーの引越し情報を用いて、ガスや電気の切り替え勧誘の成否を予測するモデルを作成する。 - そのモデルをSHAPで解釈することで、ガスや電気の勧誘成功につながる要素を見つけ出す **自分が行ったこと** - モデル作成に利用するユーザーデータの取得するための仕組みづくり - データの前処理 - 正規化 - One Hot Encoder などなど - 特徴量の作成 - 例：　サービス利用日と引越し希望日の日にちの差分 - 急ぎで引越しの予約をしようとしているユーザーは、電気やガスの手続きが終わっておらず、ガスや電気の勧誘が成功しやすいのでは？　という仮説があったため、特徴量として追加 - LightGBMでモデル作成 - SHAPでモデルを解釈し、重要な特徴量を発見する #### 結果 発見した結果を外部に発信して良いか分からないので、内容については伏せるのですが、この取り組みによって、新たな傾向の発見やこれまでの知見の強化に繋がりました。 ### dbtの導入 引越し見積もりの新サービスでは、RDBやGA4、Google広告のデータをBigQueryに蓄積していました。ただ、BigQueryに蓄積されたデータをそのまま活用するのは困難であったため、dbtというELTのT（データ変換）を行うためのツールの導入を進めました。 https://www.getdbt.com/ #### 導入した理由 データ加工の作業を容易にし、下記のような課題を解決するためにdbtの導入を提案しました。 - BigQueryに蓄積されているデータが扱いやすい構造ではない - GA4がエクスポートするデータなどでは、配列型が使われており、そのままでは扱いづらい - データの形式がリソースによって異なるため、比較等が行いづらい - 例：　日時関係のデータの持ち方がリソースごとに異なる - DATETIME型 - TIMESTAMP型 - STRING型(“YYYYMMDD”) また、今後データ分析に関わる人が増えてくると、大量のクエリが乱造されることが予想されるので、それを防ぐという意味でもデータ加工周りの処理をdbtで管理すべきだと考えました。 #### 工夫した点 - モデルを管理しやすくするための設計 - データ変換の役割ごとに、レイヤーを作ってモデルを管理しました - インターフェース - データ構造はそのままで、型変換やタイムゾーンの統一などの軽い変換を行うレイヤー - コンポーネント - 「ユーザー」「引越し予約」など要素ごとの加工/変換を行うレイヤー - コンポーネントモデル同士を組み合わせて新たなコンポーネントモデルを作成することも - データモデル - コンポーネントモデルを組み合わせて、最終的に利用するデータを作成するレイヤー - SQLのLinterであるSQLFluffを導入 #### dbtを導入してよかった点 - 複雑な変換ロジックをモデルに押し込めることができる - 非エンジニアの分析担当は、データモデルからSELECTするだけで必要なデータにアクセスできる状態にできるようになりました。 - エンジニアの管理工数を下げて、チーム全体で動けるようになりました - 各モデルにテストを書くことができる ## 今後に向けて 機械学習などを学びはじめて、かなり幅広い知識を深く知る必要のある分野であると感じました。ライブラリを使うだけでそれらしいことはできますが、どのようなアルゴリズムが裏で動いているかを把握したり、より精度を上げるためにはどのような手法を取るべきなのかなど、学ぶべきだと思う分野が尽きません。そのため、現在でも継続的にデータ分析、機械学習などの独学を続けています。最近は、基本となる統計の知識をしっかりと身につけようと思い、統計検定2級にチャレンジしようとしています。