リーダー3年目がチーム開発で大切にすべきことをまとめてみた（開発メンバー編）

ご無沙汰です！しゅんたろです！
僕はエンジニアとしての歴は8年近くになりますが、チームとして開発を経験したのは、福岡に引っ越してからの3年です。

今回は3年間の経験で感じた「チーム開発を行う上で大切にすべきこと」を２本立てで投稿します！

1. 開発メンバーが大切にすべきこと
2. リーダーが大切にすべきこと

本記事は開発メンバーにフォーカスした記事になります。
（リーダー編は年明けにでも書けたらと思ってます。）

何か1つでも2つでも3つでもお役に立つ内容がありましたら幸いですので、ご一読お願いします。

福岡オフィスでは僕が常々口にしている内容ですが、まだまだ不完全ですので、是非ご意見ご感想お待ちしております。

一. 目の前しか見てない開発は止めるべき

タイトルだけでは分かりづらいですが、要するに、動けばOK、テストが通ればOKというコードは基本的に良くないと思っています。

自分以外の誰が見ても、実装者に質問せずに理解できるコードが理想なのですが、そのためにコメントの記述が重要になってきます。

もちろん過度のコメントは可読性を落としますが、経験の浅いエンジニアがコードだけで分かるコードを書くことは難しく、また、逆にそのようなコードを読み解くことも難しいため、コメントを添えることは必須になってくると思います。

可読性が低いと、実装者はレビュー時に説明を求められ、レビュワーの時間も実装者の時間も二重でさらに取られることになり、チーム全体として非常に悪循環となるので避けたいところです。

もちろん、大前提として、プロジェクトにおける優先順位（早く売上を立てる必要があるためすぐにリリースしないといけない、緊急の不具合のためすぐに修正をしないといけない）はあるので、そこの匙加減は状況によるところだと思います。

二. 既存のコードのルールを守りつつ、疑う

プロジェクトの途中からjoinする場合や、保守対応を行う場合、他人のコードを編集することが多くなります。

その上で大切なことは、２つです。

1. 理解し、真似る
2. 疑う

1. 理解し、真似る

既に書かれているコードを基本的には真似ながら進めていきますが、自分が書くコードは全てしっかりと理解することが重要です。

先人は必ず意図を持ってコードを書いているはずなので、そこを無視して自由にコードを書かれては、レビュワーも元々のコードを書いたプログラマーも編集が大変です。

不明なコードがあった場合は、同様の処理を行っているコードをまず確認すること。それでも分からない場合はしっかりと質問をして、そのプロジェクトのルールを完全に理解することが重要です。

2. 疑う

かといって、それを全て正しいと鵜呑みにしてしまっては良くない場合もあります。
コードが間違っていれば、そのコードは間違ったままいつまでも引き継がれてしまいます。そのコードを書いた人にも責任がありますが、何も考えずにコードを流用した人にも同じくらい責任があると言えます。

常にコードを疑い、そのコードの本質を理解し、その上で、真似をするのか改善するのかを判断していくことが重要です。

「どんなソースコードにも、少なからず必ず改善の余地はあるもの」という事を念頭に取り組みましょう。

※注意事項として、改善を提案することが重要であり、勝手に変えてはいけません。
そのコードには隠れた意図がある可能性もあるので、必ずチームと共有しながら進めていくことが大切です。

三. チームのゴールを常に見据えた動きをする

プロジェクトには、必ずゴールが存在します。

最初は難しいかもしれませんが、常にチーム全体のゴールを見据えて行動できるかどうかがポイントだと思っています。

自分自身のゴールを理解するのは当たり前で、それがチームのゴールに繋がっているのかは、随時確認しながら進めていく必要があります。

チームメンバー全員が常にゴールを意識しながら動くことが出来ると、開発の進行もスムーズになり、認識の齟齬や漏れなども少なくなります。

例えば、インフラの設計、構築は自分の担当ではないため理解する必要はないと思ってしまいがちですが、そうなると本番リリース時に必要なことについて全く考える機会がありません。

その視点が欠けた状態でコーディングを行ってしまうと、視野が限定的になってしまい、本番リリース時に考慮すべきことを気付くのが毎回インフラ担当の人だけになってしまいます。

四. ボールを渡す時は期日を決め、リマインドを

プロジェクトを進める中で、タスクが自分の手元から離れて、自分以外の人にボールが渡ることがいろんなケースで起こります。

例えば、

• レビュワーに依頼を出す
• クライアントに質問をする
• チームに確認をとる
• などなど

ここで重要なのは２つです。

1. 必ず期限を決める
2. 期限終了時にリマインドをする

例えば、12/10がリリース日のものに対して、12/1にクライアントに質問をしたが、12/5になってもクライアントから返信が来ないとします。

その際、12/10に「返信が無かったので遅れました。」と言うのはとても簡単ですが、これはクライアントにとっても親切な行動ではありません。

1. 必ず期限を決める

まず、必ず期限を設けるべきです。いつまでに何をして欲しいのかを明確に伝えましょう。

2. 期限終了時にリマインドをする

期限を超えた場合は、リマインドをしてください。

返信が来ないからいつまで経っても待ってばかりでは、仕事は前に進みません。たまたま忘れていたり、そもそも気づいていないだけでリアクションをしている場合もあります。いずれにしてもそこはコミュニケーションで解決できます。

ただし

バランスも大切です。

特にクライアントに対して何度も催促するのは、相手の気分を害する恐れがあります。多忙な中ご回答いただいているという状況を考慮して、別の提案をすることの方が親切な場合もあります。

答えやすいように電話やオンライン通話の日時を設定するなど、クライアントに寄り添った提案ができると良いですね。

五. 声を掛け合えるチームを作る

これは今の開発メンバーから僕が学んだことですが、常に声を掛け合い、ヘルプを出しやすい環境づくりができていました。

ふと自分のタスクが落ち着いた時に、「○○さん、ハマってないですか？」「順調ですか？」という声がよく聞こえてきました。

これは僕はあまりできておりませんでした。

「いつでも聞いてきていいよ」という話をしていたつもりですが、気軽には聞けない雰囲気になっていたと反省しています。

「何も調べずに何も考えずにとりあえず聞く」というのは良くないですが、気兼ねなく聞ける環境を作ることは、開発チームにとって重要なことだと改めて気付かされました。

まとめ

いかがでしたでしょうか。
１つでも皆様の今後のお役に立てた内容が含まれていれば幸いです。

自分はこうやっているよ！とか、ここは少し違うと思う！とか、なんでもコメントお待ちしてます。

次はまた、リーダー編を執筆いたしますので、乞うご期待！