チーム開発を効率よく進めるために意識していること

チーム開発Advent Calendar
Tomu Obata
📅2019/12/4

チーム開発に関するトピックを、ファシリテーターやタスク振りなど様々な観点から紹介しています。

はじめに

チーム開発において、より良いプロダクトを効率よく作るためには、コミュニケーションロスを減らし、共に開発している人の生産性を最大化することは必要不可欠だと考えています。

議論の際や、ファシリテーターとしてリードしていく際など状況によってcase by caseなので、そういった中で、今回自分が意識していることを書いていきたいと思います。

また、この記事は、Treasure Advent Calendar 2019の4日目になります。

全体を通していえること

HRTの精神を忘れない

HRTの精神とはTeam Geekより、

謙虚(Humility)

世界の中心は君ではない。君は全知全能ではないし、絶対に正しいわけでもない。常に自分を改善していこう。

尊敬(Respect)

一緒に働く人のことを心から思いやろう。相手を1人の人間として扱い、その能力や功績を高く評価しよう。

信頼(Trust)

自分以外の人は有効であり、正しいことをすると信じよう。そうすれば、仕事を任せることができる。

そして、あらゆる人間関係の衝突は、謙虚・尊敬・信頼の欠如によるものだ とあります。私たちがHRTを受け入れて内面化することが、良いチームを作るための根源にあると考えています。

※ これらに関して更に深掘りした内容は、Team Geekという本に書いてあるので、興味のある方はぜひ!私のバイブルのような本です。

KPTの振り返りのスパンは短く

KPTとは、

💡
K = Keep : 今後も継続していきたいこと P = Problem : 問題・課題だったこと T = Try : 次から挑戦・改善していきたいこと

反省をしっかり活かしていくためには、認知してから挑戦までに間隔を短くすることが 忘れずに改善するためには大切だと考えています。

KPTよりも学習効率を高めたいという場合は、 項目を1つ増やしてKPLTというのも良いなと思っています。

💡
L = Learn : このプロジェクトを通じて学んだこと

各々が学びを共有することで気づきが増えることがメリットです。

頼れる部分は頼っていく。そして、感謝の気持ちを言語化して伝えること

自分1人で出来ることには限界があり、何でも自分だけで行おうとすると懸念点に気づかず 大きなミスを招くことにも繋がりかねません。1人で抱え込まずに周囲の人も巻き込んでプロジェクトを進行していくことが出来れば結果的に高い生産性のチームになっていくと思っています。

そして、相手が時間を割いてくれた訳なので、感謝の言葉はしっかりと伝えることでお互いの信頼感が形成されていくと考えています。

アドバイス・提案をする際

提案の背景を説明する

「このままいくとこうなるだろうから、今回こういった提案をしています」という風になぜその提案をしているのか背景を踏まえて説明することで提案者と受け手の共有認識のズレを減らすことが出来ると考えています。

ファシリテーターの際

はじめに、ファシリテーターのイメージがし易くなるように、ファシリテーションについて書いていこうと思います。

ファシリテーションの意味は以下の記事より、「プロセスや活動を容易にすること」

これだけでは、なかなかイメージが湧きづらいですが、集団活動を用意するためにチームワークを促進し、個人プレーでは決してつくれない成果を生み出す技術ということです。

そして、ファシリテーターとは、会議やミーティングといった集団活動を容易にするために 議論を仕切る人のことを指します。

GATを意識して進めるようにする

GATとは、

💡
G = Goal : 会議の目標。何を達成すればOKか A = Agenda : 議題 T = Time : 議題に対する時間配分

Goal

まず会議の最初に、何を達成するために会議を行うのかというGoalを共有します。

Agenda

今は何の話し合いをしているのか明確にして進めていくために、アジェンダをモニターやホワイトボードに映しておくことは有効だと感じています。Agendaは会議前に共有し、事前情報を入れた上で進める形が理想です。

Time

各議題に対して、時間管理をしっかりと行い、会議の最初に決めたGoalを達成したら、話し合いを終了します。

また、長引き過ぎてしまうのを防ぐ策として、会議の時間を強制的に中断するもの(お昼休憩・ミーティングルームの利用可能時間など)を設けるのも有効です。

思考する時間と意見を出す時間を切り分けること

決めたいことがあるが、なかなか意見が出てこない時には、みんなが考えを整理し話しやすくするために 一旦思考のみを行う時間を設けて、その後意見を出す時間を作るようにしています。この際にもしっかり時間を定めます。

サイレントミーティングを意見が出てこなくなったら用いているイメージです。

メリハリをつけるために適度に休憩を挟む

時間のかかる議題である時や、会議の密度を上げる工夫をしていても長引いてしまう時はあると思います。長引いてしまう時こそ、集中力を保つために適度に休憩を入れます。何気ない雑談などをすることで脳がリフレッシュされ、活発に意見が交わされるようになっていくはずです。

