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

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

<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サイトはコンテンツがどうしても流動的なものになってしまうので、多少のレンダリングによる差異は許容しつつも、要所要所で注意する必要があります。

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

最近はコーディング時にキーボード操作を考慮できるよう、普段からキーボードで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キーで閉じる」に加え、展開メニュー時はフォーカスをメニュー内に閉じ込め、展開メニューの最後の項目まで到達後は「閉じる」ボタンにフォーカスさせるのが一番良さそう。

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

FLATで新たに隔週雑談会という試みを始めました。 テーマを決め、それに興味のあるメンバーが有志で集まり、お互いの気になることについて意見交換をしたり、不明点を解消する場になっています。 業務時間外に行なっているので、オフィスでお酒を飲みながらゆるく開催しています。 エンジニア同士でゆるーく技術の話するのって楽しいですよね😋 <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> <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> 雑談していると自分の知らない知識や考え方に出会うことができたり、人に与えることができるので、今後も継続していきたいです。 実践レベルの話や、実際に使ってみた結果の共有のような話をすると、大体話の内容（レベル）に合ったツッコミを入れてもらえるのも楽しいポイントですね。 FLATはフロントエンドの会社ですが、メンバーの興味領域は様々です。 エンジニアを積極採用中なので、技術共有に前のめりな方のご応募をお待ちしております。

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

マネジメント

業務改善

仕事の気づき

テクノロジー

更新情報

フロントエンジニアの山村です。 コーディングの中では「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選定 - 多様化する選択肢の中で

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

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

FLATでは、社内プロジェクトを立ち上げ、業務改善やコンテンツ作成を進めています。この取り組みが始まって半年以上が経過しましたが、企画と実行を分け、メンバーにタスクを依頼する形式よりも効果があると実感しています。 プロジェクトは四半期ごとに立ち上げられ、2〜3名の少人数チームで構成されます。各プロジェクトには責任者が一人立てられ、期の終わりにはクロージングが実施され、社内全体に向けて活動報告が行われます。 企画段階で決めるのは目的やゴール、アサインするメンバーだけで、それ以降はプロジェクトごとにキックオフを実施し、メンバー全員でマイルストーンの設定や具体的なアクションを作成します。進捗管理もプロジェクト内で完結し、四半期という限られた期間で結果を出すことを目指します。 このプロジェクト形式のメリットの一つは、少人数で構成されているため、メンバーが責任感と主体性を持ちやすい点です。企画側からタスクを振られるのとは異なり、プロジェクトメンバーが企画の背景や意図を理解した上で取り組むことができます。 もう一つのメリットは、期間が限られていることです。FLATは受託開発の会社であり、業務の主体であるクライアントワークと並行して期限のないタスクを進行し続けるためには、意識の改善と仕事の進め方や働き方の工夫が必要です。しかし、プロジェクト形式にすることで他のメンバーと期限を共有しマネジメントすることで、期限を守りやすい状態になったと思います。 FLATのような受託開発の会社において、クライアントワークと並行して業務改善やコンテンツ作成などの社内業務を進めるためには、社内プロジェクト形式が有効な手段の一つであると言えます。今後もしばらくはこの形式を継続してみたいですね。

プロジェクト形式で社内業務を進める

