今回は「プロダクトマネジメントのすべて」のチームビルディングの章を元にスタートアップのチームの作り方を解説していきます。今まで2人のすごい小さいチームから（チームというかコンビ？）30人規模のチームの運営をしてきた筆者が自身の経験も踏まえて解説していきます。
この記事は下記動画でも解説しています。
スタートアップのチームの作り方
スタートアップでのチームの作り方の特徴としてはまず、アウトソースをうまく活用しないといけない場面が多いというのがあります。著書でもできれば社内リソースでデザイナーやエンジニアを確保したいが実際にはそうはいけない場面もあるとありますが、外注リソースの方とのコミュニケーションと社内リソースの方とのコミュニケーションは違うので気をつけたほうがいいです。
またどこをお願いできるか？しやすいかも違うので気をつけましょう。詳しくは下記で解説していきます。
色んな職種を取りまとめる
また、webサービス開発の特徴は一つのものをいろんな職種の人間が作り上げるという点です。例えば営業会社だと実はほとんど営業で売上の管理をしていれば目標達成できるという場合もありますが、webサービスの場合、
- デザイナー
- マーケター
- エンジニア
- bizdev
などなどいろんな人が関与します。このマネジメントも特徴の一つです。
- いろんな職種を取りまとめる
- アウトソースを活用する
この二つを意識した際のチーム運営について解説していきます。
Googleの出した良いチームの特徴
googleが2012年に115のエンジニアチームと65の営業チームを対象に成果の上がるチームの特徴を調査しました。その結果、下記の共通点がありました。
- 心理的安全性
- 信頼性
- 構造の明瞭さ（何を期待されているか、チームが何をしているのか？
- 仕事の目的
- インパクト
良いチームの心理的安全性
まず前提としてどんなチームであっても心理的安全性は必要。心理的安全性というのは例えば自分が発言しても何か言われたり叩かれたりしないという安心感。
コロンビア号の悲劇
この心理的安全性が大切なことを表すエピソードとしてはNASAのスペースシャトル「コロンビア号」の事故の話が印象的です。ケネディ宇宙センターで勤務していたエンジニアの一名は事故原因となった断熱材の問題に実は事故の前に気づいていました。
そして、実際に直属の上司に伝えたもののその上司から上に報告されることはありませんでした。これは当時ケネディ宇宙センターではなかなか問題を上司に伝えにくい状況があったからだそうです。心理的安全性がないとこういった問題がうまく行き来しないのです。
エドモンソンの心理的安全性と説明責任
心理的安全性は組織行動学を研究するエドモンソンが1999年に提唱した心理学用語で「チームの他のメンバーが自分の発言を拒絶したり、罰したりしないと確信できる状態」と定義しています。
チームの心理的安全性と説明責任を下記のようにマトリックスにし、
- 説明責任が高く
- 心理的安全性が高い
学習ゾーンに持っていったチームがより生産性が高いとしています。説明責任がなく。ただ心理的安全性が高いだけだとぬるま湯になってしまうのです。
アウトソースと社内リソースの違い
アウトソースしたサイト社内リソースの違いはまず、社内リソースの方が長期的になりやすく、またコミットする時間が長くなりがちなのでコミュニケーションが円滑になります。また、アウトソースだといつ契約が切られるか分からないので上記の心理的安全性が低くなりがちです。
また、コミュニケーションする時間がアウトソースだと社内よりは少なくなりがちなので構造や目的の共有も漏れる可能性が高くなります。googleのあげた良いチームの条件である
- 心理的安全性
- 構造や目的の共有
が低くなる可能性が高いのです。
アウトソースチームの運営
これに対して対処をするためにはまずDACIを明確にすることでコミュニケーションのフォーマットを決め、コミュニケーションを円滑にする必要があります。
DACI
アウトソースをする際に決めておきたいのが下記の４つの役割です。
- 推進者（Driver
- 承認者（Approver
- 貢献者（Contributor
- 報告先（Informed
推進者はそのプロジェクトをリードする人で大体ディレクターなどがなるでしょう。承認者はそのプロジェクトの意思決定を承認する人でアウトソースする際に発注元がこの役割を担うことが多いです。
貢献者は実行する人です。このケースではアウトソースされたデザイナーやエンジニアが担うことが多いです。
そして最後が報告先でこのプロジェクトを完遂したことを伝える先です。大体承認者と一緒になると思います。アウトソースする際に
- 推進者
- 承認者
- 報告先
をクライアントである発注元が担い、貢献者を外注先にお願いすることがほとんだと思います。大切なのは外注先に誰に報告してくださいというのをちゃんと明示することです。これが分からないと外注先はどうコミュニケーションをとって良いか分からないからです。
ちゃんと報告者を作らないと緩くなる
ちゃんと報告する先を作って成果を報告してもらわないとなあなあになってしまいます。性悪説になってしまいますが、報告を義務化することでやってませんでしたいうわけにはいかないのでちゃんとやるようになるという側面もあります。
また、例え自走する人であったとしてもアウトプットのビジョンを度々すり合わせないと後で思っていたことと違うことをしていたという状態になってしまうので要注意。
ドキュメンテーション
良いチームに挙げられていた構造の明瞭さにはドキュメンテーションが必須になってきます。ドキュメンテーションとはチームの情報を記した書類でここを読めばチームの状態や目的、話してきたことがわかるという状態になるのが理想です。
主なドキュメンテーション
主にwebサービスの開発の現場で用意されるドキュメントは下記です。
- プロダクトビジョンステートメント>プロダクトを作る目的についてまとめられたもの
- プロダクト戦略>どうビジョンを達成していくかの戦略
- プロダクトコンセプト>作るプロダクトの方向性
- プロダクトロードマップ>どの順番で作っていくかのスケジュール
- プロダクト要件>ロードマップに並べられた施策の満たさないといけない条件、機能
関係性としては上記になっており、プロダクトビジョンステートメントでまず長期的なビジョンを決めます。そのビジョンを達成するためにどう言う戦略でいくかをプロダクト戦略で決めます。
プロダクトコンセプトはビジョンと混同されがちですが、戦略上今のプロダクトのコンセプトになります。例えば戦略上、最初はメッセージングアプリのコンセプトでプロダクトを作るが後でコンセプトを変えて、送金できるようにすると言うのもあり得ます。
そして、そのコンセプトを達成するために具体的な施策を並べたのがロードマップになります。そしてそのロードマップ内にある施策の機能をまとめたものを要件と言います。
ドキュメンテーションのツール
ドキュメンテーションの中身について解説してきましたが、そのドキュメンテーションはどういったツールで書くべきでしょうか？ドキュメンテーションツールにおいて気をつけた方がいいのは下記になります。
- みんながアクセスしやすい
- タスク管理がしやすい
- オールインワンか
みんながアクセスしやすいというのは当たり前ですが、webサービス開発においてはいろんな職種が使うため意外と難しい問題です。例えばエンジニアからするとjiraやzenhubなど開発に近いツールにしたいですが、マーケなどからするとnotionなどの方が使いやすかったりします。
この辺は何を優先するかを含めて話し合いましょう。
これは個人的な意見ですが、タスク管理と紐づいていると嬉しいです。というのも大体の場合、誰かのタスクに対してドキュメントを作ることが多いですし、プロダクトロードマップは言ってみれば大きなタスクの管理だからです。
それらを一つの場所でできないとコミュニケーションコストが高いのでオールインワンで揃えられるかが重要になってきます。今だとnotionが一番全てを叶えていると思います。
チームのフェーズ
チームにはフェーズがあり、大体下記のタックマンモデルをたどります。タックマンモデルとは、心理学者のブルース・W・タックマンが1965年に提唱した、組織の成長の段階を示したモデルです。
タックマンモデル
- フォーミング（形成期）>メンバーの理解がまだ浅い時期
- ストーミング（混乱期）>議論が始まるが役割が決まっておらず議論の衝突が多い時期
- ノーミング（統一期）>役割が決まり、議論が前に進むようになる
- パフォーミング（機能期）>アウトプットが出始める
- アジャーニング（散会期）>チームの目標が達成され、解散する時期
混乱期を経て、だんだん成果を出せるようになるというモデルです。うまくいかない場合、混乱期のまま終わりますが笑
それぞれのフェーズでどういう対処をとったらいいかをまとめていきます。
関係者のキックオフ
まず、フォーミング（形成期）においてはまだメンバーの理解が浅いため、自己紹介などで理解を深めていきましょう。特にそれぞれがどういう経歴でどういうスキルを持っているかは重要です。エンジニア経験のない人に技術的なことを聞いても話が進まないですし。
個人的に今まで良かった施策は自己紹介ドキュメントをesaやnotionに作ることです。そこに各メンバーの経歴などをまとめてもらいます。意外と長いメンバーでも知らないことが多いので面白いです。
プロダクトコンセプトのキックオフ
次にプロダクトの方向性などを共有する会です。方向性の決定自体はCEOなどが行うと思いますが、ちゃんと共有する機会を設けましょう。
OKR
次に役割分担を決めるためにOKRやタスク割り振りをしましょう。OKRは各チームの目標を決める際に有用です。そこからさらに個人のタスク、役割に落としていきましょう。
振り返り
プロジェクトの終わりに振り返りをし、次に活かしましょう。これはプロジェクトの終わりだけでなく、定期的に行うことも重要です。基本的には完璧なチーム運営はなく、日々問題が出てくるのでその対処をちゃんとできるようにすべきです。
また、意見を言う機会があることで心理的安全性がある状態で意見が言えるようになります。機会を設けられていないとなかなか問題をチームに提案するのは難しいのです。