<h2 id="h8d027c8ed3">はじめに</h2>以前投稿した<a href="https://daily-report.wd-flat.com/article/web-quality" target="_blank" rel="noopener noreferrer">「Webサイト制作の制作フェーズにおけるクオリティ向上のための３つのポイント」</a>では、Webサイト制作において品質（クオリティ）を確保することは非常に重要であることをお伝えしました。 今回はFLATのチェック体制にフォーカスを当て、どのようにサイトの品質を保っているのかをお伝えしていきたいと思います。 <h2 id="hd3e16ef9d3">チェックフローについて</h2>まず、FLATで設けているチェックフローをご紹介します。 適切なチェックフローを設けることで、サイトの品質を保ちつつ、効率良く制作を進めることができます。 FLATでは、Webサイト制作の各段階において、以下のチェックフローを設けています。 1. 制作エンジニアによる自己チェック（制作者チェック） 制作エンジニアが自身の作業の見直しをし、デザイン仕様の誤りや漏れがないかを確認します。例えば、コードの構文エラーや、各ブラウザでのデザイン表示崩れなどの確認です。 2. 第三者によるデザイン再現・動作検証チェック（Wチェック） 客観的な視点でのチェックを行うため、別のエンジニアがチェックを実施します。特に第一のチェックで見逃されがちなユーザビリティの問題や動作チェックなどを詳細に確認し、「サイトが本番公開できる状態であるか」確認を行います。 3. 納品前の最終チェック（クオリティチェック） 納品前には全体のコンテンツと機能を最終確認します。このチェックでは、クライアントの要求事項（案件仕様）が全て満たされているかの確認や、ユーザー目線での最終的な動作検証を中心に行います。 4. 本番公開後チェック（公開後チェック） 納品されたコードが正しく反映されているか表示確認を行います。 <h2 id="h33acc128da">チェック項目について</h2>また、上記のチェックフローではそれぞれチェック項目を設けており、チェック項目は大きく分けて以下のとおりです。<ul><li>デザイン再現性チェック</li><li>レスポンシブ動作チェック</li><li>UI操作実行チェック</li><li>動的コンテンツによる表示崩れチェック</li><li>実機動作チェック</li><li>各ブラウザ検証チェック</li><li>テキスト・画像反映チェック</li><li>meta情報チェック</li></ul>この項目からさらに細分化していき、プロジェクトごとにも項目の内容は変わります。 このように細かくチェック項目を設けて属人化を防ぎ、エンジニア・ディレクター・プロジェクトマネージャーなど、チーム全員が一丸となって品質向上に努めることで、クライアントにとっても、市場にとっても価値あるサイトを提供していきます。 そして、クオリティの高いWebサイトを制作するためには、上述したチェックフローの徹底はもちろん、制作に関わる全員が案件に対する理解を深めることが必要となります。 <h2 id="hb3f9858bed">チェックの課題点</h2>しかしながら、現在チェック項目が40項目にも及ぶため、チェック作業に多くの時間を要することが課題となっています。 チェック項目が多すぎると、本来重要な項目が見逃される可能性もあるため、チェック項目の見直しや自動化ツールの導入を積極的に行っていく必要があります。 今後も技術の進化に合わせてチェックフローをアップデートし、効率的で効果的な制作フローを整えていくことが重要です。 <h2 id="h9be0c3393d">おわりに</h2>今回はFLATで行っているチェック体制の一部をご紹介しました。 今回ご紹介したチェックフローのほかにも、FLATではコードレビューやJavaScriptクオリティチェック、CMS構築チェックなどコード内部のチェックも行っています。 引き続き、全ての案件で一貫したクオリティを保つことができるよう、今後もチェック体制を整えていきますので、どうぞよろしくお願いいたします。

Webサイトのチェック体制について、一部をご紹介

