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に入社して初めて「相互レビュー」を導入した際に感じたメリットやより効果を上げるために実践してみたことを書いてみます。 <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>相互レビューはさまざまなメリットがありますが、開発者同士の協力が必要なため互いのスケジュールが合わない場合もあります。 そのため作業がスタックしないようにタスクや進捗の管理には気をつけていきたいです。

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

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

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

<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="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では、リモート勤務の日にはバーチャルオフィス「ovice」を積極的に活用しています。 最初はバーチャルオフィスを利用する経験がなく、どれほど活用できるか不安でしたが、使い始めると非常に便利だと感じています。 以下に、いくつかの便利な活用方法をまとめました。 気軽なコミュニケーション リモートで仕事をしていると、相手の状況がわからず声をかけにくいことがあるかと思います。 しかし、oviceを使用すると誰がその場にいるか一目で分かり、気軽に話しかけやすいです。 もくもくスペースとしての活用 受託業務の性質上、忙しい時期が発生します。その際、oviceで通話を維持しながら作業を進めるという使い方です。 限られた時間の中で、円滑な情報共有ができたり、焦りからくる不安感、孤独感も和らぐように感じます。 季節を感じて会話をする oviceでは背景を変えたり、物体を置いたりとカスタマイズが可能です。 FLATでは、季節に応じてオブジェクトが配置したり(先日はクリスマスツリーが設置されていました)、 BGMを季節に合わせたものに変えたりしています。 これにより、もう〇〇の季節ですね、だったりオフィスが素敵になっている！といった雑談が発生します。 一緒に働く仲間とこういったコミュニケーションを取れるのは楽しいなと思います。 こうした活用方法により、「場所は離れていても同じ場所で過ごしている」という感覚を得ることができ、バーチャルオフィスが非常に便利だと感じました。

バーチャルオフィスの活用

受託制作の案件に携わっている中で、さまざまな関係者とのコミュニケーションが欠かせません。 最近のプロジェクトでは、クライアントのディレクターの方の進め方が素敵だと思いました。具体的には、以下の点が特に印象的でした。<ul><li>情報の連携が端的で整理され、資料の場所やスケジュール、納品の流れなどがわかりやすい。</li><li>こちらが待機状態の際、情報共有のタイミングが最適。</li><li>質問への回答が明確かつ理解しやすく、また、先を見据えつつ「〜な可能性はありそうです」といった温度感を連携くださる。</li></ul>全体を通して感じるのは、次の能力が優れているのではないかと感じました。<ul><li>文章や情報を明快に整理する能力</li><li>先のスケジュールや関連書類の動向を把握し、的確な行動ができる能力</li><li>メンバーの動きや次のアクションを把握し、円滑な進行に寄与する能力</li></ul>これらの能力をより磨いて、案件においても円滑な進行が期待できるようになりたいと感じました。 生き抜く上で重要なスキルを身につけ、プロジェクトにおいてもより価値ある存在になりたいと考えています。

ディレクター力

特定の曜日にMTGが密集することがあり、結果的にMTG DAYになっている日があります。 ４つほど連続でMTGとなるので若干疲れますが、MTGと作業を行ったり来たりしなくて良いのは効率いいなと思います。 もちろんお客様やメンバーの予定次第ではありますが、自由に日程を決めて良い時はスイッチングコスト踏まえてMTG設定していきたいです。

MTG DAY

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

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

今まで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のリポジトリにはスターをつけたほうがいいかもという話

例えば、「詳細ページへ進む際に押す矢印ボタン」を実装する際、 今まではアイコンを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等でもこのようなスクリーンリーダー用のクラスが用意されていることを知りました。 他のエンジニアの方の実装やライブラリのクラスなどを拝見してスキルを身につけていきたいと思いました。

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

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

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

今日はスポット案件の見積もりを行いました。 このスポット案件ではスライダーの作成が求められていたのですが、ちょうど前の担当案件でスライダーにチャレンジさせていただいた経験がありました。 そのため、実装イメージを思い浮かべながら見積もりを進めることができました。 チャレンジしてうまくいけば自信になりますし、最近はこの「小さなチャレンジ」がとても大切だと思っています。 興味のある分野の仕事をさせていただいていることもありますが、質問しやすい環境や親身に相談に乗ってくださるメンバーの存在が大きいと思っています。 今後も「小さなチャレンジ」を重ねながら、自信を持てる分野を増やしていきたいです。

小さなチャレンジを続けていきたい

普段テキストコミュニケーションで意識していることを自戒を込めて整理してみます。<h2 id="h6eccbc0c8a">相手に何をして欲しいか明らかに書く</h2>相手がどのアクションを取れば良いか明確にして書いています。 基本業務で必要内容は、連絡、相談、依頼あたりでしょうか。 具体的に、以下のようにざっくりメッセージを受けた相手の行動は別れると思います。 連絡：内容の把握 相談、質問：相手の相談、相談内容を待つ、内容に対して自分の意見を言う 依頼(お願い)：何かしらアクションを取る必要がある　自分の意図したとおりに伝えるために、テキスト上に自分のメッセージがどれに該当するのか、明確に書くことを心がけています。 例）相談なのですが、〇〇案件の件で後ほどお話しさせてください。 例）連絡なのですが、〇〇案件の定例会の日時が変更になりました。 例）１点お願いさせていただきたいのですが、XXまでに都合の良い日時を教えてください。 <h2 id="h6112b706b2">極力相手がメッセージだけ見れば良い状態を整える</h2>相手に資料を探して参照してもらうのは、相手に負担をかけることにもつながるので、資料やスクショ、参考URLなどを渡すと良い気がします。 相手と資料自体の齟齬も生じかねないので、実際にものを渡してしまうのは有効だと思っています。 例）昨日の定例会で行っていた〇〇案件のアクション事項のXXってもう実施されました？(議事録URL添付、議事録スクショでもいいかも) 例）この実装を行うには、こちらの記事のようにXXXXを〇〇する必要がありそうです。(参考となりそうな記事のURL添付) <h2 id="h87d96c89d8">齟齬を減らすような工夫をする</h2>テキスト上ですと、齟齬が生じやすいのでスクショに赤枠をつけて渡すなどを積極的行うといいと思います。 社内で使わせていただいている、Gyazoというツールが大変便利です。<h2 id="h201c1e4736"> 目的や背景も併せて伝える</h2>相談などの意図がわかると、より正確なコミュニケーションがとれると思います。 例）〇〇ってXXの認識であっていますか？実はお客さんから問い合わせが来ていて、メールで回答しなくてはいけないんです。 例）少し依頼したいのですが、XXのアクセスログって取れますか？利用者のアクセス集中時間帯を把握してマーケティングに活かしたくて…。 二個目の例だと、ディレクター→エンジニアのパターンが多いと思いますが、 自分が思ったものより、正確な情報(実は他の集計方法が効率が良いなど)をくれたりするので背景を伝えるのは大事だなと思います。こんな感じでしょうか…テキストコミュニケーションって難しいな、というか工夫できる点がまだあるかも？と思う毎日です。 今後も精進していきます。みなさまも、もし意識しているポイントがあれば教えてください。

カテゴリー

人気記事

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

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

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

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

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

佐久間の日報一覧

佐久間

バーチャルオフィスの活用

ディレクター力

MTG DAY

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

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

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

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

小さなチャレンジを続けていきたい

テキストコミュニケーションで意識していること

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

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

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

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

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