<p>FLATに入社して初めて「相互レビュー」を導入した際に感じたメリットやより効果を上げるために実践してみたことを書いてみます。<br></p><h2 id="hdda799b038">導入（相互レビューで享受できるメリット）</h2><p>弊社では開発者同士で相互にレビューを行っています。これはスキルセットに関わらず、もれなく案件に携わるエンジニア全員が対象(レビュアーとしてもレビュイーとしても)です！<br>最終的なクオリティチェックの前に開発者同士でレビューし合うことによって、以下のようなメリットが考えられます。</p><ol><li>次工程へ進むコードの質が高められる</li><li>他の人の書いたコードを読むことで、新しい知見を得られる</li><li>最終チェックを行う人の負担を減らせる</li></ol><p><br></p><h3 id="h7218860a29">1.次工程へ進むコードの質が高められる</h3><p>以下のような内容は開発者同士でも確認することができます。<br></p><ul><li>仕様に対するロジックがおかしくないか</li><li>冗長な書き方をしていないか</li><li>わかりずらい命名をしていないか</li><li>(リファクタリングしているのであれば)修正前後でロジックに変化がないか</li><li>変数やメソッドなど、共通化できる部分はないか</li><li>シンタックスエラー、コンソールエラーはないか</li></ul><p><br></p><h3 id="h6fa6ae3a55">2.他の人の書いたコードを読むことで得られるものがある</h3><p>また、これはスキルセットが似通った開発者であっても、そうでなくてもメリットがあります。<br></p><h4 id="hb351c9984c">スキルセットが同じ場合</h4><ul><li>自分では書かないようなコーディング方法、ロジック、命名などがたくさん見れる</li><li>「こう書いたらもっと良いのでは」などのような議論がソースコードを使ってできる</li></ul><p><br></p><h4 id="h11f853a161">スキルセットが異なる場合</h4><ul><li>自分では書けないコードを読む機会がもらえる (新しい発想・共通化の仕方・知らなかったライブラリ等)</li><li>先輩が後輩にソースコードを見てアドバイスする経験を得られる</li></ul><p><br><span style="color:#000000">また、レビューする視点だと間違ったことは言えないのでしっかり調べたり、</span><br><span style="color:#000000">人にFBすることで自戒することにもなるのでかなり勉強になります。</span><br></p><h3 id="h5c25173b95">3.最終チェックを行う人の負担を減らせる</h3><p>単純に開発者同士でレビューを挟むことでクオリティが上がるので、最終チェック時の戻りが減ります。<br>また、過去に指摘された内容を開発者同士で共有することで、同じ指摘を防ぐことなどもできます。<br></p><h2 id="h6418494177"><br>相互レビューの効果をより上げるために実践していること</h2><p><br></p><h3 id="h5c073b1878">1. レビューで指摘された（した）内容を全てTipsとして共有する</h3><p>毎案件終わる度にNotionにTipsとしてナレッジを蓄積しています。<br>内容としては以下のようなものです。</p><ul><li>レビュワー視点で学んだとこ</li><li>レビュイー視点で学んだとこ</li><li>お互いの指摘事項</li><li>お互いが見落としてしまったこと</li><li>ソースコードで議論したこと</li></ul><p><br><img src="https://images.microcms-assets.io/assets/98f41c713ae240acbf11bfbf0993ea22/eafd2e9e3f0f4e56959d7c5855f82d36/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%88%202023-06-20%2014.03.55.png" alt=""><br>誰でも見れる場所にナレッジとして蓄積することで同じ悩みを解決したり、同じ指摘を受ける確率を減らせればと思っています。<br></p><h3 id="h02c9839586">2. 良いコードを褒める</h3><p>人は誰しも褒められるとやる気が上がる（？）と思います。（少なくとも自分は）<br>ですので、良いコードを見つけたときは「この書き方めちゃめちゃ良いですね！次から真似します」といった具合にコメントをするように心がけています。<br>お互いに指摘し合うだけではなく、議論したり、良い部分は褒め合ったりしながら開発していくことで仕事が楽しくなります。<br></p><h2 id="ha214098e44">まとめ</h2><p>相互レビューはさまざまなメリットがありますが、開発者同士の協力が必要なため互いのスケジュールが合わない場合もあります。<br>そのため作業がスタックしないようにタスクや進捗の管理には気をつけていきたいです。<br></p>

