ID:60978さん

チーム構成・規模

プロダクトマネージャー: 1名
フロントエンド: 3名
バックエンド: 2名

ProbWorksは転職と副業の二つの求人を掲載しているWebアプリです。
自分が所属している会社はスタートアップで人が全然いないので、仕様の確認や、デザイン、チームのタスク管理やコードレビューなどフロントに関わることは自分も関わっていました。
ProbWorksの開発で自分がこなした仕事の中で特に効果があったと考える仕事は以下の2つです。

• リポジトリの統合
• OpenAPIからの型の自動生成

リポジトリの統合

課題点

自分がこのプロジェクトに参加した当時はフロントのコードがユーザーページと管理者ページでリポジトリが分かれており、ただ、コンポーネントは２つのリポジトリで同じコンポーネントを使用していました。
コンポーネント単位での変更があるたびに

1. コンポーネントの実装
2. もう一つのリポジトリでも同じ実装

という手順で開発をしており、2の作業がほぼコピペということもあり手間がかかる上に、2を忘れていてリポジトリによってコンポーネントに違いがでているという状況が頻発していました。
この状態を解決するために２つに別れていたリポジトリを統合しました。

課題解決の過程

具体的にはnpm workspaceを使用してadmin(管理者ページ), app(ユーザーページ), commonsという3つのプロジェクトを作成し、commonsの中にcomponentsを作ることで管理者ページでも、ユーザーページでも同じコンポーネントを使えるようにしました。
create-react-appで作られたプロジェクトだったので、webpackを結構いじる必要があり別プロジェクトのコンポーネントをimportして使えるようにしたり、管理者ページを開発している場合でもcommonsのコードが変わったらホットリオードをするようにする設定したりするなどをしました。

成果

リポジトリを統合した結果、コンポーネントの変更があった場合でもそのコンポーネントを実装すれば管理者ページでもユーザーページでもコンポーネントが変更され、上記であげた「2. もう一つのリポジトリでも同じ実装」の作業を完全になくすことができました。
「2. もう一つのリポジトリでも同じ実装」の作業がなくなったことで、プロジェクトによってコンポーネントに違いがでるという問題も解決することができました。

OpenAPIからモデルの型・通信をする関数の自動生成

課題点

このプロジェクトでは先方から仕様の修正が入ることが多く、仕様書の変更が日常茶飯事でした。
*仕様書はstoplight studioを使用して管理していました。
フロントエンドは変更のたびに自分たちで確認し、Typescriptの型や、通信部分のコードを修正していました。
手動で修正をしていたためTypescriptの型が仕様書と違っていたり、通信のエンドポイントが仕様書の変更が反映されていないという確認の漏れが多く、その漏れにもなかなか気づきにくいという問題を抱えていました。

課題解決の過程

そこで、仕様書からTypescriptの型や、通信のエンドポイントを自動で生成するためのパッケージを作成することにしました。
はじめはopenapi2aspidaを使おうとしてみたのですが、自動生成されたコードと、既に開発しているコードとの差分がかなり大きく、今から導入するのは無理だと判断しました。
そこで、プロジェクト用に独自のカスタマイズをしたパッケージを作ることにしました。
cliに関してはopenapi2aspidaのコードを参考になるべく既存のファイル、コードに近いものを自動で生成するようにしました。
パッケージはsemantic-releaseを使うことで自動化しました。

成果

仕様書からコードを自動生成できるようになったことで、かなり多くの利点がありました。

1. モデル毎に型を手動でつくる必要がなくなった
   今までは新しいモデルが増えるたびに型を手動で作る必要があったのですが、自動化することでその作業が完全になくなりました。
2. 新しいエンドポイントができた場合も手動で作る必要がなくなった
   モデルと同様に新しいエンドポイントが出来るたびに手動で通信部分を実装していたのですが、その実装も自動化することができました。
3. 仕様の変更によるビューの修正がかなりしやすくなった

今までは仕様が変わるたびに型を手動でやっていたため、手動で変更した箇所に関しては型エラーが出て、その型エラーを修正していたので仕様の変更と、実際のコードの変更にラグが発生していました。
しかし、自動生成にかえたことで、仕様が変更されてたらすぐに型エラーがでるようになったので、仕様とフロントエンドとのラグがなくなり、常に最新の状態であり続けることができるようになりました。

チーム構成・規模

プロダクトマネージャー兼QRコードの作成・解析するエンジニア: 1名
フロントエンド: 1名
バックエンド: 1名

LogoQは普通の文字列だけでなく、LogoQアプリで読み取った場合にのみ取得できる秘匿データを持ったQRを生成、管理するためのアプリです。
LogoQはフロントエンドエンジニアとして1から携わった初めての開発でした。
ここでの自分の大きな仕事は以下の2つです。

