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

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

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

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

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

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

<p>受託でWebサイトを制作する際、クライアントからフィードバックを得ることは、よりクオリティの高い成果物を生み出すために必要不可欠です。<br>このフィードバックを通じて、クライアントの要望より深く理解し、より良いWebサイトを制作することができます。<br><br>まず、FLATのWebサイト制作フローでは、案件初期からクライアントとの密なコミュニケーションを心掛けています。<br>制作スケジュールは通常、2〜3回に分けてページを制作し、各段階でクライアントに提出します。<br>これにより、早い段階での軌道修正が可能となり、最終的な納品物のクオリティを高めることができます。<br><br>クライアントからのフィードバックは、プロジェクトの進行中に複数回にわたって共有されます。<br>初回のWebページ提出では確認すべき部分が多いため、クライアントからのフィードバックも自然と多くなりがちです。<br>これらのフィードバックには、Webサイトの見せ方の調整、ブレイクポイントやホバーアニメーションの調整、UIの改善など、様々な内容が含まれます。<br>特に、Webサイトとしてブラウザに反映された際の見た目や動きに関するフィードバックは重要です。<br>クライアントがどのような視点でサイトを見ているのか、どのような形での制作を希望しているのかを把握することで、具体的なイメージが作り出されます。<br>これにより、事前のキックオフミーティングでのクライアントの要望を超えた、より詳細で具体的な要求を反映することが可能となります。<br><br>このフィードバックの期間は、次の制作フェーズへの準備期間でもあり、多くの有用な情報が得られるので、この期間が非常に楽しみでもあります。<br>また、早めにフィードバックを確認し対応することで、制作の手戻りを減らすことができ、案件全体の効率も向上します。<br><br>結論として、Webサイト制作においてクライアントからのフィードバックを得ることは、ただの一過性の確認作業ではなく、案件の成功を左右する重要な過程です。<br>このフィードバックを通じて、クライアントとの良好な関係を築き、よりクオリティの高い成果を出すための貴重な機会であると考えています。<br>そのため、クライアントからのフィードバックは積極的に求め、真摯に受け止めることが大切です。</p>

Webサイト制作における「クライアントからのフィードバック」の重要性について

マネジメント

業務改善

仕事の気づき

テクノロジー

更新情報

飛田

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

カテゴリー

人気記事

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

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

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

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

Webサイト制作における「クライアントからのフィードバック」の重要性について

飛田の日報一覧

飛田

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

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

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

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

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

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

実装者から見たデザイン

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

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

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

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

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

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

Webサイト制作における「クライアントからのフィードバック」の重要性について