<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>

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

<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>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>以前投稿した<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>FLATに実務未経験で入社してから、丸4年が経ちました。<br>今回は、FLATで働く5年目のエンジニアが普段考えていることや、業務内容について書いてみようと思います。</p><h2 id="h8968ed5810"><br>4年目までを振り返る</h2><p>フロントエンドが得意な受託開発会社で4年間働いてきたため、WebサイトからWebサービスまで幅広い業種のフロントエンド開発を経験しました。<br>以下は有名なフロントエンドエンジニアのロードマップですが、PWAを除くすべてを経験できたと思います。<br><br><a href="https://roadmap.sh/frontend" target="_blank" rel="noopener noreferrer">https://roadmap.sh/frontend</a><br><br>現在はReact系フレームワークを活用したWebサービス開発支援を行っており、フロントエンドリードとしてプロジェクトにアサインされています。実装要件定義や開発リードに加え、マネジメントや顧客対応全般も担当しています。<br>フロントエンドの専門家として提案型の動きが求められるFLATは、フロントエンドとソフトスキルを習得しやすい環境であるといえるでしょう。</p><h2 id="h5a3c34cbb7"><br>カスタマーセールス</h2><p>FLATの強みは<strong>「フロントエンドの開発力」と「プロジェクトマネジメント力」の二つが組み合わさることで生まれる顧客体験（CX）</strong>だと考えています。<br>フロントエンドの開発力とは、多様で複雑なフロントエンド技術のナレッジを持ち、ユーザー体験（UX）や開発者体験（DX）を向上させるアウトプットを実現する力です。この開発力をプロジェクトマネジメントに活かすことで、ビジネスサイドと密に連携を取り、プロジェクトを効率的に進めることができます。<br><br>技術者におけるカスタマーセールスとは、シンプルに良い仕事をすることです。<strong>FLATの強みはまさにお客様の信頼を勝ち取り、高い評価をいただけるカスタマーセールスになり得えます。</strong>お客様とプロジェクトに寄り添う姿勢を大切にし、それを後輩のエンジニアに浸透させる教育とマネジメントを行なっています。</p><h2 id="h7237cf66f5"><br>業務領域の拡大</h2><p>今年に入ってからは、さらなる業務領域の拡大を目指し、バックエンドやインフラの学習を進めています。幸いにも、サービス開発においてはバックエンドタスクを少しずつアサインしてもらいやすいため、フロントエンドリードとしての役割を果たしつつ、今年中にはバックエンドメンバーとしても十分に活躍できるレベルまで成長したいと思います。<br><br>今後は、提案型の動きができるフロントエンドエンジニアやフロントエンドリードの育成に努め、フロントエンド以外の領域にも興味があるメンバーを巻き込んで、<strong>総合的なサービス開発支援ができる事業へと変えていきたいです。</strong><br>開発事業の拡大や技術全般に興味がある方は、ぜひ弊社にジョインしていただけると嬉しいです！</p><h2 id="h1afe451c43"><br>さいごに</h2><p>今回は、5年目のエンジニアが考えていることを一部ですが書かせていただきました。<br><br>FLATの仕事に対する姿勢や今後のビジョンについても少しご紹介できましたので、共感いただけた方はぜひ採用選考に応募していただけると嬉しいです。最近はアプリケーションエンジニアのカジュアル面談にも出席しているので、まずは気軽にお話ししましょう。</p>

5年目エンジニアが今考えていること

仕事の気づきに関する記事です。

仕事の気づき

マネジメント

業務改善

テクノロジー

更新情報

<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><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>受託で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サイト制作における「クライアントからのフィードバック」の重要性について

