ウォーターフォールPjMが アジャイルを導入するまで XP祭り2023 tanaka-san

アジェンダ • 自己紹介 • テーマ • アプローチ • 導入結果 • まとめ

自己紹介 田中 久義（tanaka-san） Sierマネージャー • 入社以来ウォーターフォール案件 現在 • アジャイル開発の部署に異動 • 現場にアジャイル（LeSS）導入 • 5チーム（約20名）のスクラムマスター

誰に向けて？ • 今までウォーターフォール型開発に参画してきた方 • これから初めてアジャイル型開発に参画する方 • これから現場を、アジャイルに変えていきたい方

ウォーターフォール（WF） ウォーターフォール プロジェクトマネージャー アジャイル • 予測型開発アプローチ • プロジェクトのライフサイクル（計画・設計・開発・テスト etc）をフェーズごとに区切って管理する • フェーズごとに完了判定を行い、 次のフェーズに行く • 完了しなければ、次のフェーズに行かない（？） • フェーズ事の計画が上手くできる場合は問題ない

アジャイル（Agile） ウォーターフォール • 適応型開発アプローチ • 大まかな目標から始めて、 漸進的に開発を進めていくこと • イテレーションというサイクルの中で、 設計・開発・リリースを繰り返し行い、開発する • 適応しながら進めていく、計画も変えていく アジャイル プロジェクトマネージャー

ウォーターフォール と アジャイル ウォーターフォールとアジャイルの違いは開発アプローチ WF：計画 ＞ 実績　⇄　Agile：実績 ＞ 計画 アジャイル 実装 設計 計画 ウォーターフォール テスト 計画 設計 実装 テスト ソフトウェア開発するという目的は同じ！

プロジェクトマネージャー（PjM） ウォーターフォール • プロジェクトマネジメント • プロジェクト 独自のプロダクトやサービスを創造するため に実施さ れる 有期性のある業務を管理する • なぜ管理が必要なのか？ • プロジェクトはそれぞれ独自性のあるもの • 業務はそれぞれが相互に関連しあっている プロジェクトマネージャー アジャイル

アジャイルにはプロジェクトマネージャーは不要？ プロジェクトにマネジメントは必要 • マネジメントを行うのが、マネージャーではなく、チームの 一人一人になった • Scrumのプロダクトオーナー＝マネージャー、スクラム マスターがリーダーではない • 誰がどう行うかは、現場それぞれによって異なる • マネージャーやリーダー経験のある人は、 どうやってみんなにマネジメントをおこなってもらうか、リー ダーシップを発揮してもらうかを考える

導入する現場 • 実際に参画した現場 • とある会社の社内システム開発チーム • 16名のマルチベンダーチーム • 慢性的な人手不足 • 毎朝全員のタスク状況を共有し、 チームのリーダーがタスクを割り当てる • リーダーが全員のタスクマネジメントを行っている • その負荷で先の見通しを立てたり、 ステークホルダーマネジメントが行えない

アプローチ ① チームに向けて • アジャイルの知見をもとに現場改善に着手 • 改めてチームビルディングを行う • 色々なワークを行い、チームを知り、自分を知ってもらう。 • 小チーム制を導入 • 人数を 3〜 5名程度に分けた小チームを構築 • Scrum / LeSSを導入 • チームリーダーはプロダクトオーナーに。 • 改善に意欲を持つメンバーをスクラムマスターに。（私と一緒に２人SM） • 残りのメンバーは、開発者に。

アプローチ ① チームに向けて 具体的なチームビルディングの手法 • AsIs-ToBe分析 • チームの目指す姿を作る（MVV） • ドラッカー式エクササイズ • スキルマップ作成、インセプションデッキ作成 • ニコニコカレンダー • 模擬スクラム研修 　　etc… 何がチームに有効なのか、実際にやってみて仮説検証を繰り返す

アプローチ ② 個人に向けて • プロダクトオーナー、スクラムマスター • 一人一人のタスクマネジメントから、ステークホルダーマネジメントや プロダクト目的の明確化や共有に比重を置く • 自分たちが行うのではなく、どうすればやってもらえるのかを一緒に考える • 開発者 • 自分たちでタスクを考えて実行していく • 個人ではなくチームで成果を残す

アプローチ ② 個人に向けて 具体的な活動 • ステークホルダーマネジメント • ステークホルダーマッピング • 会社方針の理解、会社のKPI、OKR • ピープルマネジメント • 1on1、賞賛とフィードバック、ふりかえり • フレームワークを用いながら、 個々人が興味を持ち、意欲を持てる方向を一緒に探した • どうやるか(How)を教えるのではなく、なぜやるか(Why)・なにをやるか(What)に気 がつけるようにした

導入結果 • 現在のチーム構成 • メンバーは 16名から 23名で 7名増員 • 3つのフィーチャー開発チームと、1つのイネーブリングチーム • チームの中から品質改善の声があがり、イネーブリングチームが出来上がった • 一つ一つの小チームが自律的に行動し、計画調整等も実行 • プロダクトオーナーは先を見据えたプロダクトバックログを作り、スクラムマスターは 自分の個性を生かした領域での改善を行えるメンバーに 今のところは順調に改善できている（と思われる）

まとめ • ウォーターフォールでもアジャイルでも重要なものは変わらない • ”誰がやるか”、”どうやるか”は変える必要がある • ウォーターフォール経験者がアジャイル開発に行く場合は、今まで１人でやってきた ことをみんなにどうやってもらうかを考えよう • やり方は押し付けるのではなく、現場のメンバーの考えを尊重しよう • 自分の知見を周りに広げ、周りの知見を吸収しよう • 周りに広げようとすることで自分の知見はさらに高まる • 自分の成功体験・失敗体験をみんなに役立つ知見に昇華させよう これからも周りと一緒に成長していきたいと思っています！

参考図書 • 正しいものを正しくつくる / 市谷 聡啓 プロダクトをつくるとはどういうことなのか、あるいはアジャイルのその先について • アジャイル型プロダクトマネジメント / 中谷 公巳 最高のチームで価値を実現するために • 問いのデザイン / 安斎 勇樹・塩瀬 隆之 創造的対話のファシリテーション • チームトポロジー / マシュー・スケルトン 価値あるソフトウェアをすばやく届ける適応

XP祭り2023 tanaka-san