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

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

FLATに実務未経験で入社してから、丸4年が経ちました。 今回は、FLATで働く5年目のエンジニアが普段考えていることや、業務内容について書いてみようと思います。<h2 id="h8968ed5810"> 4年目までを振り返る</h2>フロントエンドが得意な受託開発会社で4年間働いてきたため、WebサイトからWebサービスまで幅広い業種のフロントエンド開発を経験しました。 以下は有名なフロントエンドエンジニアのロードマップですが、PWAを除くすべてを経験できたと思います。 <a href="https://roadmap.sh/frontend" target="_blank" rel="noopener noreferrer">https://roadmap.sh/frontend</a> 現在はReact系フレームワークを活用したWebサービス開発支援を行っており、フロントエンドリードとしてプロジェクトにアサインされています。実装要件定義や開発リードに加え、マネジメントや顧客対応全般も担当しています。 フロントエンドの専門家として提案型の動きが求められるFLATは、フロントエンドとソフトスキルを習得しやすい環境であるといえるでしょう。<h2 id="h5a3c34cbb7"> カスタマーセールス</h2>FLATの強みは「フロントエンドの開発力」と「プロジェクトマネジメント力」の二つが組み合わさることで生まれる顧客体験（CX）だと考えています。 フロントエンドの開発力とは、多様で複雑なフロントエンド技術のナレッジを持ち、ユーザー体験（UX）や開発者体験（DX）を向上させるアウトプットを実現する力です。この開発力をプロジェクトマネジメントに活かすことで、ビジネスサイドと密に連携を取り、プロジェクトを効率的に進めることができます。 技術者におけるカスタマーセールスとは、シンプルに良い仕事をすることです。FLATの強みはまさにお客様の信頼を勝ち取り、高い評価をいただけるカスタマーセールスになり得えます。お客様とプロジェクトに寄り添う姿勢を大切にし、それを後輩のエンジニアに浸透させる教育とマネジメントを行なっています。<h2 id="h7237cf66f5"> 業務領域の拡大</h2>今年に入ってからは、さらなる業務領域の拡大を目指し、バックエンドやインフラの学習を進めています。幸いにも、サービス開発においてはバックエンドタスクを少しずつアサインしてもらいやすいため、フロントエンドリードとしての役割を果たしつつ、今年中にはバックエンドメンバーとしても十分に活躍できるレベルまで成長したいと思います。 今後は、提案型の動きができるフロントエンドエンジニアやフロントエンドリードの育成に努め、フロントエンド以外の領域にも興味があるメンバーを巻き込んで、総合的なサービス開発支援ができる事業へと変えていきたいです。 開発事業の拡大や技術全般に興味がある方は、ぜひ弊社にジョインしていただけると嬉しいです！<h2 id="h1afe451c43"> さいごに</h2>今回は、5年目のエンジニアが考えていることを一部ですが書かせていただきました。 FLATの仕事に対する姿勢や今後のビジョンについても少しご紹介できましたので、共感いただけた方はぜひ採用選考に応募していただけると嬉しいです。最近はアプリケーションエンジニアのカジュアル面談にも出席しているので、まずは気軽にお話ししましょう。

5年目エンジニアが今考えていること

