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

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

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

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

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

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

Twitterでリンクシェア時、URLに日本語が含まれていると、日本語部分をURLだと認識してくれず、URLが正しくシェアされないことが分かった。 そのため、例えば<pre><code>&lt;https://sample.jp/ブログ/今日のできごと&gt;</code></pre>というURLをTwitterでシェアしようとすると、<pre><code>「https://sample.jp/
ブログ/今日のできごと」</code></pre>という表示になり、自動リンクが途切れてしまう。 これを解消するためには、日本語をエンコードしてURLを認識できる形式に書き換える必要がある。 shopifyだと、Liquidで予め文字エンコードをしてくれるフィルターが用意されていたため、簡単にシェアできるURLに変換することができた。 ただ、シェアボタンを自作する場合はJavaScriptを使用してリンクを生成する必要がありそう。 特に運用上、クライアントが日本語スラッグを入力しそうな場合は特に気をつけたい。

shopify・Twitterのリンクシェア時のポイント

マネジメント

業務改善

仕事の気づき

テクノロジー

更新情報

伊藤

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

人は自分ひとりの力で強い意思を持ち続けることは難しい。「目標を他人に話すことで達成率が向上する」という話があるが、これを職場で実践してみたところ、想定以上の効果があった。 具体的には、当日の計画を社内の分報に投稿することで、「人に話したからにはやるしかない」という感覚が働き、仕事の優先度を意識し計画通りに進める確率が格段に向上した。 弊社は受託開発を行っており、クライアントワークの優先度が高く、社内業務が後回しにされがちな環境です。 私はエンジニアリングマネージャー（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では新たに技術雑談会という試みを始めました。 誰か1人がテーマを決め、それに興味のあるメンバーが有志で集まり、お互いの気になることについて意見交換をしたり、不明点を解消する場になっています。開催も不定期で業務時間外に行なっているので、オフィスでお酒を飲みながらゆる〜く開催しています。 直近では、<a href="https://react.dev/learn" target="_blank" rel="noopener noreferrer">Learn React</a>を題材として技術雑談会を行いました。ドキュメントの読み方や理解度は人によって様々なので、同じドキュメントを読んでいても、そこから得られることは大きく異なります。 社内では最近、公式ドキュメントを参照することの重要性を伝えています。「自分では気づかなかったことに気づくことができた」「ドキュメントを参照すれば解決するんだな」という体験を提供することで、ドキュメントを参照する習慣が身に付いたら嬉しいなと思っています。 エンジニアには継続的な学習が必要です。1人で黙々と学習するくらいなら、同じ興味を持つ人たちで集まり、お互いのスキルやモチベーションを高めあう関係を築くことで、より効率的により楽しく学習をしてほしいという想いがあります。 FLATはフロントエンドの会社ですが、メンバーの興味領域は様々です。エンジニアを積極採用中なので、技術共有に前のめりな方のご応募をお待ちしております。

カテゴリー

人気記事

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

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

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

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

shopify・Twitterのリンクシェア時のポイント

伊藤の日報一覧

伊藤

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

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

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

報連相の身につけ方

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

GitHub Copilotの導入経緯の紹介

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

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

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

技術雑談会を始めました

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

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

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

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

shopify・Twitterのリンクシェア時のポイント