あしたのチーム Tech Blog

はたらくすべての人に「ワクワク」を届けるべく、日々奮闘するエンジニアの日常をお伝えします。

すくすくスクラム 〜新卒が西部開拓期のようなチームにスクラムを導入してなんとか回したお話〜 最終章

書いた人: tomo  描いた人: tomo  最近見た映画: 地獄の黙示録

皆さんに報告があります。

私はスクラムマスターを辞任いたします。

すくすくスクラム 〜新卒が西部開拓期のようなチームにスクラムを導入してなんとか回したお話〜 最終章
f:id:ashita_tsuzuki:20190212142558j:plain

1. 未来へのバトンタッチ

いや、別にスクラムマスターをクビになったわけではないですよ?これは未来への布石なだけだから(詳しくは後述)。

前回も前々回の記事でも言ったが、スクラムとは無形態であり、チームの数だけスクラム運営が存在することはご存知のはず。
そのため、私がスクラムマスターの時は私のスクラム、引継ぎが行われたらその人のスクラム、またまた引継ぎが行われたらまたその人のスクラム
ここで前回の記事で言ったことを思い出してみよう、スクラム運営で最も恐れているものはまさしく ”形骸化” である。
一人で運営していると、手段は段々とこなすだけのものになってしまい、やがては・・・

しかし、定期的にスクラムマスターを交換すると着眼点の違いからか同じルールの上でも斬新な発想から新しいアプローチが見つかったりもする。
引継ぎ方法は簡単、候補生としばらく一緒に仕事をすればいい。包括なドキュメント?勉強会への参加?そんなものは不要だ!(強いて言えば本は一冊読んでもらいたけど)
何度も言うようだがスクラムとは無形態。包括なドキュメントなど暇つぶし、もとい有効な手段ではないと私は考える。

実際に私がとった方法として、デイリースクラムの進行、カンバンのメンテナンスなど簡単な業務から任せて行くところから始めた。やがては他事業部とのMTG、要件定義諸々などを最初は同伴だったものを完全に任せることでスクラムマスターの引継ぎを完了させることに成功した。

スクラムマスターを引き継いでから早くも一月以上が経過しているが、もはや後任は私の手を離れ、自社プロダクトの残念な・・・ゴm・・・クs 機能改修・改善の要件定義を自ら率先して進めていっている。

うんむ、よい傾向である!!

2. チーム全員がスクラムマスター相応の能力を持っていると健全な開発をすることができるという仮説

形骸化を防ぐという点ではスクラムマスターの引継ぎはとてもいいことなのかもしれない。
しかし、いいところはそこだけではない!

ここで現在私はどのような仕事をしているのかを振り返ってみよう。私はより強靭で無敵で最強なスクラムマスターになるために現場を知り尽くす手っ取り早い手段、開発に粉骨砕身している。
本格的に開発に入るのは入社以来初めてであるため中々に上手くいかないのが現状だ。
と、この話はあまり関係ないな。本題として言いたいのは次に話す体験談にすべて内包されている。

私が現在開発をメインにしている話は先ほどしたばかりだが、つい先日新スクラムマスター監修の要件定義書を手渡された。機能改善の開発である。しかし要件定義書を読み進めていくとフロントエンドのバックエンド・・・様々な変更が大きな影響を及ぼしているではないか。これは碌にタスク分解せずに着手するととんでもないことになるのではないのかと、スクラムマスター経験から直感的に危惧した私は部屋の隅っこから懐かしきあるものを取り出した。そう、元祖コンピテンシークラウドのカンバンボードだ!ま、とりあえず昔のやつはいらないので全部はがすけど・・・


混沌とした仕様書の中から現れた我らのピンチヒッター
f:id:ashita_tsuzuki:20190227091924j:plain

じゃあこのホワイトボードで何をするのかと言うと件の要件定義書案件専用のプロダクトボードの構築である!!!
ユーザストーリ単位でタスクを分解し、ユーザフローに沿ってカードを張ることで優先順位や見積もりを行っていった。この作業はスクラムマスターを巻き込み、チームも巻き込み、不透明な内容だった要件も浮き彫りのさせることに成功したのである。

ここまで言ったら何を言いたいのかは勘のいい諸君ならわかるだろう。

プロジェクトの予算、人員、実際の工数が大きくなっていってもスラムマスターは一人でやっていけるだろうか?答えは否!前回の記事でも言ったとおりに一人で抱え込むと爆発する。当然の結果だ。
しかし、スクラムマスターは規模にもよるが所詮は一人。いったいどうすればいいのだろうか?
答えは明確、全員がスクラムマスター相応の能力を持っていればいい。そうすることで広義的な解釈が考慮される要件タスクを振ってもいいし、内容次第では大きいタスク単位でのカンバンを開発者の意思で作成してもいい。
要するにこれらが実現するとチームの稼働率が大きく上昇することが期待できる。

少々話題はそれるがチームの能力を引き上げるには全員を同じレベルにしなければならないとはよく言われている話だが、全員がスクラムマスターになるのは技術力は置いといても同じ土俵で話をするという点では大きく役に立つのではないだろうかと私は考える。

3. まとめ

チーム全員がスクラムマスター相応の能力を持っていると健全な開発をすることができるという仮説
これを我々の手で証明してみせる!!乞うご期待。

4. 次のスクラムマスターは

この記事を見ている君だ!一緒にスクラムをしよう!!