<h2 id="h8d027c8ed3">はじめに</h2>以前投稿した<a href="https://daily-report.wd-flat.com/article/web-quality" target="_blank" rel="noopener noreferrer">「Webサイト制作の制作フェーズにおけるクオリティ向上のための３つのポイント」</a>では、Webサイト制作において品質（クオリティ）を確保することは非常に重要であることをお伝えしました。 今回はFLATのチェック体制にフォーカスを当て、どのようにサイトの品質を保っているのかをお伝えしていきたいと思います。 <h2 id="hd3e16ef9d3">チェックフローについて</h2>まず、FLATで設けているチェックフローをご紹介します。 適切なチェックフローを設けることで、サイトの品質を保ちつつ、効率良く制作を進めることができます。 FLATでは、Webサイト制作の各段階において、以下のチェックフローを設けています。 1. 制作エンジニアによる自己チェック（制作者チェック） 制作エンジニアが自身の作業の見直しをし、デザイン仕様の誤りや漏れがないかを確認します。例えば、コードの構文エラーや、各ブラウザでのデザイン表示崩れなどの確認です。 2. 第三者によるデザイン再現・動作検証チェック（Wチェック） 客観的な視点でのチェックを行うため、別のエンジニアがチェックを実施します。特に第一のチェックで見逃されがちなユーザビリティの問題や動作チェックなどを詳細に確認し、「サイトが本番公開できる状態であるか」確認を行います。 3. 納品前の最終チェック（クオリティチェック） 納品前には全体のコンテンツと機能を最終確認します。このチェックでは、クライアントの要求事項（案件仕様）が全て満たされているかの確認や、ユーザー目線での最終的な動作検証を中心に行います。 4. 本番公開後チェック（公開後チェック） 納品されたコードが正しく反映されているか表示確認を行います。 <h2 id="h33acc128da">チェック項目について</h2>また、上記のチェックフローではそれぞれチェック項目を設けており、チェック項目は大きく分けて以下のとおりです。<ul><li>デザイン再現性チェック</li><li>レスポンシブ動作チェック</li><li>UI操作実行チェック</li><li>動的コンテンツによる表示崩れチェック</li><li>実機動作チェック</li><li>各ブラウザ検証チェック</li><li>テキスト・画像反映チェック</li><li>meta情報チェック</li></ul>この項目からさらに細分化していき、プロジェクトごとにも項目の内容は変わります。 このように細かくチェック項目を設けて属人化を防ぎ、エンジニア・ディレクター・プロジェクトマネージャーなど、チーム全員が一丸となって品質向上に努めることで、クライアントにとっても、市場にとっても価値あるサイトを提供していきます。 そして、クオリティの高いWebサイトを制作するためには、上述したチェックフローの徹底はもちろん、制作に関わる全員が案件に対する理解を深めることが必要となります。 <h2 id="hb3f9858bed">チェックの課題点</h2>しかしながら、現在チェック項目が40項目にも及ぶため、チェック作業に多くの時間を要することが課題となっています。 チェック項目が多すぎると、本来重要な項目が見逃される可能性もあるため、チェック項目の見直しや自動化ツールの導入を積極的に行っていく必要があります。 今後も技術の進化に合わせてチェックフローをアップデートし、効率的で効果的な制作フローを整えていくことが重要です。 <h2 id="h9be0c3393d">おわりに</h2>今回はFLATで行っているチェック体制の一部をご紹介しました。 今回ご紹介したチェックフローのほかにも、FLATではコードレビューやJavaScriptクオリティチェック、CMS構築チェックなどコード内部のチェックも行っています。 引き続き、全ての案件で一貫したクオリティを保つことができるよう、今後もチェック体制を整えていきますので、どうぞよろしくお願いいたします。

Webサイトのチェック体制について、一部をご紹介

FLATでは、案件終了後に「成果報告会」という振り返りの場を設けています。 この成果報告会には案件にアサインされたメンバーだけでなく、FLAT全体が参加することで、さまざまな視点からのフィードバックが得られます。 私がFLATに入社してから何度も成果報告会を経験していますが、どれも内容は濃く、スムーズに進行できた案件であってもどこかには課題が潜んでおり、それによって議論が白熱することも多々あります。 そんなFLATの成果報告会ですが、主に以下の項目を中心に振り返りを行っています。 <ul><li>案件全体の振り返り</li></ul>プロジェクトの概要を共有し、プロジェクト進行中に発生したクライアントやFLATにとって利益となった点や、達成できなかった目標について話し合います。<ul><li>チームや個人の課題・改善点</li></ul>チームやメンバーが直面した課題を振り返り、改善点を見つけます。 これにより、個々のメンバーだけでなく、チーム全体が成長し、次の案件<ul><li>作業工数の振り返り</li></ul>案件にどれだけの時間がかかったのか、見積もり工数との乖離がないかどうか、もし乖離があった場合はなぜ乖離があったのかなどの振り返りを行います。 これにより次回以降のプロジェクトで工数見積の精度を高めることができます。<ul><li>今後のアクション</li></ul>成果報告会で得たフィードバックを元に、課題や改善点に対する今後のアクションを決めていきます。 具体的な改善策を立て、実行に移すことで、次の案件に活かせるような継続的な改善を行っていきます。

