tsukasa seya

# プロジェクトについて - 当サービスは、就活生がユーザー登録を行い、サイト内の掲載就活イベントにエントリーすることができるサービスである。そして、イベントエントリーを介してユーザーと企業(クライアント)をマッチングさせるサービスである。 - 主にRuby(Rails), Javascript(TypeScript, React)で実装を行う。 - チームメンバーは、以下の通り。 - 開発エンジニア：5 ~ 7人（時々により人数の変動があります） - PM：1人 - 担当フェーズ - タスク毎に要件定義から保守運用まで一気通貫して行う # 比較的大きめのタスク - ユーザー情報に係る学校マスタ（全国の短大, 大学, 大学院の学校名, 学部, 学科の情報）の更新 - gem nokgiriを使用したrakeタスクによりWEBスクレイピングを行う - 抽出データをDBと突合することで差分を抽出しつつ更新を行う - 入社後1ヶ月経った頃に初めて取り組んだ大きめのタスクということもあり反省点が多いと感じた。 - 当時はワンタイムな処理でしかタスクを完遂させることしかできなかったが、理想は学校情報に変更があるたびにそれが学校マスタに反映されることなので、今思うと以下のような設計ができればよかったと感じる。 - スクレイピング＆HTML解析を容易に実行することができるpythonのBeautifulSoupというライブラリを使用してスクリプトを組む。 - Rails側で学校マスタ更新用のエンドポイントを作成。 - スクリプトでは変更差分の有無の確認、及び変更がある場合はその内容をRailsで用意したエンドポイントにPOSTする。 - また、スクリプトの処理として、解析内容は特定のフォーマットに沿った内容でS3に保存し、次回の変更差分の有無の確認はそれを読み込んで行う。初回実行時だけはCSVを事前に用意する。 - API GatewayでS3にアクセスするためのインタフェースを作成。 - スクリプトは、AWS Lambdaで定期実行する。 - ERBで構築されたイベントエントリーフォームをReactで書き直す - 自分と他フロントエンドエンジニアの合計2人で行う - 自分の担当は「エンドポイントで必要になるデータの解読」及び「フォームで必要になるオプションの値の形成」である - イベントエントリーに係る処理はドメインロジックにあたり、複雑に分岐が発生していてコードの理解に苦戦した。 - EFOによる会員登録フォームのCVR改善 - デザイン及び登録プロセス変更によってCVR改善を目指す - PMと相談しながらプロセスを数段階に分けてABテストを繰り返すことで変更を徐々に加えていった - CVまでのフォーム離脱の確認は、トラッキングデータをFirebase Functionsで作成したエンドポイントにPOSTすることでFirestoreに溜まるようにし、それを別途設置したviewで可視化することで行った。 - POSTは全てBeacon APIを使用。そのため、非同期かつレンダリングをブロックしない。 - 仮にFunctionsが死んでいて500エラーが起きても、ユーザー側への影響はない。 - ユーザーのマイページ上でのイベント参加日程変更機能作成 - 特別難しい実装をしたという話ではないが、サイトのドメインロジックでありサイト全体の機能に大きく影響するポイントになるので、慎重になる大事なタスクだった。 - オンライン模擬試験ツールの作成 - バックエンド2人(自分含む)、フロントエンド1人、デザイナー1人、PM1人の小数チームで取り組んだ。 - このとき、自分は開発に加えてディレクション業務を兼任した。PMに対して要件定義を行い、設計からタスクの優先度決定及びその分配、コードレビュー、そしてそれらの進捗管理を行った。 - このタスクでは、バックエンドとフロントエンドの実装は完全分担で行った。しかし、実装上でトラブルなど起きることは無く非常に円滑に事を進めることができた。 - このようなケースでは、例えば、バックエンドとフロントエンドのデータ連携部分となるAPIの入出力の部分で議論が起き足踏みすることがあると伺ったことがある。 - 今回そのようなことが無く円滑に連携して業務を行えた理由は、以下だと考える。 - 初めの設計の段階で「どのようなデータが」「どのような形式で」「どのタイミングで必要になるか」をエンジニア3人でしっかり共通理解を構築し、ある程度具体的な形で設計できたこと。 - 実装していく中で流動的に初期設計内容と異なる内容で実装したいというケースは必ず現れるため、チームの定期的なMTG以外でもエンジニア3人で細かいコミュニケーションを積極的に行うようにしていた。 - コミュニケーションの内容は、主にエンドポイントのデータ形式の変更についてや、実装の着手順の調整。また、変更が発生する度に、ドキュメントにその内容と簡単な経緯を残した。 - ユーザー情報取得に係る新規フォームの作成 - クライアントへのユーザー送客最適化に伴い、営業を行う部署と協力し、要件定義から設計、実装まで一貫して行う。 - 当タスクは、比較的取引の多い複数のクライアントの要望を基に発生したものであり、ユーザーから取得したい情報が具体的にクライアントから提示されていた。そのため、要件定義での営業部署へのヒアリングの中で、クライアントとの実際のやり取りの内容を見せてもらって機能設計の参考にさせてもらったこともあった。 - Railsのバージョンアップ(5.2系→6.0系) - プロジェクトメンバー全員(6,7人程)で分担して行う - これに伴って使用gemのバージョンアップを先に行う - Railsのバージョンアップが必要なgemについては、Railsのバージョンアップと同時に行う。