最近はコーディング時にキーボード操作を考慮できるよう、普段からキーボードでWebサイトの操作を行うようにしている。 先日遭遇したサイトでは、ハンバーガーメニュー展開時、展開メニューの最後の項目まで到達したあとにTabキーを押すと、ハンバーガーメニューが自動で閉じられるメニューが設置されていた。 個人的に、このハンバーガーメニューはシンプルに「使いやすい」と感じた。 というのも、通常、必要のないハンバーガーメニューを「閉じる」ためには、「閉じる」ボタンまで戻るなど、何かしらの動作を行わなければいけない。 しかし、遭遇したサイトは閲覧を続ける流れでハンバーガーメニューが自然と閉じられる。 だが、JISアクセシビリティ達成基準を確認したところ、下記のような基準が設けられていた。<blockquote>フォーカスを受け取ったときにイベントを起動することのできるすべてのコンポーネントは、コンテキストを変化させてはならない。</blockquote>フォーカス時：達成基準 3.2.1 を理解する（<a href="https://waic.jp/translations/UNDERSTANDING-WCAG20/consistent-behavior-receive-focus.html%EF%BC%89" target="_blank" rel="noopener noreferrer">https://waic.jp/translations/UNDERSTANDING-WCAG20/consistent-behavior-receive-focus.html）</a> 確かに、展開メニューの最後の項目まで到達したあとにTabキーを押すとメニューが閉じられる仕様は、フォーカス時にコンテキストを変化させることになり、ユーザーの予測できない動きとなってしまう。 そのため、ある状況に置いては使用しづらさを感じる可能性があるかもしれない。 この時思うことが、「自動的に」変化を起こすものは「便利」だと捉えてしまいがちだが、「誰もが」「どの環境でも」使いやすいものを考えたときは「己の意思で操作できるかどうか」「意図した操作ができるかどうか」を念頭に置いて考える必要がある。 「Escキーで閉じる」に加え、展開メニュー時はフォーカスをメニュー内に閉じ込め、展開メニューの最後の項目まで到達後は「閉じる」ボタンにフォーカスさせるのが一番良さそう。

ハンバーガーメニューのキーボード操作について

<h2 id="h8d027c8ed3">はじめに</h2>私自身が出来ているのかわかりませんが、個人的に気をつけている議事録のポイントを共有します。 議事録とはそもそも「何のために」とる必要があるのでしょうか。自分のメモを共有するのではだめなのでしょうか。 <h2 id="ha53ecb0c17">議事録とメモの違い</h2>まず、議事録と会議のメモは異なります。 「メモ」は自分自身の忘備録として活用するものだと思います。 そのため、例えば走り書きでも単語の羅列でも「自分がそのメモを見て思い出せれば」メモをとる目的を果たせます。 ですが、議事録はそうではありません。 議事録をとる目的として多くを占めるものが「会議での決定事項を明確にし、関係者に共有すること」ではないしょうか（目的は他にもあります）。 そしてその「関係者」全員が、会議に参加しているとは限りません。 つまり、「自分だけのためにとればいい」メモとは異なり、「会議に参加していない人でも、その会議での決定事項が分かるように議事録を書く」必要があります。 このため、議事録がメモ書きになってしまっていては、議事録の目的を果たせないのです。 <h2 id="h6775ed16a1">３つのポイント</h2>……と尤もらしいことを書いてしまったのですが、具体的にどうすれば「会議に参加していない人でも、その会議での決定事項が分かるように議事録を書く」ことができるのか分からないですよね。 個人的に気をつけている大きなポイントとしては以下のとおりです。 <h3 id="h5c2e2a1036">①決定事項とその趣旨を簡潔に記載する</h3>決定事項だけでなく、その趣旨（なぜそうするのか）を記載することで、会議内容がより具体化されます。 ただ、決定事項までの流れをつらつらと書いてしまうと、議事録を読んでいる途中で「結局どうなったのか」が伝わりづらくなってしまいます。そのため、決定した事項と「なぜそれが必要なのか」を簡潔に書きます。 <h3 id="hcf032c9c47">②体言止めにせず、動詞まで記載する</h3>体言止めで記載してしまうと、具体的に何を行うのか（何が起こっているのか）が不明瞭になってしまいます。そのため、動詞を用いてより具体的に記述します。 例）「〜でコストの低下」→「コストが下がった」のか「コストが下がっている」のか「コストを下げる」なのかが分からない<h3 id="h2971335a80"> ③今後のアクションとして、「誰が」と「何を」をセットで記載する（必要あれば「いつまでに」）</h3>「誰が行うのか」という「そのアクションの責任が誰にあるのか」を明確にします。責任を明確にすることで、後々問題が発生したときにも役立ちます。 ひとまずこの３つを抑えておくといいんじゃないかなと思います。 <h2 id="h9be0c3393d">おわりに</h2>「議事録」っていうと難しい気もしちゃいますが、要は「誰が見ても会議内容が分かる記録」なんですよね。 議事録を取ることで会議の理解度を深められたり、「相手に伝わりやすい文章」と「要約する力」を身につけられると思うので、私も引き続きがんばります。