成長し続けるための「成果報告会」について

最近はコーディング時にキーボード操作を考慮できるよう、普段からキーボードでWebサイトの操作を行うようにしている。 先日遭遇したサイトでは、ハンバーガーメニュー展開時、展開メニューの最後の項目まで到達したあとにTabキーを押すと、ハンバーガーメニューが自動で閉じられるメニューが設置されていた。 個人的に、このハンバーガーメニューはシンプルに「使いやすい」と感じた。 というのも、通常、必要のないハンバーガーメニューを「閉じる」ためには、「閉じる」ボタンまで戻るなど、何かしらの動作を行わなければいけない。 しかし、遭遇したサイトは閲覧を続ける流れでハンバーガーメニューが自然と閉じられる。 だが、JISアクセシビリティ達成基準を確認したところ、下記のような基準が設けられていた。<blockquote>フォーカスを受け取ったときにイベントを起動することのできるすべてのコンポーネントは、コンテキストを変化させてはならない。</blockquote>フォーカス時：達成基準 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> 確かに、展開メニューの最後の項目まで到達したあとにTabキーを押すとメニューが閉じられる仕様は、フォーカス時にコンテキストを変化させることになり、ユーザーの予測できない動きとなってしまう。 そのため、ある状況に置いては使用しづらさを感じる可能性があるかもしれない。 この時思うことが、「自動的に」変化を起こすものは「便利」だと捉えてしまいがちだが、「誰もが」「どの環境でも」使いやすいものを考えたときは「己の意思で操作できるかどうか」「意図した操作ができるかどうか」を念頭に置いて考える必要がある。 「Escキーで閉じる」に加え、展開メニュー時はフォーカスをメニュー内に閉じ込め、展開メニューの最後の項目まで到達後は「閉じる」ボタンにフォーカスさせるのが一番良さそう。

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

マネジメント

業務改善

仕事の気づき

テクノロジー

更新情報

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

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

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

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

FLATで新たに隔週雑談会という試みを始めました。 テーマを決め、それに興味のあるメンバーが有志で集まり、お互いの気になることについて意見交換をしたり、不明点を解消する場になっています。 業務時間外に行なっているので、オフィスでお酒を飲みながらゆるく開催しています。 エンジニア同士でゆるーく技術の話するのって楽しいですよね😋 <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> <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> 雑談していると自分の知らない知識や考え方に出会うことができたり、人に与えることができるので、今後も継続していきたいです。 実践レベルの話や、実際に使ってみた結果の共有のような話をすると、大体話の内容（レベル）に合ったツッコミを入れてもらえるのも楽しいポイントですね。 FLATはフロントエンドの会社ですが、メンバーの興味領域は様々です。 エンジニアを積極採用中なので、技術共有に前のめりな方のご応募をお待ちしております。

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

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

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

