ID:68701さん

# 目的 背景 申請や稟議、営業活動の報告をスマートフォンから実現し、PCからその実績を確認、承認できるようにする。 # チームについて - 3次受けのエンジニアとして参画した - 新卒1年目で投入された - バックエンド 1名 フロントエンジニア 1名 上長 1名 3人体制 - PCとスマートフォンのフロントエンドの実装を担当した # 仕様技術 - Cordova - HTML5 - CSS3 - jQuery - Bootstrap # 業務内容 - アプリケーションの立ち上げフェーズ(`0→1`)と保守、運用フェーズ(`1→10`)を経験した - PC向けアプリケーションの画面を実装した - スマホ向けアプリケーションの画面を実装した ## 課題と工夫したこと ### 当時の所属先にはSPAのアプリケーションの開発ノウハウがなかった フロントエンドエンジニアの第1号として、1から`jQuery`と`Bootstrap`の学習しながら画面の実装とレイアウトの構成を考えた。 ajaxやSPAといった概念にふれ、他にフロントエンドの技術で相談できる相手もいなかったため、自分で技術をキャッチアップすることの重要さを学んだ。 ### 当時の所属先にはスマホアプリの開発ノウハウがなかった 2次受けからの指定でハイブリッドアプリの開発を行えるフレームワーク`Cordova`を使用した。Node.jsのエコシステムに初めて触れることができ、後述のアーキテクチャ変更の提案のきっかけになった。iOSとAndoroidの動作の違い、Cordovaプラグインの利用方法の把握のためドキュメントをよく見る意識づけになった。2次受けのエンジニアに知見があったため、相談や質問の方法を学んだ。 ### 実DOM操作による状態管理の難解さ、バグが混入してしまう jQueryとBootstrapによる開発だったため、Reactではstateで扱うような値を全てhidden属性のinput要素で管理することとなり、セレクタの管理が困難だった。そのため状態管理が困難で機能開発のたびにバグが発生していた。そこでCordovaで使用していたNode.jsのエコシステムに目をつけ、Vue.jsやReact.jsを調査した。載せ替えの容易さ、ドキュメントが日本語化されているなどの点からVue.jsを選定し、結果としては受け入れらなかったもののアーキテクチャ変更の提案した。また、商用のソフトを使って開発する会社だったため、OSSへの懐疑的な見方もあったが、Vue.jsのデモや社内wikiに調査記事をまとめるなど社内におけるOSSのツールの立場を向上できるように働きかけた。 ### CordovaアプリのOS間の動作が異なる、非推奨の機能を使っている Cordovaはアプリ内ブラウザを介してモバイルアプリを動作させるが、iOS(safari)とAndoroid(chorome)でブラウザエンジンが異なるにも関わらず、2次受けがiOSでの検証を軽くしかやっていないことが判明した。そのため、他メンバーと協力してiOSの検証を行いAndoroidと比較して何ができ、何ができないかをまとめ共有し、アプリの仕様を改めて決め直すことができた。 スマホアプリのオフライン時を考慮し、Web SQLを使ってバックエンドから送られていたデータを保持していたが、2010年に非推奨となっている規格であることを指摘した。代替の手段であるIndexedDBの仕様を調査してまとめ、結果としては受け入れらなかったものの設計の変更を提案した。 ## 業務の成果 - 月1回のリリースを継続してこなすことができた - 本プロジェクトの取り組みが一定の評価を受け、発注元の他のプロジェクトにも所属先のエンジニアが参画できた - 社内でその取り組みが評価され「新分野チャレンジ賞」を受賞した - わからないことへの解決の仕方(検索や質問の方法)を学んだ