議事録をとる上で心がけているポイント

コンテナや画像サイズの小数点には気をつけなくちゃいけない……というお話です。 <h2 id="h9e5f467c67">問題点</h2>あるカードパーツの実装をしていたところ、自宅用モニターでブラウザ幅を広げて閲覧した際、カード画像とカード枠の間に1px程度の隙間ができてしまっていました。 <img src="https://images.microcms-assets.io/assets/98f41c713ae240acbf11bfbf0993ea22/1c4557f1b62247528b27242eb3e9f0fa/subpixel_rendering.png" alt=""> しかし、社内用の別モニターではどれだけブラウザを広げても隙間が確認できなかったため、なぜこういった現象が起きてしまうのか途方に暮れていました。 <h2 id="h9c1f22bd6d">原因</h2>この現象ですが、サブピクセルのレンダリングが原因のようです。 1px以下の処理方法がディスプレイごとに異なるため、使用しているディスプレイによって見え方が異なってしまうのです。 もしやと思い該当するコンテナーサイズを確認したところ、見事に小数点が生まれていました。 この1px以下の数値（すわなち小数点）が生まれることによって、ディスプレイごとに見え方が異なっていたのですね。 ちなみに、該当スタイルの指定方法は<pre><code>grid-template-columns: repeat(3,1fr);</code></pre>のように、コンテンツは可変になるよう指定していました。 レスポンシブが主流の場合、どうしてもコンテナーサイズを可変させたい場合が多いと思いますが、可変にしてしまうと予期せぬところで小数点が生まれて、予期せぬ隙間が発生してしまう可能性があります。 <h2 id="h141087ae17">解決法</h2>今回は固定値で指定しても支障のない箇所だったため、余白が現れないことを優先し、小数点のない固定値を指定することで解消しました。 ただ、固定値指定が相応しくない箇所もあるかと思います。 Webサイトはコンテンツがどうしても流動的なものになってしまうので、多少のレンダリングによる差異は許容しつつも、要所要所で注意する必要があります。

サブピクセルのレンダリングの注意点

FLATでは、一人当たり複数の案件を抱え、社内ではコードレビューや実装に関する相談など、チャットによるテキストコミュニケーションが頻繁に行われます。 そこで、日々の作業のスイッチコストを最小限にし、エンジニアとして開発業務に集中するため、あえて即レスを避けるようにしています。 とはいえ相手に、レスが遅くて待たされているという印象を与えてはいけないので、即レスはしないけどレスが遅い人という印象を与えないための工夫を二つ紹介します。 <h2 id="h2a4289ff0d">一次返信はする</h2>即レスはしないと言いましたが、一次返信をしておくことはあります。 チャットの通知はONにしてあり、チャットが届くと画面に表示されますが、そこですぐに回答に時間がかかるとわかるものには一次返信をしておきます。 チャットを送った相手からすると、チャットを送ってから数時間経ってようやく「〇〇までに確認して返答します」という回答がくるのでは、待たされていると感じてしまうでしょう。 <h2 id="hd2bb6d06ab">返信漏れは発生させない</h2>即レスをしないことでチャットを一括で返信することになりますが、チャットをまとめて返そうとすると必然と返信漏れが発生しやすくなります。返信が遅いのに加えて返信漏れが発生していたら、相手に与える印象は最悪です。 チャットツールにはたいてい「ブックマーク」という機能があるので、既読をつけてしまったメッセージはすぐにブックマークに追加します。 少しだからと頭で覚えていようとすると、いずれ確実に返信漏れが発生しますし、そもそもそこに頭のリソースを使うのはもったいないです。 このような点に配慮することで、大量のメッセージに振り回されることなく自分のページを保って仕事をすることができます。

即レスはできないけどレスが遅い人という印象を与えないためには

