わたしの理想のプロダクトチーム 2020.10 基本とマインドセット編

わたしが今までの個人的な経験を通して、こういうチームがよいのでは、というのをまとめてみました。まだまだ試行錯誤の中なのでフィードバックやご意見あれば歓迎します。 Twitter: @yusuke_kokubo

□ ここでの言葉の整理

組織 (≒ 会社)
・なにかしらの事業を営んでいる
・組織はビジョン・ミッション・バリューを持っている

チーム
　組織内に一つ以上存在する人の集まり
　チームは事業にひもづいたミッションを持っている

■ 基本編

□ チームをつくる目的

チームは２つの目的によってつくられる

A. 事業を推進する
B. 所属する組織のビジョン・ミッション・バリューを推進し、体現する

この２つはチーム運営の両輪であってどちらも欠けることがあってはならない。すべてのチームメンバーは組織の事業、ミッション、バリューに共感していることが望まれる。
※ 共感の熱量は人によって違うけど、少なくとも方向性としてあっていて欲しい

□ すべてのチームが普遍的に目指すべき指標

・[継続性] チームが長期的に継続していける
・[健全性] チーム内に健全な調整弁が働いてる
・[成長性] チームが学習して成長している
・[再現性] チームの成果に再現性がある
・[自律性] チームのミッションに関する意思決定プロセスがチーム内で閉じている

□ 組織の骨格 （組織の形はどこにあらわれるか）

組織図
　◯◯部△△課という所属を表すものではなく組織の戦略をあらわす体制図
　会社の戦略と、チームのミッション、チーム間のつながりが見えるもの

ジョブとレスポンシビリティー
　期待される行動
　権限と裁量

会議体（会議の目的、頻度と時所要時間、参加者、アウトプット）
　仕事のプロセスは会議体のつくられかたで大きく変わる
　最小限の時間と労力で、最大限の会議の目的を達成できるのが望ましい

組織図とジョブ・レスポンシビリティーが静だとしたら会議体は動を表す

□ 3つのロール

パフォーマー
　事業の成長につながる成果を出す
　成果を出すスキルセットが重宝される

オーガナイザー
　パフォーマーが最大限の成果を出せる環境を整える
　組織課題を発見して、解決への道筋をつくる

ブリッジ
　人やチームの間をつなげる
　モチベーターとしてのスキルが重宝される

これらはあくまでもロールであって人に結びつくものではない
一人一役ではなく、一人三役。どのロールに比重を置くかは個人ごとに違う
ex) パフォーマー: 7, オーガナイザー: 2, ブリッジ: 1

※ 一般的には組織の上位にマネジャーと呼ばれる管理職がいて、末端にプレイヤーとなる現場がいる、という組織構造によってロールが決まってくることが多いと思われるが、ここではそれを否定する。事業成果を出す現場と、それを支えるオーガーナイザーという役割分担で組織体制を構成するのが望ましいと考える。

□ スタイル

リーダーシップ
　周りの意見を取り入れながら、自らが主体となって判断する
フォロワーシップ
　リーダーシップの判断を手助けするために協力する

これらも個人に結びつくものではなく、一人の中で時と場合によって使い分けられる。どういう場合に誰がどの帽子をかぶっているか、がわかるようになっているとよい。

■ マインドセット編

□ チームとしてはたらくときの態度

仕事とは実験と学習の繰り返しである
　大きく成功するためには上手に失敗しよう
　短期的な成功や失敗で一喜一憂しない、つよいこころ

小さく上手に失敗する
　リカバリー可能な範囲で上手に失敗しよう
　失敗から学習しよう

チームメンバーは全員仲間
　誰かが怠けるから失敗するのではない（ハンロンの剃刀）
　みんなで学習してみんなで成長する

□ プロダクト開発は総合力の勝負

役割はただの名札であって全員がプロダクトをつくる主人公
　プロダクトをつくるのはエンジニアやデザイナーだけじゃない
　　マーケ、セールス、その他すべての職種みんなの総合力でつくるもの
　という前提の元でロールとレスポンシビリティーは明確にする
　各自の役割と責任範囲を明確にしたうえで役割の越境を歓迎する

課題はすべてチームで解決する
　誰かが頑張るのではなく、みんなで頑張る

□ 個人の態度

自分のモチベーションは自分で管理する
　自分のモチベーションが下がりそうなときは周りに伝える努力をする
　自分の意見と相違がある場合は、意義のある対立構造をつくる
　　「人 vs 人」ではなく「問題 vs 私たち」

