ご覧いただきありがとうございます！広報のノムラです。
今回は、制作部でフロントエンドエンジニアとして実装や環境構築を担当している吉田さんにお話を伺いました。
最新技術が次々と生まれるエンジニアの世界。膨大な情報の中から「本当に実務に活かせるものかどうか」を精査し、見極める力が求められています。
吉田さんは、それらを多角的な視点で吟味し自分一人の作業効率だけでなく、後続メンバーの作業のしやすさや、ディレクター・デザイナーとの共通認識を何よりも大切にしています。
自分なりの「最適」を追求し続ける吉田さんの仕事観と、その根底にあるモノづくりへのこだわりをたっぷり語っていただきました。ぜひ最後までご覧ください！
自己紹介と現在のお仕事について
それではまず、自己紹介と現在のお仕事の内容を簡単に教えてください。
吉田：フロントエンドを中心に、Webサイトの構築やWordPressサイトの構築などを担当しています。静的構築からCMS組み込みやカスタマイズまで携わり、
開発環境の改善や保守性を意識した設計にも取り組んでいます。
最近は、AstroやDockerを活用した開発環境の整備など、
制作効率やメンテナンス性を高める取り組みにも力を入れています。
現在の業務における技術選定基準と提案する際の注意点について
現在のプロジェクトで採用している技術スタック（React/Next.js/TypeScript等）について教えてください
吉田：静的サイトの案件では、Astroを採用することが多いです。Astroは構成がシンプルで、環境構築が比較的容易な点に魅力を感じています。
個人で対応する案件が多い一方で、後から別のメンバーが入る可能性も考慮し「特別な知識がなくても、すぐに環境を立ち上げて作業に入れること」を重視した技術選定を行っています。
WordPressのテーマ開発においても、以前は静的構築後に WordPress化する手順を取っていましたが、手間や再現性の面で課題を感じていました。
そこで、Dockerを用いたローカル環境構築に加え、ViteやSCSSを取り入れることで、
開発体験と保守性の向上を意識した構成にしています。
業務の中で「技術的な改善」を提案する際、どういった点に考慮して技術スタックを選定していますか？
吉田：技術的な改善を提案する際は、まず日々の業務の中で感じている「小さなストレス」や課題を整理することから始めています。
その上で、現在主流となっている言語やライブラリ、プラグインなどに同様の課題を解決できる選択肢がないかを調べ、実際に自分で試したうえで業務に適しているかを判断します。
試した結果、既存のツールで十分に解決できる場合はそれを採用し、要件に合わない場合は別の選択肢を検討する、もしくは必要に応じてシンプルな形で自作することもあります。
既存コード（技術負債など）に対して、どのように優先順位をつけて整理・運用していますか？
吉田：以前、同じ条件分岐が複数箇所に散在しており、修正のたびに対応漏れが起きやすい状態のコードがありました。その際は、保守性向上のために処理を一箇所にまとめ、必要な箇所のみで分岐する構造へと整理を行いました。
この経験から、現在は技術的な改善を行う際、単にコードを綺麗にするだけでなく「仕様の深い理解」と「影響範囲の洗い出し」を優先にすることを、自分の中の判断基準として意識しています。
インプットを実務の課題解決に繋げる方法
フロントエンドの情報は非常に変化が激しいですが、日々のインプットでルーティンにしていることや、信頼している情報源（技術ブログ、X、コミュニティ等）はありますか？
吉田：「あらかじめ決まった情報源を追い続ける」よりも、その時々で直面している課題に応じて調べ、試すことが多いです。
日常的には X で流れてくる技術的な話題をきっかけに、気になったものがあれば関連する記事やドキュメントを確認し、実際に手を動かして検証する、という流れが多いです。
特定の情報源を「正解」として信頼するというよりは、「そういう考え方や実装方法もあるのか」という前提で受け取り、実際に自分の環境で試してみて、使えるかどうかを判断するようにしています。
最近注目している技術を、実務に落とす際の判断基準は何ですか？
吉田：実務に落とす際はまず「本当に必要かどうか」を判断軸にしています。
過去に、新しい技術を取り入れようとして想定以上に工数がかかってしまった経験があり、
現在はまず「シンプルな構成で完成させること」を重視するようになりました。
まずは安定した形でリリースすることを前提とし、その上で余裕があれば改善や検証として取り入れる、というスタンスで技術選定を心がけています。
AIの活用とこれからのフロントエンド
現在、コーディングや設計においてAIをどのように活用していますか？ 活用例があれば教えてください。
吉田：主に、実装方針を考える際の壁打ちや、自分の考えを言語化するための整理に使うことが多いです。
複数の実装パターンが考えられる場合にそれぞれのメリット・デメリットを整理したり、設計の抜け漏れがないかを確認する目的で活用したりします。
影響範囲が小さい実装については、生成されたコードをそのまま利用することもありますが、設計や影響範囲が広い部分については、AIの提案はあくまで参考とし、最終的な判断や調整は自分で行うようにしています。
AIによって「エンジニアの役割」は変化していくと考えていますか？
吉田：AIの活用が進むことで、特にコーダーやフロントエンドエンジニアの役割は変化していくと感じています。
これまでは、手を動かして一から環境構築や実装をすることが多かったと思いますが、
AI が補助できる範囲が広がるにつれ、要件をどう解釈し、どのような構成・設計に落とし込むかといったエンジニアリング寄りの力がより重要になっていくと考えています。
AI に対して適切な指示を出すためにも、技術の知識だけでなく、仕様理解や設計の判断、
その結果を評価できる経験が必要になってくるのかなと思います。
AI時代においても、フロントエンドエンジニアとして「こだわり」はありますか？
吉田：AIの進化やプロセスは今後さらに変化していくと考えていますし、ユーザーの入力情報をもとに、必要な情報を整理し、それを伝えるための UI を生成することは、AI が得意とする領域になっていくと思います。
（すでにそういった仕組みを持つツールも増えてきています）
ただ、特定の実装手法に固執するのではく「ユーザーが迷わず使えて、ストレスなく目的を達成できること」がきちんと実現できているかどうか、という点が一番大切だと思っています。
その前提の上で機能としては必須ではないけれど「使っていてちょっと楽しい」「少し嬉しい」そう感じてもらえる”遊び心”を添える余白は大切にしたい。
プロジェクトの状況に合わせてそのバランスを微調整する判断こそが、AIには代替できない、人が担うべき価値だと思っています。
今回のインタビューでは、常に「正解」よりも「最適」を追い求め、技術を手段として使いこなす吉田さんのストイックな姿勢がとても印象的でした。
「後から入るメンバーが迷わないように」というチームへの配慮。そして「使う人が少しでも楽しくなるように」というフロントエンドエンジニアとしてのこだわり。そうした吉田さんの細やかな視点は、単なる実装の枠を超えmonomodeが提供するプロダクトの品質を根底から支えています。
monomodeでは、最新技術にアンテナを張りながらもそれをどう実務に落とし込み、価値に変えていくかを自分自身で追求できる環境を大切にしています。技術に対して誠実に、そして柔軟に向き合い続ける吉田さんの挑戦を、これからも全力でサポートしていきたいと思います！
「DAYs」では、引き続き社員のリアルな声や、チームの取り組みをお届けしていきます。次回の更新もぜひお楽しみに！ monomodeでは一緒に働く仲間を募集中です。興味を持ってくださった方は、ぜひ採用情報をご覧ください！
Recruit：https://monomode.co.jp/recruitment
