フロントエンドエンジニアはWordPressまで実装すべき

私は今年の最初の方の日報で「フロントエンドエンジニアはモックからWordPressまで一貫して実装できた方がよい」と書いた(「エンジニアがモックからWordPress実装まで一貫して行うことの必要性」)。以前まではWordPress(以下、WP)実装の一部しか担当していなかったが、最近のプロジェクトでモック作成からWP実装まで全体を通してコーディングする機会があったので改めて「一貫して実装すること」のメリットとデメリットをまとめた。

メリット

工数を削減できる

フロントエンドがモックからWP実装まで一貫してやりきることで得られる最大のメリットはなんといっても工数を減らせることだ。従来まではモック作成はフロントエンドが、WP実装はバックエンドが担当、というふうに分業制を取っていた。バックエンドエンジニアはフロントに比べてHTMLとCSSの知識がそこまで豊富ではないため、WPの実装的には「このようにした方がいい」という理想があってもモックを変更するより、PHP側でなんとか結果が同じになるように実装することが多かった。一方でフロントエンドが一貫して実装すれば簡単にモックを変更できるので、PHPで工夫を凝らした実装をしてコードが複雑になるのを避けられるし、無駄に工数を浪費することも防ぐことができる。

WPのカスタマイズ性が上がる

フロントエンドが一貫して実装することは開発面だけではなくWPの管理画面におけるカスタマイズ性にもプラスだ。例えば本文エリア内で2カラムレイアウトにするとき、従来はカスタムフィールドで別に区切るしかなかったが、モック側を変更することで本文エリア内にテーブルを設置する形で対応することができる。ユーザーにとっても実際のページと編集画面のレイアウトは似ていた方が使いやすいはずだ。このように開発面だけに留まらずユーザーにもメリットがある。

仕様を伝える手間が省ける

WP実装で別のエンジニアに引き継ぐ場合、多かれ少なかれモックにコメントを残したり口頭で説明するなど仕様を伝えるのに時間を割くことになるはずだ。一人のエンジニアが一貫して実装すればコードに対してそこまで詳細にコメントを書かなくてもいいし、引き継ぎにかける時間を省略できる。また、引き継ぎによって発生する仕様の勘違いや伝え漏れも防げるようになるはずだ。

デメリット

スケジュール管理が雑だと工数が延びる

一人ですべての実装を担当するので、「モックの実装はここまで」「ここからはWP実装」というように時間管理を徹底しないといつの間にかトータルの工数が分業の場合より増える可能性がある。モックでもう少し実装に時間がかかりそうだからWP実装の時間を割り当てよう、とか曖昧な管理をやっていると終盤の実装は着実に厳しくなっていくだろう。より自分自身のスケジュールを管理する能力が求められる。

仕様のミスに気づくのが遅くなる

WP実装に入るときに別のエンジニアに引き継ぐわけではないため、本来その段階で気づけたはずのミスに気づけない可能性がある。例えば仕様を勘違いしてモックを作成し、その解釈のままWP実装もしてしまった、などだ。分業に伴う引き継ぎ時のミスや漏れを防げる一方でブラックボックス化してしまう可能性も孕んでいる。すべてとまでは言わないが、大規模実装に入る前に第三者と仕様を改めて確認するなどして未然に防ぐようにすべきだ。

一貫して実装した方が効率が良い

デメリットに挙げたものは対策すればどうとでもなるものがほとんどだ。一方でメリットに目を向けてみると開発面でもコーディングが楽になり、工数を削減することができるし、さらには利用者にとってもフレンドリーな完成度の高いサイトを作ることに繋がるはずだ。よほど大規模でない限りはモックとWP実装で分業せずにフロントエンドが一貫して実装するのが良いだろう。

そして、こういった従来のやり方を変えていき、最終的に完成させたいのは二重に作業が発生しない無駄を抑えたコーディングの進め方だ。現状は「モック作成はここまで」「ここからWP実装」というように完全分割しているが、これがベストな方法とも限らない。そもそも最終的にデータ反映を止めて切り捨ててしまうモックをそこまで作り込んでも意味はない。明確に実装期間を区切るのではなく同時並行して進めてみるのはどうだろうか。今後も決まった進め方に固執せず、試せることがあればどんどん試してより良い仕事の進め方を模索していきたい。