あまりにも長時間休憩をすると休憩前に話し合っていた内容を思い出すのに時間を要してしまうため、5〜10分が適切だと思います。

アイデア出しの際

セグメンテーション・ペルソナを意識して考えること

セグメンテーションとは、ユーザーについて類似した性質やニーズを読み解き、 顧客グループ(セグメント)を作ることです。

ペルソナとは、サービス・商品のユーザー像のことです。

アイデア出しのフレームワークにもよりますが、これらを意識しながら考えることでより具体的なアイデアが出ると考えています。

アイデアを収束する時は、時間管理を特に徹底して行う

アイデアを発散させるときは時間で区切って、次の段階へいくということがしやすいです。 しかし、アイデアを収束するときは、妥協して次に進むということがしづらく、時間管理が難しいです。

そのため、途中になってしまったとしても、決めた時間を過ぎたらそこで一旦中断し、次の取り組みに進むという流れで進行するように意識するようにしています。

開発スケジューリングの際

後々このスケジュールでは大きな問題が発生しないか考える

例えば、「Aさんの機能実装が終わらないとBさんの機能実装を行うことが出来ない際、それらを考慮し余裕のあるスケジュールになっているのか」など、今後開発が進むに連れて問題が露呈していく部分があれば早期発見できるように考えるようにしています。

初めての実装する機能や慣れていない実装などで正確に見積もることが難しい時は、短いスパンで進捗管理する

正確な見積もりが難しい時に有効な方法としては、進捗管理のスパンを短くすることだと考えています。そして、予定通りいっていない場合は、詰まっている部分の確認をしっかりと行うことで、早期解決が目指していければと思います。

見積もりの手法「プランニングポーカー」

An image from Notion

見積もりに関して余談になりますが、プランニングポーカーという手法は チームメンバー間で実装難度の共通認識を持つ際に有効だと感じています。

プランニングポーカーについては、様々な記事がありますので、興味のある方は以下を参考にしてみてください。

タスク振りの際

優先順位付けを徹底する

まず、考えうるタスクを全て洗い出します。 次に、各タスクの緊急度・影響度を定めます。 そして、以下のように取り組むタスクの優先順位を決めています。

  1. 緊急度 高、影響度 高
  2. 緊急度 高、影響度 低
  3. 緊急度 低、影響度 高
  4. 緊急度 低、影響度 低

自分は緊急度と影響度の尺度で考えていますが、以下の記事は考え方が似ていて参考になる部分がありました。

タスク管理の際

チームメンバー全員が、現在どのIssuesに取り組んでいて進捗がどれくらいなのか把握できる状態を維持すること

GitHubのIssuesやTrelloを使ったりして、残りのタスク・進捗状況を可視化することで、 メンバー間のコミュニケーションのアシストが行え、例えば詰まっている内容などの相談がしやすくなります。

GitHubのIssuesを使っている場合は、以下のようにチェックボックスなどを用いると各PRの進捗状況が一目で分かりやすくなります。

GitHubのIssues運用の例
GitHubのIssues運用の例

コードレビューの際

レビューコメントの先頭にラベル項目をつける

といった項目をレビューコメントの先頭につけると、実装者が判断しやすくなります。

また、以下の記事には、コードレビューの際に参考になることが多く書かれていたので、ご紹介いたします。

【2020/04/26追記】

Goodラベルもレビューでのコミュニケーションで有効だと思います。

チーム全体の生産性を上げるためには

まず、チームの生産性が上がったということをどのように評価すれば良いのか考えた時に、メンバーが成長したらチームの生産性が上がったと言えると思っています。

そのためには、

が大事だと考えています。 1人1人の自分が開発に参加しているという意識が高まることで、活動が活発になると思います。

おわりに

チームの性質によって、生産性を最大化するためには意識した方が良いことは異なるはずです。 そういった中で、状況に応じて臨機応変に対応できるように心がけ、自分の行動を改善し続けることが最も重要だと考えています。

また、ファシリテーターとして議論を進める人以外も、意識して工夫していけることは多くあると思います。どのようにすればもっと円滑に進むか考え、それらを行動に移せていけると強みになっていくはずです!

最後になりますが、エンジニアは常にチームで仕事をするため、チームは個人の生産性や幸福度に直接影響をもたらします。自分の目指すエンジニア像である チームとしての生産性を最大化できる人 に近づいていけるように、日々ソフトウェアエンジニアリングの「ソフトスキル」の方も磨いていきたいです。

長文読んでいただきありがとうございました。 また、自分の中で気づきがありましたら、追記します📝

それでは良いお年を!🎍

追記履歴

2020/04/26追記

SHARE

スポンサーリンク