自分が感じた良いチーム開発とは

shohei

どうも、shoheiです。

今回は自分が感じた良いチーム開発というのはどういうものかプログラマーの観点で書きます。

前職では製品開発のプログラマーからキャリアをスタートし、会社を辞めるまで大規模プロジェクトのある機能を担うチームマネージャとして数名のプログラマーを抱えて仕事をしていました。

現在はフリーのエンジニアとなり、様々なプロダクト開発のメンバーとしてジョインさせていただいています。

その中でとても良いと感じたチーム開発について具体的にかきます。

その前にまずは悪いチーム開発

その前に今までの体験談からふざけんなと思ったチーム開発について書きます。

簡単に言うとプログラマーがプロダクトマネージャ（以降、PM）に対して「この人いないくてもプロダクト開発できるやん」って思われる開発が一番ダメだと思います。

具体的には

・プログラマーに顧客折衝させる
・仕様変更などの開発に関わる情報をチーム内へ展開できていない
・技術面をリードする方が不在で設計が定まっていない

プログラマーに顧客との時間を取らせてしまうことと、顧客からのフィードバックをうまく伝えれないことです。

技術的な話が分からないのでプログラマーに入ってもらうのは仕方ないことですが、技術の話以外で全体的な開発状況の報告や全体スケジュールの調整などを全てプログラマーにやらせて自分は内職するといったPMの方をみたことがあります。

開発メンバーの負担も増えますし、それ以上にメンバーからの信頼が失われます。

プログラマーは開発に集中したいので、PMの仕事をプログラマーにさせるべきではありません。

さらに、フィードバックをせずにプログラマーから聞かれたら展開するといった聞かれたら答えるスタイルの方もいます。効率が悪すぎますし、そもそも何のために顧客と打ち合わせをしてきたのか問いたくなります。

また、技術面においては設計が決まっていないのに実装スタートするような状況は最悪です。設計が決まっていない状態で機能要件ごとに担当をアサインされてさぁよろしく！といった状況です。

機能ごとに設計が統一されていないので、他のメンバーが対応するにあたりコードを解読するコストもかかり誤った実装になる可能性が高くなります。また重複したソースコードも生まれるので保守性、拡張性が低くなります。

さらに設計が決まっていないと「全体的に見て本当にこの実装で問題ないのか？」といった迷いながらの実装になるためプログラマーの生産性も上がりません。

設計をしないことは不具合の温床にもなるので、技術面をリードする方を1人アサインしてしっかり設計をやるべきです。

良いチーム開発とは

さて、体験談より良いチーム開発とは具体的にどういうものなのか書きます。

これはフリーのエンジニアになってジョインさせていただいたチームを見て感じたことです。

私の中の答えとして良いチーム開発とは次の通りだと思います。

・PMが顧客折衝してフィードバックをしっかり展開してくれる
・技術面をリードする方が設計をしっかり決めてくれる
・定期的に打ち合わせを行いプロダクトを確認する

PMが顧客折衝してフィードバックをしっかり展開してくれる

当たり前のことだと思いますが、PMの方が顧客との折衝でプロダクトの要件定義を行い仕様をチーム内へしっかりフィードバックしてくれることです。

プログラマーは開発に集中したいため、顧客との折衝はできるだけさせないのが大事です。

PMが顧客からヒアリングした話をまとめて、定例打ち合わせなどで開発メンバーへフィードバックすることが好ましいです。

顧客から五月雨で降りかかる要件をプログラマーへ無残に降りかからないよう防いでくれるのはとてもありがたいですよね。

そうなるとPMは技術に詳しい方であればあるほど優位です。

技術を知らなければ顧客との話の中で実現できるかどうかの相談をされた際に、プログラマーに実現可能かどうかの確認作業が必要になります。PMもプログラマーも確認作業のコストがかかってしまいます。

プログラマーに確認することがダメというのではなく、できるだけそこのコストが少ない方がその分の時間を開発にあてれるのでできるだけ避けたいということです。

PMとして顧客から要望された機能を実現するためには「どのような開発セットで何が必要なのか。開発の規模感（作業時間・難易度・リスク）」を回答できるスキルがあればスムーズにプロダクト開発が進めれると感じました。

技術面をリードする方が設計をしっかり決めてくれる

プロダクトの全体設計できる方が1人いるだけでかなり良いチーム開発ができます。

ウェブ開発であればフロントエンド、バックエンド、データベース、クラウドサーバー、サードパーティーのサーバーなどを決め、さらにアーキテクチャも決めていただければスムーズに開発を進めれます。

ただ、最初の設計だけして終わりになると途中でぐちゃぐちゃなコードになってしまうので、メンバーのレビューで誤った設計で実装していないか確認する必要があります。

開発メンバーが設計を理解していない場合はその設計指針で実装したサンプルコードを用意すれば良いです。できれば1ユースケース実装されたサンプルコードです。

サンプルコードがあればプログラマーは行間を読んで実装していけるので、処理の流れから設計を理解していけれると思います。

さらに技術面でメンバーが困っている場合、ペアプログラミングや参考になる文献を紹介するなどして助けることも大切です。

開発メンバーへの啓蒙は全体的に見て自分の作業量が減ることに繋がるので、積極的にするべきだと思います。

定期的に打ち合わせを行いプロダクトを確認する

週1回の定期的に打ち合わせを行い、チーム内でプロダクトの状況を認識することです。

打ち合わせの議題は次の通りです。

・顧客打ち合わせのフィードバック
・各メンバーの進捗確認と次やること
・技術的な課題や機能に対する制限事項などの確認

テレビ電話やオフラインで打ち合わせ（1時間以内）をして確認します。

メンバーのリアルな声を聞くことで開発するプロダクトの仕様をしっかり認識しているのかや、技術的な課題で詰まっていないかなどを知るためです。

PMとしてもフィードバックを共有しないといけないので、要件をまとめる良い機会になります。

番外編 プログラマーのテンションを上げる裏技

人によってはテンション上がらないかもしれませんが、寂しがりやのかまってちゃんな僕としては次のようなことでモチベーションが上がりました。

・新しい技術を使う
・プルリクを承認した時にLGTMを使う（LGTM画像）
・チャットメッセージで絵文字スタンプを使って聞いていること伝える

ご参考まで笑

終わりに

体験談からプログラマー観点でより良いチーム開発とはどういうものなのかについて書きました。

今まで一緒にお仕事させていただいた中で、GuildWorksさんとのチーム開発がとても勉強になり楽しくお仕事をさせていただきました。

技術面もプロダクト＆チームマネジメント面も大変優秀な方々がいらっしゃいます。より良いチーム開発とはどういうものなのか教えていただきました。

知見を取り入れ今後も頑張っていきます。


いいなと思ったら応援しよう！