この記事は リクルートライフスタイル Advent Calendar 2015 の二日目です。
ホットペッパービューティーで開発を担当している須藤です。
現在ホットペッパービューティーでは開発基盤の見直しにあたって様々な取り組みを行っていますが、大体そのフィジビリを無茶振りされる役割です(笑)
新しいことは大変なことも多いですが、その分刺激的でやりがいもありますね！
この記事では自律的チームを作るために僕が心がけていること、チームで実践していることを書いてみます。
まだまだ僕自身未熟者ですが、少しでも誰かのヒントになれば幸いです。
目新しいことは特に書いてありません！
- 前提（対象とするチームの想定）
- 人数は5~10名
- ある程度継続的なチームである
- 数週間から数ヶ月単位の案件やプロジェクト
自律的なチームとは
開発プロセスは関係ありません。
「Don't just do agile, be agile」の通り、ウォーターフォール型開発でもチームは自律的になれます。
ここでは自律的なチームを「リーダーが不在でもプロジェクトを推進できる状態にあるチーム」とします。
つまり、「自律的チームを作る≒リーダーの仕事をなくすこと」と考えます。
自律的なチームにリーダーは要りません。
しかし、実際のプロジェクトではリーダーが存在します。
職能、経験、スキル、色んな要素で決まりますが、それはつまるところ責任者です。
ここではプロジェクトに責任を負う人をリーダーとします。
そして、「責任」を上手に扱うことが自律的チームを作るコツです。
チームに責任を渡す
「リーダー（あるいは他の誰か）が言ったからそうした」に代表される言い訳の余地を残さないこと。
スケジュール、見積もり、設計、実装、テスト。
もしあなたがリーダーなら、チームで一番の経験と実力があるかもしれません。
あなたは当然チームを助けるべきです。
しかし、強制してはいけません。
判断はチームに任せるべきです。
そうしなければ自己組織化は進みません。
経験上、我慢できずチームから責任を取り返してしまう（権力を発動する）人が多いです。
自分も時々やってしまいます。
そのほうが、プロジェクトはうまくいくかもしれません。
でも恐らく自律的なチームにはならないです。
悩ましいですね。
プロジェクトが失敗して怒られたり、給料が下がったり、下手すりゃ首になるのはリーダーである貴方です。
自律的なチームを作るには覚悟が必要です。
チームから責任を逃がさない
時々、チームから責任を奪おうとする人がいます。
それは「とてもえらい人」だったり「違う部署の人」だったり、あるいは「別の開発チーム」だったりします。
（顧客、上司、アーキテクト、営業部、デザインやインフラチームを想像すると分かりやすいかも）
「XXXが言ったからそうした」「XXXがやってくれなかったからできなかった」 という言い訳をチームに許してはいけません。
もちろん、妥当な指摘なら採用すべきです。
肝心なのは、チームに最終判断をしてもらうことです。
ただし特にチームの初期構築段階で、チームが外のことまで対応するのは難しいでしょう。
外部からチームを守ること（必要に応じて戦うこと！）を、はじめの内はリーダーがやるほうがいいかと思います。
チームの成熟にしたがって、チームに任せていくようにしましょう。
（そうなっていくチームを見るのは楽しみでもあります）
チームにお願いすること
ここからはチームで実施している具体的なプラクティスをいくつか紹介します。
もちろん前述のとおり、チームに強制すべきではありません。
二週間ごとのふりかえり（1h程度）
これがすべてといってもいいです。これだけやればいいです(笑)。
他のことはチームで選択していけばいいと思います。
大切なのはチームが定期的に（気軽に）会話できる場を設定することです。
会話のネタとして「前の二週間でやったこと」「次の二週間でやること」「KPT」等を採用しますが、拘る必要はありません。
最初は「最近どう？」から始まる雑談でもいいです。
アジャイルサムライにもあったように、おいしいコーヒーと甘いドーナツがあるといいかもしれません。
特にKPTをやると積み上げて行くチームが多いですが、状況は刻一刻変化していくものですので、ふりかえりのスコープはいっそ直前にまで絞るくらいの割り切りがいいと思います。
一週間だと短すぎる＋二週間以上は長過ぎるため、これくらいの周期がちょうどいいと思います。
（チームで会話して修正していくといいと思います）
週次での計画会議（1h程度）
「何をいつまでに終わらせなければいけないか」をチームが認識する場です。
基本的にその翌週に「誰が何をやるか（終わらせるか）」を決めます。
作業見積もりはチームに任せます。
ガイドラインとして、中長期のマイルストーンがあるといいでしょう。
二週間分のタスク整理をし、翌週は軌道修正にあてる運用をすることが多いです。
（想定外タスクの発生や、見積もりが外れることなんてざらにありますよね！）
チームが、他のメンバーも含めたタスクとゴールを認識する場はあったほうがいいでしょう。
毎日の朝会(15分程度)
これはもう多くの現場でやっていることですね。
- 昨日やったこと
- 今日やること
- 困っていること
を各人が共有します。
一日に最低でも一度、メンバーが顔を合わせて会話する場を設ける意義はあるでしょう。
ベイビーステップ
設計書もソースコードもその他のタスクも、
できるだけ小さいステップで進めるようにします。
大きなタスクは道に迷いやすく、また属人化を進めます。
レビューをする場合、レビュアーの負担もレビューイの負担も増すのに、精度は下がります。
おすすめは、レビューを進捗にかかわらず実施することです。
途中でもいいので、その時点での成果物をレビューするようにすることで、強制的にステップを小刻みにします。
レビュータイムの設置や、WIPプルリクエストの活用などがそれにあたります。
自律的なチームにする意味とは？
最後になりますが、自律的なチームにする意味とはなんでしょうか？
アジャイルの文脈で自律的チームや自己組織化という言葉がよく語られますが、その目的はなんなのでしょうか？
作業効率化のためでしょうか？
あるいは「顧客/ユーザーにより価値を届ける」という何ともよく分からないフワフワした目的のためでしょうか？
勿論そういった面もあるかとは思います。
ですが（おおよそプロとしてあるまじき意見かもしれませんが）、僕は「楽しくするため」だと考えています。
自律的なチームは、チームが主体となります。
それはつまり、「誰かにやらされる仕事」ではなく「自らやる仕事」だと思います。
その方がやりがいもあるしきっと楽しいのではないでしょうか。
そしてことエンジニアリングについていえば、現場が楽しむことがいいモノづくりに繋がるんじゃないかと信じております。
甘っちょろい考えでごめんなさい！
初めてアドベントカレンダーに参加してみましたが、少しでも誰かの参考になれば幸いです。
技術ネタじゃなくて失礼しました（笑）