プロジェクトをリードする技術 / Project Leading is Skill

プロジェクトをリードする技術 / Project Leading is Skill

プロジェクトをリードする技術
http://kakakakakku.hatenablog.com/entry/2018/04/23/223304

3da5b00de1285b12a17d730262cc4824?s=128

Yoshiaki Yoshida

April 23, 2018
Tweet

Transcript

  1. 4.

    関連する領域 チームビルディング / ファシリテーション / マネジメント 3.0 アジャイル ( スクラム

    / カンバン / XP ) / リーン 組織論 / 育成 / 心理学 / メンタリング / プロジェクトマネジメント 全部好き✨
  2. 7.

    プロジェクト 1 - 期間 : 約6ヶ月間 - メンバー : 5-7名

    - 特徴 : 若手メンバー中心
 アジャイル開発経験者 / 少なめ
  3. 8.

    プロジェクト 2 - 期間 : 約3ヶ月間 - メンバー : 5-7名

    - 特徴 : 技術的オールスターメンバー
 アジャイル開発経験者 / 多め
  4. 9.

    主な役割 (超兼務) - プロジェクトリーダー - スクラムマスター - テックリード - インフラ全般

    @kakakakakku 本当はもっと役割を減らすべき (後半で, デリゲーションの話をする)
  5. 13.

    「異なる粒度の計画」を管理する 全体計画 スプリント 計画 スプリント 計画 スプリント 計画 スプリント 計画

    タスク計画 2 week 2 week 2 week 2 week \ スプリントごとにスローガンを作る /
  6. 14.

    「異なる粒度の計画」を管理する - 1. 全体計画 - 「経営層 / ステークホルダー」に, コミットメントをするため -

    「チーム」に, 一緒に戦う期間を認識してもらうため - 2. スプリント計画 - 「経営層 / ステークホルダー」に, プロジェクトが前進していることを伝えるため - 「チーム」に, リリースする MVP (Minimum Viable Product) を伝えるため - 3. タスク計画 : 後述 アジャイルでも 「全体計画」は必要
  7. 16.

    TOC : 制約条件の理論 - チームのボトルネックは, 確実に存在する - 重要なのは「ボトルネックを常に推移させること」 - まさに「TOC

    : 制約条件の理論」 - ボトルネックを推移させるために, 多くのメンバーのミッションを変更する スプリント スプリント スプリント スプリント ボトルネック 仕様 ボトルネック アーキテクチャ ボトルネック API ボトルネック フロントエンド
  8. 17.

    スプリントレビュー と レトロスペクティブ - スプリントレビュー - プロトタイプ / デモを, ステークホルダーに見せる

    - 動くものを使って「リアルなフィードバック」を受ける - メンバーがどのような貢献をしたのか, 漏れなく明確に伝える (アピールする) - レトロスペクティブ - 「良かったこと / 感謝したいこと / 良くなかったこと / 改善策」を洗い出す - 課題点ばかりではなく, 良かったことにも着目する雰囲気に
  9. 20.

    タスクボードを本気で育てる Reviewing Doing (6) Sprint Backlogs Backlogs Close タスク タスク

    タスク タスク タスク タスク タスク タスク タスク タスク タスク タスク タスク タスク タスク タスク ※ ZenHub を使っている 優先順位 優先度
  10. 21.

    WIP 制限 - 「WIP = 着手中のタスク」の個数に制限を掛ける - あれもこれも着手すると, 全部が中途半端になってしまう -

    制限する「個数」はスプリントごとに見直す - 「始めるのをやめて, 終わらせることを始める」 - 名言‼ Doing (6) タスク タスク タスク タスク 多くても6個まで, など
  11. 23.

    リードタイムを短く & タスク粒度を小さく - 「リードタイム」=「リリースをして, タスクを Close するまで」をとにかく短くする - 「リーン」と同じ

    - タスク粒度は「1-3日程度」にしている - 「1時間程度」にしてタスク数が爆発するのはツライ - 「今日もこのタスクをやります」が数日間続くとツライ - 「スウォーミング」を大切にする - 複数のメンバーで, 助け合うこと
  12. 24.

    タスクの Close は全員の前で - デイリースタンドアップでタスクを Close する - 「全員の前で Close

    すること」に意味がある - 情報共有のため - 「右に進んだ 」という達成感 - 「Close おめでとう 」と褒め合える空気感 - Fearless Change「小さな成功」 Reviewing Close タスク タスク タスク タスク
  13. 26.

    「スキルマップ」を作成する - プロジェクトで扱う「技術」と各メンバーの「習熟度」を可視化する - ◦ : プロジェクトを技術的にリードする ( = 全員テックリードになる

    ) - △ : ◦ に教えてもらいながら「習熟度」を上げていく - プロジェクトを成功させるだけではなく「メンバーの成長実感を大切にする」 - 「モチベーションコントロール」のために, とにかく重要 デザイン フロント バックエンド (PHP) バックエンド (Go) インフラ A ◦ △ B ◦ ◦ △ C ◦ ◦ △ D △ △ ◦ △ E △ ◦ △ ◦
  14. 28.

    暗黙知を育てる - 暗黙知は悪ではなく, むしろ「過剰な形式知こそ悪」である - スピード感を優先するため, チーム内で 「暗黙知を育てる」 - 全員が同じことを知っている必要はなく

    - 「誰が知っているのかを知っている状態」を目指す - 「トランザクティブ・メモリー」と言う - まずは「チームを最適化する」
  15. 29.

    雑談を成功の起点にする - 「ミーティング」よりも「雑談」を大切にする - 「全員集合だよー!」の一言で, メンバー全員を集めて良い - 1人で悩むより, 全員で悩む -

    常に「オートクライン」を引き起こす - 誰かと話すことによって, 自分自身で答えに辿り着くこと - 未成熟のチームでリモートワークを導入すると, 失敗する
  16. 32.

    ポンコツリーダー - なんとなく「リーダー = 最強 = 百戦錬磨」のような固定概念があるけど - 「リーダー」には人それぞれの「スタイル」があり, 正解なんてない

    - ルフィ (ワンピース) と 達海猛 (GIANT KILLING) は全然違うリーダー - 僕のスタイルは 「ポンコツリーダー」= 頼りなさそうな感じ - 毎日, 意味もなく睡眠不足で「今日も寝てねーぞ!」とか言ってる (ミサワ) - 技術的なことで困ったら, すぐメンバーに「助けてくれー!SOS!」とか言ってる - でも, 自分が得意なことは, 圧倒的にやり抜く
  17. 34.

    成功しそう感 - 過去に成功実績が多くあるリーダーには 「成功しそう感」がある - 言い換えると「信頼残高」とも言える - Fearless Change「成功の匂い」 -

    あの人がリーダーならきっと大丈夫だろう! - と, メンバーから思ってもらえるように, 常に成功し続ける - 逆に, あの人がリーダーだと, 失敗しそうと言われないようにする
  18. 35.

    「グループ」と「チーム」の差 - メンバーが集まっただけなら, それは単なる「グループ」でしかない - 「グループ」状態で, リモートワークは絶対に失敗する -「結束したチーム」は 1 +

    1 = ∞ にできる - 異常な楽しさがある - 自己組織化が進み, どんどん前に進んでいく - 助けて!と言わなくても, 助け合いが生まれる - チームだけで盛り上がる話題, ギャグがある
  19. 36.

    44 engineering management lessons - リーダー (マネージャー) として, 必要なことが, ほとんど書いてある

    - ここまで紹介してきた内容の多くも, 似たような表現で書いてある - http://www.defmacro.org/2014/10/03/engman.html
  20. 37.