<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>「議事録」っていうと難しい気もしちゃいますが、要は「誰が見ても会議内容が分かる記録」なんですよね。 議事録を取ることで会議の理解度を深められたり、「相手に伝わりやすい文章」と「要約する力」を身につけられると思うので、私も引き続きがんばります。

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

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

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

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年目エンジニアが今考えていること

<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>

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

マネジメント

業務改善

仕事の気づき

テクノロジー

更新情報

伊藤

FLATでは、社内プロジェクトを立ち上げ、業務改善やコンテンツ作成を進めています。この取り組みが始まって半年以上が経過しましたが、企画と実行を分け、メンバーにタスクを依頼する形式よりも効果があると実感しています。 プロジェクトは四半期ごとに立ち上げられ、2〜3名の少人数チームで構成されます。各プロジェクトには責任者が一人立てられ、期の終わりにはクロージングが実施され、社内全体に向けて活動報告が行われます。 企画段階で決めるのは目的やゴール、アサインするメンバーだけで、それ以降はプロジェクトごとにキックオフを実施し、メンバー全員でマイルストーンの設定や具体的なアクションを作成します。進捗管理もプロジェクト内で完結し、四半期という限られた期間で結果を出すことを目指します。 このプロジェクト形式のメリットの一つは、少人数で構成されているため、メンバーが責任感と主体性を持ちやすい点です。企画側からタスクを振られるのとは異なり、プロジェクトメンバーが企画の背景や意図を理解した上で取り組むことができます。 もう一つのメリットは、期間が限られていることです。FLATは受託開発の会社であり、業務の主体であるクライアントワークと並行して期限のないタスクを進行し続けるためには、意識の改善と仕事の進め方や働き方の工夫が必要です。しかし、プロジェクト形式にすることで他のメンバーと期限を共有しマネジメントすることで、期限を守りやすい状態になったと思います。 FLATのような受託開発の会社において、クライアントワークと並行して業務改善やコンテンツ作成などの社内業務を進めるためには、社内プロジェクト形式が有効な手段の一つであると言えます。今後もしばらくはこの形式を継続してみたいですね。

プロジェクト形式で社内業務を進める

人は自分ひとりの力で強い意思を持ち続けることは難しい。「目標を他人に話すことで達成率が向上する」という話があるが、これを職場で実践してみたところ、想定以上の効果があった。 具体的には、当日の計画を社内の分報に投稿することで、「人に話したからにはやるしかない」という感覚が働き、仕事の優先度を意識し計画通りに進める確率が格段に向上した。 弊社は受託開発を行っており、クライアントワークの優先度が高く、社内業務が後回しにされがちな環境です。 私はエンジニアリングマネージャー（EM）として働いており、クライアントワークと社内マネジメントを効率的に並行して進める必要があります。このような状況では、計画をしっかり立て、それを遂行することが極めて重要です。 一般的に、クライアントワークに追われながら、期限が迫っていない社内業務を効率よくこなすことは容易ではありません。もちろん採用・事業計画やプロジェクトのマイルストーン、開発タスクなど、事前に計画を立てることでその期限は守られます。 しかし、組織やプロジェクト単位の計画だけでは、業務全体の効率化を最大限には引き出せません。その実現には個人単位の計画が必要です。 個人の能力やキャパシティは人それぞれ異なるため、一人ひとりが自分の仕事の効率化を図るためには、最終的に自分自身で計画を立てる必要があります。これを一人だけで遂行するには強い意志が必要となりますが、冒頭にも書いた通りそれが難しい場合が多いのも事実です。 そこで役立つのが、個人の計画を社内分報に投稿することで、他人の目に触れることによる「人に話したからにはやるしかない」という感覚を利用します。組織やプロジェクト単位の計画においても少なからずこの感覚は働いていると思っており、計画を複数人で共有することに意味があります。 この試みの要点はあくまで「人に話したからにはやるしかない」という感覚です。つまり、個人の計画を誰か特定の人に共有する必要はなく、オープンな社内プラットフォームに投稿するだけで効果を発揮します。その意味では社内分報は最適な場所であると言えるでしょう。 なにげなく始めた「社内分報に当日の計画を投稿する」ですが、現在では他のメンバーもが自発的に実践してくれています。おそらく彼らも自分と同様に効果を実感しているのでしょう。

「社内分報に当日の計画を投稿する」が仕事の効率を変えた