# プロジェクトについて - Wordpressによるコラム型コンテンツのオウンドメディアをリニューアルする。 - コラム型コンテンツの拡張、コンテンツ掲載以外の機能拡張を目的としている。 - その立ち上げから保守運用まで一気通貫して行う。 - 使用技術（言語やフレームワーク等）の選定も行う。 - 主にRuby(Rails), Javascript(TypeScript, React)で実装を行う。 - チームメンバーは、自身と他にインフラエンジニアとデザイナー、PMを合わせて4人。 - インフラエンジニアは以下を担当。自身の機能開発と並行して行う。 - AWSでの CodePipeline による CodeBuild を使用した ECS へのデプロイ - staging環境構築 - バックエンドはRailsを使用する。下記は、その背景。 - Node.js+TypeScriptによるフロントと同言語での実装やHeadlessCMSの導入等も検討材料として含めたが、リリース時期を考慮して迅速に開発する必要があったこともあり、自身が一番使い慣れている技術を選択する必要があった。 - また、社内のスキルセットから見てもバックエンドは9割Railsエンジニアであるため、Railsを使用した方が社内リソースでの継続的保守運用がしやすかった。 - Rails(Ruby)は決して旬な技術とは言えないが、まだまだ現役の技術であるため、採用という観点からもRails(Ruby)エンジニアは新規採用がしやすく安定的な運用につながることも考慮。 - また、社内での教育もしやすく、コラム型メディアということもあり特別複雑な処理が存在するプロジェクトではないので、最悪Rails初心者でも開発に着手可能。 - フロントエンドの開発において 、TypeScript + Reactも採用。下記は、その背景。 - 初期リリースにおいてはRailsによるERBも含めて実装するため、使用技術において特別な縛り等はなかったが、今後の採用活動の中でモダンな技術を積極的に組み込んでいることを実態に合わせて見せたいという開発部の思いがあった。 - また、社内の他プロジェクトにおいて、主要な全ての開発がTypeScript + Reactへ移行していることがあった。 - 加えて、開発部として社内のエンジニアにはTypeScript + Reactでフロント実装できるようになって欲しいという思いがあり、自分もそれができるようになりたいと常々思っていたことがマッチし、それを実行できる大きなチャンスであったため。 - 要件定義、基本設計、詳細設計、DB設計は自身で行う。 - 今回のプロジェクトの要である「コラム型コンテンツ」の永続化する設計について - コラム編集は、markdown形式で行うことになった。 - それにより「編集はmarkdown」「表示はHTML」と二つの状態が存在することになる。このとき、表示の度にmarkdownをHTMLに変換するのは非効率なため、それらをそれぞれ何らかの形で保存した方がいいと考えた。 - そこで、コラム用テーブルには単一のHTML形式データだけを保存し、markdown形式のデータだけをログのように残す形で保存するテーブルを別途用意することで、表示の度にデータ形式変換を行わなくて済むようにした。 - Mementoパターンとは言えない構造だが、これと同じように過去の状態に戻すことも可能となる。 - 懸念点としては、編集が増えるほどメモリへの負担も大きくなっていくこと。そのため、古いデータは定期的に削除するようなライフサイクルを組み込まなければいけない。 # これまでのタスク ## 環境構築 - Webpack導入によってバックエンドとフロントエンドの開発環境を分離する - TypeScript + Reactの開発環境構築 - Jest, ESLint, Prettierの導入 - MySQL, Rspecの導入 - Dockerの導入 - Node.jsとRailsのマルチステージビルドによってイメージサイズを最適化する ## 機能開発 - Wordpress DBの記事コンテンツをRails DBに移行 - 画像のアップロード機構作成 - gem carrierwave を使用 - 画像のリサイズには libvips を使用 - libvips の選択の背景 - ImageMagicより高速に処理ができること。 - Rails7.0系からActive StorageのデフォルトのvariantがImageMagickからlibvipsに変更されたこと。今後Railsのバージョンを7.0系に上げた場合に、variant変更のコストが発生しない。 - コラム型コンテンツ管理機能作成 - markdownエディターを採用 - エディターの生成には react-simplemde-editor を使用。下記は、その選択の背景。 - ライブラリ選択に係る機能要件としては、リアルタイムプレビューが存在することが必須要件で、他はシンプルなエディターとしての機能存在すればよかった。また、独自の記法も追加するので拡張が任意で可能なものであること。 - react-simplemde-editor は、機能要件も満たしており拡張も可能。デフォルトの機能も非常にシンプルだった。また、他プロジェクトで使用している例も存在したため、社内の他のメンバーでの管理も比較的しやすいと判断。 - react-simplemde-editor は、内部で easy-markdown-editor というライブラリを使用していて、それをReactコンポーネントでラップしたものだった。この easy-markdown-editor のメンテナンスが継続的に行われていることが確認できたので、セキュリティの観点でも一先ず問題無いと判断した。 - markdownパーサーには markdown-it を使用。下記は、その選択の背景。 - ライブラリ選択に係る機能要件は、独自の記法を追加できること。 - markdown-itは要件を満たしている。また、Marked等の他のライブラリと比べて公式及びコミュニティによる拡張プラグインが充実していて、記法の拡張が柔軟にできることがわかったため。 - また、初期リリースに必要な独自機能の追加も簡単にできることが判明したことも選択の要因。 - 頻度が高いわけではないが、ライブラリの更新も継続的に行われていて管理されていることが確認できた。 - デザインデータ（psd）を元にviewを構築 - SEO対策 - gem meta-tags を使用してmetaタグの各種設定 - gem sitemap_generator を使用してサイトマップ作成 - Amazon EventBridgeによってサイトマップ生成を定期実行し、S3に保存する。 - S3への保存は、gem carrierwaveを使用して行う。 - 構造化マークアップの作成。 - 画像遅延読み込みやページキャッシュ等によるサイトスピード向上。 # 現在 - 2022/2月初旬にリリース完了 - 新規機能開発継続中 - プロジェクトメンバーに変化なし