エンジニアの相互レビューで感じたメリット

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

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

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

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

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

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

<p><span style="color:#393a41">FLATで新たに</span>隔週雑談会<span style="color:#393a41">という試みを始めました。</span><br><span style="color:#393a41">テーマを決め、それに興味のあるメンバーが有志で集まり、お互いの気になることについて意見交換をしたり、不明点を解消する場になっています。</span><br><span style="color:#393a41">業務時間外に行なっているので、オフィスでお酒を飲みながらゆるく開催しています。</span><br>エンジニア同士でゆるーく技術の話するのって楽しいですよね😋<br></p><h3 id="h00fc534bc6">直近で開催したテーマ</h3><ul><li>キャッシュ（アプリケーションキャッシュ、サーバーキャッシュ、Redis）</li><li>Tailwind</li><li>設計図（ユースケース図、アクティビティ図、シーケンス図、ER図、インフラ図）</li><li>フロントエンドディレクトリ構成</li><li>WordPress + PHP Unit</li><li>FEのデザインパターン</li><li>microCMS</li><li>認証</li></ul><p><br></p><h3 id="h71486a4e59">これから開催予定のテーマ</h3><ul><li>プリフライト</li><li>FEでよく使うライブラリ</li><li>AWS</li><li>Svelte</li><li>VRT</li><li>Cloudflare</li><li>フルスタックTypeScriptアプリケーションを案件でやる上でインフラ含めた現実的な構成を考えてみる</li><li>見積もりの作り方</li></ul><p><br><br>雑談していると自分の知らない知識や考え方に出会うことができたり、人に与えることができるので、今後も継続していきたいです。<br>実践レベルの話や、実際に使ってみた結果の共有のような話をすると、大体話の内容（レベル）に合ったツッコミを入れてもらえるのも楽しいポイントですね。<br><br><span style="color:#393a41">FLATはフロントエンドの会社ですが、メンバーの興味領域は様々です。</span><br><span style="color:#393a41">エンジニアを積極採用中なので、技術共有に前のめりな方のご応募をお待ちしております。</span><br></p>

隔週で雑談勉強会はじめました

マネジメント

業務改善

仕事の気づき

テクノロジー

更新情報

浅井

<p>FLATでは、案件終了後に「成果報告会」という振り返りの場を設けています。<br>この成果報告会には案件にアサインされたメンバーだけでなく、FLAT全体が参加することで、さまざまな視点からのフィードバックが得られます。<br><br>私がFLATに入社してから何度も成果報告会を経験していますが、どれも内容は濃く、スムーズに進行できた案件であってもどこかには課題が潜んでおり、それによって議論が白熱することも多々あります。<br><br>そんなFLATの成果報告会ですが、主に以下の項目を中心に振り返りを行っています。<br></p><ul><li>案件全体の振り返り</li></ul><p>プロジェクトの概要を共有し、プロジェクト進行中に発生したクライアントやFLATにとって利益となった点や、達成できなかった目標について話し合います。</p><ul><li>チームや個人の課題・改善点</li></ul><p>チームやメンバーが直面した課題を振り返り、改善点を見つけます。<br>これにより、個々のメンバーだけでなく、チーム全体が成長し、次の案件</p><ul><li>作業工数の振り返り</li></ul><p>案件にどれだけの時間がかかったのか、見積もり工数との乖離がないかどうか、もし乖離があった場合はなぜ乖離があったのかなどの振り返りを行います。<br>これにより次回以降のプロジェクトで工数見積の精度を高めることができます。</p><ul><li>今後のアクション</li></ul><p>成果報告会で得たフィードバックを元に、課題や改善点に対する今後のアクションを決めていきます。<br>具体的な改善策を立て、実行に移すことで、次の案件に活かせるような継続的な改善を行っていきます。</p>

成長し続けるための「成果報告会」について