ChatGPT、Gemini、PerplexityなどさまざまなAIが登場していますが、私は直近<a href="https://www.perplexity.ai/" target="_blank" rel="noopener noreferrer">Perplexity</a>を使用することが多くなってきました。 <h2 id="h430a34b045">AI検索エンジン「Perplexity」とは</h2>ざっくり説明すると、Google検索のような従来型のブラウザ検索ではなく、チャットボットのような対話形式での回答が得られる対話型検索エンジンになります。 <h3 id="hfa6d8c229a">GPT Plusで検索させた結果</h3>Perplexityは、AIを活用した検索エンジンで、ユーザーの質問に対して自然言語処理（NLP）を用いて回答を提供します。 従来の検索エンジンと異なり、Perplexityは会話形式でユーザーの質問を理解し、関連する情報をまとめて提供します。 とのことで、大枠あってそうです。 Perplexityの利点として、 情報元のサイトもリンク形式で表示されるため信頼性も高いです。 ChatGPTと比べると日本での知名度はあまりないかもしれないですが、記事を執筆している2024年6月現在、ソフトバンクとのコラボが始まるなど、徐々に普及している感じはあります。 参考：<a href="https://www.softbank.jp/mobile/service/perplexity-ai/" target="_blank" rel="noopener noreferrer">https://www.softbank.jp/mobile/service/perplexity-ai/</a> <h2 id="hec4f003291">ユーザーの検索行動への影響に関して</h2>ここからが本題ですが、Perplexityのような対話型検索AIの開発が進み、一般に広く普及されるようになると、ユーザーの検索行動もかなり変化するのではないかと考えています。 現在はブラウザを立ち上げ、Google検索の流れが自然ですが、今後Perplexityのような対話型検索エンジンの普及が進んだ場合、ブラウザを経由せずAIに直接質問をし、サイトを経由せずに回答だけ確認して完了。 このようなユーザーの行動もあり得るのではないかと思っています。 <h2 id="h6ce25feb06">Apple Intelligenceが発表された</h2>先日のWWDC24でAppleのAI「Apple Intelligence」が発表されました。 機能の中に「ChatGPTとSiriの連携」というものがありました。 参考：<a href="https://www.apple.com/apple-intelligence/" target="_blank" rel="noopener noreferrer">https://www.apple.com/apple-intelligence/</a> 今後、Siriに質問し、ユーザーの代わりにChatGPTが情報を収集しユーザーに返却する。 というような、こともできてしまうのでは？と個人的に考えています。 <h2 id="ha214098e44">まとめ</h2>「AI時代にディレクターが考えていること」というタイトルで記事を執筆してみました。 今後のAIのWebへの影響は積極的にキャッチアップしつつ、AI時代にも対応できるようになっていきたいと思います。

AI時代にディレクターが考えていること

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

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

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

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

自分は仕事が好きです。ですので、より多くの仕事をするためにより早く仕事をこなす必要があるのです。 仕事が早ければ、持てる仕事の量が増えてより成長できたり、早く帰れたりします。 この日報では、円滑に仕事を進めるために最近実践していることを書いていきます。 <h2 id="h63deb9a994">1.&nbsp;仕事の主導権を握る</h2>仕事が予定通り進まないケースの半分以上は「進め方を相手任せにしてしまって自分が主体的になれていない」ケースです。 相手からの返答がないと先に進めない状況は避けたいです。 そうならないために、以下のようなことを心がけています。<ul><li>いつまでに返事が欲しいかを明確に伝える</li><li>1日たっても返事が無い場合はリマインドする</li></ul> <h2 id="hcbd53d8508">2. チャットの往復を最小限に抑える</h2>Slackなどが普及して気軽に質問や相談ができるようになりましたが、一方で1～2往復で済むはずのことに時間をかけすぎてしまうことがあります。 自分は割と「質問をする側」にいることが多いのですが、質問を受ける側への配慮はなるべく怠らないようにしています。 自分から質問する場合は考えうる選択肢を2～3つくらい用意しておくと相手も選びやすいので、やりとりの回数を減らせて良いと思います。 例：<blockquote>◯◯◯について確認 △△△は以下どの認識が正しいですか？ ①あり得る答えを記入 ②あり得る答えを記入 ③あり得る答えを記入</blockquote>

カテゴリー

人気記事

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

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

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

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

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

フロントエンド専門制作会社FLATスタッフの業務日報です。エンジニアが気になること、仕事の気づきを共有します。

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

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

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

プロジェクト形式で社内業務を進める

AI時代にディレクターが考えていること

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

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

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

仕事をスムーズに進めるための「主体性」

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

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

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

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

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