WEBエンジニアがプロダクト開発を通じて学んだチームビルディングに関する5つのTIPS
インタ ーネットの世紀のプロダクト ・マネジャーの役割は 、最高のプロダクトの設計、エンジニアリング、開発を担う人々とともに働くことだ
— 『How Google Works』
本記事は Livesenseその3 Advent Calendar 2016 の24日目の記事です。いきなり格好つけた言葉から入ってしまいましたが、クリスマスイブなので。同様に以下ポエミーかつエモ目の記事となります、ご容赦ください。
私は転職会議というWEBサービスの開発に携わっており、2年ほど前から開発チーム（エンジニア/デザイナ/ディレクタの混成チーム）のマネージャーとしてプロダクトオーナー（PLは持たない）兼エンジニアマネージャーのような仕事をしてきました（最近では二足のワラジに限界を感じてプロダクトマネージメントのみに集中していますが）。
本記事では、プロダクト開発に携わってきた中で、グロースに繋がったと思われるチームビルディングの要素を、5つのTIPSとして書いてみました（完全主観ですが）。
開発チームのリーダーを任された当時、マネタイズ方面に舵を切り始めた頃でした。当時は、マネタイズに向けてやるべきことはある程度わかっていたものの、結果が思うように出ておらず、もがいていました。ただ、現在では、当時の8倍程に売上規模は成長しており、当時から課題であったマネタイズ方面でのグロースもある程度成果が出てきているのかなと思っています。自分自身は、エンジニアチームを率いる事自体は初めてではなかったものの、プロダクト/サービスのグロースを含めて責任を持ってチームマネジメントをした経験は初めてのことだったため、悪戦苦闘、失敗を繰り返しでしたが、チームであれこれ試行錯誤してきたことの一部はサービスの成長に繋がったのではないかと思っています。会社の文化や組織制度等によってとるべきプラクティスは異なると思いますが、この記事が少しでも誰かのご参考になれば幸いです。
TIPS1. みんなをバスに乗せる
アジャイルサムライという本からの引用です。
開発に携わるメンバー（エンジニア/デザイナ/ディレクタ/事業企画)の向かう方向性が揃っていないとプロダクト開発が中々前に進みません。当初チームは多かれ少なかれこのような状態で、何か施策をやろうとした時にも、関係者の認識が揃わず、例えば仕様１つ決めるのにも時間がかかってしまっていたと思います。そこで具体的にやったことは以下の様なことでした。
- プロジェクト制を廃止して、全員（当時8人程）で１つのプロダクトバックログを見ながら開発を行う。（それ以前は2~3人程小チームで独立したプロジェクトを行っていました）
- プロダクトビジョンを明文化し、デザイナと一緒にビジュアライズ。興味があるメンバーにはこのプロセスに関わってもらう。
中々方向性が揃わなかったものの、幸いなことに、根本的にサービスをグロースさせたいという意思の強いメンバーが揃っていたため、このようなプロセスを経ることで施策実施までのスピードが多少あがったと思います。ただ、この取り組み自体は単体で影響が出るというよりも、チームとして成果を出すための、最低限の条件な気もしています。
TIPS2. ABテストのデータに基づいて前に進む
最近では当たり前のことだと思うのですが、以前はABテストの仕組みが整っていませんでした。その結果、仕様について細かい点で議論が長引いたり、施策効果の検証に時間がかかってしまっていました。
ABテストの仕組みを導入したことで、この状況が大きく変わりました。検証にかかる時間が短くなったことは当然のことながら、ABテストによって各メンバーの予想もしないような結果となることも多く、その結果、あまり思い込みにとらわれずに試してみること、あれこれ議論だけを重ねてスピードを落とすよりは、検証してみることの方が良いかもしれない、という意識が芽生えてきたように思います。ABテストを行う前後でチームの文化が大きく変わったようにも感じました（進研ゼミのDMマンガのような話であれですが）。
ひげぽんさんの記事にもあるように、ABテストをただ単にやれば良いというわけではもちろんないのですが、チームが前に進むには確実に必要な仕組みだったと思います。
なお、転職会議におけるABテストについては、昨年のアドベントカレンダーにて転職会議の開発メンバーが共有していますので、こちらもあわせてご参照ください。
TIPS3. 勢いを加速する
チームに徐々に勢いがついてきた頃に以下のような取り組みもしてみました。
- 基本的な開発のイテレーションサイクルを2週間から1週間に短縮。
- 一度プロジェクトを解体したが、少数のメンバーには、通常のイテレーションプロセスから切り離して、短期集中型のKPI改善プロジェクトを回してもらう。
- このようなプロジェクトでは、スクラム方式のプロセスよりも、カンバン方式のプロセスをとる。
- むしろ、プロセスなんて本人たちが好きにしてもらう。
- 意識的に「楽しさ」を作る
最後の「楽しさ」を作る、という点は意外と大事だと思っています。
この辺は自分自身はそこまで得意ではないのですが、チームにこのようなことがうまいまい方がいて、色々とやってくれています。例えば、リリースしたらシャンパンを空けたり、植樹したり、テープカットしたりとあの手この手でお祝いをしようとします。また、社長におねだりして、高い目標を達成した際に、メンバー全員で豪華で美味しい焼肉を食べに行ったりしました。このような楽しさを作っていくことも、”勢い”という観点では大事だったと思います（ただ、同じことばっかりやっているとマンネリ感が出てくるので、ここの工夫は本当に大変だな〜、といつも感じています）。
TIPS4. 当事者意識と自信の醸成
転職会議のグロースに関係するチームビルディングにおいて、この点が一番重要だったと感じています。
細かい改善を行う上で、エンジニアやデザイナーのような作りて自身が改善施策を考えて、実行し、計測して、また改善してく、というようなPDCAのプロセスを回すことはかなり効率が良いことは多くの方が考えていると思います。このような状態を作り出すために、どうしたら良いでしょうか？言葉にするとかんたんなことではありますが、その状態に一足飛びに至ったわけではなかったと考えています。
まずは、自分たち自身が施策提案を行うということを推奨しました。日々の仕事で開発工数からも施策を考える時間を差し引くようにして、なるべく自分たち自身で考えて実行するという状況を作り出そうとしました。
ただ、いきなりそのような施策がうまくいくわけではありませんでした。当時はエンジニア自身が施策を考えて改善するという経験も少なかったこともあり、なかなか大きくプロダクトを改善する施策が出てきたわけではありませんでした。
この状況が徐々に変わってきたのが、エンジニア自身がうまく改善できる！という成功体験を積んだ時からだったと思います。
当時、一部のエンジニアに経験豊富なWEBディレクタと一緒に高速なPDCAを回してもらい（通常のバックログでの開発タスクの管理のラインとは別に）、一緒になって改善施策を考え、ディレクタから改善方法についてのノウハウを注入してもらいました。（この時の話については、以下のスライドにまとめられていますので、よろしければご参照ください）
その結果、その時の経験はチーム全体が自分たち自身で、まさに結果が出ることで、さらに結果が良くなっていくという正のスパイラルが生まれていました。翌年には残念ながら当時その行動を率いてくれたディレクターは会社を去ってしまうのですが、エンジニアとデザイナだけでどうにか改善施策を回せるようになっていました。（その内容についても別のスライドにて共有されているのでご参照ください。）
この事の教訓としては、成功体験が、より良い成功を作るための呼び水になることだと思います。ですので、この時の経験を踏まえ、自分たち自身も、何か新しいことを行う際には、なるべく小さいことからで良いので、成功体験を積むような状況を作ることだと思います。難しい課題に向かい合った際には、いきなり大きくて時間のかかる解決策を投じるよりも、小さな改善を積み重ねて行ったほうが良いと考えています。
また、経験的に、このような改善がうまくハマってできるようになっているには以下のような状態が成り立っていると良いと思います。
- KPIが十分にシンプルである。
- そのKPIを達成するための要素が因数分解されていて、要素感の重みがきちんと意識されている（例えば、ECサイトの購入においては、商品ページのPV、購入ページへのリンクのクリック率、購入フォームの通過率、等に分解される、というようなことです）
- 考え方のフレームワークが共有されていることで、密度の高い仮説検証/トライアンドエラーが高速に繰り返すことができる。
- 仮説検証を行うためのデータ検証が行える状態になっている。
- その上でメンバーを信頼して任せる！（何かあったときだけケツを拭く覚悟）
とりわけ、成熟していない組織においてはKPIが十分にシンプルであることは非常にだと思います。もちろん、すべての課題がシンプルなKPIだけで扱うことは難しいと思いますが、それに取り組むためにはチームが十分な経験を積んでいる必要があると思います。誰しもいきなり難しい問題に立ち向かえません。
TIPS5. ビジネス系メンバーとの協調
とりわけマネタイズフェーズではビジネスや事業戦略に長けたメンバーの力が必ず必要だと思います。ただ、エンジニアやデザイナ等の作りてはサービス自体に思い入れはあっても、収益を優先しすぎる施策には反発しがちですし、逆に、ビジネス系メンバーはそのような感覚を理解しづらいということがあります。
やはり当初はこの辺の関係がうまく行っておらず、TIPS1で述べたように方向性がバラバラになりがちでした。ただ、プロダクトグロースを行う中で、以下のような点を通じて、ビジネス系メンバーと開発系メンバーの心理的距離感が縮まっていったように思います。
- 営業系メンバーも含めて朝会等のミーティングでコミュニケーションをとり、同列で改善施策を考える。
- 朝会の場に「小話」のコーナーがあって、仕事とは関係のない一見くだらないような話を持ち回りでしていったことが、結果
- ビジネス系メンバーの方も開発系メンバーの気持ちを理解してくれようと歩み寄ってもらえた（例えば、開発工数に関しての考え方に理解を示してくれた）
- 中長期的な影響があることについては、自分自身がビジネス系の担当者と話し合い、十分に理解を深めた上で、メンバーに対して自分の言葉で共有する
これらの活動は結果として、開発スピードの改善の一助になっていたと思います（一方、組織の規模が大きくなってきくなってくると、このような文化をどう維持するかが課題になってきます）。
以上、プロダクトの成長に関するTIPSを書いてきましたが、これは開発系/ビジネス系のメンバーを合わせて10人前後の頃の経験をもとに書いています。
一方で、プロダクトが成長し、ネタイズ的に軌道に乗ってくると、そのプロダクトにより多くのメンバーを集まってきます。人数の増加によって組織の質が変わってくるため、同じやり方を続けていても十分にスケールしない、ともすれば、グッドプラクティスだと思っていたことが、バッドプラクティスになっていく、ということもあると思います。プロダクト開発の組織運営に関しては試行錯誤の連続であり、色々と失敗することも多く、また今も模索している最中です。
この辺も書きたいことは色々とあるのですが、また大きいテーマになってしまうためまた別の記事で共有できればと思います。
終わり。
