ID:69738さん

## プロジェクト要約 製造企業向けに、製造業で必要となるさまざまな業務（製造管理・債権債務・受発注・在庫管理など）を一元的に支援する基幹システムを開発しています。プロジェクトは2020年に発足し、2022年5月に参画しました。 ## プロジェクト体制 - 開発に関わる人数：約50人 - チーム体制：製造管理・債権債務などの業務カテゴリごとのチームに分かれて開発（リポジトリは共有） ## 技術スタック - フロントエンド：JavaScript, React 17, React Router 5, Redux 4, Redux Form, redux-saga, Reactstrap, Tailwind CSS 2, FullCalendar, Prettier - バックエンド：PHP 7.4, Laravel 8, Docker - データベース：MySQL 8 - 開発支援ツール：GitHub, Slack, Notion, Jira, Confluence ## 配属チーム情報 1. 製造管理系の機能を開発するチーム - **配属期間**：2022年5月 〜 2023年7月 - **人数**：4〜6人（時期により変動） - **役割** - フロントエンドおよびバックエンドの開発 - テスト仕様書作成・テスト実施 - 仕様が煮詰まっていない担当機能の設計（自ら顧客と話し合いながら仕様を固めていくこともありました） - **担当した主な開発内容** - カレンダーライブラリを用いた月別・日別の製造スケジュール管理画面の開発 *〜人員補充のため、製造管理系の開発を中断し、以下のチームに参画〜* 2. 債権債務系の機能を開発するチーム - **配属期間**：2023年8月 〜 現在 - **人数**：約15〜20人（時期により変動） - **役割** - フロントエンドおよびバックエンドの開発 - **担当した主な開発内容** - 既存の債権債務機能の不具合修正 - 債権債務で必要な帳票（PDF, CSV, Excel）のデータ作成・出力機能の開発 - ~各債権債務機能のインボイス対応（これから本格的に実施）~（スケジュールを見直した結果、2024年3月ごろから実施予定） 3. 共通・マスタデータ系の機能を開発するチーム - **配属期間**：2023年8月 〜 2023年9月中旬（債権債務チームと掛け持ちでしたが、債権債務系の機能開発により人員を割く方針となり、そちらに注力することになりました） - **人数**：4人 - **役割** - フロントエンドおよびバックエンドの開発 ## 担当業務抜粋 1. カレンダーライブラリを用いた製造スケジュールの管理用の機能開発 - **機能説明** 日々の製造の情報（製品名・工場ライン・担当者・作業時間・作業内容など）を確認できる製造業務の担当部署向けの機能で、以下の３種類の画面を実装しました。 1. 月単位で情報を表示する画面（Googleカレンダーの月単位表示のようなレイアウト） 2. 日単位で担当者別に情報を表示する画面（Googleカレンダーの日単位表示のようなレイアウト） 3. 日単位で工場ライン別に情報を表示する画面（Googleカレンダーの日単位表示で、列が工場ラインになったようなレイアウト） - **実装方法** カレンダーの機能を１から実装するのは大変なため、チームでカレンダーライブラリを選定しました。様々なライブラリのサンプルを確認しながら、要件を最も実現できそうなFullCalendarを使って実装することにしました。 - **課題** FullCalendarは幅広い機能を提供していますが、それでも、画面の要件を満たすためにはかなりのカスタマイズが必要でした。このため、各画面を実装するのに必要なコード量が大きくなり、1画面を1つのコンポーネントで実装すると、そのコンポーネントのコードが複雑化し、見通しを悪くする可能性がありました。 - **取り組み（工夫点）** カレンダーの構成要素を別コンポーネントに切り出したり、各画面で共通の処理をカスタムフックに切り出したりして、コードを細かく分割しました。例えば、以下のように切り出しました。 - カレンダーのヘッダーや１列の表示を別コンポーネントとして切り出し - APIから必要なデータを取得し、加工する処理をカスタムフックとして切り出し この工夫により、1コンポーネントで実装すると約3,000行ものコードが必要だった画面でも、多くのファイルが300行未満、最大でも約500行のファイルに分割することができました。これにより、1ファイル内のコードの複雑化を防止することができました。 2. 顧客向け開発講習の実施 - **要約**：顧客がシステムの運用・保守を行うため、開発講習を実施 - **期間**：2023月4月〜2023年10月（週1回の頻度） - **体制**：フロントエンド担当（私）とバックエンド担当の2人体制 - **講習の内容** 基幹システムの開発で必要となる以下のスキルを習得できるように指導しました。 - フロントエンド / バックエンドの開発環境の構築 - CRUD機能を備えたAPIの実装 - 検索画面・詳細画面・編集画面・および編集内容の最終確認画面の実装 - **実施形式** - Discordを使用し、顧客の１人が画面を共有しながらハンズオン形式で実施。 - Discordの複数人が同時に画面を共有できる利点を生かし、行き詰まった人がいれば、その都度画面共有していただきながら、一緒に問題解決するようにしました。 - **工夫点** - 週１回の講習では十分なスキル習得が難しいと考え、毎回課題を提供することで、自己学習の機会を作りました。 - ハンズオンの内容をConfluenceに記載して共有することで、後からでも各々が振り返りやすいようにしました。 - 最後にリファクタリング手法（コンポーネント分離やReduxのセレクタ関数の切り出しなど）について簡単に紹介し、コードの可読性を意識する機会を作りました。 ## 改善活動 1. コード品質向上のためのコードレビュー文化の構築 - **課題** 製造管理チームでは、コードレビューがチームリーダーに一任されており、負荷が集中したときに十分なレビューが行われないことが問題でした。その結果、品質や可読性が不十分なコードがマージされることがしばしばありました（実装経験の浅いメンバーが多かったのも要因の１つだと思います）。この状況が、不具合の修正や機能追加を困難にし、開発効率に悪影響を及ぼしていました。 - **取り組み** チームメンバーもレビュアーとして参加する提案をしました。この提案を行ったのは、チームメンバーがコード実装に深く関わっていることから、特に実装方法やコードの書き方のチェックが強化できると考えたためです。最終的に、1つのプルリクエストを2〜3人でレビューする文化を根付かせることができました。 - **工夫点** 少しずつ慣れてもらうことを意識して、以下のような取り組みを行い、徐々にコードレビューの文化を作っていきました。 - 意欲のある私が積極的にコードレビューに参加し、より良い実装方法がありそうなら積極的に提案しました。これにより、レビュアーの活動内容を理解してもらいました。 - 私が担当するタスクに関しては、その領域に知見があるメンバーや、（改修タスクの場合は）以前この機能を実装したメンバーにレビューを依頼しました。これにより、まずはレビューしやすいところから取り組んでもらい、レビュアーの役割に段階的に慣れてもらいました。 2. OPcacheの導入方法の調査と提案を行い、APIの高速化に貢献 - **課題** 日々のシステム開発において、他のサービスと比較してAPIの動作がかなり遅く、個人的にストレスを感じていました。そのため、開発体験の向上のために改善したいと考えました。 - **取り組み** 多くのAPIが遅い状況だったため、個別のAPIの実装方法ではなく、全体に影響する設定に焦点を当てて情報収集しました。そして、OPcacheが、実装コードの変更なしで高速化を実現できる仕組みであることを知りました。最初に、チーム内で試しに導入してみて、高速化が実現できることと、システムの動作に問題がないことを確認しました。その後、インフラチームに提案し、AWSにデプロイしている各環境にも導入することができました。 - **工夫点** OPcacheの導入がAPI全体に影響を及ぼすことから、単に勧めるだけでは受け入れられない可能性も考慮し、インフラチームへの提案方法を工夫しました。まず、OPcacheが実装コードをコンパイルするだけで、処理内容には影響を与えないという仕組みを伝え、導入に対する懸念を解消しました。さらに、事前にOPcacheの設定項目をブラッシュアップしておき、提案時にはその構成や各設定の効果を共有することで、スムーズに導入してもらえるようにしました。提案後から導入まで時間がかからなかったため、これらの工夫が功を奏したと感じています。 - **成果** ローカル環境で約1,000msかかっていた処理が約20msに短縮され、開発体験とユーザ体験が向上しました。 3. バックエンド側のCI導入 - **課題** 定期的な内部ミーティングにおいて、Swaggerドキュメントの生成時やテストコードの実行時にエラーが発生する報告が何度もありました。この問題は、プルリクエストのチェックリストに記載されているにもかかわらず繰り返し発生しており、人手による不確実性が高いチェック方法では問題だと感じていました。また、ローカル環境でテストコードを実行するには、テストDBのマイグレーションやシーダーの実行が必要で、計30分以上の時間がかかっていました。この間は、他の開発を進めることも出来ず、時間を効率的に使えない問題がありました。 - **取り組み** 問題が繰り返し発生していることから、人手によるチェックでは解決が難しいと判断し、GitHub Actionsを活用して自動化されたチェックシステムを導入しました。具体的には、既にあるプルリクエストのチェックリストを参考にして、次のチェックを導入しました。 - PHPのPSR-4エラーチェック - Swaggerドキュメント生成時のWarningやシンタックスエラーのチェック - マイグレーションの動作確認 - シーダーの動作確認 - テストコードの動作確認 - **成果** 変更をマージする前に、確実に問題を発見できるようになりました。また、以前はローカル環境で30分以上かかっていた確認作業が、GitHub上で自動的に実行できるようになりました。このため、開発者はコード変更をプッシュした後、他のタスクを実施できるようになり、開発効率が向上しました。 4. フロントエンド側のCIにコードのフォーマットチェックを追加 - **課題** プロジェクト全体で、各開発者がファイル保存時の自動フォーマットを設定するルールになっていましたが、それでもフォーマットされていないコードがマージされることがありました。それを、後から自動フォーマットの設定を行っている人が変更すると、プルリクエストの変更差分にフォーマットされただけの行がたくさん表示され、レビューしづらい問題がありました。 - **取り組み** CIにPrettierによるフォーマットチェックを追加し、フォーマットされていないファイルがあるとCIが失敗するようにしました。これにより、フォーマットされていないコードがマージされるのを防止しました。 - **工夫点** Prettierでフォーマットした結果、稀に処理内容が変わってしまうことがあるため、単に全てのファイルを一括でフォーマットすると、不具合が発生してしまう恐れがありました。これを防止するために、CIではそのプルリクエストで変更したファイルのみをチェック対象にしました。これなら、変更したファイルについては、各開発者がそのタスク自体の動作確認を行う中で、自然とフォーマットされた状態で動作することも確認できるため、追加の手間をかけない形で導入することができたと考えています。 5. DBのコードマスタのコードをまとめたJavaScriptオブジェクトを自動生成するスクリプトの実装 - **課題** フロントエンドからDBのコードマスタテーブルの値を取得する際、値を特定するためのコードをハードコーディングしていたことが課題でした。これにより、コードを変更した場合、ハードコーディングされた部分を探し出して、同時に修正しなければならない課題がありました。 - **取り組み** この問題に対処するため、DBに接続してコードマスタの情報を自動的に取得し、`CodeKey.<コード分類>.<コード>`という形式でコードを取得できるJavaScriptオブジェクトを生成するnpmスクリプトを作成しました。これにより、コードマスタテーブルに変更があった場合も、フロントエンド側はこのスクリプトを実行するだけで最新の情報を取得できるようにしました。 - **工夫点** JavaScriptオブジェクトを生成する際、ORDER BYによる順番の固定化とPrettierによるフォーマットを適用しました。これにより、コードが変更された以外での変更差分が検出されないようにし、変更を容易に追跡できるようにしました。 ## その他で自発的に取り組んだこと 1. 勉強会の実施 - 製造管理系のチームは、多くのチームメンバーが同時期に入社し、ほぼその入社したメンバーで構成されていました。React開発の経験がない人もいたため、JavaScript, React, Reduxの基本的な使い方や、Mac, VSCodeの便利なショートカットキー・拡張機能を紹介しました。 - チームでのテストコードの書き方に問題があると感じていたため、「[単体テストの考え方/使い方](https://book.mynavi.jp/ec/products/detail/id=134252)」という本を読んだ上で、内容をピックアップして紹介しました（AAAパターンや、各テストケースが互いに影響しないように実装することなど）。 - ChatGPTを使い、開発業務の効率が上がったと感じたため、基本的な使い方・うまく使うためのコツ・注意点などを紹介しました。 2. Notionでの情報共有（これまでに30ページ以上を共有） - 開発環境構築の手順書作成 - プロジェクトのディレクトリ構成や利用パッケージの紹介 - 自分が実装する上で行き詰まった箇所の解決方法の共有 3. 開発体制の改善 - マージされていないPRを毎日リマインドするSlackのbotを、Google Apps Scriptで開発