<p>FLATのディレクターの西條です。<br>FLATにディレクターとして入社して２ヶ月が経過しました。<br><br>これまでもディレクションや実装経験の経験はあったのですが、<br>以前は職域が曖昧だったため、これを機に改めてWebディレクターの仕事内容や役割について考えてみようと思いました。</p><h2 id="h63e66fc1de">Webディレクターの仕事内容</h2><p>前提としてWebディレクターの定義から。<br>「Webディレクターとは」で検索すると大体は、</p><blockquote>Webサイトの企画立案や制作、運用における責任者の立場です。 Webエンジニア、Webデザイナー、ライター、SEO担当者といったWeb 制作に関わる人たちをまとめ、進行や品質に問題ないかチェックし、プロジェクトが円滑に進むように調整して、チームで目標の達成を目指します。<br>引用元：<a href="https://type.career-agent.jp/knowhow/it_web/web_director.html#:~:text=Web%E3%83%87%E3%82%A3%E3%83%AC%E3%82%AF%E3%82%BF%E3%83%BC%E3%81%AF%E3%80%81Web%E3%82%B5%E3%82%A4%E3%83%88,%E3%81%AE%E9%81%94%E6%88%90%E3%82%92%E7%9B%AE%E6%8C%87%E3%81%97%E3%81%BE%E3%81%99%E3%80%82" target="_blank" rel="noopener noreferrer">転職ならtype転職エージェント</a></blockquote><p><br></p><blockquote>Webディレクターとは、Webサイト制作における指揮、進行管理を担う職種です。 クライアントの目的にかなったWebサイトを制作するため、デザインやコーディングなど直接コンテンツ制作に関わるクリエイターやプロジェクトメンバーをまとめ上げ、プロジェクトを円滑に進める舵取り役といった立場であると言えます。<br>引用元：<a href="https://mynavi-creator.jp/blog/article/value-of-web-director#:~:text=Web%E3%83%87%E3%82%A3%E3%83%AC%E3%82%AF%E3%82%BF%E3%83%BC%E3%81%A8%E3%81%AF%E3%80%81Web,%E3%81%A7%E3%81%82%E3%82%8B%E3%81%A8%E8%A8%80%E3%81%88%E3%81%BE%E3%81%99%E3%80%82" target="_blank" rel="noopener noreferrer">マイナビクリエイター</a></blockquote><p>上記のような内容がヒットしますね。<br>会社さんにもよると思いますが、私も一般的なWebディレクターの定義としては「プロジェクトを円滑に進めるための舵取り役」になってくるのかなと思ってます。</p><h3 id="h7c8aec2b34">具体的なWebディレクターの仕事内容は？</h3><p>その上で、仕事内容を掘り下げていきますが、<br>今までの経験や周りのディレクターの仕事内容を踏まえると、代表的な仕事内容は以下になるのかなと思ってます。</p><ul><li>ヒアリング</li><li>企画・提案</li><li>予算管理</li><li>スケジュール/進行管理</li><li>サイト設計/ワイヤーフレーム作成</li><li>デザインディレクション（デザイン要望のヒアリング + デザイナーへの落とし込み）</li><li>実装ディレクション（エンジニアとのコミュニケーションや、サイトの品質チェックなど）</li><li>アフターフォロー（納品後のサポート）</li></ul><p>サイトの性質によっては、マーケターやライター、動画クリエイター、カメラマンなどをアサインする場合やシステムが絡んでくる場合もあるため、ディレクターが手を動かすケースはあまりないと思いますが、知識は必要になってくると思ってます。</p><h2 id="hfe6a713503">Webディレクターの役割とは？</h2><p>色々仕事内容を書いてはきましたが、<br>結局はそのどれもが「プロジェクトを成功に導く」ためにあるものと私は捉えるようにしています。<br><br>ワイヤーや提案書を作成するのが最終目的でなく、<br>プロジェクトを良い形で完了させること、プロジェクトを成功に導くのがWebディレクターの本質的な役割だと思っています。<br><br>成功に導くと書くとキラキラして見えてしまいますが、<br>進行中に問題が起こりそうになる場合もよくあり、そういった際に泥臭く奔走する必要もWebディレクターには求められると思います。</p><h2 id="ha214098e44">まとめ</h2><p>Webディレクターの仕事内容について改めて考えてみました。<br><br>ただ会社さんによって差はあると思うので、</p><ul><li>クリエイティブの比率高め</li><li>マーケティングの比率高め</li><li>セールスの比率高め</li><li>システムの比率高め</li></ul><p>などのケースもあると思います。<br><br>ちなみにFLATでは実装のディレクションはエンジニア自らが行うという文化があります。<br><br>また、エンジニア全員「フロントエンド」という共通項目こそあるものの、得意な領域はそれぞれ伸ばしていっている感じがあるため、難易度の高めの案件でも対応できるケースが多く、ディレクターとしては非常に助かってます。<br><br>入社して2ヶ月、ディレクターとして総合力をつけていくのは当然のこと、私もどこかに専門性をつけるのが今後の目標となりました。</p>

