
プロジェクトマネージャーからスクラムマスターにジョブチェンジ 〜 PM経験者向けアジャイル開発の学びかた
アジャイル開発ってPM経験者からすると隣の芝生は青い状態で羨ましくて、でも自身がアジャイル開発をファシリテートできるかというと、覚えることがいっぱいあって、なかなか手が出せないものなんじゃないかなと思うんですよね。
自分の場合は、予期せず急にスクラムマスターをすることになりました。
これまでウォーターフォールでのPMの経験は何度もあったのですがアジャイルプロジェクトの経験はありませんでした。
3週間後には自分がスクラムマスター(SM)としてアジャイルプロジェクトを推進しないといけない。。。
必死になってアジャイルの本を読み漁りプロジェクト立ち上げフェーズの大まかなプロセスは把握しました。でも実際にアジャイルプロジェクトを推進していくためには具体的な成果物はなにで、どういった順番で関係者と議論をして要件をまとめていくのか考えて手が止まってしまいました。
これはまずい…、とアジャイルコーチをあの手この手で探し教えを請いました。
PMの経験が知識があったので完全な初学者よりもアジャイル開発の理解は多分良かったのだと思います。でもネット上にはPM経験者に向けたアジャイル開発の学び方やアジャイルプロジェクトの具体的な進め方はなかなか見つからず苦労しました。
幸いなことにそのプロジェクトは無事完了しクライアントからすごく好評価をいただけ無事完了しました。
この記事では当時の僕のようにPM経験者がアジャイル開発を学ぶために書いた記事です。
1.アジャイルの基本
アジャイルソフトウェア開発宣言
そもそもアジャイル開発とはなにか原則を学ぶことが大事です。ウォータフォールと比較して、変化に強い進め方と捉えることができます。
アジャイルソフトウェア開発宣言
プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、
上記のアジャイルソフトウェア開発宣言は抽象的な表現での記載ですが、IPAの資料にその背景が解説されている資料がありました。
IPA - アジャイルソフトウェア開発宣言の読みとき方
荒ぶる四天王
アジャイルサムライの本のなかでプロジェクトの荒ぶる四天王が紹介されています。あらゆるプロジェクトは四天王が待ち受けていて、いつも必ず破壊と混乱を引き起こすと。登場する四天王はウォータフォールでも一緒ですね。
・時間:スケジュールは圧縮される
・予算:予算は削減される
・品質:バグのリストは長くなる
・スコープ:やるべきことは際限なく湧き出てくる
アジャイルでは4つの視点のうち、時間、予算、品質は固定されたものとみなし、スコープを柔軟に扱います。やるべきことが多すぎるときにどう進めるか?やることを減らして計画を変えていきます。
プロジェクトマネージャー(PM)とスクラムマスター(SM)の違い
従来型PMの仕事は、マスタースケジュールを作成しタスクを割り振って管理していくという「コマンダー型」ですが、SMの果たす役割は各メンバーの自律的なタスク推進を促す「サーバントリーダー」の位置づけです。
またSMはPMと違いスケジュール管理はメインミッションではないです。プロジェクトにとってスケジュールは重要事項ではあり、SMに責任がないわけではないですが、スケジュール責務の役割は開発チームとしています。そして何を作るべきかはプロダクトオーナーの役割です。
但しPMもSMもプロジェクト/プロダクトがうまくいくためにできることはする、なんでも屋であるという大枠の役割目的は変わらないととらえるといいのかなと考えています。
2.PM経験者のメリットと注意点
PM経験があることはそれだけでアジャイルプロジェクトを進めるうえでメリットになります。PMBOKの知識エリアはアジャイルでも重要なことに変わりはないです。
例
・スコープマネジメント
要件リストを優先順位をつけ、マスタースケジュールを作っていく(プロダクトバックログを作ること、プロダクトバックログの優先順位をつけ、スコープを区切っていくこと)
・人的資源マネジメント
プロダクトオーナー、開発チームの選定とそれぞれの役割定義
・リスクマネジメント
予めリスクがどこにあるかをリストアップし、対策を考える(アジャイルであっても事前に計画をたてることは重要で、予想されるリスクは予め対策を打っておくと後が楽です)
PM経験のメリットがある一方でこれまでの経験で注意すべき箇所があります。
注意点1 同期を取る
スクラム開発を進めていると頻繁にMTGを開催することになります。スプリントプランニング、デイリースクラム、スプリントレビュー、レトロスペクティブ(振り返り)など。PM経験者からすると、MTGの多さ=参加するメンバー分の工数がかかってしまうことに対して良いのか?と自分は考えました。
でも重要なのは頻繁に関係者間で同期をとって、ズレたまま進めないことです。ズレたまま進んで蓋を開けたら意図しないものが出来上がるよりも、こまめに同期をとって早く修正していくことが大事です。
そして関係者間でこまめに同期を取っていくことでウォーターフォールでありがちな重厚なドキュメント類を時間をかけて作ることを防ぐことができます。
注意点2 自主性に任せる
PMとSMの違いであげた、スクラム開発ではメンバーの自主性に任せることが大事です。ここでPM経験者がやりがちなのは、PM自身がタスクを割り振り、スケジュールを決めてしまうことです。このことによってメンバーの自主性が生まれず、スクラム開発の良さである自律的な組織が育たない状態になってしまいます。
少しづつでも良いので開発チームの自主性が出しやすい動きをしていくのがよいでしょう。例えばデイリースクラムの司会を任せてみる、各バックログを誰が担当するのかは開発チームの挙手制にするなどがとっつきやすくていいと思います。
3.参考書籍と読んでいく順番
①最初にお勧めの本
スクラム実践入門
コンパクトにスクラム開発の目的、進め方、ベストプラクティス、事例が載っているので最初に読むのにお勧めの本です。
いちばんやさしいアジャイル開発の教本
なぜアジャイル開発なのか?が載っている本。なぜがわかるとアジャイルの理解が深まります。「いちばんやさしい」と本のタイトルにもある通り図も多くわかりやすくアジャイル開発が解説されています。アジャイル開発を進めるうえでPM経験者なら疑問に思いそうなことがQAで載っており、そうこのQAが知りたかったんだと読んでいて嬉しかったです。
アジャイルサムライ
アジャイル開発のお勧めの本としてよく紹介されている本です。アジャイルな計画づくりについて載っているのでプロジェクト立ち上げ時および企画/要件定義って何すればいいのかがわかります。
②アジャイルの全体像が理解できてきてから読む本
アジャイルの全体像はわかってきても、絶対的にアジャイルの経験値が不足しています。アジャイル原則があって、ベストプラクティスもあって知識としては理解できるのですが、実際のプロジェクトでは現場プロジェクトに合った進め方を考えていかないといけません。
そのためアジャイル開発の知識不足を補ってくれるストーリー形式の本および実践QAの本が次に読むお勧めの本です。
SCRUM BOOT CAMP THE BOOK
ストーリー形式で話が進みます。本の中にアジャイル開発でまさにSM(プロジェクト推進者)が知りたい状況が出てきます。
「いつ頃何ができるのかがわかる計画がないと困るんだ」
カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで
こちらもストーリー仕立ての本です。アジャイルを進める上でのベストプラクティスや具体的な検討の順序が記載されているので会議のAgendaを作るときに参考にしています。
例えば見積もりの流れが図付きで以下のような順番で進めるというのが解説されています。
①規模の見積もり
②見積もったストーリーポイントの合計
③期間への変換
④スケジューリング
スクラム現場ガイド スクラムを始めてみたけどうまくいかない時に読む本
リファレンスとして使える本です。実際に現場で困ったときに知りたい事例が載っています。てかみんな困ることは結構似てるんですね。SMは先回りして困りそうなことをこの本で学んでおくとプロジェクト回しやすくなると思います。
③アジャイルの計画づくりに迷ったら読む本
アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法
PM経験者はプロジェクトのマスタースケジュールどうやって作っていけばいいんだと頭を悩ますことになります。少なくとも自分は悩みました。本書はアジャイルの計画づくりについて深い理解が得られる本です。本書のタイトルにもなっている「アジャイルな計画づくり」とは何かがわかります。
見積もりと計画づくりがアジャイルでないのに、プロジェクトがアジャイルであるということはありえない
SMなら何度も読み返したい神本です。
④理解をより深めていく本
アジャイルの基礎知識をつけた後でより理解を深めていくために僕は以下の本を読みました。
プロジェクトには不確実性がありそれとどう向き合っていくかがウォータフォール、アジャイル問わず重要です。
正しいものを正しくつくる プロダクトをつくるとはどういうことなのか、あるいはアジャイルのその先について
アジャイルでプロジェクトを進めていると今進めているプロジェクトは正しいものを作っているのか、方向性はあっているのかという気持ちになります。この本を読むことで正しいものを作るということはどういったことなのか、進め方の道筋が見えてくる本です。
チーム・ジャーニー 逆境を越える、変化に強いチームをつくりあげるまで
チームをどうやってカイゼンしていくのか、良いチームとは何かを学ぶことができます。
エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング
少し読みづらさはあるのですが不確実性について理解が深まる本です。この本を読んでビジネス側の人となぜ話が噛み合わないのか
4.実際にプロジェクトで苦労した箇所
企画フェーズって何するの?あまり明確に書いていない
アジャイル開発でも企画/要件定義フェーズをしないといきなり開発はできないものです。企画は何をどうやって進めてくのかを考えた時にあまり本やネット上で企画フェーズの進め方が書いているのがなかったです。
でも個人的にはプロジェクトで一番難しくて重要なのはプロジェクト計画(プロジェクト立ち上げ、企画)だと思うんですよね。どんなプロジェクトも計画がだめだとそもそもうまくいかないものです。
調べてみるとスクラム開発では企画フェーズはスプリント0と呼ぶらしい、と。いろいろ記事や本を探して、特にこちらのページが凄く参考になりました。
実際に自分がプロジェクトを推進する時にはアプローチ図(まずこの検討をして、次にこの検討をしてがわかるフロー図)に進め方をまとめてからプロジェクトに取り組みました。
企画フェーズはタスクがフワフワしがちなのでどういった検討の進め方をするか決めておき、かつ関係者と進め方を共有しておくことが重要です。
企画フェーズの会議が想定以上に時間掛かった
スクラム開発ではあまりドキュメントを作らないその代わりにミーティングに関係者を参加してもらって関係者で話をして要件を決めていきます。
それを実際にやっていくとそれぞれの会議でウォーターホールよりもたくさんの人を呼ぶことになります。
関係者全員がミーティングに参加してもらと会議の時間だけですごく工数がかかってしまいます。ウォータフォール開発に慣れているPMだと工数の読み違いが起きるもとになります。
スクラム開発では関係者と対話してい工数(会議の工数)は必要と割り切って、マスタースケジュールをそのように反映していくのが良いと思います。
見積もりを真面目にしすぎて工数がかかった
スクラム開発でストーリーポイントという見積もりをしていく必要があります。(マスタースケジュールを引くためにはやりたい要件=バックログごとの工数を出す必要がある)
見積もりを出す方法はいくつか手法がありますが、プランニングポーカーという手法で見積もりをしました。
プランニングポーカーは開発メンバーで相対的に見積もり値を出して、メンバー間で見積もり値が違う場合は見積りのずれの理由を確認し、適正化していくというやりかたです。
プランニングポーカーで進めると、一人では気づけない見積もりの見落としに気づける、チームで見積もるので見積もりがズレたとしてもプレッシャーが軽減でき適切に見積もり値を出しやすいなどのメリットがあります。
で、真面目にプランニングポーカーで見積もりをしていくと、あーだこーだと要件を話をしてやっと1つの要件の見積もりが終わるみたいな状況になってしまいました。
全部の要件見積もりやりきるには全然工数が足りない…。
プランニングポーカーの本来の目的を理解できていなかったです。
スクラム開発では見積もりは相対的に出すのが重要でまずはサクッと規模感出すのがよいです。見積もり値に迷ったらあっちの要件よりは軽そうだからこれはMではなくSだねぐらいでどんどん見積もり進めていかないと時間が足りなくなります。
完全リモートでのプロジェクト推進
アジャイル開発に限らずですが、コロナ禍の影響をご多分に漏れず受け、完全リモートでプロジェクト推進をしました。プロジェクトキックオフからリモートで進めたのは初めての経験でした。
リモートでのプロジェクト推進は試行錯誤の連続で、とにかく打ち手をどんどん打っていきました。
・企画会議では検討しやすいようオンラインホワイトボードのツールを導入
・会議冒頭に必ずアイスブレイクを実施。雑談の場を強制的に設ける。
・特にプロジェクト立ち上げ当初はインセプションデッキを用いて価値観をすり合わせすることに時間を割いた
・オンライン会議では出席者に話をふる回数を多くする。議論の確認をする時間をオフライン会議よりも回数を多くかつ確認で待つ間を長くとる
・オンライン飲み会の実施
関係者にも恵まれ、完全リモートでのプロジェクト推進うまくいき、かつ試行錯誤した結果、ノウハウを貯めることができました。
5.アジャイル開発QA
Q.要件定義/設計をしなくてもよい?
A.アジャイル開発でも要件定義/設計は必要です。
特にそのプロジェクトで何がしたいのが決まっていない状態でいきなり開発を進めると破綻します。また基本的なデータ構成を決めておかないと無理がある技術的負債を生むことになります。
そうはいってもいきなり要件わからん、設計も無理という場合はモックアップなり作ってみるのがいいと思います。
Q. 成果物 ドキュメントはどこまでつくればいい?
A.ドキュメントを自分たちでどこまで作るか定義してよいという場合は、そのドキュメントがなくても困らないと思ったら作らないが良いです。
※受託開発の場合は契約に依存するので、まずは契約でどこまで求められるかを決める必要があります。
Q.テストはどこまで自動化する?
A.何度もテストを回すことになるので単体テスト、結合テストは少なくとも自動化するのをおすすめします。
Q.プロジェクト管理ツールは何を使うのがおすすめ?
A.スクラム開発ではJiraがお勧めです。バックログの優先順位づけ、スプリントのボードなどが連携していて使いやすいです。アジャイル開発での具体的なJira運用方法は以下のUdemy講座がお勧めです。
Q.同じ要件ならウォーターフォール開発とアジャイル開発とで費用は一緒でしょ
A.ウォータフォールとアジャイル開発とで進め方が違い、同じものさしで測れないため、開発費用が一緒とは限りません。その質問を受けた場合は、アジャイル開発が正しく理解されていない可能性があります。
Q.アジャイル開発だと費用がいくらになるかわからないから経営観点ではプロジェクト進めるかジャッジできない
A.アジャイル開発でも規模感を企画初の時点で出すことはできます。
但しシステムを作って世の中に受けるか不確実なものに対してアジャイル開発のアプローチを取っていると思うので、開発手法が問題ではないです。
問題なのは不確実性があるプロジェクトとどうむきあっていくかです。
6.まとめ
アジャイルを知らない当時の自分からするとアジャイル開発は銀の弾丸にも思えました。でも銀の弾丸などないです。アジャイル開発の背景、目的、ベストプラクティスを学んでプロジェクトの適正に応じてウォータフォール/アジャイルを使い分けていくべきです。
最後にアジャイル開発を学んで本当に良かったです。スクラムマスターができるようになったことに加え、プロジェクトマネージャーとしてのスキルの幅が広がりました。
PM経験者ならスクラムマスターになることは他の人よりもやりやすいです。この記事がその参考になれば幸せです。
いいなと思ったら応援しよう!
