20200411_agilepm_pmdev

アジャイル開発のプロジェクトマネージャーがおさえておくべき５項目

2020/04/11 (Sat)
【開発PM勉強会☆沖縄スピンオフvol.1】プロジェクトマネジメントを学ぼう！オンラインLT会

リーダーのあるべき姿
アジャイル開発のプロジェクトマネージャーがおさえておくべき５項目
1. アジャイルはマインドセットである
2. 予算と納期を固定して、スコープを調整する
3. 管理ツールは自分たちでつくる
4. タスク出しは作業手順を書き出す
5. チーム自身で考えて行動する

Transcript

1. アジャイル開発の プロジェクトマネージャーが おさえておくべき５項目 2020/04/11 (Sat) YogAgile Engineer 岩村 琢 #開発PM勉強会
2. 自己紹介 #開発PM勉強会 @takusamar いわむー＠ヨガはいいぞ 沖縄在住のフリーランスITエンジニア ヨガ×アジャイルで健康なチームづくりをサポートしています アジャイルゆいまーる https://agile-yuimar.connpass.com Licensed Scrum Product Owner （2018/06） Certified Scrum Master （2020/02） アジャイル開発のコミュニティ 「アジャイルゆいまーる」を運営 https://agile-yuimar.connpass.com/
3. 現在のお仕事 #開発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の働き方（１週間） エンジニア募集中！ https://js02.jposting.net/kddi/u/job.phtml?job_code=603 週１で自由に使える時間
4. 【宣伝】みんなでアジャイル #開発PM勉強会 これからアジャイルをはじめようという人向けの解説書 特にエンジニア以外（PM、営業、役員、…）におすすめ お金は一切もらってません 本はもらいました
5. さて、本題の #開発PM勉強会 アジャイル開発の プロジェクトマネージャーが おさえておくべき５項目 に入る前に・・・
6. リーダーのあるべき姿 #開発PM勉強会 リーダーの三原則：媚びない、キレない、意地を張らない。 結果が出ないのは、指導者の想いが弱いからだ 矢印を相手に向けずに自分に向ける 責任を果たすリーダーがいてこそ、フォロワーシップが生まれる 自分の弱さに気づいたとき、義務が権利に変わる 「できる、できない」を選別するのではなく「どう伸ばすか？」 「信」は力なり。「信」とは「人の心に任す」こと 愛情が足りないから、気づかせることができない ： 「スクール・ウォーズ」のモデルとなった、 泣き虫先生と教え子が語る リーダー、指導者のための組織変革のバイブル
7. めあて #開発PM勉強会 1. アジャイルはマインドセットである 2. 予算と納期を固定して、スコープを調整する 3. 管理ツールは自分たちでつくる 4. タスク出しは作業手順を書き出す 5. チーム自身で考えて行動する 独断と偏見で選んだ５項目
8. 1. アジャイルなマインドセット #開発PM勉強会 マインドセット ＝ ものの見方、習慣 人生観、仕事観 「こういう生き方をしたい」 「こういう働き方をしたい」 私はどう在りたいのか、という思い アジャイルなマインドセットとは・・・ 「半分の時間で倍の仕事を」 仕事はさっさと片付けて 空いた時間で 人生を豊かに過ごそう スピードがあがらなかったら アジャイルの意味がない フレームワーク、手法、ツール・・・ そういうものを語る前に、まずこの思考回路を身につける。
9. 2. スコープを調整 #開発PM勉強会 従来の開発アプローチ 「要件は変わらないはず」 スコープ 予算 納期 （固定） （可変） アジャイル開発アプローチ 「要件は変化する」 予算 納期 スコープ 予算や納期も固定されていて どうしようもないことも良くある その場合は品質が犠牲になる 品質 品質 予算・納期に合わせて スコープを調整することで 品質を維持する
10. #開発PM勉強会 20%の機能で80%の要求はカバーできる 要求を「ビジネスに与える貢献度・重要度」の順に並べて、 どこまで作ればいいかを調整する。 「あればいい」機能は 「無くてもいい」 本当にその機能が ビジネスの価値を高めるか？ を見極める 80点で良い。100点をとろうとしない（コスパが悪い）
11. 3. 手作りの管理ツール #開発PM勉強会 目的：「現状把握」＝見える化 問題が発生したらすぐ気づき、対策をとるため。 最初のうちはアナログがベスト。 （ホワイトボード、付箋紙、など） 最低限、作るべきものは以下の２つ。 • タスクボード • バーンダウンチャート 生きてる情報をリアルタイムで 見せられることが大事 PMがExcelやパワポに ごにょごにょ書いた情報は すでに死んでいる
12. #開発PM勉強会 管理ツール例（予定表） １時間ごとのスプリントを計画 （計画通りに進むとは言ってない） とりあえずの目安として決めておく スプリント内のタイムボックス リズムを作り、慣れることが大事 【事例】娘（小６）の算数の宿題を 片付けるプロジェクト
13. #開発PM勉強会 管理ツール例（タスクボード） クローゼットの扉を活用 （青）PBL （黄）タスク
14. #開発PM勉強会 管理ツール例（バーンダウンチャート） 進み具合、遅れ具合が 直感的にわかる
15. #開発PM勉強会 見える化の定義 誰でも一瞬にして その状態が正常か異常か判定がつく状態にすること 管理基準の中か外か 管理基準（DoD=完了の定義） はチーム毎に異なる。 異常が発生したら手当てする。 正常は放っておいてよい。 他人のフォーマット、市販の管理ツールに合わせてたら ありのままを見せられない。 →自作あるのみ チームの成長に合わせてどんどんアップデートする。 前職ではJIRAやRedmineを 使っていたけど 本当に••でした
16. 4. タスク出しは作業手順 #開発PM勉強会 機能の細分化ではなく、作業手順を書き出す。 ◦：「～～を作る」「～～を設定する」 ×：「□□機能」 「△△画面」 「☆☆処理」 要件 製造 工程 設計 ユーザー ストーリー PBL ユーザー ストーリー Task GitHubリポジトリを作る Apple Developerを設定する Flutterプロジェクトを作る ： ： 「読んだら手が勝手に動き出す」 そのぐらい具体的に書く
17. #開発PM勉強会 「どうやって作るか」が品質を高める 「どうやって作るか」を開発チームで検討し共有する。 実装者に丸投げしない（チームとしての品質を保つため） Part 1 POと開発チームで話し合い このスプリントで取り組むバックログアイテムを決定する。 Part 2 開発チームで話し合い バックログアイテムをタスクに分解する。 各タスクの作業時間を見積もる（理想は１時間程度） ソフトウェアの品質とは何か？ 「バグがない」は当たり前。 その上のレベルでの品質とは？ タスクの大きさ（粒度）を揃えると 見積もりがしやすい メンバ同士の同期がとりやすい スプリントプランニング（計画）
18. #開発PM勉強会 「完了の定義」を決める 完了の定義（DoD：Definition of Done） そのタスクの作業をどこまでやれば完了としてよいか、 作業を開始する前に判断基準を定義しておく。 目的： やることが明確になる。無駄な作業がなくなる。 テストを先に書ける。テスト駆動開発（TDD）に不可欠。 次のタスクへ不具合を持ち越さない（自工程完結） 定義のコツ： 機能要件だけでなく非機能要件も定義する。 客観的に完了／未完了が判断できる基準をつくる。 タスクは完了したか？ 不具合や問題点はないか？ を判定する「測定器」
19. 5. チーム自身で考えて行動 #開発PM勉強会 スクラムガイド スクラムチームは自己組織化されており、機能横断的である。 自己組織化チームは、作業を成し遂げるための最善の策を、 チーム外からの指示ではなく、自分たちで選択する。 なぜ、自己組織化が必要なのか？ →機動力を高めるため →仕事が義務ではなく権利になるため →圧倒的に成長するため チームが決定権を持っていないと、誰かの 指示・判断を待つ時間が発生してしまう 自分の仕事という責任感を 持って取り組める 成功も失敗も自分自身で受け止め、 行動をふりかえり、改善しつづける 個々の自律的な振る舞いの結果として、 秩序を持つ大きな構造を作り出す現象 自己組織化・・・
20. #開発PM勉強会 自己組織化チームを育てるには アドバイスは自主性を潰す 質問されても答えを教えてはいけない。 自分自身で考え行動する 習慣をつけさせる エラい人の助言は絶対禁止！ その気はなくても忖度をしてしまうのが人間。 チームが思考停止してしまう。 チームに権限を与え、目標にコミットさせる 目標達成につながることならば、何をしてもよい。 その代わり、常に全力を尽くすこと。 責任をとる覚悟もなしに 口だけ出す連中から チームを守るのが マネージャーの役割 権限と責任はセット 責任ある立場に置かれると 人は成長する
21. まとめ #開発PM勉強会 1. アジャイルはマインドセットである →圧倒的なビジネススピードを重視する。 2. 予算と納期を固定して、スコープを調整する →20％の機能で80％の要求はカバーできる。 3. 管理ツールは自分たちでつくる →目的は現状把握。自分たちが使いやすいものが一番。 4. タスク出しは作業手順を書き出す →「どうやって作るか」「完了の定義」で品質を高める。 5. チーム自身で考えて行動する →誰かの指示を待つのではなく、自分たちで意思決定。
22. リーダーのあるべき姿 #開発PM勉強会 リーダーの三原則：媚びない、キレない、意地を張らない。 責任を果たすリーダーがいてこそ、フォロワーシップが生まれる 自分の弱さに気づいたとき、義務が権利に変わる 「できる、できない」を選別するのではなく「どう伸ばすか？」 結果が出ないのは、指導者の想いが弱いからだ 「信」は力なり。「信」とは「人の心に任す」こと 気づきは行動の原動力 愛情が足りないから、気づかせることができない 「言われたことだけやれば良い」が感性の鈍さを招く 自己決定が内発的モチベーションを促す
23. ご清聴ありがとうございました 今日お会いした皆様が身も心も健康で過ごせますように #開発PM勉強会