FLATにエンジニアとして入社して1年が経ちました、飛田です。 未経験でこのお仕事につきましたが、日々楽しくお仕事させてもらっています。入社してから1年間の流れやどんな仕事を経験したのか、感じたことなど振り返っていきます。 就活、転職活動中の方でFLATで働くことに興味を持ってくださっている方の参考になれば嬉しいです。 <h2 id="haab65e9a1e">入社の経緯</h2>入社前は実務ははまったくの未経験で2年弱ほど独学で学習をした状態でした。 当時はHTML、CSS、JSなどを勉強していたので、フロントエンドの実装を仕事にしたいと思って求人情報を探していました。 そんな時にWantedlyでFLAT代表のサトウさんからお声がけいただきました。 自分としては大き会社で勤めるよりも、小規模ながらノウハウを持っていて、エンジニアに裁量のある会社で働きたいと思っていたので、FLATの企業としての姿勢や働き方はとても魅力に感じて応募しました。 最終的に入社の決め手になったのは、実際に面接に行き、メンバーと話した時の感覚でした。実際に会って話をした時に「この会社、このメンバーの人たちとだったら合いそうだし、自分のスキルも磨いていけそうだ」と思えたので、入社を決意しました。 <h2 id="h8f43650e65">入社直後のオンボーディング</h2>まず初めの1〜2週間はオンボーディングとして事前に用意された「入社タスク」を進行していきます。 入社タスクは、「業務に必要なツールの登録」など1人で進行するタスクと、「業務に必要なツールの使い方（コツ）のレクチャー」みたいに先輩社員からのレクチャーしてもらうタスクがあります。 そして入社タスクが終わる頃にはFLATでの仕事の進め方について最低限把握できているような仕組みになっています。 <h2 id="h134f4a110a">入社1ヶ月〜半年</h2>オンボーディングが完了するとプロジェクトにアサインされ、初めて自分の担当するプロジェクトが始動しました。ただし、はじめから完全に一人でプロジェクトに入るわけではなく、サポートとして先輩エンジニアも一緒に入ることになります。 お客さんとのコミュニケーション、開発フェーズの進め方、など初めは本当に分からない事ばかりであたふたしていました。プロジェクトメンバーや先輩エンジニアにあれこれと聞きながら、どうにか納品まで無事迎えることができました。 FLATは「新卒だから～」「1年目だから～」といってプロジェクトを担当出来ないなどの仕事の幅に制限はありません。 社内の状況にもよりますが、自ら手を上げて「〇〇プロジェクトやりたいです」と自分の望む仕事・プロジェクトを希望すると大体アサインしてもらえます。 だだ、もし自分がマネジメント側の立場だったら、できるかどうかわからないエンジニアに、新しいことをやりたいといわれても、任せられないと思っています。 だからこそ、自分が今やってる仕事を一生懸命やり、まずは社内で信頼を勝ち取ることを意識していました。 <h2 id="he70e96add9">入社半年〜1年</h2>初めの半年は主に「Webサイト制作」を中心にプロジェクトに参画していましたが、入社半年以降は「Webアプリケーション開発」の方にシフトしていきました。 この変化は自分にとってはチャレンジングで、求められる技術や知識の量が一気に増えて少々大変でしたが、より複雑な課題に取り組むことができ、自身の成長を感じられるためとても充実しています。 <h2 id="h27dfeb9d71">FLATに入社して感じたこと</h2> <h3 id="h26eeb419a8">誰もが主体的である</h3>FLATは代表、社員5名、その他業務委託や外部顧問の方と少数精鋭の組織で、組織自体が若く、業務フローやルールはあるがまだ固まっていない部分も多いです。 だからこそ柔軟な部分が多く、それは自分にとって入社して「いいな」と感じたポイントでもあります。 業務を進行する上で自分たちで考えたり、その都度ルールを作っていくことが多々ありますが、だからこそ、誰もが受け身にならず「働きやすい環境、よりよい制作フローを自分たちで作っていく」という意識が組織全体で根付いています。 また、「こうしたい」という声の上げやすさも、主体的に働くうえで重要だと感じます。「こうしたい」という声をあげやすいのはとてもありがたいです。 <h3 id="h8649ebc9af">メンバーの改善意識の高さ</h3>FLATのエンジニアは技術向上の意欲が高いと感じます。 毎朝の1分間スピーチでは技術関連の話題が多いのだが、共有した技術はすぐに業務で活用しようとしてくれます。 技術の移り変わりが激しいこの業界では、技術の共有だけでなく、共有された技術に対するポジティブさはかなり重要だと思うので、 共有して終わりではなく、ではどう活用していくか、どう社内ルールに組み込むかなど。こうした技術に対する前向きな考え方は、とても良い影響を受けています。 また、興味の範囲がスタッフそれぞれで異なるのも良さだと思います。みんながお互いの持つ個や得意分野に対して興味や理解を持ってくれていると感じてとても楽しいです。 <h2 id="h3bcda3e6b0">最後に</h2>あっという間の一年でしたが、振り返ると本当に様々な経験と学びがあった年でした。FLATは研修やサポートも手厚いですが、やはり糧となるのは実案件を通じた経験だと改めて思います。 振り返ってみましたが、FLATで働くことに興味を持ってくださっている方の参考になれば嬉しいです。

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

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

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

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

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

自分で考えてたくさん調べて学ぶことも重要ですが、近くに優秀なエンジニアがいるのであれば十分にその環境を活用すべきだと考えています。（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>

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

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

実装者から見たデザイン

