こんにちは、かわそん(@KKohey4)です！
このような疑問に答えます。
✔️本記事の内容
- 大事なのは「対話」と「振り返り」
- よく起きるトラブル3つ
- それぞれの対策を紹介
この記事を書いている僕は、ハッカソンやインターン、受託案件などで、チーム開発を経験してきました。
その中で、だんだん「ハマりポイント」が見えてきたんですよね。
知ってないと、開発がうまくいかないような。
そこで今回は、体験を元にしつつ、共有します。
3分だけお付き合いくださいませ。
目次
プログラミングのチーム開発で大事なことは1つだけ[トラブルあり]
大事なことはズバリ、
これに尽きます。
当たり前だろって思うかもですが、甘くみちゃダメです。
なあなあじゃなくて、いくつかのポイントを押さえながら、意識的にやって初めて効果が出てきます。
チームとの「対話」とは
まずは「対話」について。
文字通り、チームのメンバーと話しましょう。
シンプルにコミュニケーションを取ることで、雰囲気もよくなるし、チームとしての進捗もわかります。
あおるのは、絶対にNG
対話するっていっても、メンバーを煽るのは、絶対にNGです。
残念ながらたまーに、こういう人がいるので。。。
「そんなの簡単じゃん」
みたいな。
絶対によくありません。
雰囲気が悪くなるし、何より、その人と協力しようっていう気持ちが無くなってしまいますので。
あくまでも振り返りの場で、「事実」として共有するのはいいけど、感情をぶつけていいっていうことではありません。
特に自分がわからないところは褒めちぎる
じゃあ、どうやってコミュニケーションを取るべきか。
基本的に「褒め」の姿勢を大切にする
上記です。その中でも特に、自分の範囲外のところは、褒めるようにします。
例えば先日、サイバーエージェントのインターンにいってきたのですが、チームのメンバーに褒められました。
そこで、逆に機械学習チームを褒めに行ったら、「この後、ご飯いこっか」みたいに、急に距離が縮まったっていうことがありました。
確実に、これは効果ありますよ。
チームでの「振り返り」について
必ず、チームで振り返るようにします。
できれば毎日、少なくとも週一回は、時間を取りたいところですね。
というか、開発をやりきるためには必須です。
振り返りの方法
どうやって振り返ればいいのか。
一番いいのは「KPT形式」の振り返りですね。
※KPTとは
P=Problem=問題
T=Try=対処法
のことです。
KPTがいいのは、問題とアプローチを言語化して、共有できる点です。
ツールはなんでもOKです。
会える距離なら、会って付箋とか使ってもいいし、会えないならTrelloが便利かなと。
具体的な使い方
これも、サイバーの例を出した方がわかりやすいかもです。
毎日振り返ってまして、2日目に目立ったKPTはこんな感じ。
✔️K=Keep
・ちょっとでも進んだら褒めてくれて嬉しかった
✔️Problem
・進捗が思ったよりも出ていない
✔️Try
言語化する中で、完成までのリアルな距離が、イメージしやすくなりますよ。
ちょっとしたTips
ちなみに、この「振り返り」のタイミングで褒めると、、、心に刺さります。
というのは、振り返りのタイミングって、1日の終わり。
つまり、やりきった感が出てて、心が緩んでて、でもなにか言われないかってドキドキしてるタイミングでもあるんですよね。
ここでプラスの意見をもらえると、、
頑張りが報われたような気がして、泣けます。
僕も案件の開発中はボコボコにされて正直、ちょっと落ち込んでましたが、振り返りの時にCTOの方から「かわそんさんのやり方は、仕事任せやすい」って言われて、かなり嬉しかった経験があります。
チーム開発の時によく起きるトラブル3つ
ここで、よく起きる問題を共有します。
下記の3つです。
- ストレス爆発
- コア機能から目が逸れる
- コードのコンフリクト
上記の通り。
もちろんもっとありますが、この3つが一番おきやすくて、重いと判断しました。
ストレス爆発
まずは、何といってもこれ。
長く開発していると、ストレスが爆発します。
進捗が思ったよりも出ない、遠隔でコミュニケーションコスト高い、、、
いろんな原因が重なって。
ぶっちゃけ、しょうがないです。人間同士が、歯車みたいにしっかりと噛み合う方がレアです。
「冷静」になる方法
これは開発というよりも、アンガーマネージメントっていうやつですね。
これが一番効果ありました。
ぶっちゃけ、怒っても生産性とか、下がる一方です。
そんなムダなことをやってる自分を自覚すると、、なんか冷めてきます。
どう考えても「協力」するのが最善なので、
ムダなところで消耗したくないですよね。
コア機能から目が逸れる
これも、、本当によく起こります。
何が大切な機能かわからなくなって、迷子になるパターン。
これは僕もたくさんミスってきまして、
最近、ようやく解決策を見つけました。
コア機能をしっかり実装する方法
結論は、
上記です。
「決心かよ」って思うかもですが、かなり使えます。
Trelloでコアのみ書き出して、なんかちょっとデザイン汚いなあって思っても、進めます。
徹底的にそれだけしかやらないって決めた時の人間は、意外と強いものですよ。
コードのコンフリクト
技術的な問題ですね。
複数人のコードをくっつけようとした時に起きます。
例えば、Aさんがここの部分をいじっていたとします。
そして、Bさんはここをいじってたとしましょう。
重なってる部分ありますよね。
どっちを優先しますか？っていう問題です。
解決策は2つありまして、最後に紹介します。
①担当のコードを切り分ける
一番シンプルな方法ですね。
それぞれが書く場所を、しっかりと分けておきます。
こうすれば、構造的にコンフリクトはおきなくなるので、問題なし。
ですが、分け切るのが難しいのも事実でして、
次に紹介します。
コンフリクト解消の技術を身につける
コンフリクトが起きた時に、スムーズに対処する技術を身につけておきます。
具体的には、この本の内容で十分です。
見たことある人も多いかもです。
1冊持っておいて損はない本でして、これでコンフリクトのストレスが減るって考えると、安い投資かなと。
まとめ:チームは「まとまり」がかなり大事
記事をまとめます。
- 対話と振り返りをしっかりと
- 「褒め」はまじで効果がある
- 振り返りはKPT形式で
- よくあるトラブルは3つ紹介
- コンフリクト解消の練習を
こんな感じですね。
もちろんチームは「人間」が作っているものなので、
いろんなトラブルとか出てきます。
でも、事前に意識しておけば、避けられるものもあるんですよね。
この記事がちょっとでもそのサポートになれば、幸いです。
ではでは(^-^)/
✔️本文中のリンク
あんまり経験がないので、注意点と対策も教えて欲しいです。」