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

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

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

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

パンくずが複数行になった場合の処理について、サイトに合った処理方法を提案できたら良いです。 パンくずは現在地表示なので、複雑なデザインパターンがいくつもあるというわけではありません。 ただ、SP表示やタイトル表示が長くなった場合に、コンテンツ枠からはみ出したものを「どう処理するのか」を考える必要があります。 ブラウザ幅からはみ出したものを<ul><li>スクロールで表示させるのか</li><li>はみ出した部分を省略させるのか</li><li>複数行にするのか</li></ul>など、処理方法はいくつか考えられます。 たとえば、サイト内の構造が複雑なECサイトであれば、 ・階層が深くなること ・ECサイトという性質上、商品名がフルで表示されたほうが、ページを認識しやすくなること などから、テキスト省略はさせずに横スクロール対応で実装したほうが、ユーザーにとってもわかりやすいと思います。 反面、階層が深くなく、長いテキストが表示される可能性が少ない場合は省略してしまったほうがすっきりと見やすくなるかもしれません。 このように、パンくずに限らず「なぜそうしたのか」を常に説明できる状態にする、ということはとても大切なことだと思います。 もしかしたらもっと良い考え方があるのかもしれませんが、このような些細なパターンも提案し、少しでもよいサイトに近づけたら嬉しです

意外と考えるパンくずの処理方法

FLATでは、一人当たり複数の案件を抱え、社内ではコードレビューや実装に関する相談など、チャットによるテキストコミュニケーションが頻繁に行われます。 そこで、日々の作業のスイッチコストを最小限にし、エンジニアとして開発業務に集中するため、あえて即レスを避けるようにしています。 とはいえ相手に、レスが遅くて待たされているという印象を与えてはいけないので、即レスはしないけどレスが遅い人という印象を与えないための工夫を二つ紹介します。 <h2 id="h2a4289ff0d">一次返信はする</h2>即レスはしないと言いましたが、一次返信をしておくことはあります。 チャットの通知はONにしてあり、チャットが届くと画面に表示されますが、そこですぐに回答に時間がかかるとわかるものには一次返信をしておきます。 チャットを送った相手からすると、チャットを送ってから数時間経ってようやく「〇〇までに確認して返答します」という回答がくるのでは、待たされていると感じてしまうでしょう。 <h2 id="hd2bb6d06ab">返信漏れは発生させない</h2>即レスをしないことでチャットを一括で返信することになりますが、チャットをまとめて返そうとすると必然と返信漏れが発生しやすくなります。返信が遅いのに加えて返信漏れが発生していたら、相手に与える印象は最悪です。 チャットツールにはたいてい「ブックマーク」という機能があるので、既読をつけてしまったメッセージはすぐにブックマークに追加します。 少しだからと頭で覚えていようとすると、いずれ確実に返信漏れが発生しますし、そもそもそこに頭のリソースを使うのはもったいないです。 このような点に配慮することで、大量のメッセージに振り回されることなく自分のページを保って仕事をすることができます。

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

レクチャーを行う際には、相手の理解度を引き出すコミュニケーションが重要です。 <h2 id="h2cb283ee5f">理解度を引き出すコミュニケーションとは</h2>人は、その時点での知識や理解度によって、受け取りやすい情報量が異なります。 情報が多すぎると理解しきれず、逆に情報が少なすぎると話の要点が伝わらず、中途半端な理解に終わってしまいます。 そのため、相手の理解度と受け取りやすい情報量を把握するために、相手に話してもらうことが大切です。 レクチャーを行う場合、教える側が話し続けることが多くなりがちですが、相手の理解度を把握するためには、むしろ相手に話してもらうことが大切です。 言葉遣いやボキャブラリー、話すテンポなどを確認しつつ、こまめに質問をすることで、理解している領域とそうでない領域を区別することができます。 そうすると、「Aは理解しているだろうがBは理解していないだろう」といった予測を立てることができます。 自分はその予測に基づいて、相手に提供する情報の量をコントロールしています。 <h2 id="ha214098e44">まとめ</h2>その人の理解度はその人自身にしかわかりませんし、その人自身も正確に把握できていないこともあります。 人になにかを教えるときは、いくつかの対話をすることで相手の理解度を引き出してあげるようなコミュニケーションを取ることを心がけましょう。

レクチャーにおけるコミュニケーションの姿勢

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

仕事の気づき

マネジメント

業務改善

テクノロジー

更新情報

自分で考えてたくさん調べて学ぶことも重要ですが、近くに優秀なエンジニアがいるのであれば十分にその環境を活用すべきだと考えています。（FLATには当然私より優秀なエンジニアがいるのでとても感謝です！） <h4 id="h2f3dd994d8">積極的に質問する</h4>私は昔から、他人に教えを乞うことが得意ではありませんでした。常に自分で調べて解決しようとしてしまう癖がありました。 ただ、先輩から得られることは多く非常に成長できたと感じます。 <h4 id="hd97d05f604">質問の仕方に注意する</h4>質問はたくさんするべきですが、質問の仕方というものには注意する必要があると考えています。 自分がどこまで理解していてどこからがわからないかを整理して共有する 例えば、(コードの実装や設計などで)案①と案②との判断に迷っているのであれば、以下を整理して共有します。<ul><li>案①は〇〇というメリットがあり、□□というデメリットがある。</li><li>案②は△△というメリットがあり、××というデメリットがある。</li><li>〇〇というメリットを享受するために案①がいいと考えた。</li></ul>このように整理してから質問することで、状況を正しく伝えられ、より良いFBをいただくことができると思っています。また、先輩の時間を奪わないという観点でも重要だと考えています。 また、以下の記事のように質問のテンプレートを活用するのも有効だと思います。 <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>

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

