GLOBIS Advent Calendarも5日目。おはようございます、グロービスの染谷です。
Qiita自体の投稿はほぼ1年ぶりなので、簡単に自己紹介してから、
タイトルにもあるようなチームビルディングの話がメインで、
チームビルディング：プロダクト＝8：2 くらいの割合になっているので、
プロダクトマネジメントに携わってる方以外にも、新規事業作ってる方の参考になればと思います。
自己紹介
グロービス学び放題という経営に必要な知識を体系的に学べるサブスクリプション学習サービスのweb領域のプロダクトマネージメントをしています。
新卒でサイバーエージェントに入社し、アドテクノロジー周りで事業開発から開発実装までを経験し、インバウンド事業で起業、その後日本伝統工芸に関するスタートアップで代表を務め、2019年1月よりグロービスにおります。
今回のチームビルディングの目的
何のためにチームビルディングをする必要があったのかを簡単にご紹介します。
概要
グロービス学び放題は2017年3月にリリースしたサービスで、
個人ユーザーのみならず、会社にお勤めの方（法人ユーザー）にもご利用いただいております。
スクラム体制でプロダクト開発を行っており、さらなるプロダクトおよび事業の成長を今も追求しています。
背景
きっかけは先月リリースされたグロービス学び放題の英語版である「GLOBIS Unlimited」。
グロービスでは、法人研修や経営大学院を主たる事業として行っており、日本語だけでなく、英語でのサービス提供を行っており、グロービス学び放題もその英語版の開発がスタートしたという訳です。
既存の開発チームはGLOBIS Unlimitedの立ち上げにシフトし、グロービス学び放題は私がゼロから新しくチーム組成をすることになりました。
社内の期待
最初は驚きでしたが、自分の性格もあり、「まぁ、なんとかなるかな〜」と思い、スタート。
上長から言われたことは以下。
- 英語版のリリースを急ぎたいが、日本語版のプロダクトの成長をしていきたい
- 部署としてメインの売上であるグロービス学び放題事業の拡大は欠かせない
- 必要なメンバーは採用してよい
つまり、開発メンバーはいなくなるけど、プロダクト/事業は成長させてほしい
…とのことでした。
いざアクション開始！！
心に決めた3箇条
新しくアクションを起こす時は、着手前に基本方針を定めると、判断がブレにくくなります。
さらに、その結果として、失敗してもそこから学べるものが明確になるので、次のアクションに活かしやすくなり、その成功率を上げることができます。
プロダクトのA/Bテストでも、テスト前に何を基準にして評価するかを決めるのは必須で、主観的にデータを解釈することを避けることができます。
今回の基本方針は以下の3つ。
誰をバスに乗せるか
名著「ビジョナリーカンパニー2」という本でも紹介されているフレーズですが、本当に大事な言葉だと思います。スタートアップの経営をやっていた時も、”人を雇う”ということは極めてセンシティブに考える必要があることを痛感しました。すでに持っているスキル以外にも、
・コミュニケーションスタイル
・本人がやりたいことと直近のアクションの整合性（楽しめるか、本人の成長にもつながるか）
・業務以外で何か得られるものはあるか
…etc
そういったことを総合的に判断し、ハイパフォームすると思った人だけに絞りました。
そして、その責任は全部自分が負います（…この気概があるかないかで結構みんなのテンションが変わる)
失敗の責任は自分にあり
「誰をバスに乗せるか」の最後にも書いてますが、最終的に自分が責任を持つという自覚とそれに伴った行動は欠かさないように気をつけました。タスクベースで、多少優先度の低いことは、リスケしたり、やらないという判断もしますが、やると決めたことに対しては何でもやり抜く姿勢は貫きます。
また、それと同時にその失敗を開示し、チームに助けを求め、一緒に解決していくスタンスもセットであるべきです。個人よりもチームで協力する方がパフォーマンス上がるので、全体の責任は自分が持ち、各分掌の責任はしっかりと各メンバーが持つことを意識づけます
夢を語る
事業KPIを追う状態でもあり、短期的な数値目標にフォーカスしがちだったので、新しい機能開発をする時に、少し抽象であっても、機能の拡張性や初期リリース後の展望についてはきちんと話すようにしました。
野球で例えると、一塁打をいくつも打つよりも、ホームランを打ちたいと思っているので、足元は適度にリソースを貼りつつ、ホームランを打つのに十分な投資を続ける…というスタンスを維持しました。ただし、結果についてはしっかりとデータに基づき考察し、思い込みで行動しないように心がけるのは必須です。
やったこと
具体的なアクションについて触れていきます。
メンバー集めは、まずは社内から。社内ルールを理解するのが大事！！
最初はほぼ一人から始まったので、まずは二人目、三人目を探します。
順番は以下のイメージ進めました。
- まずは、近くで仕事している人
- 次に、一緒に仕事したことがある別チームの人
- そして、別のチームの人の近くで仕事している人
今回は社内の「２０%ルール」を使いました。
２０%ルールとは、Googleなどで導入されているルールで、私のいる部署でも運用があり、今回は何人かに声をかけ、そのルールを使い、デザイナー１人、エンジニア１人、PdM１人に手伝ってもらうことができました。
…ここまで、約２週間。
次に社外からリクルーティング
社内メンバーが固まってきたら、社外にも声を掛けましょう。
この時も進め方は以下のイメージ。
- いつもお世話になっている人（今までの起業などで）
- 過去の同僚・上司
- 上記の知り合い
まずはfacebookやLINEで声かけて、ランチや飲みに行き、それぞれのニーズを聞きました。そこでやりたいこととやりたくないことを聞いて、誰をバスに乗せるべきかを判断します。手伝ってくれる動機は人により様々で、報酬目的な人もいれば、漠然と副業してみたい人もいたり、新しいプロダクトに触れて自分の経験を増やしたい人…などなど。
…ご飯いったりして、概ねJOINすることに合意するまで約１ヶ月。
人が集まったら、チームとしての稼働開始：ワークフロー作りとモチベーションの波を作る
バスに乗る人が決まったら、後はみんなでみんなの働く環境構築しました。
最初の方はほぼ毎週（もしかしたら毎日くらい？）フローの修正を行いました。
基本はGoogle docsに追記し、Slackで通知（…地道。。）。必要があれば、他チームに調整。
- 施策のワークフロー
- デザインのレビューフロー
- 開発（特にgithubまわり）のPRのフロー
- オペとのリリースフロー …etc
ワークフローの他に、外部メンバーが週１-２稼働だったり、リモート稼働だったので、飲み会も実施。
チームとして動きはじめて、２ヶ月位はお互いの顔も分からない状態だったので、顔合わせ兼ねての飲み会でしたが大盛りあがり。その後のSlackのコミュニケーションも盛んになり、改めて顔を知っていることによるパフォーマンス向上を感じました。
▲ワークフローの目次
振り返ってみる…
7月中旬からチームビルディングをはじめてからのリリース数をグラフにしてみました。
リリース内容の大きさにはバラツキがありますが、概ね開発速度が上がっている印象
良い結果が出た中、それぞれのチームメンバーにだいたいのことは任せた結果、様々な気付きがありました。
助かったこと
社内ルール:20%ルールとリモートワーク制度
今のチームメンバーは約10人なのですが、その半数以上は社内ルールを活用した結果でした。（20%ルールで社内から3人、リモートワーク制度で3人）リモートワーク制度は普段から使っていたので馴染みがありましたが、20％ルールは活用すると本当に協力で、社内の叡智が結集される感じで、とても助かりました。
社内メンバーの協力
7月は一人開発体制、8月以降に色々なメンバーが入ってチーム開発体制となりました。しかし、人が増えるに伴い、自分一人ではレクチャーしきれない部分も多く、開発を進めながら社内のステークホルダーや他の開発チームのエンジニアにはお世話になりました。
メンバーのガッツ
集まったみんなが基本的に「ガンガン行こうぜ！」のスタイルだったことです。
そういうタイプの人を意図的に集めた背景もありますが、予想以上にガンガンくるので、最近はプロダクトマネジメントする立場としてはタジタジです。その一方、どんどん権限移譲できるのでチームとしての開発スピードはまだまだ上がりそうです。
学んだこと
今振り返ってと学んだことは3つにまとめました。
それぞれの詳細は今までの内容を読めばわかると思うので割愛します。
これからも引き続きグロービス学び放題をよろしくお願いいたします。
・社内外の人脈ネットワークは日々ためておくべき
・バスに誰を乗せるかは大事。乗ったからには暴れてもらうのもさらに大事
・お互いの顔を知ることは大事。生産性上がる！！
最後に…
ここまで読んで頂きありがとうございます〜