# 目的 背景 輸送トラックの位置情報を取得し、PC画面から地図上位置を表示することで動態管理を実現する。 # チームについて - バックエンド 3〜5名 フロントエンジニア 2名 QA 2〜3名 PO 1名 デザイナー1名 - PCとスマートフォン、タブレット画面のフロントエンド実装を担当した # 仕様技術 - TypeScript - React.js - Redux - Redux Thunk - styled-components # 業務内容 - アプリケーションの立ち上げフェーズ(`0→1`)と保守、運用フェーズ(`1→10`)を経験した - PC向けアプリケーションの画面を実装した - ドライバー向けスマホ用画面の実装を経験した - 社内プロダクトが参照するUIコンポーネントライブラリーの実装を経験した ## 課題と工夫したこと、取り組んだこと ### 参画時点でReactの知識がなかった チーム配属時点で`React`の知識はほぼなかったものの、先輩のフロントエンドエンジニアの助けを得ながら自分でもキャッチアップを進め、Reactのコンポーネントを実装した。前職までは「動けば良い」でコードの品質まで意識が行っていなかったが、コンポーネント分割の単位や関数や変数の命名など今の仕事の進め方の基盤になるようなことを学んだ。 ### アジャイルな開発現場へ初めて参画したため、仕事の流れがわかっていなかった アジャイルな開発現場に初めて参画し、自分がどのように仕事をしたらいいか分かっていなかった。デイリースクラムで話すことがよくわかっておらず、チームリーダーや先輩社員に話を聞き、リリースに向けて進捗の状況や困っていることを話せるように事前に考えるようになった。 ### 実装した後の手戻り修正がとても多くなった デザイナーやQAエンジニアなど多様な職種が集まって開発する体制に初めて参画したが、前職の「1人でタスクに取り組む」(そもそも周りにあまり聞けなかった) 仕事の進め方で実装したために手戻りがとても多く発生することが多かった。これによってコミュニケーションの必要性を実感し、事前にデザイナーやQAエンジニアと相談し実装後のイメージをすり合わせるように仕事の進め方を修正することができた。 ### CSSの知識が不足していた コンポーネントライブラリーの開発の際に`styled-components`を使っていたが、それまでBootstrapでスタイルの実装をしていたため、CSSの知識が不足していた。実装中にMDNのドキュメントを確認したり、コードレビューを通じてCSSの記述方法も知識として身につけていくことができた。 ### ドライバー向けスマホ用アプリケーションの実装でReduxを導入した PC向けの画面ではリリース日との兼ね合いと記述量が増えやすいとの観点からReduxやRedux Thunkを使わずに実装していた。ドライバー向けのアプリケーション開発の際には、あまり経験のない自分が実装する形となり、Fluxアーキテクチャの仕組みに乗ることで雑な実装を防げると考え、メンバーとの相談の上PCの画面での技術スタックを引き継ぎながら`Redux`と`Redux Thunk`を使う意思決定を行なった。これによりAPIとの通信部分やページをまたぐで入力値の持ち回りなどが実現でき、通信部分でのバグの抑制につながった。 ## 取り組みの成果 - 週に1回リリースのスプリントを安定してこなすことができた - ReactやTypeScriptなどReactの周辺技術への理解が深まった - コンポーネントライブラリーの実装でCSSの知識を増やすことができた - チームとして働く上で、コミュニケーションがとても大事であることを学んだ

