Slide 1

Slide 1 text

アジャイル開発の プロジェクトマネージャーが おさえておくべき5項目 2020/04/11 (Sat) YogAgile Engineer 岩村 琢 #開発PM勉強会

Slide 2

Slide 2 text

自己紹介 #開発PM勉強会 @takusamar いわむー@ヨガはいいぞ 沖縄在住のフリーランスITエンジニア ヨガ×アジャイルで健康なチームづくりをサポートしています アジャイルゆいまーる https://agile-yuimar.connpass.com Licensed Scrum Product Owner (2018/06) Certified Scrum Master (2020/02) アジャイル開発のコミュニティ 「アジャイルゆいまーる」を運営 https://agile-yuimar.connpass.com/

Slide 3

Slide 3 text

現在のお仕事 #開発PM勉強会 2019年10月~ KDDI DIGITAL GATE フロントエンド開発(React/Flutter) スクラム、モブプログラミング 月 火 水 木 金 10:00 10:30 15:30 16:00 16:30 18:00 18:15 18:30 Weekly計画 Daily計画 (雑談) Dailyレビュー ふりかえり Daily計画 (雑談) Dailyレビュー ふりかえり Daily計画 (雑談) Dailyレビュー ふりかえり Daily計画 Weeklyレビュー ふりかえり (自由) (OST) オープン スペース テクノロジー DIGITAL GATEの働き方(1週間) エンジニア募集中! https://js02.jposting.net/kddi/u/job.phtml?job_code=603 週1で自由に使える時間

Slide 4

Slide 4 text

【宣伝】みんなでアジャイル #開発PM勉強会 これからアジャイルをはじめようという人向けの解説書 特にエンジニア以外(PM、営業、役員、…)におすすめ お金は一切もらってません 本はもらいました

Slide 5

Slide 5 text

さて、本題の #開発PM勉強会 アジャイル開発の プロジェクトマネージャーが おさえておくべき5項目 に入る前に・・・

Slide 6

Slide 6 text

リーダーのあるべき姿 #開発PM勉強会 リーダーの三原則:媚びない、キレない、意地を張らない。 結果が出ないのは、指導者の想いが弱いからだ 矢印を相手に向けずに自分に向ける 責任を果たすリーダーがいてこそ、フォロワーシップが生まれる 自分の弱さに気づいたとき、義務が権利に変わる 「できる、できない」を選別するのではなく「どう伸ばすか?」 「信」は力なり。「信」とは「人の心に任す」こと 愛情が足りないから、気づかせることができない : 「スクール・ウォーズ」のモデルとなった、 泣き虫先生と教え子が語る リーダー、指導者のための組織変革のバイブル

Slide 7

Slide 7 text

めあて #開発PM勉強会 1. アジャイルはマインドセットである 2. 予算と納期を固定して、スコープを調整する 3. 管理ツールは自分たちでつくる 4. タスク出しは作業手順を書き出す 5. チーム自身で考えて行動する 独断と偏見で選んだ5項目

Slide 8

Slide 8 text

1. アジャイルなマインドセット #開発PM勉強会 マインドセット = ものの見方、習慣 人生観、仕事観 「こういう生き方をしたい」 「こういう働き方をしたい」 私はどう在りたいのか、という思い アジャイルなマインドセットとは・・・ 「半分の時間で倍の仕事を」 仕事はさっさと片付けて 空いた時間で 人生を豊かに過ごそう スピードがあがらなかったら アジャイルの意味がない フレームワーク、手法、ツール・・・ そういうものを語る前に、まずこの思考回路を身につける。

Slide 9

Slide 9 text

2. スコープを調整 #開発PM勉強会 従来の開発アプローチ 「要件は変わらないはず」 スコープ 予算 納期 (固定) (可変) アジャイル開発アプローチ 「要件は変化する」 予算 納期 スコープ 予算や納期も固定されていて どうしようもないことも良くある その場合は品質が犠牲になる 品質 品質 予算・納期に合わせて スコープを調整することで 品質を維持する

Slide 10

Slide 10 text

#開発PM勉強会 20%の機能で80%の要求はカバーできる 要求を「ビジネスに与える貢献度・重要度」の順に並べて、 どこまで作ればいいかを調整する。 「あればいい」機能は 「無くてもいい」 本当にその機能が ビジネスの価値を高めるか? を見極める 80点で良い。100点をとろうとしない(コスパが悪い)

Slide 11

Slide 11 text

3. 手作りの管理ツール #開発PM勉強会 目的:「現状把握」=見える化 問題が発生したらすぐ気づき、対策をとるため。 最初のうちはアナログがベスト。 (ホワイトボード、付箋紙、など) 最低限、作るべきものは以下の2つ。 • タスクボード • バーンダウンチャート 生きてる情報をリアルタイムで 見せられることが大事 PMがExcelやパワポに ごにょごにょ書いた情報は すでに死んでいる

Slide 12

Slide 12 text

#開発PM勉強会 管理ツール例(予定表) 1時間ごとのスプリントを計画 (計画通りに進むとは言ってない) とりあえずの目安として決めておく スプリント内のタイムボックス リズムを作り、慣れることが大事 【事例】娘(小6)の算数の宿題を 片付けるプロジェクト

Slide 13

Slide 13 text

#開発PM勉強会 管理ツール例(タスクボード) クローゼットの扉を活用 (青)PBL (黄)タスク

