<p>FLATでは、一人当たり複数の案件を抱え、社内ではコードレビューや実装に関する相談など、チャットによるテキストコミュニケーションが頻繁に行われます。<br>そこで、日々の作業のスイッチコストを最小限にし、エンジニアとして開発業務に集中するため、あえて即レスを避けるようにしています。<br><br>とはいえ相手に、レスが遅くて待たされているという印象を与えてはいけないので、即レスはしないけどレスが遅い人という印象を与えないための工夫を二つ紹介します。<br></p><h2 id="h2a4289ff0d">一次返信はする</h2><p>即レスはしないと言いましたが、一次返信をしておくことはあります。<br>チャットの通知はONにしてあり、チャットが届くと画面に表示されますが、そこですぐに回答に時間がかかるとわかるものには一次返信をしておきます。<br>チャットを送った相手からすると、チャットを送ってから数時間経ってようやく「〇〇までに確認して返答します」という回答がくるのでは、待たされていると感じてしまうでしょう。<br></p><h2 id="hd2bb6d06ab">返信漏れは発生させない</h2><p>即レスをしないことでチャットを一括で返信することになりますが、チャットをまとめて返そうとすると必然と返信漏れが発生しやすくなります。返信が遅いのに加えて返信漏れが発生していたら、相手に与える印象は最悪です。<br>チャットツールにはたいてい「ブックマーク」という機能があるので、既読をつけてしまったメッセージはすぐにブックマークに追加します。<br>少しだからと頭で覚えていようとすると、いずれ確実に返信漏れが発生しますし、そもそもそこに頭のリソースを使うのはもったいないです。<br><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>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><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>弊社では「技術習得基準」というエンジニアが有するべき技術の基準を設けています。<br>今回はその技術習得基準の内容と、基準を定めるに至った背景について紹介します。<br></p><h2 id="h27520afb85">基準を定めるに至った背景</h2><p><br>弊社は元々主にCMSサイトのコーディングやCMS組み込みを生業とするWeb制作受託会社でしたが、ここ2、3年で受託するサイトはより巨大で複雑になってきました。<br>また新たにアプリ開発受託として、Webサービスやネイティブアプリの新規構築、開発支援も行うようになりました。<br><br>弊社は現在業務委託メンバーも合わせて5名〜10名程度の少人数エンジニア組織であり、常にプロジェクトや要件に合わせた最適なアサインができるほどのリソースがあるわけでもなく、拡大する業務領域と求められる技術の高度化に対応しきれないプロジェクトが発生するようになりました。<br>少ない人数でも適切なアサインをするためには、今のフロントエンド開発の現場で必要なスキルを定義し、職務グレードに応じてそれを徐々に習得してもらう。そのようにして、ある程度どのメンバーがどの開発現場に入ってもパフォーマンスを発揮できる状態を作る必要があるなと考えました。<br><br>そこで新たに「技術習得基準」を設け、サイト制作とアプリ開発それぞれで職務グレードごとに必要なスキルセットを定義するようにしました。一応補足しておくと、これは決してエンジニアの個性を否定するものではありません。まずはエンジニアとして必ず必要な基礎領域を習得することが大切で、その基礎領域も年々拡大し高度化しているということです。弊社のエンジニアには基礎領域を習得した上で、各々興味があったり得意な技術を存分に伸ばしていってほしいと思っています。<br></p><h2 id="hb74dffdce5">技術習得基準とは</h2><p><br>弊社では技術習得基準として、このように職務グレードごとに習得すべきスキルを表にまとめています。<br><br><img src="https://images.microcms-assets.io/assets/98f41c713ae240acbf11bfbf0993ea22/db5fcd95ceea445d86db27c0052c9379/%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%202024-02-22%2021.23.09.png" alt=""><br><br>そしてそれを身につけるためにおすすめの教材と、身につけたといえる基準も簡単に記載しています。参考までにReactの内容を添付します。<br><br><img src="https://images.microcms-assets.io/assets/98f41c713ae240acbf11bfbf0993ea22/3d6f66f460c041ba93288ff8904f0fc5/%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%202024-02-22%2021.26.46.png" alt=""><br><br>弊社には書籍購入制度もあるので、メンバーの多くはおすすめ教材に沿って学習を進めてくれています。<br>加えて1on1では、この技術習得基準をもとにメンバーの希望する働き方や仕事内容に合わせた学習計画を作ってあげています。<br></p><h2 id="h1afe451c43">さいごに</h2><p><br>このように弊社には、やる気さえあれば成長できる環境が整っています。<br>他にもエンジニアにとって魅力的な制度をたくさん用意しているので、興味がある方は採用応募、もしくはカジュアル面談のご応募いただけると嬉しいです。</p>

弊社の「技術習得基準」の紹介

<p>技術は、本人が必要性を感じ興味を持つことではじめて習得できるものです。私はEMとして日頃からエンジニアの教育を含むマネジメントを行なっていますが、組織としてメンバー全員に習得してほしい技術がある場合、教えるスタイルの教育では身につけてもらえないということを経験してきました。<br>例えば全員参加の勉強会を開催しても、メンバー自身がその技術を習得することの必要性を感じ興味を持たなければ、身につくことはありません。その必要性を感じてもらうためには、自らの意志でその技術に触れてもらうしかないと考えています。<br><br>そこで、弊社では教育のアプローチを変え、エンジニアとして必要なスキルを明確に定義し、それらを習得することの必要性とメリットをメンバーに説明し、それを目指してもらうことにしました。そしてジョブグレードごとに異なるスキル基準を設け、評価制度に組み込みました。<br><br>基準を目指してもらう教育と書きましたが、もちろんスキルを身につけるためのサポートは積極的に行っています。<br>メンバーそれぞれの興味に合わせたプロジェクトをアサイン、アウトプットの場を提供し、技術共有やコードレビューを社内制度やワークフローに組み込むことで、日常的にフィードバックを受けられる体制を構築しています。<br><br>弊社にはプロフェッショナルなフロントエンドエンジニアを目指して成長し続けられる環境があります。技術が好きで、技術共有に前向きな方は、ぜひ弊社にジョインいただけると嬉しいです。</p>

カテゴリー

人気記事

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

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

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

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

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

記事執筆者

マネジメント

弊社の「技術習得基準」の紹介

基準を目指してもらうエンジニア教育

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

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

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

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

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