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

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

<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>弊社ではエンジニア1名につき、複数のプロジェクトを同時進行をしているケースが多いです。<br>複数のプロジェクトが同時進行だと、タスクを見落として他のプロジェクトのスケジュールに影響を及ぼしたり、日々の作業量がキャパオーバーになったりと、自分の首を絞めることがあります。<br>自分も、タスクに追われてパフォーマンスを発揮できなくなったりという悪循環を経験したので、自分が実践しているタスク管理についてまとめたいと思います。</p><h2 id="h182266887e"><br>計画を立てることに時間をかける</h2><p>作業が詰まっていると早くタスクに着手したくなりますが、計画がないと進捗が見えず、遅れているのか進んでいるのか判断できません。<br>時間を割いてでも、タスクの整理とスケジュールを立てることが重要です。<br>自分（弊社）はAsanaで、プロジェクト始まる前に1〜2時間ぐらい時間をとって、細かめにタスクを洗い出し、期限日、予定工数などをまとめて計画をたてています。</p><h3 id="h598587f39e">ポイント</h3><ol><li>作業にかかる見積もり工数を計画に含める</li><li>見積もり工数の精度を高めるために、実際にかかった作業時間も記録する</li><li>1.2の振り返りを行い、改善する。</li></ol><p>これにより、数をこなすごとに見積もり工数の算出が正確になっていくきます。<br>見積もり工数が正確であればより堅実なスケジュールを引くことができます。<br><br><img src="https://images.microcms-assets.io/assets/98f41c713ae240acbf11bfbf0993ea22/a09fd2c4249b4964a85dfdd77576572d/a156e35d3ffafd80f8099cabc43ea3cd.png" alt=""></p><h2 id="h14cec2b452"><br>マイルストーンを積極的に設ける</h2><p>スケジュールが長くなればなるほど、タスクは粒度が大きくなればなるほど、マネジメントの難易度が上がります。<br>目安として、1ヶ月程度区切りのないスケジュールのマネジメントは難しいです。<br>例えば開発フェーズの期間が2ヶ月ある場合は2週間単位でマイルストーンを設けるなど意識的にスケジュール上の区切りを設けることで進捗管理が楽になります。</p><h3 id="h598587f39e">ポイント</h3><ol><li>意識的にスケジュール上の区切りを設ける（区切りのないスケジュールの進捗管理は難しい）</li><li>人間は期限が先のタスクを後回しにしがちなので、短すぎず長すぎない粒度でマイルストーンを設置することが大切</li></ol><h2 id="hf3d3feb9fa"><br>タスク管理ツール</h2><p>自分の場合はUIが好きなのでなるべくAsanaで管理するようにしています。<br><span style="color:#242422">ただ「1つのツールに集約させる」「複数のツールで管理する」など人によって好みがあると思います。</span><br><span style="color:#242422">これがよいとは一概には言えませんが、自分に合ったタスク管理を試行錯誤してみることが、作業効率化の第一歩だと思っています。</span><br><br></p>

エンジニア1年生のタスク・スケジュール管理術

<p>良いMTGを設計し、上手にファシリテーションするためには話の内容を誰よりも理解する必要があるな…と感じています。</p><h2 id="hcf83e1357e"><br></h2><p>ファシリテーションでは思考力とコミュニケーション力を組み合わせて、相手の発言を聞くだけではなく、</p><ul><li>相手をしっかり観察し</li><li>その発言を広げたり</li><li>掘り下げげたり</li><li>他の参加者に投げかけたり</li></ul><p>などなどしながら議論の流れを作っていくことが必要です。<br>上記のことを然るべきタイミングで行うには話の内容をちゃんんと理解できなければいけません。<br><br>MTGで自分が理解しにくい領域というものも必ず出てきます。<br>そういった苦手領域が見つかったらそこのインプットを重点的に進めていくことで改善していきたいです。<br>場数を踏んでスムーズにファシリテーションが行えるように頑張ります。</p>

MTGのファシリテーションで話の内容を誰よりも理解する

<p>自分で考えてたくさん調べて学ぶことも重要ですが、近くに優秀なエンジニアがいるのであれば十分にその環境を活用すべきだと考えています。（FLATには当然私より優秀なエンジニアがいるのでとても感謝です！）<br></p><h4 id="h2f3dd994d8">積極的に質問する</h4><p>私は昔から、他人に教えを乞うことが得意ではありませんでした。常に自分で調べて解決しようとしてしまう癖がありました。<br>ただ、先輩から得られることは多く非常に成長できたと感じます。<br></p><h4 id="hd97d05f604">質問の仕方に注意する</h4><p>質問はたくさんするべきですが、質問の仕方というものには注意する必要があると考えています。<br><br><strong>自分がどこまで理解していてどこからがわからないかを整理して共有する</strong><br>例えば、(コードの実装や設計などで)案①と案②との判断に迷っているのであれば、以下を整理して共有します。</p><ul><li>案①は〇〇というメリットがあり、□□というデメリットがある。</li><li>案②は△△というメリットがあり、××というデメリットがある。</li><li>〇〇というメリットを享受するために案①がいいと考えた。</li></ul><p>このように整理してから質問することで、状況を正しく伝えられ、より良いFBをいただくことができると思っています。また、先輩の時間を奪わないという観点でも重要だと考えています。<br><br>また、以下の記事のように質問のテンプレートを活用するのも有効だと思います。<br><a href="https://qiita.com/KNR109/items/550b52ff980c0c32bf2a#%E8%B3%AA%E5%95%8F%E3%83%86%E3%83%B3%E3%83%97%E3%83%AC%E3%83%BC%E3%83%88%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6" target="_blank" rel="noopener noreferrer">新卒1年目に使ったエンジニア質問テンプレート</a><br></p>

質問する時に考えていること

<p>普段Webサイトの実装をする際にデザインが本当に素敵だなと感じる時があります。<br>最初にデザインデータを見た時には気づかなかった細やかな配慮が所々に散りばめられていることにコーディング中に気づいたりもします。<br>こういったデザイナーさんのプロダクトに対するこだわりや情熱を感じることができるのは、とても刺激になります。<br>また、実装側としても「完成度にこだわらなければならない」責任感と「実装側からよりジャンプアップさせたい」という気持ち生まれます。<br>日常の業務から刺激をもらえるのはとても嬉しいです！</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>

カテゴリー

人気記事

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

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

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

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

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

飛田の日報一覧

飛田

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

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

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

エンジニア1年生のタスク・スケジュール管理術

MTGのファシリテーションで話の内容を誰よりも理解する

質問する時に考えていること

実装者から見たデザイン

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

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

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

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

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

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

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