Slide 14

Slide 14 text

#開発PM勉強会 管理ツール例(バーンダウンチャート) 進み具合、遅れ具合が 直感的にわかる

Slide 15

Slide 15 text

#開発PM勉強会 見える化の定義 誰でも一瞬にして その状態が正常か異常か判定がつく状態にすること 管理基準の中か外か 管理基準(DoD=完了の定義) はチーム毎に異なる。 異常が発生したら手当てする。 正常は放っておいてよい。 他人のフォーマット、市販の管理ツールに合わせてたら ありのままを見せられない。 →自作あるのみ チームの成長に合わせてどんどんアップデートする。 前職ではJIRAやRedmineを 使っていたけど 本当に●●でした

Slide 16

Slide 16 text

4. タスク出しは作業手順 #開発PM勉強会 機能の細分化ではなく、作業手順を書き出す。 ○:「~~を作る」「~~を設定する」 ×:「□□機能」 「△△画面」 「☆☆処理」 要件 製造 工程 設計 ユーザー ストーリー PBL ユーザー ストーリー Task GitHubリポジトリを作る Apple Developerを設定する Flutterプロジェクトを作る : : 「読んだら手が勝手に動き出す」 そのぐらい具体的に書く

Slide 17

Slide 17 text

#開発PM勉強会 「どうやって作るか」が品質を高める 「どうやって作るか」を開発チームで検討し共有する。 実装者に丸投げしない(チームとしての品質を保つため) Part 1 POと開発チームで話し合い このスプリントで取り組むバックログアイテムを決定する。 Part 2 開発チームで話し合い バックログアイテムをタスクに分解する。 各タスクの作業時間を見積もる(理想は1時間程度) ソフトウェアの品質とは何か? 「バグがない」は当たり前。 その上のレベルでの品質とは? タスクの大きさ(粒度)を揃えると 見積もりがしやすい メンバ同士の同期がとりやすい スプリントプランニング(計画)

Slide 18

Slide 18 text

#開発PM勉強会 「完了の定義」を決める 完了の定義(DoD:Definition of Done) そのタスクの作業をどこまでやれば完了としてよいか、 作業を開始する前に判断基準を定義しておく。 目的: やることが明確になる。無駄な作業がなくなる。 テストを先に書ける。テスト駆動開発(TDD)に不可欠。 次のタスクへ不具合を持ち越さない(自工程完結) 定義のコツ: 機能要件だけでなく非機能要件も定義する。 客観的に完了/未完了が判断できる基準をつくる。 タスクは完了したか? 不具合や問題点はないか? を判定する「測定器」

Slide 19

Slide 19 text

5. チーム自身で考えて行動 #開発PM勉強会 スクラムガイド スクラムチームは自己組織化されており、機能横断的である。 自己組織化チームは、作業を成し遂げるための最善の策を、 チーム外からの指示ではなく、自分たちで選択する。 なぜ、自己組織化が必要なのか? →機動力を高めるため →仕事が義務ではなく権利になるため →圧倒的に成長するため チームが決定権を持っていないと、誰かの 指示・判断を待つ時間が発生してしまう 自分の仕事という責任感を 持って取り組める 成功も失敗も自分自身で受け止め、 行動をふりかえり、改善しつづける 個々の自律的な振る舞いの結果として、 秩序を持つ大きな構造を作り出す現象 自己組織化・・・

Slide 20

Slide 20 text

#開発PM勉強会 自己組織化チームを育てるには アドバイスは自主性を潰す 質問されても答えを教えてはいけない。 自分自身で考え行動する 習慣をつけさせる エラい人の助言は絶対禁止! その気はなくても忖度をしてしまうのが人間。 チームが思考停止してしまう。 チームに権限を与え、目標にコミットさせる 目標達成につながることならば、何をしてもよい。 その代わり、常に全力を尽くすこと。 責任をとる覚悟もなしに 口だけ出す連中から チームを守るのが マネージャーの役割 権限と責任はセット 責任ある立場に置かれると 人は成長する

Slide 21

Slide 21 text

まとめ #開発PM勉強会 1. アジャイルはマインドセットである →圧倒的なビジネススピードを重視する。 2. 予算と納期を固定して、スコープを調整する →20%の機能で80%の要求はカバーできる。 3. 管理ツールは自分たちでつくる →目的は現状把握。自分たちが使いやすいものが一番。 4. タスク出しは作業手順を書き出す →「どうやって作るか」「完了の定義」で品質を高める。 5. チーム自身で考えて行動する →誰かの指示を待つのではなく、自分たちで意思決定。

Slide 22

Slide 22 text

リーダーのあるべき姿 #開発PM勉強会 リーダーの三原則:媚びない、キレない、意地を張らない。 責任を果たすリーダーがいてこそ、フォロワーシップが生まれる 自分の弱さに気づいたとき、義務が権利に変わる 「できる、できない」を選別するのではなく「どう伸ばすか?」 結果が出ないのは、指導者の想いが弱いからだ 「信」は力なり。「信」とは「人の心に任す」こと 気づきは行動の原動力 愛情が足りないから、気づかせることができない 「言われたことだけやれば良い」が感性の鈍さを招く 自己決定が内発的モチベーションを促す

Slide 23

Slide 23 text

ご清聴ありがとうございました 今日お会いした皆様が身も心も健康で過ごせますように #開発PM勉強会