Webディレクターの仕事内容について改めて考えてみた

<p>FLATにエンジニアとして入社して1年が経ちました、飛田です。<br>未経験でこのお仕事につきましたが、日々楽しくお仕事させてもらっています。入社してから1年間の流れやどんな仕事を経験したのか、感じたことなど振り返っていきます。<br>就活、転職活動中の方でFLATで働くことに興味を持ってくださっている方の参考になれば嬉しいです。<br></p><h2 id="haab65e9a1e">入社の経緯</h2><p>入社前は実務ははまったくの未経験で2年弱ほど独学で学習をした状態でした。<br>当時はHTML、CSS、JSなどを勉強していたので、フロントエンドの実装を仕事にしたいと思って求人情報を探していました。<br>そんな時にWantedlyでFLAT代表のサトウさんからお声がけいただきました。<br>自分としては大き会社で勤めるよりも、小規模ながらノウハウを持っていて、エンジニアに裁量のある会社で働きたいと思っていたので、FLATの企業としての姿勢や働き方はとても魅力に感じて<span style="color:#24282a">応募しました。</span><br><span style="color:#24282a">最終的に入社の決め手になったのは、実際に面接に行き、メンバーと話した時の感覚でした。実際に会って話をした時に「この会社、このメンバーの人たちとだったら合いそうだし、自分のスキルも磨いていけそうだ」と思えたので、入社を決意しました。</span><br></p><h2 id="h8f43650e65">入社直後のオンボーディング</h2><p>まず初めの1〜2週間はオンボーディングとして事前に用意された「入社タスク」を進行していきます。<br>入社タスクは、「業務に必要なツールの登録」など1人で進行するタスクと、「業務に必要なツールの使い方（コツ）のレクチャー」みたいに先輩社員からのレクチャーしてもらうタスクがあります。<br>そして入社タスクが終わる頃にはFLATでの仕事の進め方について最低限把握できているような仕組みになっています。<br></p><h2 id="h134f4a110a">入社1ヶ月〜半年</h2><p>オンボーディングが完了するとプロジェクトにアサインされ、初めて自分の担当するプロジェクトが始動しました。ただし、はじめから完全に一人でプロジェクトに入るわけではなく、サポートとして先輩エンジニアも一緒に入ることになります。<br>お客さんとのコミュニケーション、開発フェーズの進め方、など初めは本当に分からない事ばかりであたふたしていました。プロジェクトメンバーや先輩エンジニアにあれこれと聞きながら、どうにか納品まで無事迎えることができました。<br>FLATは「新卒だから～」「1年目だから～」といってプロジェクトを担当出来ないなどの仕事の幅に制限はありません。<br><span style="color:#222222">社内の状況にもよりますが、</span>自ら手を上げて「〇〇プロジェクトやりたいです」と自分の望む仕事・プロジェクトを希望すると大体アサインしてもらえます。<br><br><span style="color:#24282a">だだ、もし自分がマネジメント側の立場だったら、できるかどうかわからないエンジニアに、新しいことをやりたいといわれても、任せられないと思っています。</span><br><span style="color:#24282a">だからこそ、自分が今やってる仕事を一生懸命やり、まずは社内で信頼を勝ち取ることを意識していました。</span><br></p><h2 id="he70e96add9">入社半年〜1年</h2><p>初めの半年は主に「Webサイト制作」を中心にプロジェクトに参画していましたが、入社半年以降は「Webアプリケーション開発」の方にシフトしていきました。<br>この変化は自分にとってはチャレンジングで、求められる技術や知識の量が一気に増えて少々大変でしたが、より複雑な課題に取り組むことができ、自身の成長を感じられるためとても充実しています。<br></p><h2 id="h27dfeb9d71">FLATに入社して感じたこと</h2><p><br></p><h3 id="h26eeb419a8">誰もが主体的である</h3><p>FLATは代表、社員5名、その他業務委託や外部顧問の方と少数精鋭の組織で、組織自体が若く、業務フローやルールはあるがまだ固まっていない部分も多いです。<br>だからこそ柔軟な部分が多く、それは自分にとって入社して「いいな」と感じたポイントでもあります。<br>業務を進行する上で自分たちで考えたり、その都度ルールを作っていくことが多々ありますが、だからこそ、誰もが受け身にならず「働きやすい環境、よりよい制作フローを自分たちで作っていく」という意識が組織全体で根付いています。<br>また、「こうしたい」という声の上げやすさも、主体的に働くうえで重要だと感じます。「こうしたい」という声をあげやすいのはとてもありがたいです。<br></p><h3 id="h8649ebc9af">メンバーの改善意識の高さ</h3><p>FLATのエンジニアは技術向上の意欲が高いと感じます。<br>毎朝の1分間スピーチでは技術関連の話題が多いのだが、共有した技術はすぐに業務で活用しようとしてくれます。<br>技術の移り変わりが激しいこの業界では、技術の共有だけでなく、共有された技術に対するポジティブさはかなり重要だと思うので、<br>共有して終わりではなく、ではどう活用していくか、どう社内ルールに組み込むかなど。こうした技術に対する前向きな考え方は、とても良い影響を受けています。<br>また、興味の範囲がスタッフそれぞれで異なるのも良さだと思います。みんながお互いの持つ個や得意分野に対して興味や理解を持ってくれていると感じてとても楽しいです。<br></p><h2 id="h3bcda3e6b0">最後に</h2><p>あっという間の一年でしたが、振り返ると本当に様々な経験と学びがあった年でした。FLATは研修やサポートも手厚いですが、やはり糧となるのは実案件を通じた経験だと改めて思います。<br>振り返ってみましたが、FLATで働くことに興味を持ってくださっている方の参考になれば嬉しいです。</p>