テクノロジーに関する記事です。

テクノロジー

マネジメント

業務改善

仕事の気づき

更新情報

フロントエンジニアの山村です。 コーディングの中では「HTMLタグで囲みたい」ことや「ダブルクォーテーションからシングルクォーテーションにしたい」など、囲み文字を操作したくなる場面は多いです。 この記事では、囲み文字の編集に便利なVimのプラグインである<a style="background-color:#ffffff" href="https://github.com/tpope/vim-surround" target="_blank" rel="noopener noreferrer">Surround.vim</a>を紹介します。 <h3 id="h4277ca4f21">Surround.vimについて</h3>このプラグインをインストールすると、<code>cs</code> (囲み文字の変更) や <code>ds</code> (囲み文字の削除) といったオペレータが有効になります。 通常、囲み文字を修正するにはカーソルの移動が伴いますが、これらのコマンドを使うことでオブジェクトに対してビシッと囲み文字を指定できます！ <h3 id="hdc92f8effb">便利な使い方</h3>JSONファイルをつくるときに、プロパティ名と値をダブルクォーテーションで囲みたいとします。<code>ysiw"</code> でワードをダブルクォーテーションで囲めるため、ドットリピートと組み合わせて効率的な編集ができます。 ※ リピート可能にするには<a style="background-color:#ffffff" href="https://github.com/tpope/vim-repeat" target="_blank" rel="noopener noreferrer">repea.vim</a>プラグインをインストールする必要があります。 <img src="https://images.microcms-assets.io/assets/98f41c713ae240acbf11bfbf0993ea22/a2fd6835105b42f5b680b2b6e2f6cb24/surroundvim_1.gif" alt=""> 続いて、URLをMarkdownのリンクに編集する方法です。<code>ysiW]</code> でテキストを丸括弧で囲めるため、無駄な移動なくURLをリンクに変更することができます。 <img src="https://images.microcms-assets.io/assets/98f41c713ae240acbf11bfbf0993ea22/086924d227334f6aafd3e1a57a7b78b4/surroundvim_2.gif" alt=""> まだ、使いこなせていませんがコーディングの効率が上がるのでおすすめです 👍

Surround.vimでテキスト編集を効率化する

Webディレクターの西條です。 ここ数年CMS（コンテンツ管理システム）の選択肢が本当に増えてきたなと感じます。 以前は「WordPressがあれば大丈夫」という時代と感じていましたが、今では様々な選択肢が顔を出しています。 例えば、長い歴史を持つ「Movable Type」や、 近年注目されているヘッドレスCMSの「microCMS」や「Newt」 さらには、WordPressを静的に配信する「Shifter」といったサービスも登場しています。 当然、それぞれのCMSには独自の特徴や利点があります。 例として、Movable Typeは安定性とセキュリティに優れていて、大規模サイトに向いている一方で、WordPressはその柔軟性と豊富なプラグインで多くのユーザーに支持されています。 ヘッドレスCMSの「microCMS」や「Newt」は、コンテンツを柔軟に管理し、多様なプラットフォームへ自由に配信できる大きな利点があります。最新のJamstackアーキテクチャを採用することで、セキュリティとパフォーマンスが大幅に向上し、同時に保守コストの削減も実現しています。 Shifterは使い慣れたWordPress管理画面での操作感を維持しつつ、Jamstackアーキテクチャの採用によりセキュリティとパフォーマンスを向上させています。 <h2 id="ha214098e44">まとめ</h2>FLATでは、クライアント様のニーズに最適なCMSをご提案するため、日々さまざまなCMSについて学んでいます。各CMSのメリットやデメリットはもちろん、設置サーバーやセキュリティ要件などの技術的な側面についても知見を深めています。 単にCMSを導入するだけでなく、クライアント様のウェブ戦略全体を成功に導くことが目的なので、CMSの知識を活かしながら、クライアント様のビジネスゴールに沿ったアドバイスや提案を心がけています。 これからも、クライアント様により良いサービスを提供できるよう、CMSに関する知識と経験を積み重ねていきたいと考えています。

最適なCMS選定 - 多様化する選択肢の中で