私は社内ではEMとして、プロジェクトではエンジニアとしてさまざまな人と関わってきましたが、報連相が不足してる人はいても、報連相が過剰な人は見たことがありません。 今回はなぜ報連相が不足するのか、報連相を身につけるためにとにかく報連相を実践してみようということについて話します。 <h2 id="h214c0dd677">なぜ報連相は不足するのか</h2>まずは報連相が不足している例をいくつか挙げてみます。 <ul><li>自身の責任領域を拡大解釈しており、必要な報告が不足していた</li><li>実装者同士のコミュニケーション（連絡）が不十分で、作業の重複や手戻りが発生した</li><li>複雑な実装仕様について相談せず一人で悩んだ上解決したが、それが要因で全体のスケジュールに遅延が発生した</li></ul> このように報連相が不足していると感じるタイミングと理由はさまざまですが、共通して言えるのは、実行者が責任者が報連相を受けたいタイミングと理由、報連相することによる効果としないことによるリスクを想定できていないということです。そしてたいていの場合、実行者本人は報連相が不足していることに気づいておらず、問題が発生する要因が報連相不足にあることを理解していません。 <h2 id="h922e43e391">優秀な人ほど報連相できる</h2>報連相というと例えば「新入社員が業務に慣れるまで必要なこと」というイメージがあるかもしれません。しかし実際には、仕事を円滑に進めるために日常的に必要なものであり、そのタイミングを見極める必要があります。 優秀な人はおそらく以下のような観点で報連相を行います。 <ul><li>自身の責任領域以上の内容だと判断し、責任者に事前に確認を取ってから仕事を進めた</li><li>他の実装者の開発内容や進捗を把握しており、作業の重複が起こる可能性を考慮してコミュニケーションを取った</li><li>スケジュールに余裕がないので、自身のスキル以上の実装仕様だと判断し、アサインの変更を相談した</li></ul> これらに共通しているのは、仕事の背景や他メンバーのことなど視座を高く持ち、適切なタイミングで報連相が必要かどうかの判断をしているということです。 逆にいうと視座が低くリスクを想定できないと、そもそも報連相が必要かもしれないという思考にすらならないということです。これが報連相が不足することの主な要因です。 <h2 id="h8a35e69c11">リモートワークの影響</h2>またリモートワークは報連相の頻度を減少させうると考えています。 弊社はオンラインコミュニケーションツールを積極的に導入していますが、それでもリアルコミュニケーションと比較するとコミュニケーションのハードルが上がります。 この少しの差が「他のメンバーの進捗を確認しづらい」「これくらいなら自分で進めても良いかな」という状態を生み出し、報連相が滞る要因になります。 <h2 id="h3c16560b74">報連相はとにかく実践してみること</h2> 報連相ができるようになるためには、とにかく報連相を実践することです。 「この状況ではこのように考えるんだ」「そういうリスクもあるのか」「そこまで先のことを見据えているのか」というように、今の自分にはない知識や考え方に触れることで報連相に必要な視座の高さが身についていきます。つまり報連相を実践するというのは自己成長する機会を自身で設けているということになり、反対に報連相をさぼると自己成長の機会を損失しているということになります。 リモートワークには報連相の頻度を減少させうる特性もあるので、最初は少し過剰に報連相してみる意識を持つと良いでしょう。

報連相の身につけ方

弊社では「技術習得基準」というエンジニアが有するべき技術の基準を設けています。 今回はその技術習得基準の内容と、基準を定めるに至った背景について紹介します。 <h2 id="h27520afb85">基準を定めるに至った背景</h2> 弊社は元々主にCMSサイトのコーディングやCMS組み込みを生業とするWeb制作受託会社でしたが、ここ2、3年で受託するサイトはより巨大で複雑になってきました。 また新たにアプリ開発受託として、Webサービスやネイティブアプリの新規構築、開発支援も行うようになりました。 弊社は現在業務委託メンバーも合わせて5名〜10名程度の少人数エンジニア組織であり、常にプロジェクトや要件に合わせた最適なアサインができるほどのリソースがあるわけでもなく、拡大する業務領域と求められる技術の高度化に対応しきれないプロジェクトが発生するようになりました。 少ない人数でも適切なアサインをするためには、今のフロントエンド開発の現場で必要なスキルを定義し、職務グレードに応じてそれを徐々に習得してもらう。そのようにして、ある程度どのメンバーがどの開発現場に入ってもパフォーマンスを発揮できる状態を作る必要があるなと考えました。 そこで新たに「技術習得基準」を設け、サイト制作とアプリ開発それぞれで職務グレードごとに必要なスキルセットを定義するようにしました。一応補足しておくと、これは決してエンジニアの個性を否定するものではありません。まずはエンジニアとして必ず必要な基礎領域を習得することが大切で、その基礎領域も年々拡大し高度化しているということです。弊社のエンジニアには基礎領域を習得した上で、各々興味があったり得意な技術を存分に伸ばしていってほしいと思っています。 <h2 id="hb74dffdce5">技術習得基準とは</h2> 弊社では技術習得基準として、このように職務グレードごとに習得すべきスキルを表にまとめています。 <img src="https://images.microcms-assets.io/assets/98f41c713ae240acbf11bfbf0993ea22/db5fcd95ceea445d86db27c0052c9379/%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%202024-02-22%2021.23.09.png" alt=""> そしてそれを身につけるためにおすすめの教材と、身につけたといえる基準も簡単に記載しています。参考までにReactの内容を添付します。 <img src="https://images.microcms-assets.io/assets/98f41c713ae240acbf11bfbf0993ea22/3d6f66f460c041ba93288ff8904f0fc5/%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%202024-02-22%2021.26.46.png" alt=""> 弊社には書籍購入制度もあるので、メンバーの多くはおすすめ教材に沿って学習を進めてくれています。 加えて1on1では、この技術習得基準をもとにメンバーの希望する働き方や仕事内容に合わせた学習計画を作ってあげています。 <h2 id="h1afe451c43">さいごに</h2> このように弊社には、やる気さえあれば成長できる環境が整っています。 他にもエンジニアにとって魅力的な制度をたくさん用意しているので、興味がある方は採用応募、もしくはカジュアル面談のご応募いただけると嬉しいです。

