デブサミ2016「強いチームの作り方」に参加してきたので、ちょっと間が空いてしまいましたが忘れたくないことまとめ。
当日のスライドはこちら
【資料公開】強いチームの作り方(デブサミ2016版) | Ryuzee.com
セッションの内容は WEB + DB PRESS vol.83 (2014) 「強いチームの作り方」ベース。それを著者の吉羽さんが直々に解説してくださっている感じでした。書面だとうまくイメージできなかった部分が「なるほど、こういうことか」と理解できて良かったです。加えて吉羽さんの Amazon での経験談、身近なところからの引用に説得力があり、面白かった。正直なところ、情報量が多くて45分間ずっと集中していたのでかなり疲れた。
プロジェクトを継続してうまく進められる、強いチームを作るにはどうすればいいのか。セッションを聞いて、チームに持ち帰ろうと思ったことをまとめました。私は今、新規事業の立ち上げに関わっているので、特に印象に残った「チーム形成初期に何をするのがいいか」の話が中心となっています。
目次
- 改善のすすめかた
- 多様性のあるチームは強い
- 機能するチームができるには時間がかかる
- チーム形成初期に、合意とアコモデーションをやろう
- 初期段階でアコモデーションがうまくできるの？
- チームで何か決めるときの良い方法
- チームで決められない、進まないとき
- 徐々にチームに任せる、権限委譲のやりかた
改善のすすめかた
チームには必ず課題がある。現状に諦めずに改善してください。どうやって改善していくのがいいか。
改善する前に、一度、仕事の全体の流れを見てみる
チームの中だけ見ててもしょうがないケースがある。仕事の全体の流れを見て、ボトルネックを把握する。全体を見ず自分の目の届く範囲だけだと、部分最適化だけが起こってプロダクトをリリースする速度があがらなかったりする。
改善は自分の手の届く所から小さく細かく
技術者なのでツールに行きがちだが、もう少しチームとか組織に関わることに注目してみる。ドカンと大きな改善を全社的にやろうとすると失敗するので、自分の手の届く所から小さく細かく。やってみて、だめならやめる。
自分ひとりだと心が折れる
ひとりだと心が折れる。現場で考え、チームでこうやりたい、を基本に。上から押し付けるとうまくいかない。
目標を数値で把握するのも大事
目標を数値で把握するのも大事。測れない、見えないものは改善できない。
多様性のあるチームは強い
チームのメンバーの、年齢、性別、育った環境、経験、好み、考え方、バラバラだといい。議論するときにいろんな意見が出てくる。みんな新卒で入って同じ環境で育っていて、急に難しい問題を解決しようとすると、見方が同じでいい解決方法が出てこないことが多い。チームのメンバーを集める時の参考に。
チームに多様性がないと、今までのやり方を変えづらくなる傾向にある。何かあると飲み会とかで「うちのやり方はいけてない、ツールが悪い、長くやってきたやり方だから変えるのが難しい」と愚痴って終わり、ということが起きがち。
ただ、考え方がバラバラなメンバーが集められてすぐにいろんな意見が出てくるかというと、そうでもない。ではどうすればいいのか。まずはチームの成長過程を理解する。
機能するチームができるには時間がかかる
人があつまってもいきなりチームは機能しない。これを説明しているのが以下のタックマンモデル。チームは成長過程があって、５段階に分かれている。
形成期〜混乱期あたりは仕事を進めなければならないので、それぞれが自分がよかれと思うことをやったり、意見の違いから対立があったりする。後になって「この頃にやったことは無駄だったね」という話になりやすい。
統一期あたりからようやくチームは機能しはじめる。
吉羽さんの経験だと、機能するチームができるには半年くらいはかかるらしい。いいチームができたら解散させてしまうのは無駄が多い。
チーム形成初期に、合意とアコモデーションをやろう
チームの形成初期にやるといいことが、ゴールとか目的、チームで大事にする価値観の合意。アジャイルサムライの「バスに乗せる」というくだり。ただ、人が集まったばかりでいきなり合意できるわけではない。そのときやるといいのがアコモデーション。
アコモデーションとは「現時点では合意していないけど、これから一緒に考え続けていこう」という考え方。合意できない点があることを合意して、プロジェクトを進めながら意見を修正し、しっくりくるまで調整を繰り返していく。初期段階では、アコモデーションに合意するだけで十分だったりする。
初期段階でアコモデーションがうまくできるの？
いきなり集まってみんな様子見している状態でこういうことのリーダーシップを取るのは難易度が高い。上司がやればいいのでは？と思うかもしれない。アマゾンの場合だと、組織の価値観として「リーダシップの原則」というものがある。
この中で言っていることは以下の通り。
社員全員はリーダです。マネージャーとか、役職者は関係なく、社員全員がリーダー。リーダは賛成できない、違うと思ったら言え、面倒でも大変でも言え。妥協して馴れ合わない。ただし、みんなで最後決めたら、それは全力でやりましょう。あとから影で、あのとき反対してたけどチームで決まってしまったんで、おれは未だに納得してないからやらないんだ、はなし。
私はこの考え方をみんなと共有できていたらやりやすいな、と思いました。アマゾンはこんな文化があるらしいんだけど、みんなどう思う？って、聞いてみようと思います。自分たちで考えていい、違うと思っていることは違うと言っていい、意見をぶつけてもいい、というチーム文化をつくるのも大事ですね。
ググってみたら「Amazon Leadership Principles」の日本語訳ページがありました。
カルチャー｜アマゾンジャパン株式会社 オペレーション部門キャリア採用サイト
チームで何か決めるときの良い方法
初期段階のチームで何か決めるときは、コミュニケーションのツールっぽいものを使うとうまくいく。
「拳から５本指」(Fist to Five)
議論するとき「これについてどう思う？」の質問に対して５本指で回答してもらう。
2本以下の意見が多い場合はもう少し話し合ったほうがいい。3本もちょっと主体性がないので、話し合ってわだかまりを解くといい。「4本になるには何が足りない？」みたいに聞くと、エンジニアは答えやすいかも。これ、面白いので折を見て試してみたいと思います。
多数決は避ける
あと、初期の段階で多数決は避けたほうがいいそうです。知らない人、長く付き合ってない人と多数決でものを決めようとすると、少数派に回る人は必ず反感をもちます。フィードバックを上手に使わないと、共通理解がおきない。
チームで決められない、進まないとき
チームを作っていくと、最初いきなり集められてもなかなか進まない、やっぱり外がらプッシュしないと動かないよね、と思うことがある。こういう場合、まずはリーダーが意思決定を取るのが良い。そして、徐々にチームに任せていく。チームの成熟度に応じて、リーダーがどこまで押し付けるかは変わっていく。
徐々にチームに任せる、権限委譲のやりかた
徐々にチームにまかせていく時、どうしてもリーダーやマネージャーが関与しなくてはいけないものがあったりする。そこで、自分たちの仕事を一覧化して、以下の７段階にあてはめていく。どこは任せる、どこはまかせない、どこはどれだけ関わる、というのを合意してやっていく。いきなりすべて任せるのは丸投げであって委譲ではない。
まとめ
吉羽さんが繰り返し伝えていたこと
- 実際にゴールに対してどんな状況でどんな問題を抱えているのか。だったらこうしてみれば、というフィードバックのサイクルは短くなければいけない
- これは製品を作るときだけではなく、組織運営も同じ
- 自分の手の届く所から小さく細かく改善する
- やってみて、だめならやめる
- 変わっていかないと、いずれどこかで面倒なことになる
セッションの冒頭に吉羽さんがこうおっしゃっていました。
「プロジェクトがうまくいかないときは、技術じゃないところで失敗していることが多い」
私がこの間加わったばかりのプロジェクトも、みんな帰りが遅いです。どこが問題なのか、どこで時間を食っているのか、早いやり方にするにはどうすればいいか、まだ見えていません。単に見積もりミスってるだけなのか、無茶な納期を押し付けられてないか、ゴールがあいまいなまま動いてないか、人間的な部分で考えてみたいと思いました。
また吉羽さんはここでまとめたこと以外にも、いろんな角度でノウハウを公開されていました。Publickey にて、吉羽さんが当日話された内容が８割がた文章でおこされていますので、そちらを読まれるといいと思います。
強いチームを作るには時間がかかる～強いチームのつくり方（前編）。Developers Summit 2016 － Publickey