Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
プロジェクトをリードする技術 / Project Leading is Skill
Search
Yoshiaki Yoshida
April 23, 2018
Technology
43
46k
プロジェクトをリードする技術 / Project Leading is Skill
プロジェクトをリードする技術
http://kakakakakku.hatenablog.com/entry/2018/04/23/223304
Yoshiaki Yoshida
April 23, 2018
Tweet
Share
More Decks by Yoshiaki Yoshida
See All by Yoshiaki Yoshida
技術ブロガーを育てる!ブログメンタリングで何を教えているのか / Passion for Blog Mentoring
kakakakakku
8
36k
プログラミング初心者に教えるときは「身近な比喩」が重要なのだ! / Metaphor is Important for Beginner Programmer
kakakakakku
2
5.5k
プロジェクトの成功を支える ZenHub と モブプログラミング / ZenHub and Mob Programming
kakakakakku
1
5.6k
楽しく!アウトプットを習慣化しよう / Let's Enjoy Output
kakakakakku
3
6.6k
さぁ!今すぐプロジェクトリーダーに立候補しよう / Be a Project Leader
kakakakakku
3
8.9k
プロジェクトをリードする技術 (Kyash 社 再演) / Project Leading is Skill for Kyash
kakakakakku
4
2k
Mackerel で ECS をどこまでモニタリングできるのか / Monitoring ECS with Mackerel
kakakakakku
0
13k
[2018/01/30] Redash 初心者向けハンズオン / Redash Meetup #0.1
kakakakakku
0
2.3k
プログラミング初心者に Rails を教えるコツ / Tips for Teaching Rails
kakakakakku
5
4.1k
Other Decks in Technology
See All in Technology
ガバメントクラウド開発と変化と成長する組織 / Organizational change and growth in developing a government cloud
kazeburo
0
110
Rubyはなぜ「たのしい」のか? / Why is Ruby a programmers' best friend? #tqrk15
expajp
4
1.7k
リスクから学ぶKubernetesコンテナセキュリティ/k8s-risk-and-security
mochizuki875
1
250
【インフラエンジニアbooks】30分でわかる「AWS継続的セキュリティ実践ガイド」
hssh2_bin
1
570
つよつよリーダーが 抜けたらどうする? 〜ナビタイムのAgile⽀援組織の変遷〜
navitimejapan
PRO
22
13k
XP matsuri 2024 - 銀河英雄伝説に学ぶ
kawaguti
PRO
3
480
KDD2024参加報告
cyberagentdevelopers
PRO
0
190
10Xでのデータ基盤の変遷とこれから: データマネジメントのリアル 〜BtoB企業3社の歩みとこれから〜
10xinc
6
1.2k
Understanding and Optimising INP
akshayysharma
0
150
Dual level of task scheduling for VM workloads
ennael
PRO
0
180
Causal Impactを用いたLINE Pay UIの効果検証とABテスト実施への貢献
lycorptech_jp
PRO
2
470
C# 13 / .NET 9 の新機能 (RC 1 時点)
nenonaninu
1
1.1k
Featured
See All Featured
Typedesign – Prime Four
hannesfritz
39
2.3k
Code Review Best Practice
trishagee
62
16k
Building Adaptive Systems
keathley
37
2.1k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
42
6.5k
KATA
mclloyd
27
13k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
29
1.7k
Automating Front-end Workflow
addyosmani
1365
200k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
91
16k
We Have a Design System, Now What?
morganepeng
49
7.1k
Raft: Consensus for Rubyists
vanstee
136
6.6k
Happy Clients
brianwarren
97
6.6k
Optimising Largest Contentful Paint
csswizardry
31
2.8k
Transcript
\ プロジェクトをリードする技術 / 2018.04.23 吉田慶章 @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 ボトルネック フロントエンド
スプリントレビュー と レトロスペクティブ - スプリントレビュー - プロトタイプ / デモを, ステークホルダーに見せる
- 動くものを使って「リアルなフィードバック」を受ける - メンバーがどのような貢献をしたのか, 漏れなく明確に伝える (アピールする) - レトロスペクティブ - 「良かったこと / 感謝したいこと / 良くなかったこと / 改善策」を洗い出す - 課題点ばかりではなく, 良かったことにも着目する雰囲気に
インセプションデッキを作る - 簡単で良いので「インセプションデッキ」を作ると目線が合う - 「エレベーターピッチ」があると, ビジネスチームに価値を伝えられる - 「夜も眠れない問題」があると, タスクの優先順位を適切に見極められる
✨ タスク管理 ✨
タスクボードを本気で育てる Reviewing Doing (6) Sprint Backlogs Backlogs 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
まとめ
プロジェクトをリードすることは 「立派な技術」であり, プロジェクトが成功しないと 「リードしたとは言えない」 今日1番伝えたいこと!