チーム開発で失敗するための７個の秘訣

前置き

私がよく耳にする言葉の一つにこんな言葉がある。

成功体験より失敗体験の方が再現性が高い

実際その通りだ。成功体験は複雑な要因の上に運などの不確定要素が絡まってできている場合もあり、一概に成功体験の原因を定義することは難しい。
一方失敗体験の場合、その原因の特定は容易かつネガティブなものであるので皆が避けるべきものとして価値の高いものとなる。

今回は、私が所属していた #inteeプログラミングゼミ のチーム開発を通して学んだ成功体験を、逆に失敗体験に落とし込んで共有していく。
プログラミングでのチーム開発に沿って書いているため、所々で専門用語らしきものが登場するが、なるべく噛み砕いた表現に落とし込んだのでぜひ最後まで読んでほしい。

1. 細かなコミュニケーションを取らない

細かなコミュニケーションとは、報告・連絡・相談やそれに対する返信などである。Slackで言うとリアクションなどが当てはまるだろう。

こういった細かいコミュニケーションを行わないと、メンバー同士の状況を把握することが難しくなる。今日中に目を通して欲しい連絡を行った際に、確認はできているのか、電話などで催促をしたほうが良いのかなど、連絡する側に対する心理的負担が生まれる。

2. その場で次の予定を立てない

オンライン上でチーム開発を行う際に気をつけて欲しいのが、次の予定をその場で決めることだ。具体的には、「いつまでに何を完成させるのか」「次のZoomミーティングをいつにするか」などがある。

ミーティングが終わったあと、次の予定を立てずに終了してしまうと、連絡にラグが生まれるSNS上でやりとりをしなければいけなくなる。その結果、次の予定が曖昧になってしまった経験がある人も多いのではないだろうか。

3. 悩み事を共有しない

コードの実装方法に行き詰まった時、チーム内で解釈のすり合わせをしたくなった時、悩み事をすぐに共有しないまま一人で抱え込んでしまうことは失敗の原因になる。他の人と相談する必要がある内容を自分の中だけで留めてしまうことは無駄な時間を過ごすことに繋がるからだ。

また、悩み事を共有できないと言うことはメンバー間の関係に何らかの溝があることを意味する。悩み事を積極的に共有することで。個人ではなくチームとして課題解決をしている意識を持つことができ、自然とチームの一体感が生まれる。

4. 他人任せにする

悩みを共有すると言うことは、他のメンバーに課題を丸投げすると言うことではない。あくまで自分の解釈を中心に課題解決を行う意識が必要である。

その他にも、自分の担当作業が終わった際に暇を作るのではなく、メンバーの担当作業を手伝うこともチーム開発を行う上で重要だ。しかし、他メンバーの担当を手伝う時には担当者の解釈を最優先にすることが求められる。なぜなら、実装する際に担当者と自分の間で意図がズレないよう注意を払う必要があるからだ。

5. 役割分担をしない

業務をいくつかに細分化した際に、役割分担を欠かすことは無意味な作業コストを支払う可能性がある。また、作業が重複するだけではなく、抜けのある作業が出る可能性も考えられる。

業務を細分化した後は必ず業務ごとに担当者を作る。そうすることで責任者が明確になり、業務の重複や抜けがなくなる。また、先に述べたように業務を誰の解釈をもとに行うべきなのかが分かりやすくなる。

6. 納期を明確にしない

納期を明確にしないことは生産性を低下させる、その結果、業務をダラダラと先延ばしにしてしまう。納期を決めることで、逆算的に開発を行う計画が定まり、生産性が向上する。

7. やりたいことを詰め込む

自分の理想を最大限に膨らませ、やりたいことを詰め込むと業務にかける日数が肥大化していき、納期に間に合わなかったり、途中で中弛みが起きモチベーションが低下する。

要件定義の際に機能の重要度を明確化しておき、必要最低限の機能を備えたらまずサービスをリリースすることが重要である。この時、完成度は60%程度でも構わない。そこから徐々に必要な機能の付け足しや、既存のコードの改善を行なっていく。

終わりに

こうしてみると当たり前のことではあるが、自身の行動を振り返ってみるとできていないことはこの他にも多くある。

例えば、6.と7.に関しては私自身失敗した経験をもとにチーム開発の舵取りを行う際に気をつけた点である。

自身の成功体験について、成功した要因だけでなく失敗しなかった要因にも注目することで新たな学びが得られることに気がついた。