VScodeのスニペットを設定し始めて、半年が経過しました。 サイト作成で使われるHTML、CSS、JavaScript、およびWordPressを中心に、よく使用されるコードや、実装がやや手間のかかるパーツをまとめてきました。 確認したところ、個人用のスニペットは70個以上蓄積されていました。これを機に、スニペットの作成時に留意しているポイントを整理します。 prefixに関連キーワードを含める: prefixはコードを呼び出すためのショートカットで、任意の文字列を設定できます。覚えるのは難しいため、キーワードを含めるようにしました。 具体的には画像系のスタイルの場合は「img」をprefixに含め、中央寄せ系のスタイルは「center」を含めるなど、整理しておくと便利です。 これにより、「center」を入力するだけで中央寄せ系のスタイルが提案され、記憶の負担が軽減されます。 言語名を含める パーツによってはHTMLとCSSがセットで必要な場合があります。 例えば、セクションの背景に画像を敷く場合、「img-background-html」「img-background-css」といった形で命名することで、HTMLとCSSの対応がわかるようにします。 言語名を組み込むことで、どの言語のスニペットか一目で分かり、開発の効率向上になると思います。 ちょっとした工夫ですが、スニペットの活用により、実装が効率的になるだけでなく、コードの品質向上も期待できます。 これからも効果的なコーディングを目指し、精進していきます。

スニペット作成で気をつけていること

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

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

FLATでは新たに技術雑談会という試みを始めました。 誰か1人がテーマを決め、それに興味のあるメンバーが有志で集まり、お互いの気になることについて意見交換をしたり、不明点を解消する場になっています。開催も不定期で業務時間外に行なっているので、オフィスでお酒を飲みながらゆる〜く開催しています。 直近では、<a href="https://react.dev/learn" target="_blank" rel="noopener noreferrer">Learn React</a>を題材として技術雑談会を行いました。ドキュメントの読み方や理解度は人によって様々なので、同じドキュメントを読んでいても、そこから得られることは大きく異なります。 社内では最近、公式ドキュメントを参照することの重要性を伝えています。「自分では気づかなかったことに気づくことができた」「ドキュメントを参照すれば解決するんだな」という体験を提供することで、ドキュメントを参照する習慣が身に付いたら嬉しいなと思っています。 エンジニアには継続的な学習が必要です。1人で黙々と学習するくらいなら、同じ興味を持つ人たちで集まり、お互いのスキルやモチベーションを高めあう関係を築くことで、より効率的により楽しく学習をしてほしいという想いがあります。 FLATはフロントエンドの会社ですが、メンバーの興味領域は様々です。エンジニアを積極採用中なので、技術共有に前のめりな方のご応募をお待ちしております。

技術雑談会を始めました

例えば、「詳細ページへ進む際に押す矢印ボタン」を実装する際、 今まではアイコンをbackground-imgで指定して終わり、疑似要素でアイコンを表示させて終わり……。 といった実装になっており、アクセシビリティへの配慮ができていなかったことにフィードバックをいただいて学ぶことができました。 具体的には以下のようにアイコン等の要素の子要素としてspanタグを入れ、画面上spanタグを表示させないような実装をすると、 スクリーンリーダーを用いるユーザーにもボタンの意図を伝えることができることを学びました。 ```&lt;p class="c-nextButton__arrow"&gt; &nbsp;&nbsp;&lt;span class="u-visuallyHidden"&gt;詳細ページへ&lt;/span&gt; &lt;/p&gt;``` 「画面上不可視とする」ことをどのように実装しているのか確認してみると、 以下のような実装になっていました。 ```u-visuallyHidden { &nbsp;position: absolute; &nbsp;width: 1px; &nbsp;height: 1px; &nbsp;padding: 0; &nbsp;margin: -1px; &nbsp;overflow: hidden; &nbsp;clip: rect(1px 1px 1px 1px); &nbsp;border: 0; } ``` 調べてみると、Bootstrap等でもこのようなスクリーンリーダー用のクラスが用意されていることを知りました。 他のエンジニアの方の実装やライブラリのクラスなどを拝見してスキルを身につけていきたいと思いました。

アクセシビリティ対応に関する学び

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

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

何を聞いているのか、何を解決したいからこの問いを聞いているのかを明確にして正確に捉えることが必要である。問い①に対しては、答え1でなく、答え①を返す必要がある。 ①をそもそも正確に抑えれていない場合、正確な答え①を返すことはできない。まずは課題の本質を捉える練習を行いたい。仕事は朝〜晩まで課題解決の連続だと思う。進捗会一つにしても、常に何を解決するための話なのか、何のための行動なのかを意識しながら話を聞く読むを行なっていきたい。正しく理解する。

カテゴリー

人気記事

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

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

意外と考えるパンくずの処理方法

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

レクチャーにおけるコミュニケーションの姿勢

仕事の気づき

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

スニペット作成で気をつけていること

意外と考えるパンくずの処理方法

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

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

技術雑談会を始めました

アクセシビリティ対応に関する学び

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

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

問い(課題)を正しく聞き、正しく読み

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

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

意外と考えるパンくずの処理方法

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

レクチャーにおけるコミュニケーションの姿勢