概要
こんにちは。 ホグワーツレガシーで魔法を使わず白菜ばかり使っている、広告技術部のUTです。
今回はチームが有機的に動くために実施している取り組みを紹介したいと思います。
有機的とは
「機械的組織」とは、職務権限が明確で、上層部に情報が集中し、トップの命令と指示によって統制される中央集権型組織だ。 それに対して「有機的組織」とは、職務権限が柔軟で、情報は組織内のあらゆる場所に分散し、水平的なネットワーク型の伝達構造をもつ分散型組織を指す。 by Salesforce https://www.salesforce.com/jp/blog/2012/12/vol5-be-social-empowerment.html
労働力の物量で戦うのではなく、片手で数えられる人数のチーム構成で変化の激しい現代を進んでいくには、有機的な組織で動いていかなければなりません。
もう少しチームという観点で分解・解釈していくと、
- 各人が各タスクにおいて何をすればよいかを理解しており、緊密な連携を取れている
- 各人がチーム内の課題を見つけ提案できている
- 他チームとの連携においてチーム内でのボトルネックが発生していない
となっている状態が有機的と言えるでしょう。
なにをやっているか
有機的にチームが動く上でどのような取り組みを行っているかを紹介します。 そんなのどの組織でもやってるし当たり前だろという内容や小粒なものも紹介しますが、一つでも「確かにこれはいいな」と思ってもらえるものがあると光栄です。
やることの明確化と振り返り
スクラム
弊チームではスクラムを取り入れていますが、厳密なスクラムではありません。 １週間の流れとしては
- スプリント前準備
- KPT
- スプリント計画
となっています。
スプリント前準備という聞き慣れないものがあるかと思いますが、
- 次のスプリントに何をやりたいか
- なにか課題はあったか
をチーム内で洗い出す時間になっています。 時間としては30分で終わるようにしていますが、こちらは事前に書きこんでもよいですし、このMTG内で考える時間も確保しているのでその場で出すでもよいです。 これとは別にバックログへのタスク切りは随時チーム全員が自由にやっています。 「チームとしてやるかわからないけどやったほうが良いか議論したい」みたいなものを挙げる場が少ないので、この前準備がその場になっています。
ほとんどのチームにとって、チームがスプリント計画前に集まり、バックログのレビューと見直しを行うことは有益です
上記の様に スプリント計画 | Atlassian にも書いてあります。 他チームからの依頼もここに上げておくことが多いです。
このスプリント前準備とバックログリファインメント自体は役割が違うので、バックログリファインメントは別途実施しています。
スプリント計画では開発チームがメインで何をやるかを決めています。 ベロシティをもとにある程度チケットを事前に分割して、どのタスクをやるかを決めています。 手を動かすチケットの粒度としては最大1日半くらい、調査などかかる時間が読めないものは1日半で見積もりしています。 また各タスクは作成時に「DONEの定義」を必須にしているため、このタスクは何をもって終了するのかを全員が意識できています。
スプリント終了時にはKPTを行っており、コロナ以前からずっとGoogleDocsに記載する形式を取っています。 昔は付箋でやっていたのですが結果を残したいけど付箋だと保管が面倒ということで（当時はMiroなどはなかったので）GoogleDocsになっています。
弊チームでは上記のようにそれぞれの項目でプライベートでのことも上げていたりするのも、特徴的かなと思います。 また文末についている絵文字は「自分もあげようと思った」だったり「上げられなかったけどめっちゃ同意」などの意味でつけています。 また同一Docsに追記しているので過去分もすぐに遡れるのも強みかなと思っています。
それぞれが責任を持つ
広告事業部ではチーム全員が扱うプロダクトの全範囲を改修するようにしています。 インフラのTerraformからフロントのJavaScriptまですべて担当しています。 具体例でいうと、チームでKubernetes（EKS）を運用しているため、EKSのバージョンアップは定期的なタスクとして必要ですが、チームメンバー全員が経験しており誰もができる状態になっています。 逆に直近では管理画面の改修を行った際、Reactで大量のform部分を刷新するというプロジェクトがあり、モブプロでチームが全員参加し全員が改修できる状態になっています。
また基本的にはタスクを取った人がそのタスクの責任者であるので、他チームへの相談などでチーム内の人がわからなければ本人が聞きに行くなど積極的に外へ出ていくようにしています。
開発形態として全範囲を見ることはベンチャーでは多いと思いますが、同時にSREや他チームがそれぞれ別で新たなトライをして各チームに還元しているので、新しい技術へのキャッチアップが効率的にできています。
他チームとのコミュニケーション
よく企画チームとのコミュニケーションの問題が取りざたされますが、あまりそこで問題になったことがありません。
よくありがちな問題として各チーム間の問い合わせがDMになっているということが多いかと思いますが、問い合わせ窓口としてSlackのワークフローを整備しています。
問い合わせ単位でそのスレッドで会話するので検索性もあり、オープンチャンネルなので他の人もフォローがしやすくなっています。
また、広告プロダクトにおける何を作るかに関しては週１の定例で営業、企画、エンジニアの特定メンバー（大体10人くらい？）が集まり議論しています。 開発チームも広告ドメインにおけるキャッチアップを行っており、企画チームもSQLによる分析やHTMLタグなどの調査など両者がそれぞれ侵食しあっているということもあり、 どちらもただ言われたことをやるという受託関係ではなく、それぞれ良いと思うものを発言できているのも強みかなと思います。
まとめ
会社の規模やフェーズによってやること、やりかたは全然違うかと思います。 これらは一朝一夕で実現したのではなく、日々改善を積み重ねてできたものなので、各組織に合うかもそれぞれかと思います。 ただ手前味噌ながら今の所チーム運営としてはうまく回っているかなと思ったので、チームの雰囲気を共有させてもらいました。
最初にも記載しましたが、こんなの当たり前だよが大多数かと思いますが、一つでも参考になる箇所があると幸いです。