すべては人と人の関係
　「プロダクト」「チーム」「ユーザー」という概念を取っ払えば社内でも社外でもすべては人と人との関係で成り立っている
　合理性と正論だけでは人や組織は動かない
　相手の意見に納得できなくとも理解して尊重する努力が必要になる
　　※ 無理に同意や納得をする必要はない
　自分の意見を理解してもらう努力を怠らない
　　理解してもらったうえで納得するかどうかは相手の判断に任せる
　　相手に同意を求めるのではなく、お互いの意見をかけあわせて一緒に正解を探すことを心がける

ひとりひとりが特別、だからこそチームになれる
　ひとりひとり違うからこそできることが広がる
　自分が他人と違うこと、それ以外の人たちも全然違う人間であることを楽しめたら勝ち

□ 行動基準

情報はドキュメントで共有する
　情報の透明性はチームの相互信頼を育む基礎になる
　情報は共有されてこそ価値が出る

自分から相手に信頼してもらう
　相手に察してもらうことを期待しない

個人に依存しない仕組みをつくる
　仕組みをつくり、その仕組みを改善する
　問題が起きるのは人の問題ではなく仕組みの問題として捉える
　　「人vs人」ではなく「人vs仕組み」という構図をつくる
　コミュニケーションのプロトコルをつくる
　　約束事を決めることで、無駄なやりとりを減らす
　　ex) ◯◯を依頼するときは△△のフォーマットを使う
　チームの型をつくって破ることを繰り返す
　　守破離の手順を間違えない
　　まずは守ることから

期待値を丁寧にすりあわせる
1. 会社の明確な方針として決められていること（交渉の余地がない）
2. 会社とチーム（または個人）が相談して決めること（交渉次第で変わる）
3. チーム（または個人）の裁量に任されていること（交渉不要）

この判断軸の認識があっていれば、チームが自律的に行動できる
なので、この線引きをすりあわせることを妥協してはいけない
（逆に言うと、この線引きができてないのにチームが自律することを期待してはいけない）

□ 事業と個人の関係

組織は常に矛盾を抱えるものであることを受け入れる
　組織のビジョンと事業成長は相互補完の関係
　自分たちがやりたいことをやるためには事業で資本を稼ぐ必要がある
　手段と目的どちらも大事

自分の仕事と事業を結びつける
　「チーム」はプロダクトとサービスをつくる
　「プロダクト」「サービス」はユーザーに価値を提供する
　「ユーザー（顧客）」は会社に価値の対価を支払う
　「会社」はチームに対価を還元する
　「個人」にチームの成功が還元される

👆これらのどれかが欠けたら事業は成立しないことを認識する
　全員の日々の仕事は循環してつながっている
　個人の判断、チームの判断、会社の判断がどれか一つに偏ることがないように全員が気をつける
　　※ ある期間だけ集中して取り組むことはあっても、年間通して◯◯しかやってない、という状況は避けたい

意識的に心と体を整える時間をつくる
・事業として攻めることと同じように、チームが継続的に戦える兵站を整えることも大事
・何も考えないと、最前線で立ち止まってしまい疲弊することになりがち
　　整える時間を事前に計画に入れる

□ プロダクト開発

プロダクトを開発するのと同じように、自分たちのチーム自身を開発する
　開発環境
　プロダクトデザイン
　開発プロセス
　マーケティングや労務など開発以外の業務効率化
　... etc

ソフトウェアエンジニアは組織の課題をエンジニアリングの力で解決することが期待される。プロダクト開発は組織の課題の一つでしかない。

チームは自分たちの生産性の維持に責任を持つ
・技術的負債を溜めるときには返す計画もセットで考える
　　返す当てがない負債を溜めない
・無茶な機能開発を簡単に受け入れない
　　これは無茶だ、と主張するのは開発者の責任
　　無茶をした影響を予測できるのは開発者しかいない
　　無茶した結果は会社の責任

プロダクト開発は機能をつくるだけではない
　「できる」と「使える」は別軸の概念
　機能を「増やす」 vs 「磨く」
　機能を「増やす」のは簡単
　　「磨く」は難しい
　　「消す」はさらに難しい

ユーザーにとって、自分の目的にあう機能を気持ちよく使えることがだいじ。そのためにユーザーがプロダクトを使うときの気持ちに寄り添ってUIを設計する。機能を十分な速度で使えるようにする。いつでも安定して使えるようにする。

■ プラクティス編

memo

チームをうまくマネジメントするためには、コマンドコントロールが必要のない仕組みをどれだけうまくつくれるか、が大事だと思ってる。
うまくマネジメントができてる状態というのは、マネジメントが必要ない状態である。

⚫︎対等な人間関係
⚫︎判断軸の明確化と共有
⚫︎継続的な学習と改善

基本的にはこの三本柱