TECHNICAL BLOG

2024/7/16 # 入門 # プロジェクト管理 2024/7 少人数開発でのコーディング規約をどうするか

新卒で大阪事業所に入社し、4年目となる山口です。
ここ2年程、多い時でPM含め6人、普段は3人の少人数チームでの開発作業に携わっています。
その中でちょっとした反省点が浮上し、少人数の開発チームでのコーディング規約についてどうすればいいのかを考える機会があったので、私なりの考えをご紹介できればと思います。
また、 「少人数開発でコーディング規約は必要なのか?」 という視点でもお話ししたいと考えています。

コーディング規約とは?

そもそもの話ですが、コーディング規約とはなんでしょうか?(ご存知の方は読み飛ばしていただいて構いません)

コーディング規約とは、複数人で開発をする際のルール集のようなものです。
各プロジェクトによってその中身は異なりますし、明確に定めていないプロジェクトも多くあると思います。私の所属するプロジェクトでも、現時点で明文化したコーディング規約はありません。

大人数のチーム開発において、みんながバラバラの実装方法でコーディングしてしまうと、作成者ごとに実装方法が全く異なったり、同じような機能を別々の人が作ってしまったりで効率が悪く、保守性も下がってしまいます。

そこで、設計思想や変数の命名方法やリソースの配置場所などを明文化しておくことで、作成者ごとのブレを減らし、品質や保守性を高めることが期待できます。

一般に、大人数であるほどコーディング規約の重要性が高く、メンバーのスキルが低いほどその中身は細かく、丁寧にしたほうが良いとされています(品質の均一化のため)。

ルールブック

当時の状況

前述の通り、私がコーディング規約について意識するようになったきっかけとして、あるwebサイトのリプレイス開発の際、ちょっとした反省点がありました。ここではその元となった状況を説明します。

使用言語・フレームワーク

  • バックエンド側:PHP・Laravel
  • フロント側:jQuery

    既存メンバー

  • PM(プロジェクトマネージャー)
  • 開発担当(私含め二人)

すでにこの3人でwebサイトの管理画面の開発を粗方終えており、公開画面側は保守性を高めるため、できるだけ管理画面と同じような形で実装を行いたいという状況でした。

また、この3人は同じ顧客の別システムも担当しており、おおむねプロジェクト内での実装方針などの認識が共通化されています。ただし、3人という少人数のプロジェクトなこともあって、コーディング規約の明文化はしていません。

公開画面側追加メンバー

  • Aさん(完全新規メンバー)
  • Bさん(以前このプロジェクトでの経験があり、ある程度実装方針などは把握している)

フロント側の開発では、新たに上記二人のメンバーに加入していただき、実装を進めることになりました。二人とも私よりも経験豊富な方です。

実際に起きた事例

いざチームで実装を進めていくにあたって、私たちのチームでは、実装方針や管理画面のソースの説明をあまりすることなく、
「仕様は現行踏襲で。ソースの書き方は管理画面と同じ感じで。」
というふわっとした感じで進めていました。

Bさんのほうは以前このプロジェクトに参加していたこともあり、問題なく作業されていました。

しかし。Aさんのほうは、管理画面の実装と違う形で実装を進められていました。

例えば、本プロジェクトのバックエンドは、MVCモデルにServiceの概念を取り入れた「MVCS」の形で実装していたのですが、Aさんは「MVC」で実装されていました。
JS側の方も、イベントの呼び出し方などを少しプロジェクト内で工夫していたのですが、Aさんには伝わっていませんでした。

そうした結果、Aさんとほかのメンバーの間で、実装方法が大きくずれてしまっていました。
そうなると保守性や可読性に欠けることとなってしまうため、Aさんには後で本プロジェクトの方針に合うようリファクタリングしていただくことになってしまいました。

プロジェクトのスケジュールに影響はなかったのですが、Aさんに余計な作業を発生させてしまう結果になりました。

困る人

どうすればよかったか

上記の事態を避けるために、事前に管理画面のソース説明を行うべきでした。

実装方法(MVCSの使用など)を口頭で実際にソースを見ながら説明しておくのが望ましかったと思います。 私がAさんの立場だった場合でも、同じような状況になってしまっていたでしょう。

コミュニケーションをとりながら開発

さらに言えば、 口頭で伝え漏れがないように、プロジェクトのwikiなどにメモを残しておくべきでした。
こういったメモがあれば、伝達漏れを防ぎ、後から振り返ることができるうえ、簡易的なコーディング規約 としても活用できて便利だなと気づきました。

メモ

「誰が」行うべきか

ここまでお話ししてきた内容は、いわゆる「プロジェクト管理」といった部分の内容です。
なので、私のような開発者ではなく、管理層であるPMやPL(プロジェクトリーダー)が考え、実施すべき内容では?と考えられる方もいるかもしれません。

ですが、実際にメインで開発を行い、ソースコードと一番長く向き合っているのは開発者だと思います。 開発者ならではの注意点や意識していることなどもあるでしょう。

そういった点を逃さず伝えるためにも、こうしたコーディングに関する取り決めや、その連携は 開発者が主導となって行ったり、PLやPMに積極的に働きかけていけると良いなと感じました。
また、自分が新しいプロジェクトに参画する際は、そういった部分の確認を事前に行うにするべきだと学びました。

少人数開発でコーディング規約は必要なのか?

ここまで書いてきたのですが、現時点での私の考えとしては、少人数プロジェクトではかっちりとしたコーディング規約は不要だと考えています。
当然ですが、コーディング規約を設定するのにも手間と時間がかかります。少人数のプロジェクトだと、その利益は少なくなります。そのコストに見合っているかは微妙なところだと思います。

ただし、前述の通りコーディングに関して、メンバー間で認識を固めておくことは重要です。
そのためにコーディングに関するメモをまとめておき、結果として簡易的なコーディング規約になる。くらいの温度感で取り組むべき内容だなと感じています。

コーディング規約を作った場合でも、新しいメンバーが入った際は口頭でコーディング規約を読み合わせ、実際のソースとともに説明する時間を作ることが理想だと思いました。

最後に

私は、開発者の立場でも、プロジェクト管理に関する視点を持って 「よりよいプロジェクトにするにはどうすればいいか」 を考えて働くことはとても大切だと考えています。
そういった意味でも今回の失敗は、プロジェクト管理の視点を強化する良い経験だったなと思いました。