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