# 目的 背景 倉庫にトラックが接車し荷積や荷卸しなどの作業管理をシステム化する # チームについて - バックエンド 3〜5名 フロントエンジニア 2〜3名 QA 3〜4名 PO 1名 デザイナー1名 - PCとスマートフォン、タブレット画面のフロントエンド実装を担当した # 仕様技術 - 共通 - TypeScript - React - Redux - zod - PC向け - Redux-Thunk - styled-components - タブレット向け - Redux Toolkit - stitches - zod - React Hook Form # 業務内容 - 主力プロダクトへの投入となった - 運用フェーズ(`1→10`)を経験した - 物流拠点向けPC画面の機能開発、保守を行なった - ドライバー向けタブレット用拠点受付画面のリニューアルを経験した - 既存コードに対するリファクタリングを行った ## 課題と工夫したこと、取り組んだこと ### フォームのバリデーションが複雑で抜け漏れが発生しやすい フォームのバリデーション関数を工数の関係で自前実装していたが、機能追加のたびにパターン漏れが発生して細かなバグが発生しやすいい状態だった。これに対処すべく、チームとも相談し他のフロントエンドエンジニアとともに`zod`を使ったバリデーションを行うことを提案した。QAメンバーとも相談の上リリースのタスクとして組み込み、少しずつでも差し替えの実装を行った。これによってバリデーションの実装がわかりやすくなり、パターンの考慮漏れによるバグも減った。 ### 他プロダクトとの連携タスクの実装、改修 配車受発注・管理サービスMOVO vista との連携サービスを実装した際、プロダクトオーナー間で話し合いが進んでおらず、仕様がとてもあやふやだった。口伝での共有事項も多く、画面のデザインを担当していたデザイナーも退職したタイミングだったのでキャッチアップが難しかった。そこで、コードの読み込みと並行して開発に関わった他のエンジニアへ積極的に聞き込みをし、仕様理解に努めた。実装の前段階でテストを担当するQAエンジニアと想定のイメージを合わせられるように開発中の画面を見てもらうなど、すり合わせをしっかり行った。結果的に手戻りを減らせつつ、`2スプリント(4週間)`でリリースできた。 ### テキストエリアをリッチテキストエディタへ移行した 拠点の管理者から現場作業員や、荷物を運んでくる運送会社の方向けに連絡事項を伝える機能に関して、これまでテキストエリアによるテキストでしか表現していなかったが、より連絡事項を強調したいとの要望を受け新機能を開発することになった。リッチテキストを用いることに決まり、技術選定から参加することになった。いくつかのライブラリを比較、検討しHeadless Editor Frameworkの`Tiptap`を選定した。他のリッチテキストエディタでは要件外の機能も盛り込まれオンオフの設定が煩雑な事、スタイルがライブラリ固有のものとなっており、自社開発していたコンポーネントライブラリと見た目が揃わないことなどから除外した。Tiptapでは必要な機能だけ導入することができるが、スタイルはついていないためデザインを作る必要があり、デザイナーが不在の期間だったため自分で簡単な`figma`デザインを起こした。上記をもとにプロトタイプを作ってQAエンジニア、プロダクトオーナーと動作、仕様を擦り合わせた上で実装した。上記の取り組みによって手戻りを抑制しつつ、`2スプリント(4週間)`でリリースできた。リリース後、プロダクトオーナーから「現場訪問してきたけどお客さんの反応も良かったよ」との報告を聞いて嬉しかった。 ### タブレット向けのプロダクトの再実装 既存のドライバー向けタブレット用拠点受付のアプリケーションはかなり短期で作り上げられたものを引き続き使っており、コードの複雑性も高く、変更の容易性が低くなっていた。また予てから「入力項目が多く、どこを操作しているかわからない」などUXに関する利用者の方の改善要望も多かった。これらの社内外の意見受け自分と共に実装を担当したフロントエンジニアが中心となって開発チームでプロダクトオーナーやCTOと話し合い、タブレット向けのプロダクトの再実装を行うことになった。自分はフロントエンドの技術選定から関わることになった。CRAベースの既存のアプリがリリースから2年ほど経ち、やや技術スタックが古めになってきたタイミングだったため、今後の技術スタックを考えある程度新しいライブラリを選んだ。まず`Vite`ベースとし、ビルド時間の短縮化を目指した。グローバルstateの管理も`Redux Toolkit`を用いて冗長に書かなくてもグローバルstateを管理できるようにした。他にもゼロランタイムのCSS in JSである`stitches`を採用したり、`zod`と`React Hook Form`を導入してフォームの複雑性を下げられるように意識した技術選定を行なった。また、既存のアプリはPC向けの社内コンポーネントライブラリのスタイルを強制的上書きして使っていたが、事前にプロジェクト内にstorybookを立て、タブレット向けのコンポーネントをデザイナーと相談しながら新規作成した。これらの設計をベースに`3ヶ月ほど`で実装が完了することができた。 # 取り組みの成果 - 2週間に1回のリリースサイクルを安定して回すことができた - リファクタの重要性を認識できるようになった - ロジックの共通化や分割を意識できるようになった - 最新のフロントエンドの技術を調べ、設計に挑戦することができた - 自分より社歴の短いメンバーが多くなってきたので、経緯を交えて説明できるように意識できるようになった

