チーム開発の効率的な進め方

会社開発

こんにちはJUNOです。

現在のプロジェクトでチーム開発をしているのでそこで感じた「チーム開発の効率的な進め方」について考えてみました。

チーム構成

チームとしてはマネージャー1人、開発4人、インフラ1人、デザイナー2人で私は開発担当でJOINしました。

要件定義や設計はマネージャーが担当し、開発がフロントエンドとサーバーサイド、インフラがDockerやAWSの環境構築、デザイナーがXDデザイン作成という役割分担でした。

開発の流れは以下の流れで進めました。

①要件定義・デザイン
↓
②フロントエンド
↓
③サーバーサイド
↓
④テスト

当記事では②フロントエンド、③サーバーサイド、④テストフェーズにおいて振り返りたいと思います。

振り返り

一通りの開発を終えて感じたことを以下にまとめてみました。

コーディングはまずコンポーネントから開発！
共通部品に関しては随時共有しておく
ディレクトリ構成や実装方法のルール決めをする
実装後に動作確認する
わからなければ聞く
実装に詰まったら誰かとタスクを交換する
コードレビューを取り入れる
マネージャーの返答が速いのはとてもありがたい
進捗会はできる限り関係者全員参加すべし

コーディングはまずコンポーネントから開発！

ボタンやカードなどページによって同じ部品がありますが、ページのデザインが決まっている場合はページを作成する前にまずは全員で分担してページ全体で使う共通部品を一通り作ることをオススメします。
今回フロントはVue.jsでの開発で私達は最初2人でコーディングが始まりました。それぞれ担当のページをそれぞれ独立して進めていくことになりましたが、ここで問題となったのが同一パーツ扱いです。ボタンなどの使いまわしできるコンポーネントを作っていなかったため、お互いにとりあえず同じものを作ってしまいその時間は無駄になってしまいました。コンポーネントがあれば全員がそれを使えばいいだけなので、重複開発の時間が削減されますし、部品単体で作れば独立した結合の弱い再利用可能なコンポーネントとして作れます。

共通部品に関しては随時共有しておく

もしフロントのコンポーネントやバックエンドの共通メソッドなどを作ったならばその機能を実装者全員に共有しておきましょう。共有することで同じ機能が必要な際に無駄に同じものを作らずに済むからです。おそらく共有しなければその存在に気づくことはありません。共有してメンバーの頭の片隅に置いておきましょう。

ディレクトリ構成や実装方法のルール決めをする

これは今回のプロジェクトではじめに決めていてよかったと思ったことです。ディレクトリルールもなく進めていたらもはやディレクトリなどなく１つの中にすべてが突っ込まれていたと思います。どこに何があるかわかりやすいのはとても大切なことなのでまずはルール決めをしておきましょう。また実装に関しても「Controllerにはビジネスロジックを書かない」「バリデーションはFormRequestクラスに切り分ける」などある程度ルールを設けたほうが実装に統一性が生まれるので決めておきましょう(もし決めてなかったらみんなControllerに全部突っ込まれていただろうな…)。

実装後に動作確認する

これは人によっては当然の事かもしれませんが、しっかり仕様通りの動きをするか確認を怠ってしまう人もいます。もし確認せず動作しないでそのまま実装完了にしてしまうとテストの際に確実に戻しになり時間が修正に時間がかかります。また、もしかしたらテストをする人や修正する人が実装者でない場合もあり、その人達の時間も奪うことになってしまいます。完全に実装漏れをなくすことは難しいですが、実装完了後は一度動作確認しておきましょう。

わからなければ聞く

「仕様がイマイチ理解できない」「実装方法がわからない」など普段あるあるだと思います。そんなときはチームメンバーに聞いちゃいましょう！一人でずっと考えていてもわからないものはわかりません。他の人に聞いたらすぐに解決してしまうことは多々ありますし、わからなくても協力して解決できることもあります。とにかく聞きましょう！相談して快く協力してくれるメンバーが集まっていればそれだけでもういいチームです。

実装に詰まったら誰かとタスクを交換する

いろいろやってみたけど実装できない！というときはそのタスクを他の誰かにやってみてもらうのもありです。他の人がやると意外とすんなり解決できてしまったりすることが多々あります。

コードレビューを取り入れる

コードを洗練させるならコードレビューが効果的です。

「ここのプログラムもう既存にあるよ！」「ここの処理は別の場所でも使いたいから別メソッドに分けたほうがいいよ」などメンバーのチェックが入ることによってプロジェクトのコードが洗練され、また実装に学びが生まれます。洗練されたコードほど修正や運用が大変楽になります。可能であれば絶対にやりたいものですね(今回はちょっと時間がなくて….泣)。

マネージャーの返答が速いのはとてもありがたい

一番感動しているのはマネージャーのレスの速さでした。「ここの仕様ってこれであってますか？」「ここで実装が難しいのですがどうすればいいでしょうか」など開発メンバー全員からひっきりなしにslackで質問が飛び交う中、質問を投げた直後にはslackの下の方に「〇〇さんが入力しています…」と表示されすぐに回答してくれます。実装者側としては作業が止まらないためとてもありがたいです。最近はよくビジネス系の書籍や動画で「できる人は通知を切る」とか紹介されていますが、複数プロジェクト掛け持ちのマネージャーの早レスはもはや仕事ができる以外の何者でもありません。自分がマネージャーになったときにもそうでありたいと尊敬した体験でした。

進捗会は関係者全員参加すべし

プロジェクトの進捗会議ではできる限り関係するメンバー全員の参加をオススメします。

私達のプロジェクトでは毎週進捗会議をしています。メンバーは開発メンバーとマネージャーだけで行っています。そこで１つ失敗したなーと思ったのがコーディング工程での確認でデザイナーなしで進めてしまったことです。

一通り全ページが完成した段階で社長とデザイナーによるレビューが入ったのですが、「テーブルヘッダーの色がデザインと違う」「ボタンの文字が少しずれている」など修正点が100項目以上あり修正に多大な時間がかかってしまいました。当時はどのくらいの精度でコーディングすれば良いのかという温度感もわからないままコーディングをしていました。もし、毎週の進捗会議にもデザイナーの方が参加していれば１ページだけの修正で済んでいたかもしれませんし、コーディングに求める精度だったりが分かって良かったのではないかと思いました。逆に、デザイナーさんが実際のコーディングで気づく点も多くありました。例えば、「Chromeの最小フォントサイズが10px」であることや「ブラウザによってスクロールバーのデザインが異なる」などコーディングしないとわからないことも見えてくるので、デザイナーさんにとっても早い段階で修正ができたのではないかと思います。

もちろん皆さん忙しいのは重々承知しています。毎回参加は難しい現場もあるかもしれません。参加できるときはその時だけでも参加して確認に時間を取ると戻しも少なくなりプロジェクト全体としては進みが早くなるかもしれません。(全部できてからの修正はきついので…)