Slide 1
Slide 1 text
＼ プロジェクトをリードする技術 ／
2018.04.23
吉田慶章 @kakakakakku
社内勉強会
Slide 2
Slide 2 text
前提
社内のビジネスチームに
エンジニアリングの事例を紹介するため
できる限り, 技術的な用語は使わないようにする
Slide 3
Slide 3 text
プロジェクトをリードすることは
「立派な技術」であり,
プロジェクトが成功しないと
「リードしたとは言えない」
今日1番伝えたいこと！
Slide 4
Slide 4 text
関連する領域
チームビルディング / ファシリテーション / マネジメント 3.0
アジャイル ( スクラム / カンバン / XP ) / リーン
組織論 / 育成 / 心理学 / メンタリング / プロジェクトマネジメント
全部好き✨
Slide 5
Slide 5 text
過去に紹介した事例も似ている
Slide 6
Slide 6 text
直近1年間で担当した
2個のプロジェクト事例をベースに紹介する
Slide 7
Slide 7 text
プロジェクト 1
- 期間 : 約6ヶ月間
- メンバー : 5-7名
- 特徴 : 若手メンバー中心
アジャイル開発経験者 / 少なめ
Slide 8
Slide 8 text
プロジェクト 2
- 期間 : 約3ヶ月間
- メンバー : 5-7名
- 特徴 : 技術的オールスターメンバー
アジャイル開発経験者 / 多め
Slide 9
Slide 9 text
主な役割 (超兼務)
- プロジェクトリーダー
- スクラムマスター
- テックリード
- インフラ全般
@kakakakakku
本当はもっと役割を減らすべき
(後半で, デリゲーションの話をする)
Slide 10
Slide 10 text
＼ プロジェクトをリードする技術 ／
Slide 11
Slide 11 text
✨ 計画 ✨
✨ タスク管理 ✨
✨ マネジメント ✨
✨ リーダーシップ ✨
Slide 12
Slide 12 text
✨ 計画 ✨
Slide 13
Slide 13 text
「異なる粒度の計画」を管理する
全体計画
スプリント
計画
スプリント
計画
スプリント
計画
スプリント
計画
タスク計画
2 week 2 week 2 week 2 week
＼ スプリントごとにスローガンを作る ／
Slide 14
Slide 14 text
「異なる粒度の計画」を管理する
- 1. 全体計画
- 「経営層 / ステークホルダー」に, コミットメントをするため
- 「チーム」に, 一緒に戦う期間を認識してもらうため
- 2. スプリント計画
- 「経営層 / ステークホルダー」に, プロジェクトが前進していることを伝えるため
- 「チーム」に, リリースする MVP (Minimum Viable Product) を伝えるため
- 3. タスク計画 : 後述
アジャイルでも
「全体計画」は必要
Slide 15
Slide 15 text
クリティカルパスを常に意識する
- 「計画が得意」=「クリティカルパスの見極めが得意」である
- プロジェクト全体を俯瞰して把握する必要がある
- 粒度は「スプリントレベル」や「プルリクエストレベル」など, いろいろ
- 特に「過去の経験が活きる」部分と言える
Slide 16
Slide 16 text
TOC : 制約条件の理論
- チームのボトルネックは, 確実に存在する
- 重要なのは「ボトルネックを常に推移させること」
- まさに「TOC : 制約条件の理論」
- ボトルネックを推移させるために, 多くのメンバーのミッションを変更する
スプリント
スプリント スプリント スプリント
ボトルネック
仕様
ボトルネック
アーキテクチャ
ボトルネック
API
ボトルネック
フロントエンド
Slide 17
Slide 17 text
スプリントレビュー と レトロスペクティブ
- スプリントレビュー
- プロトタイプ / デモを, ステークホルダーに見せる
- 動くものを使って「リアルなフィードバック」を受ける
- メンバーがどのような貢献をしたのか, 漏れなく明確に伝える (アピールする)
- レトロスペクティブ
- 「良かったこと / 感謝したいこと / 良くなかったこと / 改善策」を洗い出す
- 課題点ばかりではなく, 良かったことにも着目する雰囲気に
Slide 18
Slide 18 text
インセプションデッキを作る
- 簡単で良いので「インセプションデッキ」を作ると目線が合う
- 「エレベーターピッチ」があると, ビジネスチームに価値を伝えられる
- 「夜も眠れない問題」があると, タスクの優先順位を適切に見極められる
Slide 19
Slide 19 text
✨ タスク管理 ✨
Slide 20
Slide 20 text
タスクボードを本気で育てる
Reviewing
Doing (6)
Sprint Backlogs
Backlogs Close
タスク
タスク
タスク
タスク
タスク
タスク
タスク
タスク
タスク
タスク
タスク
タスク
タスク
タスク
タスク
タスク
※ ZenHub を使っている
優先順位
優先度
Slide 21
Slide 21 text
WIP 制限
- 「WIP = 着手中のタスク」の個数に制限を掛ける
- あれもこれも着手すると, 全部が中途半端になってしまう
- 制限する「個数」はスプリントごとに見直す
- 「始めるのをやめて, 終わらせることを始める」
- 名言‼
Doing (6)
タスク
タスク
タスク
タスク
多くても6個まで, など
Slide 22
Slide 22 text
完了の定義
- 全てのタスクで
「完了の定義」を決める
- 本当にタスクが完了なのか？の判断軸がブレないようにするため
- 作業時間の大幅なブレ, 無駄も減る
- 「終わったことになってるけど, 終わってなくない？」
- みたいな, 会話が多いと要注意
Slide 23
Slide 23 text
リードタイムを短く & タスク粒度を小さく
- 「リードタイム」=「リリースをして, タスクを Close するまで」をとにかく短くする
- 「リーン」と同じ
- タスク粒度は「1-3日程度」にしている
- 「1時間程度」にしてタスク数が爆発するのはツライ
- 「今日もこのタスクをやります」が数日間続くとツライ
- 「スウォーミング」を大切にする
- 複数のメンバーで, 助け合うこと
Slide 24
Slide 24 text
タスクの Close は全員の前で
- デイリースタンドアップでタスクを Close する
- 「全員の前で Close すること」に意味がある
- 情報共有のため
- 「右に進んだ 」という達成感
- 「Close おめでとう 」と褒め合える空気感
- Fearless Change「小さな成功」
Reviewing Close
タスク
タスク
タスク
タスク
Slide 25
Slide 25 text
✨ マネジメント ✨
Slide 26
Slide 26 text
「スキルマップ」を作成する
- プロジェクトで扱う「技術」と各メンバーの「習熟度」を可視化する
- ○ : プロジェクトを技術的にリードする ( = 全員テックリードになる )
- △ : ○ に教えてもらいながら「習熟度」を上げていく
- プロジェクトを成功させるだけではなく「メンバーの成長実感を大切にする」
- 「モチベーションコントロール」のために, とにかく重要
デザイン フロント
バックエンド
(PHP)
バックエンド
(Go)
インフラ
A ○ △
B ○ ○ △
C ○ ○ △
D △ △ ○ △
E △ ○ △ ○
Slide 27
Slide 27 text
デリゲーション (権限移譲)
- 「リーダーの限界」を「チームの限界」にしてはいけない
- リーダーがボトルネックにならないようにする
- 積極的に「デリゲーション」をする
- 「デリゲーション」と「丸投げする」は全く違う
- 期待を込めて, 技術的な判断を「任せる」
- デリゲーションポーカー (7段階) を意識する
Slide 28
Slide 28 text
暗黙知を育てる
- 暗黙知は悪ではなく, むしろ「過剰な形式知こそ悪」である
- スピード感を優先するため, チーム内で
「暗黙知を育てる」
- 全員が同じことを知っている必要はなく
- 「誰が知っているのかを知っている状態」を目指す
- 「トランザクティブ・メモリー」と言う
- まずは「チームを最適化する」
Slide 29
Slide 29 text
雑談を成功の起点にする
- 「ミーティング」よりも「雑談」を大切にする
- 「全員集合だよー！」の一言で, メンバー全員を集めて良い
- 1人で悩むより, 全員で悩む
- 常に「オートクライン」を引き起こす
- 誰かと話すことによって, 自分自身で答えに辿り着くこと
- 未成熟のチームでリモートワークを導入すると, 失敗する
Slide 30
Slide 30 text
モブプログラミング
- チーム全員で1個の開発に取り組む
- レビュープロセスがなく, その場で「合意」となる意思決定の速さがポイント
- スキルセットが異なるメンバーの強みを伝播させる
- 仕様スキル
- 設計スキル
- 実装スキル
- ショートカット / IDE 操作なども学び合える
Slide 31
Slide 31 text
✨ リーダーシップ ✨
Slide 32
Slide 32 text
ポンコツリーダー
- なんとなく「リーダー = 最強 = 百戦錬磨」のような固定概念があるけど
- 「リーダー」には人それぞれの「スタイル」があり, 正解なんてない
- ルフィ (ワンピース) と 達海猛 (GIANT KILLING) は全然違うリーダー
- 僕のスタイルは
「ポンコツリーダー」= 頼りなさそうな感じ
- 毎日, 意味もなく睡眠不足で「今日も寝てねーぞ！」とか言ってる (ミサワ)
- 技術的なことで困ったら, すぐメンバーに「助けてくれー！SOS！」とか言ってる
- でも, 自分が得意なことは, 圧倒的にやり抜く
Slide 33
Slide 33 text
ファシリタティブ・リーダーシップ
- 中立的な立場ではなく「攻めるファシリテーション」を意識する
- これを「ファシリタティブ・リーダーシップ」と言う
- 議論の「発散と収束」に責任を持つ
- 脱線する場合は「パーキングロット」に逃がす
- 適切なタイムキーピングもリーダーの仕事
- 時間通りに終わらせるだけではなく, 伸ばす判断も含めて
- 結論が出たら「Disagree & Commit」な雰囲気にする
Slide 34
Slide 34 text
成功しそう感
- 過去に成功実績が多くあるリーダーには
「成功しそう感」がある
- 言い換えると「信頼残高」とも言える
- Fearless Change「成功の匂い」
- あの人がリーダーならきっと大丈夫だろう！
- と, メンバーから思ってもらえるように, 常に成功し続ける
- 逆に, あの人がリーダーだと, 失敗しそうと言われないようにする
Slide 35
Slide 35 text
「グループ」と「チーム」の差
- メンバーが集まっただけなら, それは単なる「グループ」でしかない
- 「グループ」状態で, リモートワークは絶対に失敗する
-「結束したチーム」は 1 + 1 = ∞ にできる
- 異常な楽しさがある
- 自己組織化が進み, どんどん前に進んでいく
- 助けて！と言わなくても, 助け合いが生まれる
- チームだけで盛り上がる話題, ギャグがある
Slide 36
Slide 36 text
44 engineering management lessons
- リーダー (マネージャー) として, 必要なことが, ほとんど書いてある
- ここまで紹介してきた内容の多くも, 似たような表現で書いてある
- http://www.defmacro.org/2014/10/03/engman.html
Slide 37
Slide 37 text
まとめ
Slide 38
Slide 38 text
プロジェクトをリードすることは
「立派な技術」であり,
プロジェクトが成功しないと
「リードしたとは言えない」
今日1番伝えたいこと！