いろいろやるチーム

この記事は CrowdWorks Advent Calendar 2016 の16日目の記事です。

最近脳科学にちょっと興味ありの エンジニアリングマネージャーの @oura です。

しばし前の話になりますが、いろいろやるチーム¹のマネジメントを経験する機会がありました。当時ノウハウや情報があまり得られず、だいぶ試行錯誤していたので、それを共有できればと思います。²

チーム結成時の状況

2016年7月頃になります。開発のチームメンバーは私含め3名で、またその内ひとりは業務委託で完全リモートという構成でした。そしてチームが担当するのは3つの部署であり、3つの部署のうち一つは、その部署の中でも2つの役割の異なるグループに分かれているような組織で、実質チームは４つの組織の担当となってました。
それまでもグループで複数の組織に対応することはしていたのですが、このチーム結成を期に考え直してみました。そこで改めていくつかの問題を意識することになります。

問題とは

それは数多くありましたが、大きい問題として捉えていたのは以下のようなものです。

• 問題1: チームの位置付けが曖昧。
• 問題2: タスク管理の難易度が高い。複数プロジェクトの管理が必要で、かつ開発メンバーにリモートワーカーがいる。
• 問題3: 部署メンバーと開発メンバーとの関係の浅さ。

問題にどう立ち向かったか

では、それぞれの問題に対してどう対処していったのかを具体的にみていきます。

問題1: チームの位置付けが曖昧

解決策: チームのキックオフの中で「もう "その他チーム" でいいんじゃないのか？」という意見も出たりしましたが、グループの象徴的なチームであり、関係する事業が拡大すればこのチームから今後派生してチームが生まれていくだろうと考え、最終的にはコアユニットという名称にしました。そして「我々はなぜここにいるのか」を考え、出来る限り関連する部署毎の目標を設けました。

問題2: 部署メンバーと開発メンバーとの関係の浅さ

解決策: プロセスの見直しを実施しました。何故なら締め切り間近の依頼が個人宛に届き、無理です。ごめんなさいすることで関係が悪化するということをしばし目にしていたからです。そこで第一歩として、お互いを意識する仕組みが必要だと考えました。

各部署との進め方。「アイテム」と記載しているのはプロダクトバックログアイテムのことになります。

それぞれのイベントをみていきましょう。

週次ミーティング

このミーティングがあることで部署メンバーが自分の作業に関連して開発が発生することを失念するのを防げたり、依頼に気を使わせてしまったりすることがなくなります。開催にあたって部署含む参加メンバーには以下を周知してます。

• 必要に応じて開催。³
• 部署毎に個別で実施。
• 次スプリントでやるべきことを見直し、準備完了の状態にする。(バックログのグルーミング⁴)
• 準備完了(Ready)になったタスクの優先順位づけを行う。
• 月次で振り返りを実施。

月次ミーティング

当初のこのミーティングの目的は各部署から集まったタスクの優先順位を部署横断で決めていくことでした。しかしながら実際に運用を始めてみると、各部署毎の週次ミーティングを設けることで、ある程度バッファをもって取り組めるため、「我先に」という状況が発生しませんでした。そこで趣旨と開催頻度を変更し、結果の共有の場としましたため、以下のような内容となっております。

• 参加者は各部署からひとりづつ参加。
• ミーティングの内容は開発からの報告がメインで、各部署間の調整を必要に応じで実施。
• 週次ミーティングで集めたKPTを共有し、それをもとに開発が作成した、次月の改善ポイントの報告を行う。

週次報告 on Slack

週次の報告は Slack 上で簡易に行いました。内容としては前週の作業のサマリとバーンダウンチャート、ベロシティー、前週と次週のポイントなどになります。

↓このような具合です。

問題3: タスク管理の難易度が高い

解決策: まったくノウハウの無い中、 @koichiro より書籍「エッセンシャルスクラム」の紹介があり、それを参考にしました。ありがたや。当初の各部署メンバーを集めての優先度決めもこの書籍を参考にしてます。
複数プロジェクトのタスクを横断的にを扱えるということで プロジェクト管理には Waffle.io を選びました。また、各部署にどれくらいリソースを割いているのかを可視化するために toggl も導入⁵しました。
「我先に」の状況でないため、最終的なプランニングは開発メンバーのみで行い、金曜日までにフィックスされ、各部署メンバーは月曜日に参照できると行った具合です。

月次ミーティングでは各部署毎の作業時間がこのようにレポーティングされます。

まとめ

試みを始めた当初は、事業部メンバーにスクラム開発に関する基本的な説明を実施することからはじめる必要があったため不安でいっぱいでしたが、実際やってみると、一定度の理解と関心をもっていただけ、前進できた感覚をもちましたし、事業部メンバーに匿名アンケートを採ってみたところ良いフィードバックばかりでした。

上記はただの例であり、当然そのまま他の環境で適用するのは難しいとは思います。正解のないマネジメントの世界。とりあえずやってみることが重要で、振り返りを実施して成果が出る方向へやり方はどんどん変えてけばいいと思いますし、どんどん変えていかねばと思う今日このごろです。
はじめにも書きましたが、マネジメントの情報ってなかなか表に出てこないもので、この記事がどなたかの助けになると良いなと想いつつ締めたいと思います。

明日は私と同じく EM の @teriyakisan から「マネージャーをやりたくなかった人が開発組織のマネージャーになるまで」をお送りします。お楽しみに！

---

1. 厳密にはユニットと呼んでました。 ↩

2. クラウドワークス エンジニアブログ にて @yo-iida 執筆の「エンジニア×他部署のチームビルディングにおいて重要なこと」がありますのでそちらもどうぞ！本記事はそこでのお話の一部です。 @yo-iida が所属のユニットとは別ユニットのお話です。 ↩

3. 運用していく中で一定タスクが出きった部署などがでてきたため追加してます。 ↩

4. プロダクトバックログアイテムの作成と改良、見積もり、優先順位付けなどを指します。 ↩

5. 作業内容の登録は面倒でしたが、togglで登録したものを Slack でチームに共有する仕組みが作られ、チームメンバーの作業の見える化にも繋がりました。 ↩