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

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

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

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

<p>今までGitHubアカウントは仕事用と個人用に分けていたのですが、統合することにしました。<br>それに伴い、コントリビューション(通称「草」)の移管について調べましたので共有します。<br><br>新しいアカウントに過去のコミットを属させるには、コミットの作成に使用したメール アドレスを、保持しているアカウントに追加すれば良いそうです。<br>アドレスは移管したものの、コントリビューションが反映されなかったので調べてみました。<br>コントリビューションが反映されるには以下の条件のうち少なくとも一つが必要とのことです。<br>* リポジトリのコラボレーターであるか、またはリポジトリを所有する Organization のメンバーであること。<br>* リポジトリをフォークしたこと。<br>* リポジトリでプルリクエストまたは Issue を開いていること。<br>* リポジトリに Star を付けたこと。<br><br>お客様先のGitHubリポジトリに招待されるスタイルですと、そのうちOrganizationから解除される可能性があります。<br>そのため、頑張って草を生やしてもOrganizationから解除されたタイミングで消えてしまう可能性があります。<br>なので、草を維持したい方は、一旦コミットしたリポジトリにスターをつけておくといいかもしれません。<br><br>参考文献<br><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><br><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></p>

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

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

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

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

カテゴリー

人気記事

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

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

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

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

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

テクノロジー

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

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

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

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

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

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

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

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

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

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