# プロジェクト要約 保守性の高い開発を学び、実践する場としてショッピングサイトを開発しています。 # 各種リンク - [Webサイト](https://next-bazaar.vercel.app/) - [GitHubリポジトリ](https://github.com/ot07/next-bazaar) - [システム構成などをまとめたブログ記事（記載中）](https://techblog.ot07.me/posts/next-bazaar) # 開発の背景 業務を通じて次のような思いが募り、この開発を始めました。 - **保守性の高いコードの実装スキルをつけたい**：業務で扱うコードを読む際、その可読性・実装容易性に課題を感じ、工夫すればもっと読みやすく保守性の高いコードは書けるはずだという思いがありました。ただ、業務のソースコードがベースにあると、頑張っても良い実装方法が思いつかない部分も多々ありました。そこで、個人開発として、技術選定や画面設計などからじっくりと取り組もうと思いました。 - **身につけた知識を実践する場を作りたい**：上記のような課題感を持ち始めてから、保守性を高めるための知識を深めるようにしました。しかし、ただ知識を深めるだけだと実際の開発に落とし込むことはできないと思い、実践する場を作ろうと思いました。 また、以下の理由から、開発の対象としてショッピングサイトを選びました。 - 世の中にサービスがたくさんあり、それらを参考にすることで、アプリケーション自体の設計に悩むことは少ないと考えたため（保守性の高い開発手法を学ぶのが目的） - 普遍的なアプリケーションを対象にすることで、さまざまな種類のシステム開発に通用する汎用的な知見が得られると考えたため # 技術スタック - フロントエンド：TypeScript, React, Next.js, Jest, Storybook, TanStack Query, React Hook Form, Zod, Mantine, Orval, ESLint, Prettier - バックエンド：Go, Fiber, Swagger, sqlc, swag, Docker (デプロイ環境用) - データベース：Amazon RDS (PostgreSQL) - ストレージ：Amazon S3 - デプロイ：Vercel, AWS App Runner # アピールポイント 1. 効果的なテストコードの実装 - **課題** 業務で初めてテストコードを実装する経験をしたのですが、それがリグレッション（デグレーション）を防止することに貢献している感覚がありませんでした。そして、実際に不具合が多発しました。この経験から、単にテストコードを実装するだけでなく、良いテストコードがどんなものか判断する考え方を身につける必要があると感じました。 - **取り組み** 「[単体テストの考え方/使い方](https://book.mynavi.jp/ec/products/detail/id=134252)」という本を読み、良いコードを書くための考え方を身につけました。また、本を読み進めながらこのプロジェクトで実践しました。 - **工夫点** 効果的なテストコードを実装できるように、以下の工夫を行いました。 - APIの正常系テストでは実際の環境に近いテスト用のDB（Dockerコンテナ）を使用し、異常系テストでは例外発生のためにモックDBを使用 - リファクタリングしても壊れないテストコードにするために、外部から観察可能な情報のみ（APIのレスポンスなど）を使って振る舞いをテストすることを意識して実装 2. コード自動生成による実装の効率化 - **課題** これまでの開発を通じて、同じような情報を多重に管理することは、変更時にすべての場所を同時に更新しなければならないことから、保守性の観点で課題だと感じました。その一例として、APIのリクエスト・レスポンスの型を、フロントエンドとバックエンドの両方で管理することが挙げられます。 - **取り組み** APIのリクエスト・レスポンスの型をなるべく一元管理できるように、１箇所の情報から必要なコードを自動生成する仕組みを作りました。 具体的には、次のパッケージを導入し、バックエンド側に書いたコメントから、各エンドポイントと接続するReactフックを自動生成できるようにしました。 - [swag](https://github.com/swaggo/swag)（Goパッケージ）: APIリクエストとレスポンスのモデル（Goの構造体）、およびコメントから、OpenAPIドキュメントを自動生成 - [Orval](https://github.com/anymaniax/orval)（npmパッケージ）: OpenAPIドキュメントから、各エンドポイントと接続する[TanStack Query](https://tanstack.com/query/latest)ライクなReactフックを自動生成 - **工夫点** 以前から、API側のデータを扱うライブラリの中でも、TanStack Queryは使いやすく、コードもシンプルに保てるライブラリだと思い、好んで使っていました。そのため、今回の自動化を行う中でも、なるべくTanStack Queryを用いた場合と同じような実装ができるものを探しました。Orvalは、TanStack Queryライクに使えるReactフックを生成できる数少ないライブラリであり、最近もしっかりとメンテナンスされていることから、採用することにしました。 3. 静的型付け言語の採用 - **課題** 動的型付け言語（JavaScript, PHP）を使った大規模なシステム開発を経験する中で、エラーの早期発見が難しいことや、型が明示されていない他人のコードを理解するのが難しいことなどを課題に感じました。 - **取り組み** 静的型付け言語を使用することで上記の問題は軽減できると考え、フロントエンド開発にTypeScript、バックエンド開発にGoを採用し、静的型付け言語の強みを体験することにしました。その結果、オブジェクトのプロパティや関数の引数などを変更した際に、ビルドエラー等で付随箇所の修正漏れに気づくことができ、安心してデプロイできるようになりました。また、採用した副作用として、静的型付け言語を使用すると、コードエディタの「定義/参照に移動」が適切に機能し、開発効率自体も大きく向上することが分かりました。

