Tweet
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