• QRコードを読み取るためのiosアプリをswiftで開発したこと
• schemaの変更によるコードの自動生成をciに組み込んだこと
• フロントでのテスト文化の作成

  swiftを使ったiosアプリの開発

  QRコードを読み取るためのiosアプリをswiftで開発したこと
  このプロジェクトではQRコードの秘匿情報を読み取れるiosアプリを作成する必要がありました。
  私は今までモバイルアプリの開発はしたことがなくswiftを触ったこともなかったのですが、iosアプリを任せてもらいました。

  苦戦したところ

  ビューの作成方法や、delegateなどがReactとは特に違いがあり中々とっつきにく、苦戦したのですが、「swift 詳解」の本を呼んでswiftの言語仕様を学び、youtubeや、appleの公式ドキュメントのチュートリアルをやりながら手を動かすことで理解していきました。
  まだまだ改善点は多いのですが、swift-uiを使って秘匿データを取得できるQRリーダーを作り切りました。

schemaの変更によるコードの自動生成をciに組み込んだ

課題

このプロジェクトではgraphqlで開発をしており、graphql-codegenを使用していました。
開発当初はschemaが変更するたびにcodegenのコマンドを手動で実行する必要があり、codegenコマンドを実行し忘れるとschemaとフロントエンドのコードで差異が生まれてしまい、バグが発生するという問題がありました。
また、フロントエンドではschemaの変更があるたびにschemaディレクトリでbuildコマンドを実行して、フロントディレクトリでcodegenコマンドを実行するようにしており、ディレクトリを移動する必要があり手間を感じていました。

課題解決の過程

そこで、schemaが変更されたらciで自動でcodegenのコマンドが実行されるようにしました。
具体的にはhuskyとpre-commitを使用してcommitのたびにschemaファイルをbuildするようにして、
schemaのプルリクエストが立つたびにgithub actionsでcodegenのコマンドを実行し、差分のcommitまでを自動化しました。

成果

schemaとフロントエンドのコード差異がでなくなり、スキーマの内容とフロントエンドのコードが違くなるという問題を解決することができました。
またフロントのコードがschemaと違うとcodegenコマンドが失敗するのですが、その失敗もschemaファイルのプルリクエストが立てられた時点で気づくことができるようになったので、codegenコマンドが通るように修正する作業もスムーズに取り組めるようになりました。

Coadmapはエンジニアに必要な知識を体系化し、ユーザーのなりたい像に対してロードマップ提供するプログラミングの教育支援ツールです
ここでの自分の大きな仕事は

• Coadmap UIというUIライブラリを作成した
• チュートリアルを作成した

  チュートリアルの作成

  アプリには登録してくれたもののそこから何も進まずに去ってしまうユーザーが多いという課題に対しててユーザーにCoadmapの使い方を知ってもらうためにチュートリアルを作成しました。
  Coadmapのキャラクターや、アニメーションを使って実装しました。
  チュートリアルの反響をいくつかもらうことができて、実際にチュートリアルを行ってから次のステップに進んでくれるユーザーも約30%上昇させることができました。

  UIライブラリを作成した

  Coadmapではデザインシステムを作っていたのですが、その一環でUIライブラリを作成しました。
  こちらは現在進行中で、近い将来OSSにする予定です。
  今までUIライブラリは使うだけだったのですが、いざ作ってみるとant designなどのUIライブラリがいかに良く作られているかが分かりました。
  storybookを使っており、コンポーネントは誰でも一目で分かるようになっています。
  デザインシステムを作っていく過程で安定して良いデザインを作るにはデザインシステムによるデザインの統一はとても大事だと感じました。

チーム構成・規模

プロダクトマネージャー: 1名
フロントエンド: 3名
バックエンド: 3名

業務内容

Webサービスに関するヘルプサイトを1から作成

マイクロCMSにContentfulを使用して1から作成しました。
作成するにあたって実際にやったことは

• graphql, graphql-codegenの導入
• lintのルール作成
• 静的サイトの作成

  静的サイトの作成

  インフラのコスト(デプロイはS3にアップロードするだけ)や、運用コストの面からクライアントサイドでは通信をしない静的サイトとしてサービスを作成しました。
  そのため、ヘッダーやナビゲーションコンポーネントでContentfulのデータを使用したい場合はデータをJSONファイルで保存し、JSONに入っているデータを利用してヘッダーや、ナビゲーションにデータを表示するようにしました。

  成果

  ヘルプサイトを1ヶ月でリリースまですることができました。
  また静的サイトとして作成したことで、CI/CDでlintや型チェックなどをし、デプロイも自動化しているためデプロイした後に本番環境でデータが表示されないなどの大きななバグにいたったことはありません

Contentfulのモデルに変更があった場合のデプロイの自動化

Contentfulのモデル変更が発生したときに、メディア側の本番環境とContentful側でモデル変更のタイミングが違うとクライアントサイドで通信している箇所が動かなくなるという事故が発生するため、本番リリース時に複数人で対応しリリース後も手動で確認するという状況が発生しており、手間がかかっていたので改善しました。
主な改善点は

• モデル変更のコード化
• CI/CDでContentfulをデプロイできるように整備

  成果

  Contentfulのモデル変更が発生した場合でもデプロイタイミングを気にする必要がなくなり一人で本番リリースができるようになりました。
  また、問題があった場合でもCI/CDが失敗してデプロイがされないようになるため緊急の対応ではなくなり開発メンバーの負担が軽減されました。