今までGitHubアカウントは仕事用と個人用に分けていたのですが、統合することにしました。 それに伴い、コントリビューション(通称「草」)の移管について調べましたので共有します。 新しいアカウントに過去のコミットを属させるには、コミットの作成に使用したメール アドレスを、保持しているアカウントに追加すれば良いそうです。 アドレスは移管したものの、コントリビューションが反映されなかったので調べてみました。 コントリビューションが反映されるには以下の条件のうち少なくとも一つが必要とのことです。 * リポジトリのコラボレーターであるか、またはリポジトリを所有する Organization のメンバーであること。 * リポジトリをフォークしたこと。 * リポジトリでプルリクエストまたは Issue を開いていること。 * リポジトリに Star を付けたこと。 お客様先のGitHubリポジトリに招待されるスタイルですと、そのうちOrganizationから解除される可能性があります。 そのため、頑張って草を生やしてもOrganizationから解除されたタイミングで消えてしまう可能性があります。 なので、草を維持したい方は、一旦コミットしたリポジトリにスターをつけておくといいかもしれません。 参考文献 <a href="https://docs.github.com/ja/account-and-profile/setting-up-and-managing-your-personal-account-on-github/managing-your-personal-account/merging-multiple-personal-accounts" target="_blank" rel="noopener noreferrer">複数の個人アカウントのマージ</a> <a href="https://docs.github.com/ja/account-and-profile/setting-up-and-managing-your-github-profile/managing-contribution-settings-on-your-profile/why-are-my-contributions-not-showing-up-on-my-profile" target="_blank" rel="noopener noreferrer">コントリビューションがプロフィールに表示されないのはなぜですか？</a>

関わったGitHubのリポジトリにはスターをつけたほうがいいかもという話

<code>git add -p</code>コマンドが便利なので共有します。 <code>git add</code>に<code>-p</code>のオプションをつけることで、このように対話形式でどんな変更が行われたか表示され、変更箇所ごとに「変更をステージングするか」を設定できます。 実装時に一時的にコメントアウト箇所した箇所を見つけられたりなど便利なので、ターミナル派の方は是非使ってみてください。

git addの-pオプションが便利

日報ブログ（本サイト）で人気記事一覧を実装する際に「GA4から取得したデータをmicroCMSへPATCHする」という処理をGitHub Actionsで定期実行する必要があり一部Node.jsを使用していました。 Node.jsのプロジェクトでTypeScriptで開発をするには<ul><li>TypeScript ファイル (*.ts) を&nbsp;<code>tsc</code>&nbsp;で *.js にコンパイルする</li><li>&nbsp;出来上がった js ファイルを&nbsp;<code>node</code>&nbsp;で実行する</li></ul>↑「2ステップ」の作業が必要です。 ただ<code>ts-node</code>を使用することで「1ステップ」でTypeScriptのコードを実行できます。（便利…） 具体的には以下の1つのコマンドでコンパイル→実行をしてくれます。<pre><code>$ ts-node index.ts</code></pre> 今後もこういったケースはJamstack案件ではよくありそうなので覚えておきたいです。<h2 id="hcf83e1357e"> </h2>参考記事 <a href="https://ics.media/entry/4682/" target="_blank" rel="noopener noreferrer">TypeScriptで始めるNode.js入門</a> <a href="https://www.wakuwakubank.com/posts/726-typescript-ts-node/" target="_blank" rel="noopener noreferrer">ts-nodeでTypeScriptのコードを直接実行 &amp; デバッグ</a>

カテゴリー

人気記事

Webサイトのチェック体制について、一部をご紹介

ハンバーガーメニューのキーボード操作について

議事録をとる上で心がけているポイント

サブピクセルのレンダリングの注意点

即レスはできないけどレスが遅い人という印象を与えないためには

テクノロジー

Surround.vimでテキスト編集を効率化する

最適なCMS選定 - 多様化する選択肢の中で

関わったGitHubのリポジトリにはスターをつけたほうがいいかもという話

git addの-pオプションが便利

Node.jsで手軽にTypeScriptを使用する

Webサイトのチェック体制について、一部をご紹介

ハンバーガーメニューのキーボード操作について

議事録をとる上で心がけているポイント

サブピクセルのレンダリングの注意点

即レスはできないけどレスが遅い人という印象を与えないためには