チーム開発を効率よく進めるために｜HRTの精神と実践的なタスク管理
チーム開発を成功させるためのファシリテーション、タスク管理、コミュニケーション戦略を徹底解説！より良いプロダクトを効率よく作るためのノウハウを紹介。
はじめに全体を通していえることHRTの精神を忘れないKPTの振り返りのスパンは短く頼れる部分は頼っていく。そして、感謝の気持ちを言語化して伝えることアドバイス・提案をする際提案の背景を説明するファシリテーターの際GATを意識して進めるようにするGoalAgendaTime思考する時間と意見を出す時間を切り分けることメリハリをつけるために適度に休憩を挟むアイデア出しの際セグメンテーション・ペルソナを意識して考えることアイデアを収束する時は、時間管理を特に徹底して行う開発スケジューリングの際後々このスケジュールでは大きな問題が発生しないか考える初めての実装する機能や慣れていない実装などで正確に見積もることが難しい時は、短いスパンで進捗管理する見積もりの手法「プランニングポーカー」タスク振りの際優先順位付けを徹底するタスク管理の際チームメンバー全員が、現在どのIssuesに取り組んでいて進捗がどれくらいなのか把握できる状態を維持することコードレビューの際レビューコメントの先頭にラベル項目をつけるチーム全体の生産性を上げるためにはおわりに
はじめに
チーム開発において、より良いプロダクトを効率よく作るためには、コミュニケーションロスを減らし、共に開発している人の生産性を最大化することは必要不可欠だと考えています。
議論の際や、ファシリテーターとしてリードしていく際など状況によってcase by caseなので、そういった中で、今回自分が意識していることを書いていきたいと思います。
全体を通していえること
HRTの精神を忘れない
謙虚(Humility)
世界の中心は君ではない。君は全知全能ではないし、絶対に正しいわけでもない。常に自分を改善していこう。
尊敬(Respect)
一緒に働く人のことを心から思いやろう。相手を1人の人間として扱い、その能力や功績を高く評価しよう。
信頼(Trust)
自分以外の人は有効であり、正しいことをすると信じよう。そうすれば、仕事を任せることができる。
そして、あらゆる人間関係の衝突は、謙虚・尊敬・信頼の欠如によるものだ
とあります。私たちがHRTを受け入れて内面化することが、良いチームを作るための根源にあると考えています。
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さんの機能実装を行うことが出来ない際、それらを考慮し余裕のあるスケジュールになっているのか」など、今後開発が進むに連れて問題が露呈していく部分があれば早期発見できるように考えるようにしています。
初めての実装する機能や慣れていない実装などで正確に見積もることが難しい時は、短いスパンで進捗管理する
正確な見積もりが難しい時に有効な方法としては、進捗管理のスパンを短くすることだと考えています。そして、予定通りいっていない場合は、詰まっている部分の確認をしっかりと行うことで、早期解決が目指していければと思います。
見積もりの手法「プランニングポーカー」
見積もりに関して余談になりますが、プランニングポーカーという手法は チームメンバー間で実装難度の共通認識を持つ際に有効だと感じています。
プランニングポーカーについては、様々な記事がありますので、興味のある方は以下を参考にしてみてください。
タスク振りの際
優先順位付けを徹底する
まず、考えうるタスクを全て洗い出します。
次に、各タスクの緊急度・影響度を定めます。
そして、以下のように取り組むタスクの優先順位を決めています。
- 緊急度 高、影響度 高
- 緊急度 高、影響度 低
- 緊急度 低、影響度 高
- 緊急度 低、影響度 低
自分は緊急度と影響度の尺度で考えていますが、以下の記事は考え方が似ていて参考になる部分がありました。
タスク管理の際
チームメンバー全員が、現在どのIssuesに取り組んでいて進捗がどれくらいなのか把握できる状態を維持すること
GitHubのIssuesやTrelloを使ったりして、残りのタスク・進捗状況を可視化することで、
メンバー間のコミュニケーションのアシストが行え、例えば詰まっている内容などの相談がしやすくなります。
GitHubのIssuesを使っている場合は、以下のようにチェックボックスなどを用いると各PRの進捗状況が一目で分かりやすくなります。
コードレビューの際
レビューコメントの先頭にラベル項目をつける
- [MUST]：どうしても修正してほしい場合に付けます
- [IMO]：自分の意見・提案をする場合に付けます(In My Openionの略語)
- [NITS]：改行やインデントなど小さな指摘をする場合に付けます。(Nits pickの略語)
といった項目をレビューコメントの先頭につけると、実装者が判断しやすくなります。
また、以下の記事には、コードレビューの際に参考になることが多く書かれていたので、ご紹介いたします。
【2020/04/26追記】
- [Good!]：良い実装だと思ったところに付けます。
ラベルもレビューでのコミュニケーションで有効だと思います。
チーム全体の生産性を上げるためには
まず、チームの生産性が上がったということをどのように評価すれば良いのか考えた時に、メンバーが成長したらチームの生産性が上がったと言えると思っています。
そのためには、
- 1人1人の裁量を高めて、自律して行動していける時間を増やすこと
が大事だと考えています。
1人1人の自分が開発に参加しているという意識が高まることで、活動が活発になると思います。
おわりに
チームの性質によって、生産性を最大化するためには意識した方が良いことは異なるはずです。
そういった中で、状況に応じて臨機応変に対応できるように心がけ、自分の行動を改善し続けることが最も重要だと考えています。
また、ファシリテーターとして議論を進める人以外も、意識して工夫していけることは多くあると思います。どのようにすればもっと円滑に進むか考え、それらを行動に移せていけると強みになっていくはずです!
最後になりますが、エンジニアは常にチームで仕事をするため、チームは個人の生産性や幸福度に直接影響をもたらします。自分の目指すエンジニア像である チームとしての生産性を最大化できる人 に近づいていけるように、日々ソフトウェアエンジニアリングの「ソフトスキル」の方も磨いていきたいです。
長文読んでいただきありがとうございました。
また、自分の中で気づきがありましたら、追記します📝
それでは良いお年を！🎍
小幡 十矛（Obata Tomu）｜価値を共創するエンジニア
東京を拠点に、アプリ開発・新規事業立ち上げ・ブランドづくりに取り組んでいます。
2021年にサイバーエージェントへ新卒入社後、ABEMA Live や AmebaブログのiOSアプリ開発を担当。
現在はフリーランスとして、複数の新規プロダクトやリアル店舗の立ち上げに挑戦中です。
🎯 Mission｜人の挑戦を加速する仕組みをつくる
── アイデアを形にし、前に進める“土台”や“場”を共創する
📌 「リアルな場 × デジタル」の可能性を探求し、新しい挑戦が生まれる土壌を育てる
🔹 エンジニアリング × ビジネスの視点から、アイデアを形にし、成長を支えていく
🔹 実店舗オーナーを目指し、オーダースーツ・ドライヘッドスパ・セレクトショップの複合店舗の立ち上げにも挑戦中
👥 特に、社会人1〜5年目くらいで
「やりたい気持ちはあるけど、最初の一歩に迷っている」方へ。
「自分の可能性をもっと広げたい」
「モヤっとしたアイデアがあるけど、どう進めていいかわからない」
そんなフェーズにいる方と、一緒に考えたり、手を動かしたりできたら嬉しいです。
🌱 「挑戦したい20代」との出会いも、大切にしています。
「ちょっと話してみたいな」くらいの気持ちで、気軽に声をかけてもらえたら嬉しいです！🙌
🌐 詳しいプロフィールはこちら
https://obata-tomu.jp/