<p>受託でWebサイトを制作する際、クライアントからフィードバックを得ることは、よりクオリティの高い成果物を生み出すために必要不可欠です。<br>このフィードバックを通じて、クライアントの要望より深く理解し、より良いWebサイトを制作することができます。<br><br>まず、FLATのWebサイト制作フローでは、案件初期からクライアントとの密なコミュニケーションを心掛けています。<br>制作スケジュールは通常、2〜3回に分けてページを制作し、各段階でクライアントに提出します。<br>これにより、早い段階での軌道修正が可能となり、最終的な納品物のクオリティを高めることができます。<br><br>クライアントからのフィードバックは、プロジェクトの進行中に複数回にわたって共有されます。<br>初回のWebページ提出では確認すべき部分が多いため、クライアントからのフィードバックも自然と多くなりがちです。<br>これらのフィードバックには、Webサイトの見せ方の調整、ブレイクポイントやホバーアニメーションの調整、UIの改善など、様々な内容が含まれます。<br>特に、Webサイトとしてブラウザに反映された際の見た目や動きに関するフィードバックは重要です。<br>クライアントがどのような視点でサイトを見ているのか、どのような形での制作を希望しているのかを把握することで、具体的なイメージが作り出されます。<br>これにより、事前のキックオフミーティングでのクライアントの要望を超えた、より詳細で具体的な要求を反映することが可能となります。<br><br>このフィードバックの期間は、次の制作フェーズへの準備期間でもあり、多くの有用な情報が得られるので、この期間が非常に楽しみでもあります。<br>また、早めにフィードバックを確認し対応することで、制作の手戻りを減らすことができ、案件全体の効率も向上します。<br><br>結論として、Webサイト制作においてクライアントからのフィードバックを得ることは、ただの一過性の確認作業ではなく、案件の成功を左右する重要な過程です。<br>このフィードバックを通じて、クライアントとの良好な関係を築き、よりクオリティの高い成果を出すための貴重な機会であると考えています。<br>そのため、クライアントからのフィードバックは積極的に求め、真摯に受け止めることが大切です。</p>

Webサイト制作における「クライアントからのフィードバック」の重要性について

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

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

<p>技術がどんどん複雑化している中で、より良いアウトプットを生み出すためには、アウトプット以外のストレスを極力なくす必要があります。<br>FLATでは、スタッフのストレスを極力なくしてより柔軟な働き方ができるよう、従来より週3出社と週2リモートのハイブリッドワークを採用しています。<br>今回は、FLATの内部コミュニケーションに焦点を当て、リモート時の働き方やコミュニケーションについてご紹介します。<br></p><h2 id="hec51ffd425">FLATのハイブリッドワークのメリット</h2><p>FLATでは、ハイブリッドワークによって出社とリモートワークのメリットを最大限に活かしています。<br>出社することでチームメンバーとの直接的なコミュニケーションや情報共有が行える一方で、リモートワークでは自宅や好きな場所で集中して作業することができます。これにより、柔軟性のある働き方やストレスの少ない環境を実現しています。<br></p><h2 id="h242db292b5">リモートワーク時の課題とその解決策</h2><p>ですが、通常のリモートワークでは勤務状況の把握やコミュニケーションが難しいという課題があります。<br>そこでFLATでは、バーチャルオフィスというツール（oVice）を導入しています。このツールを活用することで、リモート時におけるスタッフ同士のオンラインコミュニケーションを活性化させることができます。<br></p><h2 id="h264e606a70">バーチャルオフィスの活用方法</h2><p>oViceでは、スタッフ同士が質問や相談、雑談などを自由に行うことができます。<br>また、FLATでは「もくもくデスク」というスペースを用意しており、作業に集中したい時やミーティング中など、話しかけ不可の時のためのスペースが用意されています。<br>このスペースにいるときは外から話しかけることができないため、スタッフが今どのような状況であるかがオンラインでも分かるようになっています。<br>これにより、スタッフの自由を尊重しつつ、出社時と同様のコミュニケーションがリモート時にも可能となっています。<br><img src="https://images.microcms-assets.io/assets/98f41c713ae240acbf11bfbf0993ea22/05cfce37198e4c56b6bad3adacb4a953/ovice%E3%81%AE%E6%A7%98%E5%AD%90.jpeg" alt="">（FLAT oViceの様子）<br></p><h2 id="h5e79b1bd1c">バーチャルオフィスの効果</h2><p>同じ案件を進行している場合でも、oViceを活用することで他のメンバーへの質問や相談がスムーズに行えます。<br>これにより、解決までのスピードが速くなり、業務効率が向上しています。<br>また、リモートワークでのコミュニケーション不足や情報共有の課題も解消され、チーム全体の連携が強化されています。<br><br>このようにFLATでは、ハイブリッドワークとバーチャルオフィスの導入によって、リモート時のコミュニケーションを活性化させ、効率的でストレスの少ない働き方を実現しています。</p>

