ビジネス

January 31, 2021

アジャイル
スクラム

先が読めないプロジェクトでアジャイル開発のスクラム導入を検討した話

scrum development 1

以前参画したプロジェクトで、アジャイル開発のスクラム導入を検討した時の話。

結論から言えば、私の在籍期間中にスクラムは導入できなかった。

今後、同じ轍を踏まないよう自分を戒める意味でも、当時考えていたことを書き残しておく。

プロジェクト参画時の役割(1)ー プロダクトオーナープロキシ

BtoBマーケティング向けのMAツール開発に参画し、最初の業務はプロダクトオーナーと開発チームの仲立ち(要件定義 〜 リリース迄)だった。恐らくプロダクトオーナープロキシに相当すると思われる。

各部署のリーダーが、メンバーから要望やフィーチャーをヒアリングし、スプレッドシートで管理する。週次定例ではプロダクトオーナーが中心となり、実施可否と優先順位が決められていた。

当時はスクラムへの興味が薄かったので気づけなかったが、プロダクトオーナーはスクラム開発の役割を見事に果たされていたと思う(自分の意識や理解が追いついていなかったのが残念)

プロキシとしての役割を振り返った際、次の3点に考えが行き届いていなかったと反省する。

反省1プロダクトオーナーに優先度の高いPBIの概算工数を提示できていなかった.
反省2見積もり算出とベロシティへの意識が欠如していた.
反省3スクラムに適したプロジェクト管理ツールで適切に管理出来ていなかった.

優先順位を決める際、各アイテムのコストが必要になる。しかし優先度高めのPBIでさえ、概算工数を提示できていなかった。理由は諸々あるが、開発チームとの調整不足で、プランニングが機能していなかったと感じる(PBIの見積もりとベロシティは後述)

またPBIの管理についても、ツール選定から熟慮していればと後悔ばかりが募る。後で調査したところ、スクラム開発を本格的にやるのであれば Jira Software が最も適していそうだった。

プロジェクト参画時の役割(2)ー 開発チームのマネジメント

後任にプロダクトオーナープロキシを引継ぎ、次に担った役割は開発チームのマネジメントだった。開発チームの問題解決をフォローし、自己組織化を促すロールだったと認識している。

この時、既にスクラム開発を意識していた。徐々に人数も増え、開発メンバーもスクラムを実現させる能力が身につき始めていたので、なんとかスクラムを導入できないか試行錯誤した。

スクラム開発では開発メンバーに機能横断的な多様性(T型人材)と十分な能力(バックエンド / フロントエンド / クラウド)が求められ、WEB開発における一通りの知識と経験が必要になる。

この点について、スクラムの スプリントレトロスペクティブ を取り入れ、KPTでの振り返りで改善のサイクルを生み出せたが、チームキャパシティの考慮や技術的負債を返す意識を持ってもらう働きかけが足りていなかったかもしれない(チームのキャパシティは後述)

反省4チームキャパシティの考慮(=タスク棚卸し+分割)
反省5タスクレベルの作業に強力な技術プラクティスを取り入れてもらう働きかけ.

エッセンシャルスクラムでも度々、エクストリームプログラミング(XP)の技術プラクティスが紹介されている。スクラム導入を真剣に考え出した時には、既に離任することが決まっていたので、当現場では本書の紹介に終わってしまったのが残念でならない。

PBIの見積もりとベロシティ

PBIの優先順位を決める材料として、プロダクトオーナーはコストを把握する必要がある。

そのタスクをどの程度のベロシティでこなせるのか計測しなければならない。

エッセンシャルスクラムでは、見積もり方法や単位、実施タイミングを次のように定めている。

scrum development 2

ポートフォリオプランニングはスクラムに含まれていので、開発チームには関係ないかもしれないが、要件も出揃っていないため、Tシャツのサイズくらいにざっくりした数値となる。

PBIの見積もりでは、ストーリーポイントと理想日がよく使われ、本書では前者を推奨。

scrum development 3

アイテムの内容次第だが、成熟した開発チームであれば、これまでの経験に照らし合わせ、納得感のある数値が出せるかもしれない。お約束事には次の2つが考えられる。

約束1見積もりに使う数字は尺度を決めておく(チケット作成は2、チケット検索は8など)
約束2正確な見積もりが目標であって、必要以上に精度を追い求めすぎないことが大切.

また見積もりのテクニックではプランニングポーカーが紹介されており、次の手順に沿って進める。

scrum development 4

ブラウザ上でプランニングポーカーができる hatjitsu がある。

PBIの見積もりが算出できれば、スプリント終了時に完成させたPBIサイズを合計し、チームのベロシティ(生産量)が算出できる。数回スプリントを続け、ベロシティを監視すれば、チームの成長具合も測れるし、次のスプリントでどの程度の作業にコミットできるか、判断材料にも使える。

チームキャパシティ

スプリント期間を、全てスプリントの実施に充てられる訳ではない。

キャパシティに影響を与える要因が多くあることを認識し、スプリント期間で消化可能なタスク量を算出しなければならない。キャパシティの単位は、ストーリーポイントか作業時間を使うことが推奨されており、改めて見積もりの考慮が重要だと痛感させられる(作業時間の方がやりやすそう)

scrum development 5

ちなみにスプリント期間が2週間の場合、プランニング、レビュー、レトロスペクティブなどのアクティビティに約1日は確保、プロダクトオーナーのグルーミング(PBI修正、見積もり、優先順位付け)の支援に、最大10%程度の時間確保が望ましいと言われる。

スクラムでは開発チームが自己組織化している必要があり、どの作業から着手すべきか、どのようにタスク計画するか、誰が作業するかをチーム自身が決めるなければならない。特にジュニアメンバーばかりの場合、スクラムマスターが正しく導かなければ、なかなか上手く進められない。

反省点踏まえ色々書いたが、次の現場ではスクラムを成就させたい!!

参考記事

スクラムガイド@2020年11月
お薦めの【アジャイル・スクラム本】16冊を学習レベルごとにご紹介
新米スクラムマスターにお勧めの本
スクラムってどんな開発手法? 基本ルールや必要な役割を紹介@CodeZine
アジャイル開発とは?今さら聞けない開発手法のメリット・デメリット
スクラム開発におけるプロジェクト管理ツール比較
Jiraではじめるスクラム開発 ー スクラムボードの使い方初級編
オンラインでプランニングポーカー
ブラウザでプランニングポーカー


©Copyright2020 TaNA LABO. All Rights Reserved.