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