技術は、本人が必要性を感じ興味を持つことではじめて習得できるものです。私は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>その人の理解度はその人自身にしかわかりませんし、その人自身も正確に把握できていないこともあります。 人になにかを教えるときは、いくつかの対話をすることで相手の理解度を引き出してあげるようなコミュニケーションを取ることを心がけましょう。

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

テクノロジーに関する記事です。

テクノロジー

マネジメント

業務改善

仕事の気づき

更新情報

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

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

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

カテゴリー

人気記事

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

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

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

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

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

テクノロジー

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

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

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

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

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

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

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

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