フロントエンドエンジニアとしての1年半の成長記録：コミュニケーションとプロジェクト推進

はじめに

フロントエンドエンジニアとして1年半働く中で振り返ると、技術スキルの向上以外にも、チーム内外とのコミュニケーションやプロジェクト推進において成長を実感しています。特に、開発現場での日々の課題に向き合う中で、単なる実装だけでなく、チームとしての効率的な開発の重要性を強く認識するようになりました。本記事では、具体的な取り組みと成果について共有させていただきます！

1. 効果的なコミュニケーション手法の確立

1.1 認識齟齬を防ぐための確認プロセス

エンジニアとして最も重要視したのが、相手との認識合わせです。プロジェクト初期段階での認識の違いが、後の大きな手戻りやスケジュール遅延につながる経験から、特に以下の点に注力しました。

• 依頼内容の理解度確認
  単に「はい、わかりました」で終わらせず、具体的な実装イメージを共有
• 解釈の明確化
  あいまいな表現を避け、具体的な数値や条件を明確化
• 実装前の合意形成
  実装手法の選択理由や想定される制約事項を事前に共有

具体例：ディレクターとのプロジェクトでの取り組み

新機能の実装依頼を受けた際、以下のようなプロセスを確立しました。
このプロセスは、機能改修や新規機能の実装時に効果を発揮しました。

1. 依頼内容のサマリーを作成
2. 理解した内容を箇条書きで整理
3. 実装方針の提案と確認
4. 認識齟齬がある場合の早期発見と修正

このプロセスにより、後工程での手戻りを大幅に削減することができ、プロジェクトの遅延リスクを最小限に抑えることができました。

↓確認した際のチャットの画像

1.2 非エンジニアとのコミュニケーション改善

技術的なバックグラウンドを持たないステークホルダーとのコミュニケーションでは、視覚的な要素を積極的に活用しました。特に、技術的な制約や実装の複雑さを説明する際に効果を発揮しました。

具体例：営業部門とのデザイン改修プロジェクト

• 現状と改修後の比較画像の作成
  Before/Afterを視覚的に示すことで、改修の価値を明確化
• 技術的な制約の図示化
  システムの制約や実装の複雑さを図解で説明

この取り組みにより、プロジェクトの進行速度が向上し、相互理解も深まりました。特に、技術的な課題を非エンジニアにも理解しやすい形で説明することで、スムーズな合意形成が可能になりました。

1.3 フロントエンドチームでの意見共有

チーム内でのコミュニケーションにおいては、以下の点を意識して改善を図りました。特に、技術的な議論や改善提案の際に効果を発揮しています。

• ロジカルな構成での意見提示
  問題点、原因分析、解決案を段階的に説明
• 背景情報の明確な説明
  なぜその改善が必要なのか、現状の課題は何かを具体的に共有
• 具体的な解決案の提示
  実装方法や想定される影響を含めた提案

2. プロジェクト推進とドキュメント整備

2.1 SEO施策の推進

「SEO強化による自然検索流入の増加」というミッションに対して、以下のような取り組みを行いました。既存の知見を活用しながら、自事業の特性に合わせた施策を展開することで、効率的な改善を実現しました。

1. 社内の別事業のSEOコンサル資料の分析と活用
   • 他事業での成功事例の研究：具体的な改善点と効果測定結果の分析
   • 既存の施策の応用検討：自事業への適用可能性の評価
2. 自事業への展開
   • チーム内勉強会の企画・実施：月1回のペースで知識共有セッションを実施
   • 具体的な改善施策の立案：技術面とビジネス面の両方を考慮した提案
   • 優先順位付けとロードマップの作成：短期・中期での実施計画の策定

↓実際に自事業への展開する際に使用したスプレッドシートのスクショ

2.2 フロントエンドルールの体系化

チームの開発効率向上のため、包括的なドキュメントを作成しました。特に、チーム内での作業の標準化と品質維持を重視しています。

主な整備項目

• PRを上げる際のルール
  レビュー効率を上げるためのガイドライン

• レビューについて
  レビュー漏れがないようにレビューする時間帯についてやslackの自動通知について

• ステージング確認ルール
  テスト環境での確認項目の明確化

• Feature-flags
  機能の段階的リリースのための運用ルール

• コーディングルール
  コードの品質維持のための規約

• 画像について
  画像の最適化(next/imageの使用方法)と管理のガイドライン

• リリース前の動作確認について
  チェックリストの整備

• sentryのエラーについて
  モニタリングと対応フローと曜日別の担当者の記載

• システム定例について
  定期的な確認事項と議事録の順番

  

成果

• チーム内での作業の再現性向上
  標準化された手順による品質の安定化
• コミュニケーションコストの削減
  共通認識の形成による議論の効率化

今後起こりうる成果

• 新規参画メンバーの立ち上がり時間短縮

2.3 障害対応とナレッジ共有

発生したバグに対して、以下のような取り組みを行いました。特に、同様の問題の再発防止と、チーム全体での知見の共有を重視しています。

1.原因特定と対応フローの確立

• エラーログの分析と原因の切り分け
• 影響範囲の特定と優先度の判断
• 対応手順の文書化(先輩が作成)

2,わかりやすい報告書の作成

• 問題の概要と技術的な詳細の整理
• 対応の経緯と選択した解決策の根拠
• 今後の改善点の提案

3,再発防止策の提案と実装

• システム的な対策の実装
• モニタリングの強化
• チーム内での知見の共有

↓実際にバグ対応した際のチャットでの報告

まとめ

1年半の経験を通じて、以下の点で特に成長を実感しています。

• 効果的なコミュニケーション手法の確立
  技術的な内容を、様々な立場の方々に分かりやすく伝えられるようになりました。
• プロジェクト推進力の向上
  チーム全体の効率化を考えながら、具体的な改善施策を提案・実行できるようになりました。
• ドキュメンテーションスキルの向上
  チームの知見を形式知化し、効率的な開発環境の整備に貢献できるようになりまし

これらの経験を活かしながら、今後も以下の点を意識して成長していきたいと考えています。

• より効率的なチームコミュニケーションの探求
• 技術力の向上とナレッジの共有
• チーム全体の生産性向上に貢献できる取り組みの推進

まだまだ成長途中のエンジニアですが、これからも周りの方々から学びながら、チームに価値を提供できるエンジニアを目指して頑張っていきます！