カウンターワークスに入社してからこれまで、プロダクトチームの立ち上げに注力してきたのですが、とりあえず序章は終えたかなというところまできたので、忘れないうちにやってきたことを書き残しておきます。

チームビルディングに関しては、個別の課題ベースの取り組み事例はよく見かけますが、立ち上げの全体の流れと取り組みをセットにした事例はあまり見かけないような気がしますので、誰かの何かの参考になれば幸いです。

入社当時のプロダクト開発の状況

カウンターワークスへは、2017/05にエンジニア職として入社しました。

入社した当時のプロダクト開発メンバーは、私の他に、エンジニア1名、HTML/CSSコーダー1名(業務委託。週1〜2ぐらい)、デザイナー1名(業務委託。週2ぐらい)でした。

入社前にCEO/CFOらからは課題感として「プロダクト開発リソースの不足で改善がなかなか進まない」「プロダクトとビジネスの接続、事業グロースのための開発がなかなかうまくいっていない」といったような話を聞いていました。

まずは状況を掴むために、入社2ヶ月ほど前からSlackに招待してもらい、そこでされている会話やQiitaTeamに蓄積されている記事を全て読んだり、入社後も1〜2週間ほど開発環境を整えたり小さいバグ修正をしたりしながら、プロダクト開発全体の課題感を掴んでいきました。

当時のプロダクト開発が抱えていた課題

プロダクトマネジメントが機能していない

リソースが少ないながらに少しずつ開発は進んでいたのですが、取り扱う課題の質が高くなく、解の質も同様でした。場当たり的な開発になっていました。

最小限のコアバリューの実現は既にできていたので、グロースや体験改善に注力する必要がありましたが、これがうまくできていませんでした。プロダクトマネジメントの経験があるメンバーがいなかったことも要因だと思います。

チームとして機能していない

必要最小限のドキュメントや、開発環境が整っておらず、チーム開発に移行できる状態ではありませんでした。(当時まだチームというほど人数がいないので、必要でなかったという側面もあるのですが)

また、チームが成長していくための仕組みがありませんでした。事業内容的に先行者の少ない領域のため、学習量が重要で、チームに効率的に学習成果がたまっていく仕組みをつくる必要がありましたが、それがありませんでした。稼働の短いメンバーが多いことも学習が進みにくい要因のひとつとなっていました。

リソースが足りない

扱っているプロダクトのサイズ感、事業のフェーズ感に対して、単純にリソースが足りない状況でした。そのため、スピードを優先した結果、プロダクトの品質も落ちがちでした。

また、事業のスタート時から尽力していただいていたエンジニアの方は徐々に離脱する予定となっていたため、そうなるとエンジニアが私ひとりになってしまう状況でした。

事業の戦略・状況を踏まえたリソースマネジメントが順調に進められていないことも課題でした。

プロダクトに負債がたまっている

DB設計、アプリケーションコード、インフラなどに技術的負債が蓄積していました。リソースが足りないまま開発を続けてきたことの影響が多分にあると思います。

また、プロダクトマネジメントが機能していなかったことが原因で、仕様面の負債もたまっていました。つぎはぎの仕様追加で、必要以上に複雑化している箇所が多々ありました。

このことに起因するバグの発生も多々あり、その対応に追われ、本質的な課題解決のための開発が進みにくい状態にありました。

STEP1.下準備(2017/05-06)

効果的なプロダクト開発をするにあたって、最低限揃えておく必要があるものを整えていった期間。

採用(「リソースが足りない」の解決)

前準備として、採用要件を決めるために、事業・プロダクトの状況を把握していきました。

最終的には、ざっくり下記の要件で採用することに決めました。

・高い専門性を持ったエンジニア < 広く対応できるエンジニア

プロダクトのフェーズとして、コアの価値は実現していましたが、使いやすさの面がかなり未成熟で、いわゆるバケツに穴が開いている状態にあったため、まずはそこを整えていくことが最優先、かつそこをやるだけでも短期的には事業成長できると判断しました。

そのため、現時点で専門性の高い技術の需要は低く、それよりも広く色々なスキル(もしくはそれをやるマインド)を持ったエンジニアの採用をするほうが優先であると考えました。