リモート時のコミュニケーションについて

<p>Webサイト制作において、クオリティの高い成果物を生み出すためには、エンジニアとしての技術だけでなく、制作フェーズでの適切なアプローチが不可欠です。<br>今回は、フロントエンドエンジニアとしての視点から、Webサイト制作の制作フェーズにおけるクオリティ向上のためのポイントを3つ紹介します。</p><h2 id="h61f44fed44">1. 事前準備と確認の重要性</h2><p>Webサイト制作の際、事前準備と確認が成果物のクオリティを左右します。<br>制作を進める前に、必要な情報や素材が揃っているか、依頼事項や制作範囲が明確化されているかを確認しましょう。<br>また、進行途中でも定期的な確認を怠らず、クライアントからの情報や要求事項を見逃さないよう心がけましょう。<br>事前の準備と確認が不十分だと、手戻りやクライアントとの信頼関係に悪影響を及ぼす可能性があります。</p><h2 id="h381086a96c">2. 適切なタスクの着手順序を考慮する</h2><p>タスクの着手順序を適切に選択することも、制作フェーズでは重要です。<br>例えば<br>「軽微なタスク」<br>「未経験のタスク」<br>「重めのタスク」<br>があったとします。どのタスクから取り組むのが良いでしょうか。<br>この場合、軽微なタスクから順に取り組むのではなく、未経験や重めのタスクから優先して対処したほうがよいです。<br>軽微なタスクは比較的容易に処理でたり、完了までの予測が立てられるものがほとんどだと思います。<br>対して、未経験や重めのタスクは完了までの予測が立てづらかったり、遂行できる人が限られてしまう場合があります。<br>制作フェーズの後の方に未経験のタスクや重いタスクを残してしまうと、その結果、期間内に完了できなかったり、他の人にヘルプを頼まないといけなくなってしまう可能性があります。<br>このため、最初に未経験や重めのタスク内容を把握し適切に処理することで、プロジェクトの品質を向上させることができます。</p><h2 id="hb02ea8b7f9">3. 適切な報告とコミュニケーション</h2><p>また、制作の進捗状況や重要な情報について、適切なタイミングでクライアントとのコミュニケーションを図ることが重要です。<br>完了したタスクの報告だけでなく、進捗状況や課題について定期的に共有しましょう。<br>クライアントとの円滑なコミュニケーションを通じて、クオリティの高い成果物を共に作り上げることが可能です。</p><h2 id="hcbec2bf0d9">終わりに</h2><p>このようにWebサイト制作において、技術力だけでなく、適切なプロジェクト管理やコミュニケーションによって成果物のクオリティを高めることができます。<br>これらを意識することによって、制作フェーズの進行のしやすさは変わってくるかと思うので、ぜひ意識して取り組んでいきましょう。</p>

Webサイト制作の制作フェーズにおけるクオリティ向上のための３つのポイント