# 目的 背景 研究員個人にしか蓄積されていなかった試薬配分の知見を共有し、実際に機械を動かさなくても推算で求められる物性のゴムを得られるようにする。 # チームについて - リードエンジニア 1名 バックエンド 1名 フロントエンジニア 1名 - PC画面のフロントエンド実装を担当した # 使用技術 - TypeScript - React - Recoil - SCSS - Tailwind - urql - graphql - MUI - apollo client # 業務内容 - 運用フェーズ(`1→10`)を経験した - PC向け画面の機能開発、保守、リファクタリングを実装した ## 課題と工夫したこと、取り組んだこと ### SCSSに分かれていたアプリケーションのスタイルをTailwind CSSにまとめた コンポーネントやページの実装に関して、SCSSとReactの実装に分かれていた。さらにコンポーネントライブラリにMUIを利用しているため、MUIが依存しているemotionのコードとTailwind CSSによるスタイリングも存在し、スタイルの実装が散らばっていると感じた。この状態だとスタイルとコンポーネントの実装が分かれていて網羅的な確認がしづらく、CSSとTSの記述を行ったり来たりするため実装時にスイッチングコストがあると感じた。そこで`Tailwind CSS`へスタイルをまとめるリファクタを提案した。CSS in JSなどにすると大幅に書き換えることになるため今回は除外した。他のバグ修正や機能改善と並行して入れ替え作業を行い1ヶ月半ほどで移行を完了した。これによりスタイルとコンポーネントの実装を網羅的に確認でき、emotionでの上書きも極力こちらに寄せられたのでスタイルの実装の把握と変更がしやすくなった。 ### ビルド環境をCRA(Create React App)からVite + React環境へ移行した 本アプリケーションはCRAによって作られたアプリだったため、ビルド時間とReactやTypescriptのバージョンアップが開発上の課題だった。 React 19も見越してアプリケーションのバンドルツールの移行を行うことになった。Storybookも利用していたためこちらも`Vite`ベースへ移行した。　ViteのSCSSの変更監視とtyped-scss-modeluesの変更監視のバッティングなど細かい問題はあったものの、今回の移行によって`30秒ほど`かかっていたビルド時間が`1秒ほど`に短縮された。Storybookは新たに環境を作り直すことになったが、ビルド時間の短縮に成功した。TypeScriptもバージョンアップでき、別のメンバーがReactのバージョンアップやパッケージを更新した際にエラーが出ることを減らすことができた。移行の手順や参考にしたサイトなどの情報をまとめNotionで他のメンバーへ共有した。 ### OktaによるOAuthの実装 Oktaによる認証基盤の実装に参画した。認証基盤を含むアプリケーションを動かす基盤環境を構築しているチームは別企業のエンジニアのチームだったため、backlog上でのやり取りを密に行い、齟齬がない形で実装が進められるように意識した。React上では提供されているSDKを実装すれば認証機能は実現できるが、画面デザインが存在しない状態だったため、`figma`を使い簡単な画面のデザインを作成し、他のメンバーのレビューを受けた上で実装を進めた。 # 取り組みの成果 - `Recoil`や`Graphql`といった新しい技術に触れ、知見を得ることができた - Figmaを使い、簡単な画面のデザインを作成できた - バンドルツールやTailwind CSSへの移行などより大きな範囲で改善を考え行うことができた - アプリを利用しているお客様との打ち合わせで仕様について提案するなど、実装以外の領域でも活動できた - 継続的なアプリの更新や品質が認められ、保守契約の延長に繋げられた