・技術特化マインド < 事業・UXに興味が持てるマインド

上にも書いたように、しばらくの間は現状プロダクトの延長線な開発が多くなりそうなことや、現時点ではシンプルな技術構成のプロダクトであり高度な技術力が必要となる場面が少なそうであったため、技術特化型よりも事業・UXに興味が持てるようなマインドの人をまず採用すると決めました。

採用は、やり始めたらすぐに採用できるというものでもなく、早く始めるのが大事なので、入社2週間の時点で打診してすぐにスタートしました。

採用実務(母集団形成・面談)もやりましたが、ここは前職のビズリーチでの経験が活きたなと思います。

結果として、7〜9月ごろの間にエンジニア2名、デザイナー1名の採用決定に至りました。

データの可視化・可視化のための環境整備(「プロダクトマネジメントが機能していない」「チームとして機能していない」の解決)

当時、KPI出力ロジックがアプリケーション上に実装してあり、エクセル&Slackチャンネルに週次で出力してMTGで共有している状態でした。

出力している指標も少なく、自分たちのサービス・プロダクトのおかれている状況の把握が不足していました。地図が頼りない状態です。

また、クイックなデータ分析ができないため、施策ベースでの分析が難しいし、学習のレバレッジが効きづらい状態にありました。

そのため、Redashを導入して、データをだれでもいつでもクイックに活用できる状態をつくりました。

主要なKPIや施策の効果検証データは、Redash上に表示して共有するようにし、会社全体としてデータへの意識の向上を促しました。

プロダクトマネジメントの導入(「プロダクトマネジメントが機能していない」の解決)

ユーザーの体験を左右する施策を考える時は、コンセプトシートを用いるようにしました。場当たり的な開発をやめ、重要なことにフォーカスし、施策の内容自体も精度を上げるためです。

なぜ、誰のどんな課題を解消するためにやるのか、その課題はどのぐらい重要なのか、どのぐらいのインパクトが見込めるのか、どうやって効果検証するのか、といったことを事前に設計しながら施策内容や優先度を決めるようにしました。

また、意思決定の精度を上げるため、プロダクトマネジメント経験のある私がプロダクトマネージャー職能を兼ねる体制としました。

変則的なOKRの導入(「プロダクトマネジメントが機能していない」「チームとして機能していない」の解決)

プロダクトチームのみ、OKRを変則的な形で導入しました。

本来OKRは全社的な目標をツリー構造にするものなのですが、今回はプロダクトチームの目標を明確に定義し、重要なことにフォーカスするためだけの用途として導入しました。OKRは定量的な目標が立てにくいプロダクト開発においても使いやすいと思います。

目標が明確になることで、日頃の頭の使い方や会話も自然と目標に沿ったものになっていきますので、チームとしての学習を促進する効果もあります。

STEP2.チーム化に向けた仕込み(2017/07-09)

10月、11月に新メンバーの入社が決まっていたため、チームとして機能するための仕込みをひたすらした期間。

学習するチームになるための仕組みづくり(「チームとして機能していない」の解決)

1.プロダクト週次MTG

Redashでデータを見ながら事業の状況を全員が同じ目線で把握したり、各自のタスク進捗や問題を把握したり、個人の学習したことをチーム内で共有したりする場という機能を持たせました。

これによって、問題をチームで解決しやすくなることと、個人の学習成果がチームの学習成果に転換しやすくなります。

2.月イチのKPTによる振り返り

日頃の業務の中で、良いと思ったこと、問題に感じたこと、その対策をチームで共有し、対策の実行までが成されるようにしました。

3.コンシェルジュチーム(一般的に言うCS)からのフィードバックを集める仕組み

Slackにフランクにフィードバックを投稿できるチャンネルを作り、そこに投稿された課題を取り上げてissue化するMTGを設けました。

これによってコンシェルジュチームとプロダクトチームで視点や状況の共有が促進するので、不毛な摩擦がうまれなくなったり、ユーザーの声や抱えている課題、コンシェルジュチームの業務上の課題をどんどん伝えてもらえるようになりました。

