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
20241031_AWS_生成AIハッカソン_GenMuck
tsumita
0
110
バクラクにおける可観測性向上の取り組み
yuu26
3
410
オニオンアーキテクチャで実現した 本質課題を解決する インフラ移行の実例
hryushm
14
3k
Jr. Championsになって、強く連携しながらAWSをもっと使いたい!~AWSに対する期待と行動~
amixedcolor
0
190
10分でわかるfreeeのQA
freee
1
3.4k
Forget efficiency – Become more productive without the stress
ufried
0
120
来年もre:Invent2024 に行きたいあなたへ - “集中”と“つながり”で楽しむ -
ny7760
0
470
AWSコンテナ本出版から3年経った今、もし改めて執筆し直すなら / If I revise our container book
iselegant
15
4k
生成AIとAWS CDKで実現! 自社ブログレビューの効率化
ymae
2
330
ガバメントクラウド先行事業中間報告を読み解く
sugiim
1
1.3k
使えそうで使われないCloudHSM
maikamibayashi
0
170
MAMを軸とした動画ハンドリングにおけるAI活用前提の整備と次世代ビジョン / abema-ai-mam
cyberagentdevelopers
PRO
1
110
Featured
See All Featured
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
280
13k
The MySQL Ecosystem @ GitHub 2015
samlambert
250
12k
Thoughts on Productivity
jonyablonski
67
4.3k
10 Git Anti Patterns You Should be Aware of
lemiorhan
654
59k
It's Worth the Effort
3n
183
27k
Automating Front-end Workflow
addyosmani
1365
200k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
504
140k
Typedesign – Prime Four
hannesfritz
39
2.4k
Gamification - CAS2011
davidbonilla
80
5k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
46
2.1k
Product Roadmaps are Hard
iamctodd
PRO
48
10k
Practical Orchestrator
shlominoach
186
10k
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番伝えたいこと!