# 目的 背景 研究員個人によってバラバラに管理している実験とそれに紐づく評価の流れをモデリングできるようにし、部署全体で評価、実験のフローを共通化できるように支援する。 # チームについて - リードエンジニア 1名 バックエンド 1名 フロントエンジニア 2名 - PC画面のフロントエンド実装を担当 # 使用技術 - TypeScript - Remix SPAモード - Tailwind - tailwind-variants - urql - graphql - apollo client - valtio - radix-ui - Storybook - Zod - Zodix - svgr - dnd-kit - React Flow # 業務内容 - アプリケーションの立ち上げフェーズ(`0→1`)を経験した - 画面のデザインを除き、技術選定、ライブラリの調査を含むフロントエンドのアーキテクチャから構成を自分で考えて実装した ## 課題と工夫したこと、取り組んだこと ### アーキテクチャの選定 Next.js、Vite + Reactの構成などいくつか候補があったが、`Remix SPAモード`を選択した。Next.jsだとアプリの仕様より多機能すぎて機能を把握している時間が工期を圧迫しそうだと判断した。Vite + Reactの構成も候補にあったがルーティングの設定などもう少しルールのあるフレームワークが欲しいと感じ、そういった要望にRemix SPAモードは合致していると感じ選択した。選定の際にはRemix公式のサンプルや技術記事などで公開されているサンプルコードを参考に実装をし、その所感や参考記事などの調査結果をNotionにまとめチームメンバーに共有、合意を得た上でRemix SPAモードを選ぶことができた。 ### コンポーネント開発 別なアプリケーション(推算アプリケーション)ではMUIを利用していたため、スタイルをTailwind CSSへほぼ完全に移行したとはいえ、一部MUIが参照しているemotionのコードが一部に存在する形になってしまい、スタイルの実装方法が揃えられなくなっていた。そこで今回の実装ではメンバーからの提案もありheadless componentを使って実装することにした。Headless UIとReact Aria、Radix UIの3つの候補を検討した結果現状のデザインをカバーすることが可能と判断して`Radix UI`に決定した。Headless UIはコンポーネント数が少ないため今回の採用は見送った。React Ariaはサンプル実装中に挙動が怪しくなることがあり、実装経験ある他のメンバーからも挙動に関する意見があったため今回は見送った。headless componentの技術選定に関してはStorybook環境を立ち上げそれぞれのコンポーネントライブラリを実装し比較を行った。その結果もNotionにまとめチームメンバーへ共有し、技術選定の参考資料とした。アプリケーションに実装する際にもプロジェクト内でStorybook環境を立ち上げコンポーネントを実装し、`play関数を使ったコンポーネント単位でのテスト`を実装した。 ### その他の技術選定 アイコンとしてsvgを利用することが予想されたため、`svgr`の設定を構築しsvgをReact コンポーネントとして利用しやすい形にできるような体制を整えた。バックエンドとのやり取りはGraphqlを用いることとなったため他プロダクトの設定を参考にしながら`graphql-codegen`の設定を構築した。さらに.graphqlrc.tsを設定しVSCodeの拡張機能を取り込んだ状態でクエリを記述すると補完が効くように設定した。画面仕様として`React Flow`、`dnd-kit`を使用することが想定されたため、簡単なプロジェクトを作って検証し、結果をNotionにまとめて他のメンバーへ共有した。 ### タスクの進捗管理 今回フロントエンドの実装が2名体制だった。デザイン工程が押したため実装の期間が短くなったいる状況もあり、そのためタスクの配分と進捗の見える化を行う必要があった。そこで`Githubのissueをprojectを使ったボードで管理し、着手状況が把握できるようにした`。issueを書き出した際にタスクの規模感を大(topic) → 中(subject) → 小(task)と分割し、実装範囲を個人が把握しやすいようなタスク分割を行った。これにより当初の予定から遅れることになったが、お客様へ定量的に説明し新しいリリース日を設定しやすくなった。 ## 取り組みの成果 - 当初のリリース日からは遅れたものの、その後に行われたアンケートでは業務のモデリングに肯定的なフィードバックを得られた - アプリに対する機能追加の継続と、一般業務向けのデータモデリングツールの案件に繋がった - RemixのData Flowの知識とアプリの開発経験を得られた - React Flowやdnd-kit、floating-uiといったライブラリの知見を得ることができた - コンポーネント単位でstorybookを介したテストコードを記述し、デグレを防ぐ仕組みを作った - 個人の力で初めてフロントエンドのアーキテクチャを考えるところからリリースまで携わった - issueやprojectによるタスクの配分や管理を行い、進捗の見える化を行なった -ドキュメントに残すことを意識し、技術選定やアプリケーションのREADMEをしっかり書くなど他のエンジニアが参入した際にハードルを下げる施策を実行できた