<p>Web制作は、案件開始時点からアサインされているものもあれば、案件の進行途中からアサインされたりスポットで制作を行うものもあります。<br>ここで重要なのが、案件への理解度です。<br></p><h2 id="ha42527eb78">Webサイト制作において大切なこと</h2><p>まず、Webサイト制作において大切なことは、制作段階でいかにWebサイトのクオリティ（品質）を上げられるか、だと考えていますが、<br>クオリティを上げるためには制作速度を上げる必要があり、この制作速度を上げるためには「案件への理解度」を高めることが必要となってきます。<br>なぜ案件への理解度が必要なのかというと、理解度が高ければそれだけ物事の判断速度が上がるからです。<br>つまり、案件の理解度が制作速度を左右するといっても過言ではありません。（もちろん、クオリティ向上のために必要な要素は他にもいくつかあります）<br><br>例えば、修正課題の１つを行うのでも</p><ul><li>どのような流れで修正が入っているのか（なぜこの修正が必要なのか、本当に必要なのか）</li><li>案件の状況からすると修正タスクの優先度はどれくらいか</li><li>環境開発やディレクトリ構成、どこに何が格納されているのか</li><li>指摘された箇所以外にも、同様の修正が必要な箇所はないか</li><li>この修正を行うことで別の修正が発生する可能性はないかどうか</li><li>代替案を提案することでよりよくなることはないか</li></ul><p>など、案件を理解していることですぐに判断できることがたくさんあります。<br>もし案件の理解度が低いとそれだけ判断が遅くなったり、必要な修正がされずに手戻りが多くなったりしてしまい進行に支障を来してしまいます。<br></p><h2 id="h44e5f4ecee">Webサイト制作におけるクオリティとは</h2><p>また、案件への理解度は制作速度だけでなく、サイトのクオリティに直接関わってきます。<br>Webサイト制作におけるクオリティとは、デザイン再現やUI向上はもちろんのこと<br>クライアントの要望が何かを理解し、それに向けてWebサイトの価値を高めることにあると考えています。<br>そのため、案件への理解が低いと、ただ降りてきたタスクを進行するだけとなってしまいます。<br>そうではなく、クライアント要望を把握したうえで制作進行し、「なぜWebサイトが必要なのか」を理解することで制作段階での制作の幅が広がり、<br>Webサイトの価値を高めることができます。<br></p><h2 id="h3bcda3e6b0">最後に</h2><p>このように、案件への理解度というのは、制作するWebサイトのクオリティに影響してきます。<br>そのため、たとえスポット対応でもまずは案件概要を理解するところから始めると、結果的に制作速度があがりクオリティ向上に繋げられるかと思います。</p>

案件の理解度を高める必要性

<p>フロントエンドの仕事をしていて好きな瞬間はいくつかあるのですが、</p><ul><li>新規制作予定のデザインを見る瞬間</li><li>コーディングによって静的デザインが動きだす瞬間</li></ul><p>は特に好きな瞬間です。<br><br>まだ世に出ていないデザインを見られることはとてもわくわくしますし、デザイナーやディレクターの方がどのような意図でデザインしたのかを考えたり、どの要素をどう動かしたらよりよいサイトになるのか、デザインに息を吹き込めるのかを考えたりする、そういった時間がとても好きです。<br><br>フロントエンドの仕事は「デザインに関われる仕事」です。だからこそ私はフロントエンドの仕事が好きです。<br>サイトのインタラクションはデザイナーの方から指示をいただくこともあるのですが、エンジニアにお任せの場合も多いです。<br>そうしたとき、サイトの雰囲気がどのようになるのかはエンジニア次第でもあります。<br>0.1秒の変化の違いで、アニメーションの動き、雰囲気は大きく変わってしまうからです。<br>サイトのイメージはどのようなイメージなのか、何を目立たせたいか、デザインとの統一感を考えながらインタラクションの実装を行なっていきます。<br><br>このように「デザインに興味があること」はフロントエンドの仕事をするうえで大きな強みだと思うので、<br>引き続きデザインに興味を持ち続けて、サイト制作に関われたら良いです。</p>

フロントエンドはデザインに関われる仕事、ということ