未経験からFLATにエンジニアとして入社して1年がたったので振り返り

<p>人は自分ひとりの力で強い意思を持ち続けることは難しい。「目標を他人に話すことで達成率が向上する」という話があるが、これを職場で実践してみたところ、想定以上の効果があった。<br>具体的には、当日の計画を社内の分報に投稿することで、「人に話したからにはやるしかない」という感覚が働き、仕事の優先度を意識し計画通りに進める確率が格段に向上した。<br><br>弊社は受託開発を行っており、クライアントワークの優先度が高く、社内業務が後回しにされがちな環境です。<br>私はエンジニアリングマネージャー（EM）として働いており、クライアントワークと社内マネジメントを効率的に並行して進める必要があります。このような状況では、計画をしっかり立て、それを遂行することが極めて重要です。<br><br>一般的に、クライアントワークに追われながら、期限が迫っていない社内業務を効率よくこなすことは容易ではありません。もちろん採用・事業計画やプロジェクトのマイルストーン、開発タスクなど、事前に計画を立てることでその期限は守られます。<br>しかし、組織やプロジェクト単位の計画だけでは、業務全体の効率化を最大限には引き出せません。その実現には個人単位の計画が必要です。<br><br>個人の能力やキャパシティは人それぞれ異なるため、一人ひとりが自分の仕事の効率化を図るためには、最終的に自分自身で計画を立てる必要があります。これを一人だけで遂行するには強い意志が必要となりますが、冒頭にも書いた通りそれが難しい場合が多いのも事実です。<br><br>そこで役立つのが、個人の計画を社内分報に投稿することで、他人の目に触れることによる「人に話したからにはやるしかない」という感覚を利用します。組織やプロジェクト単位の計画においても少なからずこの感覚は働いていると思っており、計画を複数人で共有することに意味があります。<br><br>この試みの要点はあくまで「人に話したからにはやるしかない」という感覚です。つまり、個人の計画を誰か特定の人に共有する必要はなく、オープンな社内プラットフォームに投稿するだけで効果を発揮します。その意味では社内分報は最適な場所であると言えるでしょう。<br><br>なにげなく始めた「社内分報に当日の計画を投稿する」ですが、現在では他のメンバーもが自発的に実践してくれています。おそらく彼らも自分と同様に効果を実感しているのでしょう。</p>