4.ステージング環境の整備

誰でも気軽にプロダクトを触れる環境がなく、エンジニア以外(デザイナーやビジネスサイド)のメンバーのプロダクト・ユーザー体験の理解や、学習の妨げになっていたため、ステージング環境を整備しました。

チーム開発への移行準備(「チームとして機能していない」の解決)

開発環境構築、インフラ周り、開発・リリース手順等々のドキュメント化が不十分だったため、必要十分なレベルまでドキュメント化しました。

また、ローカル・ステージングのテスト環境を整備し、リリースサイクルにおける品質担保が効率的にできるようにしました。

これまでタスクはGithub issueのみで管理されており、今どんな施策が進んでいるのか、どの施策の優先順位が高いのか、状況把握できなかったため、Github Projectを使ったカンバンによるタスク管理を導入しました。

プロダクトサイドとの付き合い方研修の実施

弊社の特徴ですが、ビジネスサイドにIT事業会社出身のメンバーが少なかったため、エンジニア等とのコミュニケーションに慣れておらず、今後社員数が増えてコミュニケーションが減っていくに連れて、プロダクトサイドとビジネスサイドの間で不毛な摩擦が生じたり、遠慮がうまれてプロダクトサイドにユーザーの情報がうまく流れてこなくなる問題が顕在化する懸念がありました。

そのため、よくあるケースを題材にして「プロダクトサイドメンバーのこういう行動にはこういう意図がある」という話や「こういう風にコミュニケーションをとれると嬉しい」といったような点を資料にまとめて、ビジネスサイドメンバーに対して説明する会を実施しました。

STEP3.チームが興る(2017/10-12)

新メンバー3名が立て続けに入社し🎉、本格的にチーム化が始まる。ここからは、既に存在していた問題を解決するための取り組みだけでなく、今後問題を発生させないための取り組みが増えてきます。

新メンバーの導入MTG強化

新メンバーの入社時、これまでは開発環境や開発の進め方に関する情報を共有するのみでしたが、新たに、事業におけるプロダクトのミッションのインストール、四半期の目標のインストール、期待する役割のすり合わせ、新メンバーのスキルセット・志向性の確認とアサイン最適化、といったことを丁寧にやるようにしました。

これによって、新メンバーの早期立ち上がりと、各メンバーの強みを活かしたタスクアサインをすることによるチーム全体の生産性の向上を図りました。

1on1の開始

業務上のストレスは、時間経過と共に必ず徐々に発生してくる認識のズレから生まれるものと考えていますが、これを放置するとちょっとしたスレ違いによる退社などのお互いに不幸な結果を招きかねません。これを防ぐため、定期的にズレを解消するために、1on1を開始しました。

主に各メンバーのモチベーション面の状況把握・課題拾い上げ、個人で解決し辛い問題の拾い上げ、キャリアの方向性にあったアサイン最適化することを目的として実施しています。

なお、通常業務においてコミュニケーションは十分とれているので、月に一回程度の頻度でやっていますが、たとえ通常業務でコミュニケーションがとれていたとしても、1on1はやったほうがいいです。

バグ & 改善要望対応DAYの開始(「プロダクトに負債がたまっている」の解決)

10月・11月とエンジニアメンバーが立て続けに入社し、バグや負債回収に少しリソースを割ける状況になったため、毎週金曜日をグロース戦略(OKR)と関係ない改善(バグor小さな改善or技術的負債回収)をする日に設定して、細かくプロダクト品質を改善していけるようにしました。

毎週一日を固定で割く形としたのは、グロース戦略(OKR)との間での優先度管理を不要にし、リソースマネジメント・タスクマネジメントを単純化して管理コストを削減するためです。

運用担当制度を開始

曜日ごとに運用担当(コンシェルジュチームの問い合わせに一次対応したり、リリースマネジメントをしたり、システムトラブル対応する役割)を変える制度にしました。

当初は私が全て担当していましたが、開発メンバーが増えたことによって開発量が増え、それに伴って運用にかかる時間的コストも増えたため、プロダクトマネジメントや本質的な課題発見に時間を割けなくなるという問題が発生したためです。

