Developer's Summit 2016 【19-C-1】強いチームの作り方 聴講メモ

講演資料

http://www.ryuzee.com/contents/blog/7078

概要

　チームの課題解決(カイゼン)、スキルアップ、文化形成など、強いチームを作るための適切なアプローチについて、Amazonの例などを提示しつつ語る。

スピーカー

• 吉羽さん
  • 野村総研、AWSを経て現在フリー。
  • 新刊３冊出るので手に取ってね。

詳細

ピープルウェアの言葉

• 過去の経験上、失敗するときは技術ではなく人間、社会学系で失敗している。
• そこを学ぶべきでは、という問題意識。

チームの課題とカイゼン

• 挙手でアンケート。

  • 『現状のチームに課題があると思う人?』
    • 会場の8割が挙手。
    • 課題はないと答えた人、そんなはずはない。
  • 『実際に改善に取り組んでいる人?』
    • 意外に少なかった。
    • 問題があるのに改善しない、というのは質が悪い。
    • できるところから改善してほしい。

• 大きな改善をドカンとやると失敗する。

  • 目の前、手の届くところから改善していく。

カイゼンの進め方

• バリューストリームを見る(全体を見る)事が重要。

  • 全体を見ないと部分最適化が進むから。
  • 『自分だけ改善しても、プロダクトをリリースする速度は変わりませんね』ってことになる。

• 人間系の知恵を使う。

  • エンジニアはツール大好きなのでツールばかりに目が行くが、ツールに頼り過ぎないこと。

• 目標を数字で図れるようにする。

  • 見えないものは改善できない。

• 自分だけがやったら心が折れる。

  • チームでやる。
  • 上からの押し付けはうまく行かない。

• 製品開発の考え方にリーンスタートアップがある。

  • リーンスタートアップは製品だけじゃなく、組織運営にも必要。

なぜチームが必要か

• 一人で出来るなら一人でやったほうがコミュニケーションコストも不要。

  • が、世の中の仕事は一人でできない仕事のほうが圧倒的に多い。
  • だからチームを組む。

• メンバーひとりひとりには得手不得手がある。

  • 一人でフルスタックである必要はない。
  • チームでフルスタックであれば良い。

• 強いチームの特徴は、以下3点を『続けられる』こと。

  • ビジネス上の結果を出す。
  • 変化に対応する。
  • 成長を維持する。

• スポット的に出来るだけではなく、継続して成果を出せることが大事。

強いチームの形成

• 工場労働のように、仕事が単純な場合、概ね以下の様な傾向になる。

  • 単純な繰り返し作業ならばらつきを減らす方向に。
  • 自分だけ別なやり方をすることは許容されない
  • 安定性を追求する。機械化されやすい。

• が、ソフトウェアに関する仕事は複雑な仕事。

  • なぜならビジネスに紐づいているから。

  • 多様性が必要。

    • 性別、年齢、国籍など、表面的な多様性もあるが、
    • 考え方などのバックグラウンドも多様性。
    • 複雑な問題には多角的な視点で対象に迫る必要がある。
    • フィードバックによる軌道修正も必要。

  • 多様性がない場合

    • 従来のやり方に対してフィードバックしにくい。
    • 文句が外向きになる。愚痴ばかり言うようになる。
    • 思考を停止してあきらめる。

チームの形成ステージ

• タックマンモデル。チーム形成のステージを5つに分類している。
  • 形成期
  • 混乱期
  • 統一期
  • 機能期
  • 解放期
• 形成期、混乱期は、自分が良かれと思ったことをそれぞれやりだす時期。
• 当初、タックマンモデルは4つだったが、後に解放期が追加された。
• 安定して機能するチームの形成には半年、早くても３ヶ月はかかる。
• 形成期、混乱期から統一期へ至るには、以下を合意していることが必要。
  • ゴール
  • 目標
  • 価値観
• とはいえ、これらはそんな簡単には合意できない。
  • そこで、上記の合意に至る前に、以下を合意する。
    • 『相手のことを良く知ろう』ということについて合意。
    • 『自分たちはまだ合意していない』ということについて合意。
    • 『引き続き検討していく』ということについて合意。

Amazonのリーダーシップ原則

• Amazonでは社員全員がリーダー。
  • 合意しないことについてどのように振る舞うか示されている。
    • 賛成出来ない場合は異議を唱える
    • が、一度チームが決定したら、全面的にコミット。
    • 『俺は反対したからやらない』はナシ。
  • リーダーシップ原則は14箇条ある。
    • Webに載っているので見ておくと良い。

多数決の危険な罠

• とある、なかなか話が進まない漫画の中で、多数決のリスクについて書いてある。

  • 実は少数派の意見を抹殺している行為。
  • 常に少数派に回る側の人は不満を募らせることになる。
  • 初期の段階で多数決を決めるのはリスキー。

• そこで、5本指で意見を聞くという方法がある。

  • 意思決定をする際、挙手を求めるが、その際の指の数で賛成度合いを示す。
  • この考え方はプランニングポーカーに通じる。
    • プランニングポーカーではフィードバックを行うことで理解を得る。

チームの責任

• 説明責任と改善責任。

  • 完成責任をチームが負うことは無理。
  • ただ、全力を尽くす責任はある。

• チームのルール

  • 外部のルールが障害になることがある
    • 思考停止しない事が大事。
    • 意図がわからないものや、不要なものは廃止する。
    • ルールにないものをやっていいと考えるか、やってはダメと考えるか。
      • その人のバックグラウンドによって大きく別れる。
      • やってはいけないわけではない。
  • 大野耐一の言葉。
    • 『言う通りやる奴はバカで、やらん奴はもっとバカ。もっとうまくやる奴が利口』
  • 自分たちのルールを自分で作ること。