「社内分報に当日の計画を投稿する」が仕事の効率を変えた

<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>私は社内ではEMとして、プロジェクトではエンジニアとしてさまざまな人と関わってきましたが、報連相が不足してる人はいても、報連相が過剰な人は見たことがありません。<br>今回は<strong>なぜ報連相が不足するのか、報連相を身につけるためにとにかく報連相を実践してみよう</strong>ということについて話します。<br></p><h2 id="h214c0dd677">なぜ報連相は不足するのか</h2><p>まずは報連相が不足している例をいくつか挙げてみます。<br></p><ul><li>自身の責任領域を拡大解釈しており、必要な報告が不足していた</li><li>実装者同士のコミュニケーション（連絡）が不十分で、作業の重複や手戻りが発生した</li><li>複雑な実装仕様について相談せず一人で悩んだ上解決したが、それが要因で全体のスケジュールに遅延が発生した</li></ul><p><br>このように報連相が不足していると感じるタイミングと理由はさまざまですが、共通して言えるのは、実行者が<strong>責任者が報連相を受けたいタイミングと理由、報連相することによる効果としないことによるリスクを想定できていない</strong>ということです。そしてたいていの場合、実行者本人は報連相が不足していることに気づいておらず、問題が発生する要因が報連相不足にあることを理解していません。<br></p><h2 id="h922e43e391">優秀な人ほど報連相できる</h2><p>報連相というと例えば「新入社員が業務に慣れるまで必要なこと」というイメージがあるかもしれません。しかし実際には、<strong>仕事を円滑に進めるために日常的に必要なものであり、そのタイミングを見極める必要があります。</strong><br><br>優秀な人はおそらく以下のような観点で報連相を行います。<br></p><ul><li>自身の責任領域以上の内容だと判断し、責任者に事前に確認を取ってから仕事を進めた</li><li>他の実装者の開発内容や進捗を把握しており、作業の重複が起こる可能性を考慮してコミュニケーションを取った</li><li>スケジュールに余裕がないので、自身のスキル以上の実装仕様だと判断し、アサインの変更を相談した</li></ul><p><br>これらに共通しているのは、仕事の背景や他メンバーのことなど視座を高く持ち、適切なタイミングで報連相が必要かどうかの判断をしているということです。<br>逆にいうと視座が低くリスクを想定できないと、そもそも報連相が必要かもしれないという思考にすらならないということです。これが報連相が不足することの主な要因です。<br></p><h2 id="h8a35e69c11">リモートワークの影響</h2><p>またリモートワークは報連相の頻度を減少させうると考えています。<br>弊社はオンラインコミュニケーションツールを積極的に導入していますが、それでもリアルコミュニケーションと比較するとコミュニケーションのハードルが上がります。<br>この少しの差が「他のメンバーの進捗を確認しづらい」「これくらいなら自分で進めても良いかな」という状態を生み出し、報連相が滞る要因になります。<br></p><h2 id="h3c16560b74">報連相はとにかく実践してみること</h2><p><br>報連相ができるようになるためには、とにかく報連相を実践することです。<br>「この状況ではこのように考えるんだ」「そういうリスクもあるのか」「そこまで先のことを見据えているのか」というように、今の自分にはない知識や考え方に触れることで報連相に必要な視座の高さが身についていきます。つまり報連相を実践するというのは自己成長する機会を自身で設けているということになり、反対に報連相をさぼると自己成長の機会を損失しているということになります。<br><br>リモートワークには報連相の頻度を減少させうる特性もあるので、最初は少し過剰に報連相してみる意識を持つと良いでしょう。</p>

カテゴリー

人気記事

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

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

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

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

5年目エンジニアが今考えていること

仕事の気づき

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

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

5年目エンジニアが今考えていること

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

Webディレクターの仕事内容について改めて考えてみた

未経験からFLATにエンジニアとして入社して1年がたったので振り返り

「社内分報に当日の計画を投稿する」が仕事の効率を変えた

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

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

報連相の身につけ方

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

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

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

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

5年目エンジニアが今考えていること