山名 流聖 の記事一覧

こんにちは。GMOインターネットグループ株式会社でフロントエンドエンジニアをしている山名です。入社3年目にして初めてNext.jsに触れたエンジニアが、中規模サービスのコンポーネントを設計する中で感じたことや実際に試したことなどを書いていきます！コンポーネントの設計は人によって好みが分かれる部分な気がしているので、あくまでひとつの例として見ていただけると嬉しいです！ 前提：コンポーネントとその設計 実は今回のコンポーネント設計を担当するにあたり、最初は「そもそもコンポーネントって具体的に何？」「それを設計するって言われても...」状態でした。困ったときはどうするかと言うと、そう、AIに聞きます。 つまりは、ページやサービスを作成する際のUIをそれぞれパーツ毎に分割したものがコンポーネントであり、その分割の仕方やそれぞれにどんな機能を持たせるか、どんな管理方法にするのかを決めていくのがコンポーネントの設計ということですね。 とにかくやってみないことには始まらないので、ある程度UIのデザインが固まった時点で構成やどんな粒度でコンポーネントを分けて開発していくかを決めていきます。 アトミックデザインで考える ひとまずコンポーネントの設計には、アトミックデザインの手法を採用して構築していくことにしました。 アトミックデザイン アトミックデザインは、簡単に言えば「UIコンポーネントを5つの大きさに分類して効率的に設計するデザイン手法」になります。 この単位に合わせてUIを小さな要素から大きな要素へと構築していきます。 アトミックデザインを採用するメリット 一般的にアトミックデザインを採用するメリットは、再利用性や一貫性の向上、スケーラビリティ、開発効率の向上が挙げられます。 実際に自分がサービス開発で触れた際も、アトミックデザインを採用した設計はコンポーネント毎の大きさや使用する場面,場所など、開発が楽になるように明確なルールを持たせることができるのが非常に魅力的でした。 メリットがあればデメリットもある 前述のメリットがある一方で、実際に設計してみて気づいたデメリットもいくつかあります。 ・過剰な設計による管理の複雑化　→ 今回の規模感で丁寧にアトミックデザインで設計しようとすると、細くなりすぎる部分がありむしろ管理が大変になってしまう ・設計粒度が統一しずらい　→ チーム開発の現場においては、設計粒度のルールがあっても個人間で微妙な認識のずれが起こる可能性がある ・特にMoleculesとOrganismsの違いが明確につけずらい　→ コンポーネント自体がそこまで多くない環境だと、個人的にとても分けずらい印象があった オリジナルの設計を考える どうしてもデメリットの部分を無視できなかった結果、少しだけ設計を変えてみることにしました。 新しい設計の要件は、「ベースとしてアトミックデザインを踏襲しつつ、過剰設計と設計粒度のずれ問題を解決する」です。 単位を減らして分け方を簡単にしてみる 元々のアトミックデザインの考え方自体はとても有用なものだったため、それを踏襲しつつ課題を解決することを考えた結果、見出しにある通り設計の単位を減らすことにしました。 具体的には、サービス規模とコンポーネント数の関係で違いが付けずらかったMoleculesとOrganismsの分類をなくし、Units（ユニット）と言う単位を新設することでコンポーネントの分類を簡略化、設計粒度のずれが起こらないようにしています。 AtomsとUnits Atomsがコンポーネントの最小単位であることは変わりませんが、新設したUnitsの分類については「何かしらのUIコンポーネントが内部で呼び出されているか」で判別しています。 コンポーネント作成時に考えるポイントが、他のコンポーネントを読み込んでいるかどうかだけで良くなったというだけでコンポーネントの分類を２つにした意味はあるかなーと思います。 （ただ、この運用だとUnitsコンポーネントが同じUnits単位のものを読み込むという状況が起こってしまうのが若干スッキリしないポイント...） まとめ 今回素人ながらコンポーネント設計を担当し感じたことは、「開発ルールを明確にする」ことと「ある程度遊びが効くようにする」ことのバランスが大事ということです。コンポーネントの開発自体は規模によって変動していくものですが、前述のバランスが取れていない状態だとどんな状況であれ無駄な工数や再設計のリスクが高まる気がしています。 記事内の設計の話については個人的な好みが多分に含まれていますが、一つでも何かしらのヒントなれば幸いです。