<h2 id="h8d027c8ed3">はじめに</h2><p>マークアップにおいて、a要素やbutton要素における「クリック可能な範囲」は気をつけいたいポイントの１つです。<br>なぜなら、「クリック可能な範囲」は「サイトの使いやすさ」に直結するからです。<br>この「クリック可能な範囲」は私にとって悩むポイントの１つだったりします。<br></p><h2 id="h62147a41f3">適切は範囲を探る</h2><p>例えば、下記のようなデザイン。この時のリンク範囲はどこが適切でしょうか。<br><img src="https://images.microcms-assets.io/assets/98f41c713ae240acbf11bfbf0993ea22/6ed916cf27f345c99b89a202d39ddb4f/blog01.png" alt=""><br>私自身、クリックできる範囲はなるべく広くとったほうが、ユーザーにとってクリックしやすいのではないかと考えているため、普段の実装ではa要素の範囲をなるべく広めに設けるようにしています。<br>そのため、下記の赤枠のように、導線用のテキストだけでなく、リンク先の説明部分までの広範囲でa要素を指定することも考えられます。<br><img src="https://images.microcms-assets.io/assets/98f41c713ae240acbf11bfbf0993ea22/8f2321a0bc0b4c2b9ef9ca8feb4034ef/blog02.png" alt=""><br>ですが、このようなデザインの場合、リンク可能な範囲を広めにとってしまうと、反対に「リンクの範囲が曖昧になってしまう」ように思います。<br>曖昧になってしまうと何が起こるかというと、曖昧になってしまうことで誤操作が増え、意図しない挙動を起こしてしまい<u>、ユーザーにとってはストレスとなってしまう可能性</u>があります。<br><br>そのため、私なら下記のようにa要素を指定します。<br><img src="https://images.microcms-assets.io/assets/98f41c713ae240acbf11bfbf0993ea22/a5c6c460c10d4ce1bd19a6a9715e88b5/blog03.png" alt=""><br></p><h2 id="hcbec2bf0d9">終わりに</h2><p>このように、全体にa要素を指定しまうことで、意図しないところでクリックしてしまう可能性も考え、最近はあえてリンクの説明には不要なテキストや、過度なpaddingを取りすぎないように指定しています。<br>特にスマホだと誤操作が増えてしまうため、気をつけたいところです。</p>

適した「リンクの範囲」について

<p>パンくずが複数行になった場合の処理について、サイトに合った処理方法を提案できたら良いです。<br><br>パンくずは現在地表示なので、複雑なデザインパターンがいくつもあるというわけではありません。<br>ただ、SP表示やタイトル表示が長くなった場合に、コンテンツ枠からはみ出したものを「どう処理するのか」を考える必要があります。<br>ブラウザ幅からはみ出したものを</p><ul><li>スクロールで表示させるのか</li><li>はみ出した部分を省略させるのか</li><li>複数行にするのか</li></ul><p>など、処理方法はいくつか考えられます。<br><br>たとえば、サイト内の構造が複雑なECサイトであれば、<br>・階層が深くなること<br>・ECサイトという性質上、商品名がフルで表示されたほうが、ページを認識しやすくなること<br>などから、テキスト省略はさせずに横スクロール対応で実装したほうが、ユーザーにとってもわかりやすいと思います。<br>反面、階層が深くなく、長いテキストが表示される可能性が少ない場合は省略してしまったほうがすっきりと見やすくなるかもしれません。<br><br>このように、パンくずに限らず「なぜそうしたのか」を常に説明できる状態にする、ということはとても大切なことだと思います。<br>もしかしたらもっと良い考え方があるのかもしれませんが、このような些細なパターンも提案し、少しでもよいサイトに近づけたら嬉しです</p>

カテゴリー

人気記事

エンジニアの相互レビューで感じたメリット

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

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

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

隔週で雑談勉強会はじめました

浅井の日報一覧

浅井

成長し続けるための「成果報告会」について

Webサイト制作における「クライアントからのフィードバック」の重要性について

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

リモート時のコミュニケーションについて

Webサイト制作の制作フェーズにおけるクオリティ向上のための３つのポイント

案件の理解度を高める必要性

フロントエンドはデザインに関われる仕事、ということ

適した「リンクの範囲」について

意外と考えるパンくずの処理方法

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

エンジニアの相互レビューで感じたメリット

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

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

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

隔週で雑談勉強会はじめました