FLATに入社して初めて「相互レビュー」を導入した際に感じたメリットやより効果を上げるために実践してみたことを書いてみます。 <h2 id="hdda799b038">導入（相互レビューで享受できるメリット）</h2>弊社では開発者同士で相互にレビューを行っています。これはスキルセットに関わらず、もれなく案件に携わるエンジニア全員が対象(レビュアーとしてもレビュイーとしても)です！ 最終的なクオリティチェックの前に開発者同士でレビューし合うことによって、以下のようなメリットが考えられます。<ol><li>次工程へ進むコードの質が高められる</li><li>他の人の書いたコードを読むことで、新しい知見を得られる</li><li>最終チェックを行う人の負担を減らせる</li></ol> <h3 id="h7218860a29">1.次工程へ進むコードの質が高められる</h3>以下のような内容は開発者同士でも確認することができます。 <ul><li>仕様に対するロジックがおかしくないか</li><li>冗長な書き方をしていないか</li><li>わかりずらい命名をしていないか</li><li>(リファクタリングしているのであれば)修正前後でロジックに変化がないか</li><li>変数やメソッドなど、共通化できる部分はないか</li><li>シンタックスエラー、コンソールエラーはないか</li></ul> <h3 id="h6fa6ae3a55">2.他の人の書いたコードを読むことで得られるものがある</h3>また、これはスキルセットが似通った開発者であっても、そうでなくてもメリットがあります。 <h4 id="hb351c9984c">スキルセットが同じ場合</h4><ul><li>自分では書かないようなコーディング方法、ロジック、命名などがたくさん見れる</li><li>「こう書いたらもっと良いのでは」などのような議論がソースコードを使ってできる</li></ul> <h4 id="h11f853a161">スキルセットが異なる場合</h4><ul><li>自分では書けないコードを読む機会がもらえる (新しい発想・共通化の仕方・知らなかったライブラリ等)</li><li>先輩が後輩にソースコードを見てアドバイスする経験を得られる</li></ul> また、レビューする視点だと間違ったことは言えないのでしっかり調べたり、 人にFBすることで自戒することにもなるのでかなり勉強になります。 <h3 id="h5c25173b95">3.最終チェックを行う人の負担を減らせる</h3>単純に開発者同士でレビューを挟むことでクオリティが上がるので、最終チェック時の戻りが減ります。 また、過去に指摘された内容を開発者同士で共有することで、同じ指摘を防ぐことなどもできます。 <h2 id="h6418494177"> 相互レビューの効果をより上げるために実践していること</h2> <h3 id="h5c073b1878">1. レビューで指摘された（した）内容を全てTipsとして共有する</h3>毎案件終わる度にNotionにTipsとしてナレッジを蓄積しています。 内容としては以下のようなものです。<ul><li>レビュワー視点で学んだとこ</li><li>レビュイー視点で学んだとこ</li><li>お互いの指摘事項</li><li>お互いが見落としてしまったこと</li><li>ソースコードで議論したこと</li></ul> <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=""> 誰でも見れる場所にナレッジとして蓄積することで同じ悩みを解決したり、同じ指摘を受ける確率を減らせればと思っています。 <h3 id="h02c9839586">2. 良いコードを褒める</h3>人は誰しも褒められるとやる気が上がる（？）と思います。（少なくとも自分は） ですので、良いコードを見つけたときは「この書き方めちゃめちゃ良いですね！次から真似します」といった具合にコメントをするように心がけています。 お互いに指摘し合うだけではなく、議論したり、良い部分は褒め合ったりしながら開発していくことで仕事が楽しくなります。 <h2 id="ha214098e44">まとめ</h2>相互レビューはさまざまなメリットがありますが、開発者同士の協力が必要なため互いのスケジュールが合わない場合もあります。 そのため作業がスタックしないようにタスクや進捗の管理には気をつけていきたいです。

カテゴリー

人気記事

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

5年目エンジニアが今考えていること

Webサイトのチェック体制について、一部をご紹介

成長し続けるための「成果報告会」について

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

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

Author

飛田／フロントエンドエンジニア

関連記事

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

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

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

5年目エンジニアが今考えていること

Webサイトのチェック体制について、一部をご紹介

成長し続けるための「成果報告会」について

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