こんにちは、フロントエンドチームの深堀です。 普段はフロントエンドエンジニアとして、クライアントサイトのコーディングを担当しています。
ありがたいことに私たちは、生成した成果物に対してクライアントから高い評価をいただくことが増えてきています。その背景には、フロントエンド実装においてプロジェクトの過程で様々な課題や不測の調整事項に直面する中、私たちなりに明確に工夫した点があったからであると捉えています。
今回は、高い評価をいただくことができている背景について、私の視点からまとめます。
課題量の多いフロントエンドだからこそ人数に頼らない仕組み化を
フロントエンドとは、Webサイトやアプリにおいてユーザーが実際に操作して様々なサービスなどを体感する部分のことを示します。
Webサイト制作の実際の現場では、企画者が様々な背景から組み立てた内容をもとに、要件定義や設計、デザインなどの工程を経て、フロントエンドで実装することになります。つまり、様々なプロセスでディスカッションを経た「要望」が、フロントエンドで実装することでWebサイトとして「具現化」されるのです。
しかし、だからこそ多くの調整事項が発生することも多いです。特にコーディングボリュームの多い案件では、どうしても作業量が膨大になり、スムーズに進めることができないことが多くあるのが事実です。
このような時、従来は手を動かすフロントエンドエンジニアの人員を追加することが検討されがちでした。ただ私たちは、人員追加ではなく仕組み化でコーディングボリュームの多い案件をクリアする方法があるのではと考えました。
そして実際に、高品質を保ちながらプロジェクトを円滑に進めることができたのです。
仕組み化ができていない状況の場合、人数を増やすことで解決できる課題はあるかもしれませんが、仕組み化を避けてしまっては本質的な解決策とは言えないと考えています。
ここからは、具体的にどのように仕組み化したのか、その管理方法やエスカレーション方法、ルール策定についてまとめていきます。
プロジェクトにおける仕組み化の事例
まずは、私が直面した「コーディングボリュームの多い案件」の内容について整理していきます。
そのプロジェクトはクライアントサイトの制作で、サイト規模からも大きなプロジェクトであり、複数社が参加していました。ノヴィータではコーディング業務を担っていました。
ただ、デザイン担当、開発担当、コーディング担当（ノヴィータ）というように、担当によってすべて異なる会社が携わっていたのです。こうなると、コミュニケーションコストは必然的に高まり、プロジェクト進行の難易度が上がるのは明らかです。
実際にプロジェクトの過程では、途中で別の範囲を担当していた会社が変わってしまうなど、変動要素が少なくありませんでした。
この状況から、当プロジェクトは流動性が高いと判断しました。そこで、フロントエンドエンジニアのリーダーが定例の会議に積極的に参加して状況把握することにしたのです。
クライアントやデザイン担当、開発担当など様々なメンバーが参加する会議体において、随時コーディングに関わる部分の責任分界点の切り分けをし、責任の所在がどこにあるのかを常に把握できるよう整理していきました。
その中で「案件全体管理シート」や「課題管理シート」を作成し、会議に参加して判断するリーダーと、実際に作業をするフロントエンドエンジニアとが共同作業でシートを更新するようにしたのです。HTML仕様の要点定義は、ファイル仕様やブレイクポイントなど、一通り実施しました。
こうした仕組み化を通じて責任の所在を常に明確にしたことにより、プロジェクトを円滑に進めることができたのです。
他にも、構築するコンポーネント（要素）が100個を超える状況だったこともあり、自発的にデザイン担当側へ依頼しナンバリング管理を導入しました。HTMLコンポーネントのナンバリング管理を記載した管理シートを作って実装ステータスをプロジェクトメンバーに共有したことで、関係者の状況把握がスムーズになりました。
フロントエンドエンジニア観点で取り組んだこと
次に、フロントエンドエンジニアの作業観点で取り組んだことについてまとめます。
まずは大前提となる、コーディングガイドラインの遵守です。ガイドラインを守れていなかったら元も子もありません。ガイドラインを遵守するよう、ともに作業にあたる自社のチーム内で確認する時間を定例で設けました。
その上で、ピクセルパーフェクトに近い成果物を提出するために、ブラウザの拡張機能(※)を使用して機械的なデザインチェックを導入しました。
また、デザイン変更が度々起こる中で、反映漏れをフロントエンド側で防ぐために、新旧コンポーネントのデザインデータを一つひとつ比較確認することも忘れないようにしました。
その過程で、万が一デザイン作成時点で考慮しきれていない点や、挙動仕様に関する疑問点などがあれば、社内用の課題管理表（スプレッドシート）に起票し、リーダーへ共有するように徹底しました。
その際にリーダーが管理しやすいよう、コンポーネント管理シートをスピード重視で細かくステータス共有し、進捗把握しやすくすることで修正漏れの予防に努めています。具体的には、「デザイン未確定だけど仮にて制作」「デザイン変更前に制作済みだが新デザイン未反映」「新デザインで制作済み」など状況に焦点を当てて詳細にステータス管理をしました。これにより、デザインの変更が頻繁な状況においても、業務進行を大幅に改善することができたのです。
まとめ
私たちは、クライアントをはじめ、プロジェクトに参加していた他の企業との間では、認識齟齬が少ない状態で精度の高い納品物を提出することができました。その理由は、管理方法とエスカレーション方法、ルール策定などを徹底したからであると考えています。
以前までの私たちは、依頼内容に変更が多くボリュームも膨大なコーディング業務に対し、取り急ぎの解決手段としてフロントエンドエンジニアの人数を追加する方法を取っていたかもしれません。しかし今回、人員増加ではなく仕組み化によって解決できたことは、今後の業務をさらに洗練させていく上では、私たちにとって大きな成功体験でした。
※参考
使用したブラウザ拡張機能：
https://chrome.google.com/webstore/detail/perfectpixel-by-welldonec/dkaagdgjmgdmbnecmcefdhjekcoceebi
ノヴィータのサービスにご興味がございましたらお問い合わせください！
コーポレートサイトもぜひご覧ください。
仲間を求めています！ 募集中の職種はこちらから（Wantedly）
