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

今まで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キーで閉じる」に加え、展開メニュー時はフォーカスをメニュー内に閉じ込め、展開メニューの最後の項目まで到達後は「閉じる」ボタンにフォーカスさせるのが一番良さそう。

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

マネジメント

業務改善

仕事の気づき

テクノロジー

更新情報

MTG DAY

仕事の気づきに関する記事です。

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年がたったので振り返り

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

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

FLATのディレクターの西條です。 FLATにディレクターとして入社して２ヶ月が経過しました。 これまでもディレクションや実装経験の経験はあったのですが、 以前は職域が曖昧だったため、これを機に改めてWebディレクターの仕事内容や役割について考えてみようと思いました。<h2 id="h63e66fc1de">Webディレクターの仕事内容</h2>前提としてWebディレクターの定義から。 「Webディレクターとは」で検索すると大体は、<blockquote>Webサイトの企画立案や制作、運用における責任者の立場です。 Webエンジニア、Webデザイナー、ライター、SEO担当者といったWeb 制作に関わる人たちをまとめ、進行や品質に問題ないかチェックし、プロジェクトが円滑に進むように調整して、チームで目標の達成を目指します。 引用元：<a href="https://type.career-agent.jp/knowhow/it_web/web_director.html#:~:text=Web%E3%83%87%E3%82%A3%E3%83%AC%E3%82%AF%E3%82%BF%E3%83%BC%E3%81%AF%E3%80%81Web%E3%82%B5%E3%82%A4%E3%83%88,%E3%81%AE%E9%81%94%E6%88%90%E3%82%92%E7%9B%AE%E6%8C%87%E3%81%97%E3%81%BE%E3%81%99%E3%80%82" target="_blank" rel="noopener noreferrer">転職ならtype転職エージェント</a></blockquote> <blockquote>Webディレクターとは、Webサイト制作における指揮、進行管理を担う職種です。 クライアントの目的にかなったWebサイトを制作するため、デザインやコーディングなど直接コンテンツ制作に関わるクリエイターやプロジェクトメンバーをまとめ上げ、プロジェクトを円滑に進める舵取り役といった立場であると言えます。 引用元：<a href="https://mynavi-creator.jp/blog/article/value-of-web-director#:~:text=Web%E3%83%87%E3%82%A3%E3%83%AC%E3%82%AF%E3%82%BF%E3%83%BC%E3%81%A8%E3%81%AF%E3%80%81Web,%E3%81%A7%E3%81%82%E3%82%8B%E3%81%A8%E8%A8%80%E3%81%88%E3%81%BE%E3%81%99%E3%80%82" target="_blank" rel="noopener noreferrer">マイナビクリエイター</a></blockquote>上記のような内容がヒットしますね。 会社さんにもよると思いますが、私も一般的なWebディレクターの定義としては「プロジェクトを円滑に進めるための舵取り役」になってくるのかなと思ってます。<h3 id="h7c8aec2b34">具体的なWebディレクターの仕事内容は？</h3>その上で、仕事内容を掘り下げていきますが、 今までの経験や周りのディレクターの仕事内容を踏まえると、代表的な仕事内容は以下になるのかなと思ってます。<ul><li>ヒアリング</li><li>企画・提案</li><li>予算管理</li><li>スケジュール/進行管理</li><li>サイト設計/ワイヤーフレーム作成</li><li>デザインディレクション（デザイン要望のヒアリング + デザイナーへの落とし込み）</li><li>実装ディレクション（エンジニアとのコミュニケーションや、サイトの品質チェックなど）</li><li>アフターフォロー（納品後のサポート）</li></ul>サイトの性質によっては、マーケターやライター、動画クリエイター、カメラマンなどをアサインする場合やシステムが絡んでくる場合もあるため、ディレクターが手を動かすケースはあまりないと思いますが、知識は必要になってくると思ってます。<h2 id="hfe6a713503">Webディレクターの役割とは？</h2>色々仕事内容を書いてはきましたが、 結局はそのどれもが「プロジェクトを成功に導く」ためにあるものと私は捉えるようにしています。 ワイヤーや提案書を作成するのが最終目的でなく、 プロジェクトを良い形で完了させること、プロジェクトを成功に導くのがWebディレクターの本質的な役割だと思っています。 成功に導くと書くとキラキラして見えてしまいますが、 進行中に問題が起こりそうになる場合もよくあり、そういった際に泥臭く奔走する必要もWebディレクターには求められると思います。<h2 id="ha214098e44">まとめ</h2>Webディレクターの仕事内容について改めて考えてみました。 ただ会社さんによって差はあると思うので、<ul><li>クリエイティブの比率高め</li><li>マーケティングの比率高め</li><li>セールスの比率高め</li><li>システムの比率高め</li></ul>などのケースもあると思います。 ちなみにFLATでは実装のディレクションはエンジニア自らが行うという文化があります。 また、エンジニア全員「フロントエンド」という共通項目こそあるものの、得意な領域はそれぞれ伸ばしていっている感じがあるため、難易度の高めの案件でも対応できるケースが多く、ディレクターとしては非常に助かってます。 入社して2ヶ月、ディレクターとして総合力をつけていくのは当然のこと、私もどこかに専門性をつけるのが今後の目標となりました。

Webディレクターの仕事内容について改めて考えてみた

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

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

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

ディレクター力

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

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

例えば、「詳細ページへ進む際に押す矢印ボタン」を実装する際、 今まではアイコンを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のアクセスログって取れますか？利用者のアクセス集中時間帯を把握してマーケティングに活かしたくて…。 二個目の例だと、ディレクター→エンジニアのパターンが多いと思いますが、 自分が思ったものより、正確な情報(実は他の集計方法が効率が良いなど)をくれたりするので背景を伝えるのは大事だなと思います。こんな感じでしょうか…テキストコミュニケーションって難しいな、というか工夫できる点がまだあるかも？と思う毎日です。 今後も精進していきます。みなさまも、もし意識しているポイントがあれば教えてください。

カテゴリー

人気記事

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

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

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

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

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

MTG DAY

Author

佐久間／フロントエンドエンジニア

関連記事

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

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

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

Webディレクターの仕事内容について改めて考えてみた

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

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

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

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

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

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