弊社の「技術習得基準」の紹介

弊社では2024年1月よりエンジニア全員に対してGitHub Copilot for Businessを支給しています。組織にCopilotを導入するためには、事前にセキュリティ上の懸念をクリアし、期待できる費用対効果を算出するなど、いくつかの事前準備が必要になります。 今回は弊社がCopilotを導入するにあたり実施したことを紹介します。 <h2 id="h134cca86dd">テスト導入期間</h2> まずは2ヶ月のテスト導入期間を設け、2名のエンジニアでCopilotを使用してみました。テスト導入期間の主な目的は以下の4つです。 <ul><li>Copilotを活用できる業務領域の定義</li><li>使用上の注意点を定義</li><li>期待できる費用対効果を数値として算出</li><li>上記3つの内容をメンバーに共有するためにドキュメント化</li></ul> テスト導入期間を経ることで、サイト制作からアプリ開発までおおよその業務領域でCopilotを活用できることがわかり、以下のように費用対効果を算出することができました。 そして使用上の注意点をドキュメントにまとめメンバーに共有することで、全員が一定の成果を出しやすい状態を作ることができました。 <img src="https://images.microcms-assets.io/assets/98f41c713ae240acbf11bfbf0993ea22/bf19c838b2be40b0b2e7dba9926bcaaa/github-copilot-cost.png" alt=""> <h2 id="h28dfd51d31">セキュリティ調査</h2> セキュリティ面に関しては別途調査を行いました。調査の結果、GitHub Copilot for Businessを使用してOrganization単位で設定を行うことで、セキュリティ上の懸念を最小限にする設定をメンバー全員に共有できることがわかりました。 メンバーにはセキュリティ上の安全性も理解した上でCopilotを使用して欲しかったので、こちらもドキュメントにまとめて共有しています。 Copilotのセキュリティの懸念については、<a href="https://zenn.dev/miyajan/scraps/3567cee380280c" target="_blank" rel="noopener noreferrer">こちら</a>の記事が非常に参考になります。 <h2 id="h3b2fc9e234">本導入開始</h2> 最後に、セキュリティの安全性と期待できる費用対効果を会社に報告し、作成したドキュメントを読んでもらったメンバーから順次Copilotの使用を開始しました。 <h2 id="ha214098e44">まとめ</h2> 今回の結果を踏まえると、開発効率を向上させる施策としてCopilotの導入は非常に有効だと考えられます。 もしまだCopilotを導入していない方がいれば、よかったら今回の内容を参考に導入を検討してみてください。 今後もAIの進化は止まらないので、弊社ではAIを積極的に活用し、時代にあった開発手法、そしてエンジニア組織を目指していきたいです。

GitHub Copilotの導入経緯の紹介

弊社はWebサービスのフロントエンド受託開発を行なっており、その中で日々、ディレクター、デザイナー、バックエンドエンジニアなど、さまざまな職能との協業が欠かせません。 さまざまな職能と協業する以上、ディレクションと開発、デザインと実装、フロントエンドとバックエンドといった境界が発生しますが、その境界、つまり職域や役割を超えた行動をできるとプロジェクトは成功しやすいです。 私はクライアントさまの開発チームにフロントエンドエンジニアとして参画していますが、プロジェクトマネジメントに改善の余地があればツールの導入やワークフローの変更を提案したり、UXや実装の観点から画面仕様やデザインにフィードバックすることもあります。またサーバーサイド開発の動向を把握し、APIの仕様に関する提案をすることもあります。 弊社のようなフロントエンド受託開発において、境界の向こう側は社外であることがほとんどです。その境界を超えることに抵抗が伴うこともありますが、FLATではエンジニアが常にプロジェクトを前進させる姿勢を持ち、クライアントさまや協業会社さまと併走できるエンジニア、エンジニア組織を目指していきます。

職域を超えた行動をできるエンジニアを目指す

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

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

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

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

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

カテゴリー

人気記事

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

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

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

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

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

伊藤の日報一覧

伊藤

プロジェクト形式で社内業務を進める

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

「社内分報に当日の計画を投稿する」が仕事の効率を変えた

報連相の身につけ方

弊社の「技術習得基準」の紹介

GitHub Copilotの導入経緯の紹介

職域を超えた行動をできるエンジニアを目指す

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

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

技術雑談会を始めました

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

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

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

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

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