青空な日々

ITエンジニア関連で興味あることをアウトプットして共有したいブログ

仕事で分報を導入した話しとその振り返りの話。

チーム内で分報を導入して1ヶ月後たった。

転職初日にSlack分報の導入を提案して採用され1ヶ月たった。
今回はその経緯と感想をアウトプットする。

リーダーが進捗確認するのに口頭だとツライとボヤく。

チームに参加した初日、環境構築の進捗を聞かれて答えていた際の出来事。
詳しく聞いてみると以下の問題が分かった。

  • メンバーが集中していると邪魔しちゃう気がして話しかけづらい
  • 報告が1日の終りだと問題があっても把握するのが遅くなる
  • 逆に自分(リーダー)の都合が悪いときがあるとその日は進捗が聞けない

というわけで、お互いの状況に関わらず報告・確認が可能で、
もっと頻繁に報告できる仕組みが必要だと分かった。

Slack分報の提案

上記の問題解決としてSlack分報を提案してみた。

Slack分報については詳細は以下を参照のこと。
Slackで簡単に「日報」ならぬ「分報」をチームで実現する3ステップ〜Problemが10分で解決するチャットを作ろう

ざっくりまとめると仕事用のTwitterみたいなもの。
Twitterで、〇〇が分からない~、とか東京駅でオススメの居酒屋をおしえて!とかやっている、アレ。

リーダーに上記のサイトを教えた後、
口頭でそれぞれの問題に対する説明をしたところ試しに導入して見ることとなった。

  • メンバーが集中していると邪魔しちゃう気がして話しかけづらい
    →メンバーの都合が良い時に勝手に書くので邪魔しない!
  • 報告が1日の終りだと問題があっても把握するのが遅くなる
    →何か問題があればすぐ分報に報告があがるので対応速度アップ!
  • 逆に自分(リーダー)の都合が悪いときがあると進捗が聞けない
    →リーダーの都合が良いときに進捗確認が出来る!

ただし、人によって合う/合わないがあると思ったので、
とりあえず一定期間はお試しとして入れてみて振り返りをすることにした。
(この時はオフィスの引越などもあったので2週間後にした)

実際の分報内容。

業務上問題がありそうな部分はマスクしているが以下のような感じで運用している。


  • (自分)おはようございます。
    今日は昨日の続きでHoge機能を実装する。
    修正先のソースがHoge.javaだと思うんだけど、
    どうも違うっぽい?
  • (リーダーから返信)Hoge.javaじゃなくて、Hoges.javaだな。
  • なるほど!ありがとう!


  • (他のメンバー)Fuga機能の実装が終わった!
    💯2
     ※こんな感じで作業報告にリアクションが付く



ちなみに自分のチームではメンバー間もお互いの分報を見ていて、
リアクションを送りあったりしている。
ただし個人差があって、自分はリアクションするけど他のメンバーはあまりリアクションしない。
ただ反応はしないだけで見てはいるようだ。

振り返り結果について。

導入後、1.5週間後に振り返りをした。
当初は2週間後に振り返りと言っていたが、
思いのほか好評だったのでもう良くね?となって振り返りしてみた。

チーム内でkptなどの振り返り文化がなかったので、
振り返りは単純に意見を聞いただけ。

良かった点

  • リーダーは進捗確認しやすくなった。
  • 壁打の効果
    分報に書き出そうとする時点で自分からの「アウトプット」になるので、
    問題や課題が整理できる(整理される)。
    これによって誰かが回答する前に問題や課題が解決される場合がある。
    これを自分の中では壁打ちと定義している。
    一般的?にはオートクラインという名前らしい。
    (先輩に話しかけて質問していたら答えがわかった経験はないだろうか?アレのことである)

課題になりそうな点(今は大丈夫だけど)

  • 定期的に進捗をアウトプットする習慣がない人。
  • Twitterの経験が無い人はイメージが掴みづらい。
    →これらは慣れるしか無い気がする…。

新しい課題

その後、導入から1ヶ月ほど経ってから新しい課題が見つかった。

メンバーの一人から分報に書けない(書きたくない)作業があるという話を聞いた。
というのもそのメンバーがリーダーの実装方針に反対のとき、
隠れて自分の理想とする実装をしていたらしい。
そのため、それを分報に書くとバレるのでどうしよう?という話だった。
(今まではレビューで説得してみて通ればそのまま、ダメなら戻すということをしていたらしい)

それは分報の問題ではなくてチーム内のコミュニケーションの話なので、
分報の是非の問題ではないと思う。
が、問題に感じているのは事実なので何か考えなければならないと思っている。

幸いにもそのメンバーは、理屈では「隠れて自分の理想とする実装」するのが良くないと分かっているようだ。
そのため、実装方針を決める際はもっとチーム内で納得するまでコミュニケーションを取るようしようね、
というところを一旦の落とし所とした。

今後について

今後もチームメンバーが増える予定があるので、
新しいメンバーが来た際に何も考えずに「分報をやれ!」と押し付けないようにしたい。
またそういうタイミングで見直しもしていきたい。

進捗や問題の報告の方法としてより良い方法があれば、チームで相談して乗り換えられるようにしたいと思う。