12/5-6 に弊社最大のテックカンファレンス「GMO Developers Day 2023」が開催されました。自分はdevday特設サイトのフロントエンド・webコーディング周りを担当しておりましたので、今回はその制作裏話をまとめてみました。 対応範囲 デザインコーディングフォーム実装配信・アンケート連携実装各切り替えタイミングに合わせた時限設定の実装2023管理用のWordPressの用意 ティザーページ メインページ キャンペーン詳細ページ 配信ページ フォームページ×3 (フォーム回答完了ページ×2) メインページ内にはデザインコーディングから少し外れたような機能実装も含まれていますが、大雑把に分けると上記のような対応範囲で制作にあたりました。 サイト構成 ディレクトリ構成自体は昨年改修されたものをもとに、2023年用のディレクトリを新設しています。/developersday/からのインクルード先を変更するだけで簡単に公開/アーカイブが切り替えられるため、去年以前のサイトには手を加える必要もなく安全に作業できたように思います。 developersday/ ... 集客前はティザーページ、開始後はメインページをインクルード ├ 2020/ ├ 2021/ ├ 2022/ ├ 2023/ │ ├ index.php ... メインページ │ ├ teaser/ ... ティザーページ │ ├ broadcast/ ... 配信ページ │ ├ campaign/ ... キャンペーン詳細ページ │ ├ entry/ ... 事前登録フォーム │ │ └ complete/ ... 登録完了ページ │ └ survey/ │ ├ session/ ... セッション別アンケートフォーム │ ├ archive/ ... アーカイブアンケートフォーム │ └ complete/ ... 回答完了ページ ├ broadcast/ ... 配信ページをインクルード ├ campaign/ ... キャンペーンページをインクルード ├ entry/ ... 事前登録フォームをインクルード └ survey/ ├ session/ ... セッション別アンケートフォームをインクルード └ archive/ ... アーカイブアンケートフォームをインクルード また、今年はテスト段階でグループのパートナーにも確認が必要とのことで、従来の社内IPによる閲覧制限が使用できず、急遽2023/配下にBasic認証を入れて制限付きでテスト確認を行なっていました。 デザインコーディングについて 「DevDay2023はクリエイティブにも力を入れたイベントにしたい！」とのことで、サイトデザインもかなりリッチなものになっています。担当デザイナーさんの力作です。 演出面などはデザイン段階でイメージなどをデザイナー・映像クリエイターと共有しつつ、「こんな動きならできます」「いやそれは厳しいっす」などのやり取りを繰り返し、最終的には実装可能な範囲でデザインに落とし込んでいただきました。 基本的なコーディングは普段のものとあまり変わらなかったのですが、今回は演出面でスクロール量や位置に合わせてアニメーションが変化する「スクラブアニメーション」の実装が必要になりました。 初実装＆実装範囲がページ全体ということで、今回は1から自分で作るのではなくJavaScriptライブラリの「ScrollTrigger」を使っての実装に決定しました。 const timeline = gsap.timeline({ scrollTrigger: { trigger: '.js-trigger', // トリガーとなる要素 start: 'top 50%', // アニメーションの開始位置 end: 'bottom -10%', // アニメーションの終了位置 scrub: true, // 大事!! trueにすることでスクロール量に合わせてアニメーションが進む }, }); ------ timeline.fromTo('.js-target', { // アニメーションさせる要素 scale: 0, // 開始時のスタイル backgroundSize: 'auto 400px', // 開始時のスタイル }, { scale: 10, // 終了時のスタイル backgroundSize: 'auto 200px', // 終了時のスタイル }); ただ、実装簡略化のために使用を決めた結果、一旦何ができるのか・どういう仕様なのかを確認する時間が発生してしまいました。結果的に最初に設定されていたライブアップの段階では、細かく調整したものは間に合わず大枠ができたものをライブアップ→その後数日かけて調整、アップデートする流れとなりました。 フォーム実装について 今年作成したフォームは、下記の3つになります。 事前登録フォームセッション別アンケートフォームアーカイブ用アンケートフォーム それぞれ項目や処理部分に若干の違いはありますが、概ね同じ仕様にて実装しています。特筆すべきは回答の収集をGoogleフォームで行っていることです。 サイト側とGoogleフォーム側で同じ項目・選択肢を作成し、サイト側からAPIを介して回答データをGoogleフォームへ送信しています。 基本的にGoogleフォーム側にある項目ごとのIDを間違えていなければ問題なく送信されます。ただ、いくつか気をつけないとエラーが出たり想定外の動作になったりしたので実際のケースを共有しておきます。 選択肢の文字が違う 　　→ 送信するデータとGoogleフォーム側は全く同じ文字列じゃないとエラーが出ます。当然文字コードも同様なんですが、macだと同じ文字に見える問題がありエラーが出ました。 チェックボックス形式で複数回答を送信 　　→ 今回の処理（curl送信）だと、1回の通信で同一のIDに複数回答を送ることはできないため、選択した項目を結合後1つのテキストデータとして送信していました。 配信・アンケート連携について 昨年に比べて、配信ページ自体の仕様はかなり簡単なものでした。最初はそもそも不要なページではあったのですが、やはりサイトに訪問してほしい＆サイト内にのみアンケートの導線を置きたいとのことで、配信画面とセッション別にアンケートへの導線を表示するページを作成しました。 配信画面 今年は配信をYouTube Liveで行うとのことで、配信画面はお馴染みiframeで埋め込むだけで完了です。 結果的には実装なしになりましたが、YouTube Liveのチャット欄を埋め込む案も出たためそちらの検証も行いました。デザイン的な自由度はありませんが、チャンネルIDと埋め込み先のドメインを指定することで動画同様にiframeで埋め込み可能です。 <iframe width="" height="" frameborder="0" src="https://www.youtube.com/live_chat?v=【チャンネルID】&embed_domain=【埋め込み先のドメイン】" allowfullscreen></iframe> Day1からDay2、アーカイブ期間への切り替えもありましたが、その辺りはまとめて時限設定をして自動で切り替わるようにしています。 アンケートバナー セッション別のアンケートバナーは、セッション開始”予定”時刻の10分後からセッション終了”予定”時刻の10分後まで表示される仕様で、表示するタイミングを判断する処理は昨年の「1分ごとにJSONデータを読み込む」処理をもとに実装しています。 処理自体は一見シンプルに見えますがユーザーの環境に影響されにくく、かつ処理も重くない。さらにデータの取り扱いも楽ということで実装自体もだいぶ楽にできたように思います。 時限設定 配信ページの切り替えは、下記のタイミングで時限設定を組み込みました。 Day1配信終了時　→ 配信画面をDay2に切り替え Day2配信終了時　→ アーカイブ配信画面に切り替え アーカイブ公開期間終了時　→ 配信ページクローズ・トップへリダイレクト 時限の設定自体は難しいものではないので実装に関して特筆することもないのですが、今回は何より時限の数が多いことが問題でした。配信ページ以外でもトップやキャンペーンページでそれぞれの時限設定が入り混じるので、確認にかなり工数をかけた気がします。 それに加えて、フロントでデバックする時用に用意していた、アンケート表示のための時限設定（ページ切り替えとは別）も別軸で確認が必要でした。 実装を断念したもの / 課題 いくつか実装に至らなかったものや課題が残る点があったため最後にまとめておきます。 プッシュ通知 イベントの開始時間や、ユーザー自身が選択したセッションのプッシュ通知を受け取れるという機能です。 実装方法は developers.gmo.jp/developersday/配下 をPWA化することにより、キャッシュ保存機能を追加。ローカル環境でも動作するようにしたところでserviceWorkerから、指定の時間になったらプッシュ通知を送信するというものです。検証を始めた当初、PWA化もプッシュ通知送信も問題なく動作していたのですが、細かい仕様の実装に入ったところで壁がありました。 ユーザーごとに選択したプッシュ通知を受け取る仕様なんですが、以下のような過程で検証を進めた後、期間内では無理ということに。 通知に関しては、カレンダーリンクを設定することで解決しましたが、プッシュ通知はどこかのタイミングでリベンジしたいです。 アンケート項目について 例年セッションごとにアンケートは回答してもらう仕様になっていますが、例に漏れず今年も同様の仕様でした。 セッションごとのアンケートとなるとフル回答で34セッション、アーカイブアンケートを含めると68セッション分もあるのです。 もちろん、それぞれに対してしっかりと感想や評価を回答して欲しいのですが、名前やメールアドレス、ユーザー属性など回答ごとに変化しないものに関してはcookieに保存しておくとユーザー的にも嬉しかったのかなと思います。 こちらの意見は本番中にいただいたのですが、イベント中にフォームに改修を加えるのもいかがなものかということもあり、次回への課題として残しておこうと思います。 制作スケジュールについて デザインコーディングの部分でも少し書きましたが、スケジュールが中々にタイト且つ調整やスタイルを当てる作業に時間をかけてしまったことにより、Web制作期間の中盤あたりがかなりぐちゃぐちゃになってました。。 日々の定例やガントチャートで逐次確認はしていたものの、自身の作業遅れ＋追加の仕様変更＋テスト/ライブ修正対応が重なるタイミングがあると、スケジュールはあってないようなものになりがちでした。 もう少し長めに制作期間をとることもそうなんですが、まず修正がないよう丁寧な仕様確認とコーディングをすることは確実に今後の課題です。 最後に 反省と学びが凄まじいプロジェクトでしたが、2年目で経験できてラッキーだと思います。 来年以降もまたイベントは開催されますので、そこに向けてさらに良いものが制作できるよう今年の反省を活かしていきます。

こんにちは。GMOインターネットグループ株式会社 クリエイティブ部 フロントエンドエンジニアの山名です。Webコーダーとして業務レベルでどのようにGitHub Copilotを活用しているかご紹介します！ はじめに 現在GMOインターネットグループは全社的にAI活用に取り組んでいます。 私が所属するクリエイティブ部フロントエンドチームでもGitHub Copilotが導入されて約3ヶ月が経ちますが、もう使う前には戻れないくらいその便利さを実感しています。 そんなGitHub Copilotですが、一通り業務内で活用してみて、なんとなく便利な使い方やパターンが見えてきましたので、「WebコーダーのGitHub Copilot活用術」としていくつかご紹介していきます！ 前提：GitHub Copilotとは GitHub CopilotはAIを用いてコーディング作業を支援する有料サービスです。具体的にできることを、実際にCopilotに聞いてみました。 GitHub Copilotを活用すると何ができるのか教えてください。 CopilotGitHub CopilotはAIプログラミングアシスタントで、以下のようなことが可能です：・コードの自動補完：GitHub Copilotは、あなたがタイプするにつれてコードを自動的に補完します。これにより、新しいAPIを学んだり、既存のコードを早く理解したりするのが容易になります。・コードの生成：GitHub Copilotは、あなたが書き始めたコードから意図を推測し、必要なコードを生成します。これにより、新しい機能の開発やバグの修正が効率的になります。・コードの学習：GitHub Copilotは、あなたが書いたコードから学習します。これにより、あなたのコーディングスタイルやプロジェクトの特定のパターンを理解し、それに基づいて提案を行います。・コードのレビュー：GitHub Copilotは、あなたが書いたコードをレビューし、潜在的な問題を指摘します。これにより、コードの品質を向上させることができます。ただし、GitHub Copilotはあくまでアシスタントであり、全てのコードを自動的に生成したり、全てのバグを見つけ出したりするわけではありません。あなた自身の判断と経験が重要です。 とのことです。 他にも、チャット機能から様々な質問をすることもできるため、本当に優秀なアシスタントが常にいるような感覚になります。 ちなみに、 GitHub CopilotはGPT-3.5 TurboGitHub Copilot ChatはGPT-4 が使われているそうです。 ある程度のコードの叩き台を生成するときは通常のGitHub Copilot、ライブラリの使い方や詳細な回答が欲しい場合はGitHub Copilot Chatを使うなどの使い分けもできますね。 GitHub Copilot活用例 基本のスタイル生成 作りたい形などのイメージをテキストで入力することで、即座にそれっぽいコードを生成してくれます。 特に「吹き出し」や「リボン」など擬似要素を含めた形の長めなスタイリングは、書き慣れていたとしても生成した方が早かったりすることもしばしばあります。 実際にコメント部分とクラス名のみを入力して生成した例です。 コードがサジェストされるまでは0.5秒程度ですが、その後修正する時間を考えてもかなり早くなっています。 羅列データの変換 エクセルから持ってきたような羅列されたデータに対しては、HTMLのリスト要素や配列などの形式を指定すれば一括で変換したコードを生成してくれます。 地味といえば地味なんですが、データの数が多くてしかもツールとか使えない状況だと本当に助かります。 コメントにクラスの追加や○個目の要素に〜などの指示を入れることで、ほぼ修正も必要なく生成できるのも便利です。 CSSからSCSSへの書き換え リファクタリングなどでCSSのコードをSCSS表記に移管するのはなかなかに面倒な作業ですが、変換したい部分を選択して「SCSS形式に変換」とするだけで、クラス名やネストをしっかり守ったコードに変換してくれます。 正規表現のサポート 正規表現も条件や目的が明確であれば、ある程度の精度でコードを生成してくれます。 複雑な正規表現の例として、メールアドレスバリデーションのための正規表現をCopilot Chatに聞いてみました。 検証は別途必要だとしても、説明付きでここまでの正規表現を生成してくれるのはありがたいですね。 まとめ 個人的な視点で便利な使い方などをいくつかご紹介しましたが、コード生成の精度が上がってきたり使用者のAI活用スキルが向上することでまだまだ便利な活用方法が出てくるのではないかと思っています！ ただ、やはり現状では生成したコードが本当に正しい挙動をするのか。Webコーダー視点で言えば、デザイン的に問題ないスタイリングがされているかなど、人の目が必要な部分があるのも事実です。 AIは積極的に活用しつつ、あくまで補助としてこれまでの制作に組み込みながらうまく付き合っていくのが必要ですね。

こんにちは。GMOインターネットグループ株式会社 フロントエンドエンジニアの山名です。今回は、HTMLやCSSの進化によって実装がより簡単になったデザインや機能を従来の実装方法と比較しながらご紹介していきます！ 執筆の背景 いきなりですが、HTML,CSSをはじめとしたWebコーディングの世界って進化が早いですよね。 新機能のリリースやデザイントレンドの移り変わりがあって、これまでスタンダードだと思っていた実装方法がいつの間にか過去のものに...なんて経験がある方も少なくないはずです。 そんなWebコーディングの"ちょっと前"と"今"を比較して、どれだけ便利になったのか確かめてみようということで本記事の執筆にいたりました。 CSSの実装比較 早速、最新のコーディング技術をご紹介！といきたいところですが、まず前提として今回ご紹介する新機能の基準を書いておきます。 CSSの新機能を紹介執筆時点で主要ブラウザにて動作が確認できる 上記に記載の条件に沿って、5つピックアップしましたので従来の方法と合わせて比較、ご紹介していきます！ グラデーションテキストを作る 従来：illustratorなどで画像書き出し テキストにグラデーションを設定した画像を作成し、<img>要素で読み込むことで表示させる必要があります。 今：background-clip: text を使って実装 background-clip: text を使用することで、指定したテキストの形に背景を切り取ることができます。 また、背景の指定をグラデーションから画像にすることで画像をテキスト型に切り取ることも可能です。 See the Pen Untitled by RyuseiYamana (@RyuseiYamana) on CodePen. 要素の固定 従来：position: fixed を使用 単純な要素の固定であれば、特定の要素にposition: fixed を指定することで実装可能ですが、任意の場所で固定を解除したい場合などはjsからpositionの値を変える必要があります。 今：position: sticky を使用 IEサポート終了によって使いやすくなったposition: sticky は、要素を任意の位置に固定/解除ができるプロパティです。 ページ内に複数実装するのも簡単ですが、親要素に高さを持たせるのを忘れがちなので、注意が必要です。 See the Pen Untitled by RyuseiYamana (@RyuseiYamana) on CodePen. スムーススクロールの実装 従来：JavaScriptで実装 スムーススクロールを実装する方法はいくつかありましたが、いずれもプラグインを読み込んだりJavaScriptやjQueryを使用する必要がありました。 細かいカスタマイズができる利点はありますが、やっぱり少し手間に感じます。 今：scroll-behavior: smooth を使用 CSSでhtml要素にscroll-behavior: smoothを指定するだけで、ページ内アンカーリンクの移動がスムーススクロールになります。 html { scroll-behavior: smooth; } ホバースタイルの出し分け 従来：画面幅によってホバースタイルを出し分け メディアクエリで画面幅からPC/SPを分けることで、それぞれホバースタイルを出し分ける方法ですが、デバイスサイズが多様化したりユーザー環境により期待通り動作しない場合があります。 a { color: #000; } // PCの画面幅を指定 @media screen (min-width:900px){ a:hover { background-color: #555; color: #fff; } } 今：ホバー対応デバイスかで出し分け メディアクエリのany-hover を使うことで、そのデバイスがホバーアクションに対応しているかどうかによってスタイルを出し分けることができます。 // ホバー対応デバイス @media (any-hover: hover) { a:hover{ background-color: #555; color: #fff; } } // ホバー非対応デバイス @media (any-hover: none) { a{ color: #000; } } ブレイクポイントの指定 従来：min-width,max-widthで指定 画面幅の最大値、最小値などの組み合わせでブレイクポイントを指定します。 @media (max-width: 599px) { // SP用スタイル } @media (min-width: 600px) and (max-width: 1200px) { // TB用スタイル } @media (min-width: 1201px) { // PC用スタイル } 今：画面幅を比較演算子で指定 メディアクエリで比較演算子「 < , <= , => , > 」が使用可能になったことで、より直感的にブレイクポイントが指定できるようになりました。 @media (width < 600px) { // SP用スタイル } @media (600px <= width < 1200px) { // TB用スタイル } @media (1200px <= width) { // PC用スタイル } 終わりに 今回はCSSに焦点を当てて、新機能の紹介や従来の実装方法との比較をしてみました。体感的にはCSS（＋HTML）だけで完結できるような機能や表現がだいぶ増えたなという感じです。 もちろん従来の方法が適している状況だったり、今回例として出していない他の実装方法の方が良い場面なんかも多々あると思いますが、ひとまず「CSSでこんなことできるようになったんだ」くらいに感じていただければ幸いです。 まだまだ主要ブラウザの対応が待ち遠しい新機能もありますので、ぜひリリース情報にアンテナを立ててみてください！

こんにちは。GMOインターネットグループ株式会社 フロントエンドエンジニアの山名です。この度、弊社の新卒採用サイトのフルリニューアルを担当させていただいたので、その際に新卒なりに意識したことなどをご紹介していきます！ 執筆の背景 冒頭でも少し触れましたが、この度GMOインターネットグループ株式会社の新卒採用サイトをフルリニューアルするとのことで、企画から公開までフロントエンドとしてプロジェクトに参画させていただきました。 自分が配属されてから約3ヶ月、案件としてサイトの構築から担当するのは初めてだったこともあり、何もかも手探りの状態で制作を進めました。 そんな中でも、「ここはこうしよう」「これはこっちの方がいいはず」と自分の知識を総動員しつつサイト構築を行っていたのですが、今思えば結構大事なことを考えていたのかもしれないなぁと思っています。 ということで今回は、新しくなった新卒採用サイトの告知がてら新卒一年目がサイト構築で意識したあれこれをご紹介していこうと思います！ サイト構築で特に意識したこと4選 ここからはサイト構築で特に意識したことを4つご紹介していきます！ 1.チーム内のルールから逸脱しすぎない やって当然と言われそうですが、なんならここが一番大変だった気がします。 今までの個人制作では、厳密なルールなどは決めずに好きに作っていましたし、入社後担当していた商材の保守案件では元々チーム内のルールに沿って作られたものを編集するだけなことが多かったため、いざ1から作るとなるとどうしても自分の手癖が出てしまって苦労しました。 ある程度好きに作ってもいいよとは言われていたのですが、クラスや変数の命名規則、基本的なディレクトリ構成に関しては、今後の保守に関わってくる部分なのでコーディングをする際にはこういった部内ルールを守るようにしていました。 また、GMOインターネットグループ株式会社のサイトとして公開される以上、グループ共通のヘッダーやロゴの扱いに関しても厳しいルールがあるため、そういったことも含めて構築するサイトがチーム内のルールから逸脱しすぎないように意識していました。 // 例 // クラス名はBEMで書く // JavaSvcriptで制御するものには接頭辞に「js-」をつける <section class="mainvisual"> 　　<div class="mainvisual_movie"> 　　　　<video src="◯◯"></video> 　　</div> 　　<button class="mainvisual_movie_play js-movie_play">PLAY</button> </div> 2.誰が見ても分かるコード やって当然（2回目）です。それでもやっぱり難しいのですが... ”誰が見ても分かるコードを書く” ということに関しては、サイト構築の際だけじゃなく常日頃から気をつけていることになるのですが、やっぱり後々誰が触るかわからない以上自分だけがわかるコードじゃダメだと思っています。 そんな中で今回のサイト構築、自分1人で作っていくため誰が見てもわかるようなコードなのか判断が難しく、処理を書いては見返したり、クラス名や変数名がしっかりそのものを表しているか確認したり、モジュールは適切に分けられているか確認したり... とにかく一度自分が書いたコードを何度も確認することで、なんとか分かりやすいコードを目指しました。実際できているかは分かりませんがなんとか自分の癖は薄められたんじゃないかなと思います。笑 // 例 // モーダルウィンドウ表示部分の一部処理 // 変数の中身と処理の内容がわかりやすい（はず） const $movie_play = document.getElementsByClassName('js-movie_play'); const $modal = document.querySelector('.js-modal'); const $modal_movie = document.querySelector('.js-modal_movie'); const $modal_close = document.querySelector('.js-modal_close'); const $modal_back = document.querySelector('.js-modal_back'); for (let i = 0; i < $movie_play.length; i++) { $movie_play[i].addEventListener('click', () => { 　　　　const src = $movie_play[i].getAttribute('value'); 　　　　$modal_movie.setAttribute('src', src); 　　　　$modal.classList.add('is-active'); 　　　　$modal_back.classList.add('is-active'); }); 　・・・　 } 3.デザイナーとの連携 次にデザイナーさんとの連携です。 新卒採用サイトのリニューアルにあたり、同期のWebデザイナーがサイトデザインを担当していたのですが、コンセプトが「枠組みを壊せ」なだけあってダイナミックでおしゃれなデザインを作ってくれていて、それに合わせてアニメーションの提案やデザインの調整等の連携を積極的に行っていました。 分からないことや確認したいことも含めて些細なことをこまめに共有し合うことで、生産効率がかなり向上していたように思います！ 4.自分らしさを出す このままでは部内ルールに沿って、もらったデザインをコーディングしているだけなんですが、やっぱり自分らしさは少し出したい！といことで、企画から公開までの流れでちょくちょく自分なりに提案をさせてもらっていました。 結果的には、前述したアニメーションの提案やSEO対策、サイトの軽量化や運用に関わる部分で自分なりに考えた構築ができた気がします。 こうして自分らしさを少しずつ出しながら進めていくことで、終始楽しみつつモチベーション保って制作ができていたので、改めて大事なことだなぁとしみじみ感じました。 終わりに いかがでしたでしょうか。 分からないことだらけのサイト構築で、デザイナーや先輩方に助けていただきながらではありますが中々のものができたんじゃないかなーと思ったりしています。 実際にリニューアルしたサイトはこちらになります。 気になる方は是非見てみてください！ また、GMOインターネットグループ株式会社では、現在「次世代リーダー」を募集しております。 詳しくは上記サイトからご確認いただき、是非エントリーしてみてください！

こんにちは。GMOインターネットグループ株式会社新卒1年目の山名です。今回は、Webページにおける横並びの実装方法を調査、比較しましたのでご紹介します！ 執筆の背景 皆さんはWebページで要素を横並びにしたいなーって時、どんな方法で実装していますか？Webコーディングをする上で必須とも言える横並びレイアウトですが、その歴史は深くWebの技術やHTML,CSSがアップデートされる度にさまざまな実装方法が生まれてきました。私自身、複数ある実装方法の中でどれを使うか迷ってしまうという状況によく直面します…今回は、そんな「何を使えばいいんだろう」という悩みを解決するとともに、数年前まで横並びの最前線で使用されていたfloatが現在では使われなくなってしまった理由を明らかにしていこうと思います！ なぜfloatは駆逐されたのか 早速ですが、floatを使った横並びはなぜ駆逐されていったのか...その理由を考えてみます。 このブロックには、想定されていないか無効なコンテンツが含まれています。ブロックのリカバリーを試行 一言で言えば「flexが便利すぎて戻れない！！」floatで作るレイアウトの自由度が低かったり、実装に手間がかかるという理由もあるにはあると思いますが、何よりもflexレイアウトが便利すぎるんです。というのも、昨今の横並びレイアウトで主に使われているflexレイアウトは複雑な配置でも柔軟に対応できるというで、floatで出来ることのほとんどはflexに取って代わられてしまいました。また、機能面の改善だけでなく「 flex って書けば、初期値でだいたい望む配置にできてしまう」「クリエイターが言葉で表現しにくい細かい部分も勝手に調整してくれる」「何より実装が簡単で戻れない」といった、実装するコーダー本人の体験が改善されていったことも大きな理由です。他にもgridレイアウトを使った横並びでもできることが多く、結局floatを使わなくてももっと簡単に便利に実装できるようになってしまったことで、現在ではほとんど出番がなくなっています。 横並びレイアウトとは 横並びレイアウトとは、文字通りWebページの要素を横並びで配置することです。<span>タグや<a>タグのようなインライン要素と呼ばれるものを除き、Webページでは基本的に要素の後に自動的に改行が入るため縦方向に要素が連なっていきます。それらの要素を横並びに設定し直すことで、ページが長くなりすぎることを防ぎ、ページ全体の可読性を向上させる効果があります。実際には、グローバルナビゲーションやサイドバーとメインコンテンツの配置等に主に用いられている横並びレイアウトですが、その実装方法は複数存在しているため以降ではいくつかの実装方法とその特徴をそれぞれ説明していきます！ 横並びレイアウトを比較解説 今回は、「float」「flex」「grid」の3つの実装方法で以下のデザインを作成し、それぞれの特徴を比較していきます。※サンプルコードにCSSの共通部は記載していません。 「float」の特徴と実装方法 floatは、CSS3が普及するより以前に横並びを実装するために一般的に使用されていたCSSプロパティです。本来floatは文章の中に画像を差し込んだり、要素の周りに文章を回り込ませることが目的のプロパティですが、その要素が回り込むという性質を利用することで横並びレイアウトを実装しています。 メリット 「flex」「grid」を使った実装と比べ、古いブラウザまで対応できる→ float以外の新しい技術に関してもブラウザ対応が進んでいることもあり、横並びでfloatを使用するメリットはかなり少なくなっています。 デメリット 配置の自由度は高くない予期せぬ回り込み等でデザインが崩れることが多い 使用する際は、横並びにしたい対象に対して「float:left（またはright）」を指定することでその要素を横並びにすることができます。 .box{ float: left; } .clearfix::after { display: block; clear: both; content: ""; } <h1>「float」を使った横並びの実装</h1> <div class="clearfix"> <div class="box box1"></div> <div class="box box2"></div> <div class="box box3"></div> </div> <p>サンプルテキスト</p> floatを使って横並びにした場合、それ以降の要素に回り込みが設定され続けてしまうため、その都度回り込みを解除する記述が必要になります。上記のコードでは「clearfix」を使用した手法で解除しており、親要素の疑似クラスに解除用のスタイルを適用することで以降の要素を縦並びに戻しています。他にもclearプロパティを使った方法やoverflowを使った方法があり、それぞれ記述量が少ないため用途やデザインによって使い分けるのが良さそうです！ 「flex」の特徴と実装方法 flexは、CSS3から追加された縦横配置のレイアウトを簡単に実現できるプロパティです。 現在は極端に古いブラウザを除きほとんどのブラウザで対応している点と、レイアウトが柔軟でなんでも作れてしまうという特徴も相まって、flexレイアウトは横並びのスタンダードになっていると言っても過言ではありません。 メリット 要素の縦横並びの変更だけでなく表示の順番や要素間の幅、高さなどさまざまな値が柔軟に調整できる実装が比較的少ないコード量でできる デメリット 入れ子構造が複雑になりがち 基本的な実装方法は簡単で、配置を変えたい要素の親要素に「display:flex」を設定することで子要素にflexレイアウトが自動で適用されるようになります。 .boxflex{ display: flex; } <h1>「flex」を使った横並びの実装</h1> <div class="boxflex"> <div class="box1"></div> <div class="box2"></div> <div class="box3"></div> </div> <p>サンプルテキスト</p> 今回は使用していませんが、flexレイアウトには多くのプロパティが用意されており、使いこなすのは難しいですが様々な組み合わせによってより複雑なレイアウトや状況に応じたレスポンシブ対応の実現が可能になっています。特に、折り返しのスタイルを指定する flex-wrap やレスポンシブ対応等で配置の方向を変更したい時に使用する flex-direction は使用する場面も多く便利なプロパティなため、ぜひ覚えて使ってみてください！ 「grid」の特徴と実装方法 gridは、格子状のマス目のグリッドに要素を配置し、順番を変えたり結合することで様々なレイアウトが実現できるプロパティです。実際にgridレイアウトを使用する場合は、あらかじめ格子のレイアウト決めておき、そこに要素を割り当てていく方法が基本になります。 メリット 縦横の配置に対して比較的自由にレイアウトできる デメリット 要素の増減に対しては柔軟に対応しづらい古いブラウザだとまだ対応していないこともある→ 使用する際には事前に対応しているブラウザの確認が必要 実装方法はflexレイアウトと同様で、配置を変えたい要素の親要素に「display:grid」を指定することで子要素の配置を変更できるようになります。今回の場合は、幅100pxの四角形を横に3つ並べるため「grid-template-columns」でマス目の幅を100pxで3つ並ぶように設定しています。 .boxgrid{ display: grid; grid-template-columns: 100px 100px 100px; } <h1>「grid」を使った横並びの実装</h1> <div class="boxgrid"> <div class="box1"></div> <div class="box2"></div> <div class="box3"></div> </div> <p>サンプルテキスト</p> gridレイアウトは、そもそもfloatやflexで作るレイアウトとは配置を指定する方法も違っているため、最初は難しく感じることもありますが、覚えてしまえば二次元的に自由な配置ができるためとても頼もしい存在です！また、使用すると要素（グリッド）間の幅を細かく調整することができる gap というプロパティがあるのですが、これはflexレイアウトにはないプロパティのため、使えるのはgridレイアウトのみになります。 まとめ Webページにおいて横並びは一般的なレイアウト手法ではありますが、その実装方法はCSSの発展と共に変化しています。しかし、今は使われなくなっている技術も確実にCSSの一時代を支えていたと思うと、今からでも知識として持っておくことに損はないと思います。また、現在でもテキストの回り込みにはfloatを使うのが便利であり、これが本来の使い道だということを考えると、適材適所に戻ったとも言えるのではないでしょうか。 これを機に、横並びレイアウトの変化だけでなくCSSの全体の歴史にも興味を持っていこうと思います！