• 硬い会社だと、できない理由を先に言ってしまう。

  • 出来る方法を考えること。
  • 部下が何か提案した時に『ルールだから駄目だ』と返すマネージャがいる。
    • 私見だが、これはマネージャの職責を果たしていないと言える。

スキルの見える化

• チームでスキルマップを決める。

  • 出来ること、できないこと、今後習得したいことをしるし付け。
  • 1ヶ月ぐらいの単位で更新していく。
  • スキルが見えると、そのチームのリスクが見える。
    • あるスキルを持った誰々が倒れたらヤバイ、とか。
  • 『マネージャが人事評価に使おう』と言い出すことがある。
    • そう言い出した瞬間に、みんな甘くつけ始める。
    • 絶対にダメ。
  • 『チームのためにやる』事が大事。

• 個人としてのスキルアップをどう考えるか。

  • 『個人として変化に対応するか?』という問題。
    • 個々の価値観の問題。
    • 『1回限りのプロジェクトなので成長する気はない』
      • という人に対しては、
    • 『変化に対応しないなら生殺与奪の権利は自分以外の手に移るよ』
      • と一応言うことにしている。
  • 自分を守るために自分にスキルをつける、ということ。
  • 過去の成功体験と不安が変化を阻む。

単一障害点

• チームに問題が起こった時のことを考える。
  • 問題が起こっても許容できるなら放置すればよい。
  • が、その結果夜も眠れないとしたら、何かが間違っている。
  • この時の対策は『特定の人しか知らない情報』をなくすこと。
    • 一方で、誰しも、自分の仕事を守りたい要求がある。
      • その要求を捨てること。
      • 外で役に立たないものを守る意味はない。

マネージと委任

• SL理論
  • チームの成熟度に応じたマネジメント手法。
  • 成熟度に応じて4種類のマネージを使い分ける。
    • 指示(S1)
      • マネージャが意思決定し作業指示。
    • 説得(S2)
      • 考えを説明して方向性を示す。
    • 参加(S3)
      • 意思決定に参加し助言。
    • 委任(S4)
      • 進め方、意思決定も含めて任せる。
  • いきなり委任してもうまくいかない。

チームメンバーの入れ替え

• 一度に入れ替えた場合、既存のチーム文化は失われることを覚悟しなければならない。
• 一度に入れ替える人数は少なく(1,2人)。

採用

• 一緒に働く人が採用の判断をした方がいい。

  • 期待値を明確に。
  • チームがぶっ壊れない人を。
  • 会社のカラーに合う人を。
  • チームの平均以上の人を取り続ける。

• 退職

  • やめる理由を生々しく聞いたほうがいい。
  • その理由を聞いた上で改善すれば、同じ理由による退職を止められる。
  • ちなみに、退職理由の中で『給与』は5番目。

組織構造とアーキテクチャ

• システムを設計する組織の組織構造は、その組織が作る製品のアーキテクチャとそっくりになる。
  • マイクロサービスをやりたい、と思うかもしれないが、
    • それができるかは組織に依存する。
    • 分業が増えるだけかもしれない。
    • 自分のチームに合うかどうかを考える。
  • チームの外側を見る。
    • 開発(Dev)のスループットは高いが、運用(Ops)のリードタイムが長いかもしれない。

コミュニケーション

• コミュニケーションはHow。

  • 目的ではない。
  • 何のためにそれが必要かの合意が要る。

• コミュニケーションには段階がある。

  • 送信済み
  • 受信済み
  • 理解
  • 合意
  • 行動

• 行動になって初めてコミュニケーションが成立した、と言える。

• 同期型と非同期型のコミュニケーションを使い分けること。

• チームが生産性を保つためには、会議を減らす方向に持っていったほうがいい。

  • 挙手アンケート『１日の業務のうち、会議の比率が25%を超えている人?』
    • 25%を超える人は3割ぐらい。
    • ドラッガー『1/4以上会議に使っているなら、組織構造に問題』

• コミュニケーション頻度が高い場合、組織構造が問題。

• 技術的に解決する方法もある。

  • Amazonの事例。
    • 昔、繁忙期のサーバ機能増強の際、都度インフラ部門に調達要求をしていた
    • この手続きをAPI呼び出しに置き換えた。
    • コミュニケーションのオーバヘッドを削減。
    • 人のリアルコミュニケーションにしておく必要は必ずしもない。
    • Amazonには他にも『2ピザルール』¹とか色々なルールがある。
      • 調べておくといい。

評価とフィードバック

• 評価の基本原則

  • 価値観、優先度、期待値、求める成果を『先に合意せよ』。
    • 後出しを避ける
  • 当たり前だが公平、公正であること。
  • 定量評価と定性評価を組み合わせるとよい。
    • 定量だけにすると倫理観が崩壊する。
  • 仕事をうまくやるのが目的。
    • 1ヶ月から3ヶ月程度のスパンで頻繁に行う。
    • ピアレビュー(1:1)で行う。
      • アマゾンだと1ヶ月に1度、全従業員が直属上長と1:1で話す。

• フィードバック方法

  • 頻繁に。
  • 常時ネガティブなことを言ってはダメだが、必要に応じて。
    • 個人攻撃と取られないように言う。
    • 個人攻撃と取らないように聞く。
    • "I message"(私はこう思う/感じる…)を使う。
    • 対立構造に見える座り方を避ける。

---

1. チームの規模はピザ2枚でまかなえる程度にせよ、というルール。↩