開発は一人でやらない限り、ある程度の実装手段のブレは許容すべきだ。というより、完璧に統一するのは不可能である。
きっちり揃えてほしい！でもそれは“こだわり”とも取れる
私が去年担当したベイジのコーポレートサイトのリニューアルは、結果的にいろんなエンジニアが参加して書いたコードがごちゃまぜになった状態で「これは困る！」というほどの違いはないものの表記の揺れだったり、実行順序とかそういう細かいレベルで言うとかなり違いがある。
私は元来、性格的にこういうのが気になるのだが、その性格に従って自分好みの表記に統一するのは実装を分担して手伝ってもらう意味がないし、無駄な工数だ（というか、フォーマットの統一はprettierなりを使えということである）。なので、そういう風に言い聞かせて何もしないことにしている。
実害、そして膨らむ工数
とはいえ、中には統一されてないことで実害が出るような実装もある。例えば、本来インクルードを用いた共通化が行われているべき箇所が直書きされていて「見た目は同じなのに個別化された実装」になっていると、後の改修で何箇所にも同じ改修を施さねばならなくなり、工数が多く必要になる。
解決するには？
こういった場合は、判明した時点でそこは共通化すべきだ。これは無駄な工数ではない。それでは、そもそも複数人で分担して開発してなるべくブレが出ないようにするには、どうすればよいか。私は「事前の準備」と「思想の浸透」が重要だと考えている。
事前の準備
「事前の準備」はどちらかというと実務的で、先程の例で言えば、インクルードファイルを使える状態に準備しておいて「それを使ってね」と伝えることと具体的な参照方法や呼び出し方を例示する。他のエンジニアが参加する前に開発準備を整えておくことだ。これに限らず、エンジニアがJOINする時点で開発に関する情報をしっかり時間をとってコードを見ながら共有することが大事だ。
思想の浸透
一方で「思想の浸透」はそのプロジェクトに限らず常日頃から開発に関する思想を統一する活動をしておくということだ。（なんだか危なっかしい表現になってしまった）
これはたとえば、以下のようなものが挙げられる。
- 設計思想
- ディレクトリ構成
- 命名ルール
こういった議論はプロジェクト開始前に時間をとってエンジニアで煮詰めたり、チーム全体でコーディングガイドラインを作る・見直す機会を定期的に設けて話し合うといった活動が有効的だろう。
あるいは、すべてのプロジェクトに導入できるような共通の初期テンプレートを作るというのも良いだろう。実際に私たちのチームでは、WordPressのウェブサイト案件においてはフォーマットとなるテーマファイルを構築し、運用している。これによって設計方法、ディレクトリ構成、その他あらゆるコーディングにおいて一定レベルで共通化された。
こうすることで例えば突然そのプロジェクトにJOINすることになったエンジニアも、情報インプットの時間をほぼ必要とせずシームレスに開発に参加することができるようになった。また、担当していたエンジニアが急遽プロジェクトから外れることになっても、大きな混乱を引き起こすことなく別のエンジニアに引き継ぐこともできるだろう。
おわりに
最近のベイジでは複数人で開発する案件が増えてきている。開発以外のところに時間を割く活動ではあるが、これらの準備をしておくことでプロジェクトのトータルの工数は削減できるはずなので、自戒も込めつつ、ここにまとめたことを実施していきたい。
