サムザップテックナイトvol.1 に参加してきました

株式会社サムザップが開催する下記に参加してきました。
【好評により増席！】サムザップテックナイトvol.1 - connpass

【サムザップテックナイトとは？】テーマに合わせて専門性の高い方をお呼びし、全てのスマートフォンゲームクリエイターの方々に「実地で活かせる生の情報」を持ち帰っていただける勉強会を実施し、スマートフォンゲーム業界を盛り上げていくことを目的に定期的に開催する予定です。　. 　. 　. 第１回目は、吉羽龍太郎氏にご登壇いただきます。内容は「強いチームの作り方デブサミ2016バージョン #devsumiC」。ベストスピーカー賞を受賞したときの内容を今回特別に再演となりますので、お見逃しなく…！

というわけで、定期的に開催される予定とのこと。
vol.1 に参加した感想としては大変面白く、vol.2 もぜひ参加したいと思える内容でした。
次回の情報を楽しみに待ちつつ、今回の内容をさらっとご紹介。

資料は下記に公開されています。(ありがたや)

強いチームのつくり方デブサミ2016バージョン #devsumiC | Ryuzee.com (on Azure)

以下、口頭で捕捉されていた内容や、個人的に気になった箇所のメモです。

サムザップテックナイトvol.1 に参加してきました

Sumzap memo 強いチームの作り方

契約交渉より人と人との繋がりを
- お客さんとの関係がこじれるなどというのは避けなければ

チームの課題と改善

課題を見つけているか
改善しているか
- 課題を見つけているのに改善してない？絶望している？

改善の進め方

個人の効率アップでは限界がある
- 流れに注目する
闇雲にやってはダメ
- 具体的に測れない目標はむずかしい。やる気をあげたい、とか測れない
時間を作る
- 辞めれるものを見つけることから

なぜチームが必要か

一人でできることばかりやるなら一人でやる方が楽
チームを作るなら「なんのために集まってるのか」の共有が必要
強いチームは「続けられる」
- 成果を出し続けられる、変化に対応し続ける、成長を維持し続ける

強いチームの形成

単純作業なら機械化される
ソフトウェア開発は複雑
多様性が重要
- 多様性があっても最初から強いチームではない
タックマンモデル
- 安定して機能するチームを作るには時間がかかる
- 気軽に解散するのはすごく勿体無い
- スタートアップの買収は、良いチームを手に入れることが目的かも？
合意とアコモデーション
- 相手のことをよく知ることを合意する、現時点では合意できないことを合意する、検討を継続することを合意する
拳から5本指へ
- フィードバックを行うことで共通理解を得られる
チームの大事な責任
- 結果責任を開発チームが取るのは無理
- 説明責任、改善の責任
既存のルールに縛られず、減らしにかかる
スキルマップ
- 評価に使うとみんなまるつけるから失敗する
- プロジェクトのクリティカル要素だが対応可能メンバーが少ない、とかリスクがみえる
人生がときめく片づけの魔法
ナレッジマネジメント
- 後生大事に抱え込んでも外では役に立たない
- 透明性を確保する
SL理論
- メンバーが成熟するにつれリーダーの行動が変化する
- 指示、説得、参加、委任
チームのマネジメント・権限の委譲
チームメンバーの入れ替え
- いっぺんに変えるとタックマンモデルの初期に戻る
- 遅延プロジェクトに人足すとだめなのはこれが起こるから
- 一度に入れ替えるメンバーは2割ぐらいまで
チームメンバーの採用
- 2、3回会っただけではだめ
- こちらがどういう権限を与えてどういう仕事を任せたいかを詳細に説明すればするほどマッチする人が来る
- 文化への適合性も判断基準に入れる
  - これが合わないだけで採用を見送ることも
- 絶対評価より相対評価のほうが精度が高い
- 優秀な人の紹介は優秀
- 良い人を落としてしまうより悪い人を採用してしまうほうがマイナス
チームメンバーの退職
- 退職の統計は取ったほうが良い
- なぜやめたのか、改善する
アメリカ海軍に学ぶ「最強チーム」の作り方
チームの外側を見る必要性
- チームだけ改善しても、外側に問題があるかも？

チームのコミュニケーション

コミュニケーションは手段
- アートオブアジャイルデベロップメント
同期型コミュニケーション
非同期型コミュニケーション
- 相手が増えると手間と時間が増える
- 意図したことが伝わったかどうかがわかりにくい
無駄なコミュニケーションを極力減らす

評価

定性評価も組み合わせる
- 会社をよくする活動に積極参加しているか、文化にあった活動しているか
評価は小刻みに
- 最近のプロジェクトどう？とか最近どんなこと考えてる？なにか課題ある？とか週1とかでも

質疑応答

開発中のフィードバックで仕様変更が大量になる
- あれもこれも詰め込みすぎ
- 残ってる課題を全部並べろ
- 優先度順に上から並べろ
  - 上のものはすぐやる、下のものはできないかも
- スプリント中の仕様変更は認めない
  - 意地でも決めてからもってこい
  - 途中で割り込むと計画も崩れ、生産性も下がる
- それでも内部事情を知っていると受け入れてしまうことがある
  - 新人さんにスクラムマスター担当を任せるとうまくいくパターンが多い
    - スクラムマスターの役割のみをたたき込み、それのみに従ってもらう
    - 内部事情に流されることもなくなる
文化の異なる人がチームにいる場合
- 価値観、と置き換えるとしっくりくるかもしれない
開発終盤で終わりが見えなくなるやつ
- QCD、スコープの中で妥協点を見つける
- 品質は絶対下げてはダメ
  - 求められる品質は絶対に決まっていて、そこを下回ると自組織に損害しかない
- 全然聞いてもらえない場合は他の手を
  - 発注元の担当者のさらに上司にかけあう
    - このまま進めると最終的に何も出来上がらずお互いに不幸な結果に終わることを伝える
    - 自分から言わなくても自分の上司から伝えるのもいいかもしれない
- そもそも最初から QCD もスコープも決めきるなんて無理
  - それができないから見積もりにはどんどんバッファが増えていく
  - 発注側もそのバッファもある種の保険と割り切って支払う、そんな構図

感想など

アメリカ海軍に学ぶ「最強チーム」の作り方の内容が紹介されていて、こんなのも参考になるんだな、と不思議な感じを覚えたり、いろいろ新しい発見がありました。

懇親会ではフードとドリンクが振舞われ、ここでいろいろお話できたのも楽しかったです。
ryuzee さんご本人も気さくにいろいろ答えてもらえて疑問点をいろいろ聞くことができました。

「最初から全部決めきるなんて無理なんだし準委任でアジャイル開発を」
「それだと単価が下がると自組織上部から反発が出るような会社さんもあると思うんです」
「そこで無理して結局赤字出してませんか。メンバーが疲弊してませんか」

みたいなやりとりでぐぬぬ、仰る通りかも。

できるところから改善していこうと胸に誓った１日でした。