# プロジェクト要約 Astroファイルのimport文をソートする`prettier-plugin-astro-organize-imports`というPrettierプラグインを開発しました。このプラグインはnpmパッケージとして公開されており、実際に利用することができます。 # 各種リンク - [GitHubリポジトリ](https://github.com/ot07/prettier-plugin-astro-organize-imports) - [npmパッケージ](https://www.npmjs.com/package/prettier-plugin-astro-organize-imports) # 開発の背景 プロジェクト全体でコーディングスタイルを揃えることは、コードの書き方における個人差を小さくし、可読性を向上させる上で重要だと考えています。それは、import文の順序においても言えることだと考えています。そこで、個人開発におけるTypeScriptプロジェクトでは、[prettier-plugin-organize-imports](https://github.com/simonhaenisch/prettier-plugin-organize-imports)というPrettierプラグインを活用し、import文をフォーマットしています。 ところで、私は、高速な静的サイトを構築できるAstroというフレームワークを使った開発を行っています（[リンク](https://github.com/ot07/portfolio)）。Astroは独自の言語を持っており、`.astro`という拡張子のファイルとして作成されます。この言語は、HTMLやJavaScriptの文法に似ており、import文も存在しますが、上記のPrettierプラグインは対応していません。そこで、Astro用のプラグインを開発することにしました。 # 技術スタック - 開発言語：TypeScript, JavaScript（一部の設定ファイル） - パッケージマネージャ：pnpm - ビルドツール：esbuild - その他：Prettier # アピールポイント 1. 他のPrettierプラグインと併用できる仕組みづくり - **課題** 開発したプラグインは、Prettierプラグインの本来の仕様とは異なりました。通常、Prettierプラグインは、標準でサポートされていない言語向けにフォーマッタを提供するために設計され、1言語に1つのフォーマッタを持つことが一般的です。しかし、今回のプラグインは局所的な用途（import文のソート）を持つため、Astro用の他プラグインとも併用して使えることが重要だと考えました（特に、Astroの公式フォーマッタがプラグインとして公開されているため、このプラグインと併用できることはマストだと思います）。 - **取り組み** 仕組みが似ている以下の既存プラグインのソースコードを参考にしながら開発を進めました。 - [prettier-plugin-organize-imports](https://github.com/simonhaenisch/prettier-plugin-organize-imports)：import文のソート部分の実装を参考にしました。 - [prettier-plugin-astro](https://github.com/withastro/prettier-plugin-astro)：Astro公式が開発しているフォーマッタで、Prettierが標準でサポートしていない言語に対してプラグインを実装する方法を参考にしました。 - [prettier-plugin-tailwindcss](https://github.com/tailwindlabs/prettier-plugin-tailwindcss)：他のプラグインと併用可能なプラグインを実装する方法を参考にしました。 - **工夫点** import文をソートするというシンプルなプラグインのため、Astro用の他プラグインと併用可能であるとともに、単独でも動くようにしました。 2. Prettier 3のサポート - **課題** このプラグインは、Prettierの最新バージョンが2系のときに開発しました。しかし、公開後にPrettier 3がリリースされ、そのバージョンでは動作しない問題が発生しました。 - **取り組み** Prettier 3の環境で動作するように、以下の流れでプラグインをアップデートしました。 - **現状把握**：原因を調査したところ、CommonJSとしてプラグインをビルドすると使えないなど、何点か要因は発見できました。ただ、Prettier 2と3で仕組みが少しずつ異なるようで、うまく修正することは出来ませんでした。一方で、他の既存プラグイン（prettier-plugin-tailwindcss）はPrettier 3をサポートしていることを把握しました。 - **対応方法**：コード量が少ないこともあり、prettier-plugin-tailwindcssのコードをベースに、新たに作り直すことにしました。その結果、Prettier 3をサポートすることができました。

## プロジェクト概要 - vCenter Serverを活用した自社クラウドサービスの構築・管理の自動化コードを開発 - 3名の開発チーム ## 担当業務 - Ansible 2.9での自動化コードの設計書作成・実装・テスト仕様書作成・テスト実施 ## 自発的に取り組んだこと - テスト仕様書作成やテスト実施に労力がかかると感じ、Ansible Moleculeによる自動化コードのテスト自動化の提案〜導入を実施（テストコードの実装方法の調査・実装・CI構築）

## プロジェクト概要 - 所属部署が所有するvCenter Serverの運用・保守を担当 - vCenter Serverには、他部署の開発環境として提供している仮想マシンもあり、新しい開発環境の構築や脆弱性対応などを実施 ## 取り組んだこと - 仮想マシンのLog4j脆弱性対応が必要となったとき、手作業で対応するのではなく、Ansibleで修正パッチ適用の自動化コードを実装し、他部署の開発環境も含めた複数の仮想マシンへの一括適用を実施した。これにより、作業時間の削減や人的ミスの軽減を実現した。