My Engineering Mindset
基礎・低レイヤーの理解
新しい技術に向き合うとき、私は基礎を重視します。
調査や応用的な実装、エラー原因の究明において、その分野の基礎知識をどれだけ持っているかによって、得られる情報や実装の質、問題解決までの時間は大きく変わります。
また、私の経験上「すごい人」は、基礎がしっかりしているだけでなく、低レイヤーへの理解が段違いに深いと感じます。
基礎や低レイヤーの理解を疎かにせず、物事を正しく深く見られるように心掛けています。
My Development Approach
HTML
訪問者に対して、サイト内の情報が隔てなく公平に伝わるよう、HTML 構造を考えています。 視覚的な CSS の装飾によってのみ、その文章構造が把握できるということがないように、スクリーンリーダーによる読み上げやタブフォーカスの順序を考慮した設計を意識しています。 また、各 HTML 要素がユーザー側にどういった情報を伝えるのかを把握することに努め、文脈に沿った適切な要素を選択できるよう心掛けています。
CSS
デザインを忠実に再現することを前提とし、その上で設計者が意図する視線誘導の一助となる工夫が出来ればと考えています。要素を表示するタイミングや移動量、イージングが適切か検討を重ね、ストレスを感じないか、逆に視線誘導の妨げになっていないかを考えるようにしています。 なお、現状ブラウザのレンダリングプロセスに関する知識や経験が乏しく、適切なパフォーマンスであるかを定量的に判断することが出来ていません。ブラウザでの検証を通じて、知見を深め、パフォーマンス改善の感覚を養うことが今後の課題です。
CSS Frameworks
これまで CSS フレームワークと真剣に向き合ったことがありませんでしたが、Twitter（現X）上でそれに関する話題を目にする機会が増え、最近 Tailwind CSS を触り始めました。「○○ だから Tailwind はダメ」という指摘が度々波紋を呼んでいますが、自身に経験がないことにはどうとも受け止められないので、まずは色々と試すことにしました。今のところ、HTML 内で CSS が完結する点や、スタイルの影響範囲が明確であるという点で、Tailwind の良さを感じています。また、Arbitrary values や Arbitrary properties、Arbitrary variants といった自由度の高さも気に入っています。
SVG
CSS では難しい表現、特にフィルター系の表現は SVG が有利だと感じており、その可能性を模索しています。一方で、SVG filter はブラウザによって挙動がまちまちであるため、ブラウザごとの特性を理解することが大事だと考えています。正しく記述しているはずなのになぜか動かないといった不具合も度々遭遇するため、経験値的な部分も大事にしています。
JavaScript, TypeScript
フロントエンド開発において、ライブラリやフレームワークをどう活用するかだけでなく、その背景にある考え方や仕組みを理解することを大切にしています。 特に、JavaScript ライブラリを使用する際は、その動作原理を理解するため、スクラッチを経由する場合が多いです。 GSAP のようなモーションのタイミング制御・補間を行うライブラリや、Swiper のような特定の UI 機能を提供するライブラリなど、簡単に利用できる反面、その抽象化の裏にある実体は理解しにくいと感じます。 スクラッチを通してそれらの動作原理を追うことにより、応用する力、エラーへの対応力を磨き、汎用的に活かせる知識を得ることを心掛けています。 また、最近は TypeScript を使う機会が増えました。型エラーに悩まされることもありますが、その恩恵も強く感じています。IDE の型補完により、引数や戻り値が即座に把握できたり、protected を含むアクセス修飾子でクラス設計の意図がより明確になることで、保守性・拡張性の向上を感じています。
JavaScript Frameworks
バックエンドの学習を進める中で、API を介したフロントエンドとの連携に興味を持ち、Next.js を学び始めました。Next.js で基本的な UI 機能を実装する練習を通して、コンポーネントの考え方や状態管理への理解が深まりつつあります。 一方で、自分の実装がフレームワークの思想に沿っているのか確信が持てないため、公式ドキュメントを参照しつつ、SNS 上の有識者の意見も取り入れながら「保守性」「パフォーマンス」「可読性」の観点から実装の妥当性を検討しています。 また、Next.js のほかに Astro も触り始めました。Web サイトとしての文脈では、プロジェクト規模によっては Next.js が少し大袈裟に感じられることもあり、その点で Astro のシンプルさや扱いやすさに魅力を感じています。
WebGL, GLSL
板ポリゴンを使った演出を好み、Web サイトに自然に溶け込みながらも、思わず「おっ」と感じさせる表現を探求しています。 特に、シェーダアートと呼ばれる分野に興味があり、Web サイトという文脈で活かせる表現を模索しています。一方で、フラグメントシェーダによる実装が主となるため、描画負荷は画面解像度に大きく依存します。そのため、シェーダ処理の最適化や Canvas 解像度の制限、FPS の安定化など、パフォーマンスを維持するための調整にも取り組んでいます。 また、3D モデルを使った演出にも興味があり、今後は Blender の学習を進めたいと考えています。モデリングから Web 上での実装まで、一貫して担える知識と経験を身につけることを目指しています。
PHP
フォームやログイン認証機能、CMS がどのように設計・実装されているのかを知りたいという思いから、バックエンドの学習を始めました。 学習を進める中で、API で返したデータがフロントエンドでどのように利用されるのかを意識するようになり、「API を作る側」と「API を使う側」の両方の視点が必要だと感じています。 API の設計理解を深め、バックエンドとフロントエンドをつなぐ全体像を俯瞰できるようになることを目指しています。
SQL
バックエンドの学習をするにあたり、データベースの操作をできるようになるため学習を始めました。 N+1 問題を避けてパフォーマンスを維持すること、トランザクションでデータの整合性を保つことなど、データ操作における基本原則を意識しながら理解を深めていきたいと考えています。
PHP Frameworks
CMS を自作したいというモチベーションと、メインの機能開発に集中したいという思いから、Laravel を学び始めました。 PHP でフォームやログイン認証機能をスクラッチ実装した際は脆弱性対策が大変でしたが、Laravel では CSRF 対策などが自動化されており、安全性が保たれる工夫を実感しました。 Laravel で自作の CMS を実装する目的は果たしましたが、今後は API ベースの CMS を実装することを目標とし、その過程で API 設計の理解を深めたいと考えています。
CMS
これまで WordPress と microCMS を用いたサイト制作を経験してきました。 WordPress では、PHP テンプレートにコードを書き込むクラシックな方法で実装してきましたが、保守性や現在の WordPress の方向性を踏まえると、ブロックテーマによるフルサイト編集を中心としたノーコード実装への移行が必要だと感じています。フルサイト編集の経験はまだ浅く、書籍を参考に試作した程度ですが、今後習得すべき重要なスキルと考えています。 一方で、個人的にはフルサイト編集よりも、microCMS などのヘッドレス CMS を活用した実装に魅力を感じています。特に、開発に自由度があるゆえ、演出やユーザー体験の表現を柔軟に設計できる点が魅力的です。予算やプロジェクトの特性に応じて判断する必要はありますが、今後はこうした技術を活かせるプロジェクトに携わりたいと考えています。 また、ノーコード領域では Framer や Studio といったサービスも存在感を増しており、プロジェクトの特性に応じて最適な選択ができるよう、これらのツールも積極的に試していきたいと思っています。
Development Environment
ソースコードのバージョン管理に Git を利用し、開発環境の構築には Laravel で Docker を、WordPress では Local や MAMP を利用しています。 また、最近は GitHub Actions を触り始めました。ビルドやレンタルサーバーへのデプロイを自動化することを目的に導入しましたが、今後 CI におけるテストの導入や運用についても理解を深めたいと考えています。