$shibayu36->blog;

クラスター株式会社のソフトウェアエンジニアです。エンジニアリングや読書などについて書いています。

チーム内プロジェクトが発足した時に、プロジェクトの朝会を用意すべきか

 最近チーム内で少し大きめなプロジェクトが発足して取り組んでいたのだが、その時プロジェクトの朝会(デイリースクラム)をするべきなのか悩んだことがあった。自分の中ではプロジェクトごとの朝会を用意すべきという結論に至ったのだが、今回はその結論に至った経緯をメモしておく。

 なおこのような開発フローの話は全てのチームに適用できるわけではなく、チームの状況によって最適なものが違うので、一つの参考例としてどうぞ。

前提

  • 7~8人ほどのチームで、3~4人で取り組むプロジェクトが発足したときの話
  • チーム全体の朝会は行っていて、進捗確認や問題解決はそこそこ上手く行っていた
  • チームの朝会は、一人ずつやったこと・やること・気になりごと・相談を発表するスタイル

プロジェクト朝会実施前

 最初は全体朝会で話せば良いかと思い、プロジェクトの朝会は用意していなかった。しかし、最初は良かったものの、徐々に問題が起き始めた。例えば以下のようなものが挙げられる。

  • プロジェクト自体の進行状況が細かく頭に入ってこない
  • プロジェクトに関わることのコミュニケーションが不足気味になっていた
  • プロジェクトの細かい問題になぜか気づけず、解決されないままになっていた

 この結果として、気づいたら問題が積み重なっていて、本当に間に合うのだろうかという状態になってしまっていた。

プロジェクト朝会を実施することに

 このままではまずいと感じ、プロジェクト朝会を実施することにした。

 この朝会は全体朝会のあとに10分ほどプロジェクトの関係者のみで行った。その中ではタスクの進行確認やプロジェクトに関わる気になりごとの発表、相談などを簡易的に行った。

 この結果、先程挙げた問題がある程度解消した。進行状況がある程度明快になり、細かな問題もメンバーから発言されるようになった。また、少なくとも毎日一回はコミュニケーションを取れる機会が強制的に作られ、連鎖的にSlackやGithubなどのコミュニケーションも多少活発化した。

なぜ問題が解決したのか

 単に、実施したら解決しましただと学びがないので、なぜ問題が一定解決したのかについて考えてみた。例えば次の二つが考えついた。

  • 全体で話すと、関係ない人の時間を奪う(とメンバーが思ってしまう)ので話しにくい
    • しかし関係者だけであれば、全員が関係する話なのでそのような障壁がない
    • 障壁がなくなれば、コミュニケーションがスムーズにいく
  • 全体で話すと、チーム全体でやっているいろんなことの話と、そのプロジェクトの話が混ざり、頭に入りにくい
    • しかし関係者だけだと、そのプロジェクトの話に集中できる
    • プロジェクトの話に集中できることで、進行状況を把握したり、細かい問題に気づいたりできるようになった

プロジェクト朝会を実施する時に注意したこと

 また、プロジェクト朝会を導入するときには、そのデメリットについても考えて注意をしたので、その点についても書いておく。

 プロジェクト朝会をするということは、反面チーム全体からそのプロジェクトだけ隔離された状況になりやすい。もしそのプロジェクトのチーム全体への情報共有が過剰に少なくなると、そのプロジェクト外の人からは全く状況が分からないということが起こることがある。その結果、実は進行状況が悪かったなどの問題が後から判明することがある。これはリスクである。

 今回はそのようなことにならないために、タスクの進行状況だけはチーム全体に見えるようにするよう配慮した。具体的には

  • チームではTrelloのボードを使って、現在のタスクを管理している
  • そのプロジェクトのタスクも、同じTrelloのボードに入れる
  • そのプロジェクトのタスクだけ、「○○プロジェクト」というラベルをカードに付けておく
  • チーム全体では、全体のボードを見るが、プロジェクト朝会ではTrelloのフィルタをかけて、そのプロジェクトのタスクに絞ってみる

という運用にした。これがうまく行ったかは分からないが、少なくとも外から進行状況が全く見えなくなるということは起こらなかったと思う。

まとめ

 自分の中では今回の経験から、チーム内で少し大きめのプロジェクトが発足したときはプロジェクトの朝会を用意したほうが良いという結論に至った。理由はコミュニケーションがスムーズになりやすいことと、話に集中できることで進行状況や問題の把握がし易いためである。

 もちろんチームの形によって最適な形は変わりうる。例えば20人規模のチームになった場合、そもそもチーム全体の朝会はせず、プロジェクトごとの定例だけ行い、全体の状況はそれぞれのプロジェクトリーダーと全体の統括をしている人だけで話す、という方法のほうが良いかもしれない。

 組織の大きさによってどのような形が最適かというところについて興味があるが、まだ体系的には学ぶことが出来ておらず、今の段階では経験則でしか話せていない。なので、このあたりについて体系的にまとまった本があれば読みたいと思った。