複数人でコーディング！良かったこと・気を付けた方が良いことのまとめ

この記事は2023/03/31に作成されました。

最近の案件にて、HTML/CSS（SCSS）コーディングを私と後輩エンジニア/O.Hの2人で共同作業する機会がありました。
複数人でのコーディングは今回が私も初めてです。エンジニア/O.Hは入社から1年が経ちましたが、早くからこのような経験ができてラッキーだと思います。

今まで1人でやっていた作業を今回初めて複数人でやったものですから、当然良かったと思うこともあれば、ああしておけば良かったと思うこともあります。
今回の記事では私の視点はもちろん、一緒に作業したエンジニア/O.Hおよび、バックエンド制作を担当したプログラマー/N.Gとプログラマー/A.Aにも意見を聞いた結果をまとめました。

私個人の備忘録として、複数人でコーディングをする機会があるという方の先人の知恵としてこの記事を活用していただければ幸いです。

やって良かったこと4選

①モチベーションを保ったまま終われる

見出しの通りです。当然、1つの作業を複数人でやれば早く終わります。

特に今回取り組んだ案件はひとつのサイトに2つの大きなコンテンツがあり、共通レイアウトやパーツの流用を利かせにくく、その分ページ数も多かったです。

そのため、1人で作業していたらモチベーションを保てたかどうかも怪しく、実際に完了した2~3倍の作業時間はかかっていたのではと思います（私は飽きっぽい性格ゆえモチベーションが続かないと結構ペースダウンしがちです...）。

複数人でやると1人でやる範囲が狭くなるので、そのリスクも軽減します。

②得意・不得意分野があってもカバーしやすい

コーディングに限らず、複数人作業の最大のメリットと言えば、メンバーの得意・不得意をカバーできるところです。今回は特にこのメリットに助けられました。

私はCSSアニメーションなどを駆使した動作を作るのが苦手ですが、エンジニア/O.Hは得意です。複雑に動きそうな部分は彼女に任せ、その代わり私で全体のレイアウトを調整したり、ほとんどのページで使われるような共通のリストパーツなどを作成したり、先方との連絡・調整役を行うようにしました。

③メンバーのメソッドをこっそり参考・吸収できる

他メンバーの書いたソースを見てみると、自分では思いつかなかった効率の良い書き方やテクニックを覗き見することができます。

わざわざ声を掛けて機会を設けなくとも、自然と情報交換の機会が生まれるのです。
この機会を利用しないのはあまりに勿体ないので、他メンバーの書いたコードも積極的に目を通しておきたいものです。
万が一、誤った書き方をしていたらそれを正すチャンスもゲットでき、まさに一石二鳥でしょう。

逆に、変な書き方をしてると恥をかく可能性もあります。なので、普段から綺麗にかつ効率の良い書き方やテクニックを磨いていた方が良いと思います。

④必然的にコミュニケーションが取れる

誰かと仕事をするということは、コミュニケーションを取る必要があるということです。

当然自分ルールオンリーで進める訳には行きませんから、自分の考えてることとメンバーの考えていることをすり合わせる必要があります。

必然的に会話する機会が発生したり、連絡もより密に取る必要が出てくるため、仕事上のコミュニケーションに慣れてなかったり、苦手としている方には凄く良い機会だと思いました。

次回気を付けたいこと3選

①状態変化のあるパーツの構造の統一

「クリックしたらこの部分が消える」「このステータスの時は色が付く」等、状態で見た目が変化するパーツの作り方を統一し、共通認識とした方がコーダー的にもバックエンド的にも楽だっただろうと思います。

例えば同じ開閉できるパーツでも、チェックボックスによる制御やJSを使ってclassを追加/削除する方法など、やり方は様々です。
後者の方法を用いる場合は、classの命名規則も決めておけるとよりわかりやすくできたのではと思います。

もちろん、同じ動作をする全てのパーツで統一すべきという訳ではありませんが、せめて1~2パターンに揃えた方が毎回新しくソースを作り直すこともなく効率的だと思います。

②複数ページで利用するパーツのリストアップ

ヘッダーやフッターを始め、テキストフォームやボタンなど、複数ページでの使用がほぼ決まっている要素は最初のうちにリストアップし、どこまで出来ているか管理しながら進めるべきだったと思いました。
誰が何のパーツをいつ作ったか管理すれば、二重作業や取りこぼしが起きるのを防げた可能性は高いだろうと考えています。

また、毎回「あれ作って、これ作って」と声を掛けられるのが煩わしく感じる人もいるでしょうし、予め作るものを可視化しておけば、不要なコミュニケーションによるタイムロス削減にも繋げられそうです。

同時にclass名も併せて管理しておけばチートシート代わりにもなり、より便利に活用できそうです。

③ソースコードの衝突回避

弊社ではGit Labを使用してソースコードのバージョン管理をしています。
最初のうちはHTML、CSS、SCSSの全てをコミット&プッシュしていましたが、そのうちCSSでの衝突が大量に発生するようになりました。

それも当然で、コンパイラーソフトは何を使っているか、どんな設定になっているかで吐き出される内容は微妙に違ってきます。一々衝突を解消しているようでは大幅なタイムロスになり効率も悪いです。

なので、途中からCSSのプッシュは中止し、SCSSを更新したらメインブランチにこまめにマージするよう徹底しました。コーディングが全て終了してからメインブランチのSCSSをコンパイルし、バックエンドに引き継ぎました。

最初からこうしておけば良かったです。多分、一番今回の案件で反省しているミスはこれです。

その他にも、誰かが作成したソースに手を加えすぎない、分割して作成したソースは1人の手で統合するなど、作成段階で衝突しないように工夫することも必要です。

まとめ

初めて取り組んだ複数人コーディング。様々な気づきを得られた非常に良い機会でした。

今後また同じようなタスクが発生したら、今回書いた気を付けたいと思ったことを必ず実行して効率よく作業をこなし、自身の成長の機会としたいです。