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
プロジェクトをリードする技術 (Kyash 社 再演) / Project Leading i...
Search
Yoshiaki Yoshida
April 27, 2018
Technology
4
2k
プロジェクトをリードする技術 (Kyash 社 再演) / Project Leading is Skill for Kyash
Yoshiaki Yoshida
April 27, 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
プロジェクトをリードする技術 / Project Leading is Skill
kakakakakku
43
46k
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
10分でわかるfreeeのQA
freee
1
3.4k
Oracle Base Database Service 技術詳細
oracle4engineer
PRO
5
49k
グローバル展開を見据えたサービスにおける機械翻訳プラクティス / dp-ai-translating
cyberagentdevelopers
PRO
1
150
ABEMA のコンテンツ制作を最適化!生成 AI x クラウド映像編集システム / abema-ai-editor
cyberagentdevelopers
PRO
1
180
Fargateを使った研修の話
takesection
0
120
Oracle Cloud Infrastructureデータベース・クラウド:各バージョンのサポート期間
oracle4engineer
PRO
27
12k
Forget efficiency – Become more productive without the stress
ufried
0
140
MAMを軸とした動画ハンドリングにおけるAI活用前提の整備と次世代ビジョン / abema-ai-mam
cyberagentdevelopers
PRO
1
110
フルカイテン株式会社 採用資料
fullkaiten
0
36k
サイバーエージェントにおける生成AIのリスキリング施策の取り組み / cyber-ai-reskilling
cyberagentdevelopers
PRO
2
200
新卒1年目が向き合う生成AI事業の開発を加速させる技術選定 / ai-web-launcher
cyberagentdevelopers
PRO
7
1.5k
30万人が利用するチャットをFirebase Realtime DatabaseからActionCableへ移行する方法
ryosk7
5
350
Featured
See All Featured
What's new in Ruby 2.0
geeforr
342
31k
RailsConf 2023
tenderlove
29
880
Speed Design
sergeychernyshev
24
570
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
32
1.8k
Code Reviewing Like a Champion
maltzj
519
39k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
167
49k
A better future with KSS
kneath
238
17k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
328
21k
Building an army of robots
kneath
302
42k
Reflections from 52 weeks, 52 projects
jeffersonlam
346
20k
Documentation Writing (for coders)
carmenintech
65
4.4k
Why Our Code Smells
bkeepers
PRO
334
57k
Transcript
\ プロジェクトをリードする技術 / 2018.04.27 吉田慶章 @kakakakakku 社内イベント
\ 奇跡の 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 ボトルネック フロントエンド
スプリントレビュー と レトロスペクティブ - スプリントレビュー - プロトタイプ / デモを, ステークホルダーに見せる
- 動くものを使って「リアルなフィードバック」を受ける - メンバーがどのような貢献をしたのか, 漏れなく明確に伝える (アピールする) - レトロスペクティブ - 「良かったこと / 感謝したいこと / 良くなかったこと / 改善策」を洗い出す - 課題点ばかりではなく, 良かったことにも着目する雰囲気に
インセプションデッキを作る - 簡単で良いので「インセプションデッキ」を作ると目線が合う - 「エレベーターピッチ」があると, ビジネスチームに価値を伝えられる - 「夜も眠れない問題」があると, タスクの優先順位を適切に見極められる
✨ タスク管理 ✨
タスクボードを本気で育てる 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番伝えたいこと!
再演 工夫 意識 \ 今日のアジェンダ /
ベロシティを伸ばす - 事前に「ベロシティが伸びなさそう」と推測できる場面はある - 新技術を導入するため, 学習コストが発生したり - 新人メンバーを育成したり - 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