また、システムの運用自体も私一人だけができる状態ではSPOFになってしまいますので、担当を回すことで、全メンバーが運用スキルを獲得し、安定したシステム運用が行えるようにするという狙いがあります。

プロダクトチーム→プロダクトマーケチームへ

マーケティングによるユーザーの流入から、プロダクトへのランディング後の体験は一気通貫でつくるべきと考えていたため、プロダクトチームとマーケ担当をひとつのチームとし、同じ目標を持つようにしました。

目標・リソースを一元化することで、プロダクトリソースの都合でマーケ施策が進まないことや、マーケの都合でプロダクトリソースのコントロールが難しくなることを避けることも狙いのひとつです。

プロダクトマーケ合宿の実施

プロダクトマーケチームのメンバーで、外部の会議室にこもって一日合宿をしました。内容は、デザインスプリントの前半部分を少しアレンジしたようなものです。

目的は多岐に渡りますが、「(主に新メンバーの)市場・事業環境・プロダクト・ユーザーへの理解促進」「課題の自分ごと化によるモチベーティング」「メンバー間の事業・プロダクト等への認識格差を埋めコミュニケーションコストを下げる」「(受託文化から来たメンバーが多いので)本質的な課題発見・解決アプローチのトレーニング」といったあたりになります。

STEP4.そして、最近やってること(2018/01-)

プロダクトマーケチームを各目標に紐づく少チーム制へ

四半期のプロダクトマーケチームの大きな目標を3つ設定し、各目標に紐づく形で、プロダクトマーケチームの中に小さなチームを3つ作りました。

それぞれ、プロダクトマネジメント、エンジニア、デザイナー、マーケター(※必要に応じて)のロールを最低1人ずつアサインし、各小さなチーム単体で目標に沿った施策の検討・意思決定・実装・検証のサイクルが全て回せる体制にしました。

個人個人の取り組む目標が更に明確になり、継続的に同じテーマに頭を使い続けることでラーニングがたまりやすくなる効果があります。また、全てのサイクルを小チームで回せるようにすることで、施策の品質を保ちつつ、意思決定スピード・改善速度をあげる狙いがあります。

弊社は、プロダクトマネジメントスキル、ディレクションスキルを身に着けたいという志向性のメンバーが多いため、少人数のチームにすることでそういった業務に関わりやすくする目的もあります。

まとめ

書き出してみたら思っていたよりもかなり長くなってしまいましたが、以上がみんなと一緒にプロダクトチームを立ち上げるためにやってきたことでした。

どんなチームビルディングをしていくと良いかは、会社・事業のミッションや抱えている課題によって大きく変わってくるので、まずはしっかり自分たちの課題を把握し、自分たちの課題の解消に適した方法を採用していくことが非常に重要です。

また、基本的には極力シンプルに保つのが鉄則です。プロセスや仕組みは多いより少ないほうがいいです。このあたりは、設計・コーディングやプロダクト・UIデザインと一緒です。よく聞く手法や流行りのやり方を、目的なく導入してしまわないように気をつける必要があります。

一度始めたことも、合わないと思ったらすぐやめることが大事です。合わないままやり続けていると、変更容易性を失っていき、いずれそのプロセスは負債化します。

それから、会社・事業・チーム・ユーザーは成長するし、変化します。ずっと同じではありません。ずっと同じではないので、やり方も成長や変化に合わせて変えていく必要があります。そのことを忘れずに。

これは個人的なポリシーですが、チームビルディング・チームデザインはメンバーをユーザーに見立てたUXドリヴンでやるのがいいと思っています。

みんな意義のある仕事をやりたいとか、仕事を通じて活躍したいという気持ちを少なからず持っていると思うので、それを実現するにはどうしたらいいか？を軸に考えます。そして、活躍してもらえて、それによって事業・会社も成長していけば万々歳です。

最後に、お約束ですがカウンターワークスでは一緒にチームをつくりあげてくれる仲間(エンジニア、デザイナー、etc...)を大募集しています！

ちょい興味がわいたなーと思ったら、ぜひ一度気軽にお茶でもしましょう！チームビルディングの話でもしましょう！

Twitterです