こんにちは！ STORES でフロントエンドエンジニアをしている @m0nch1 です。
表題のとおり今回はスクラムのお話をします。
具体的には『More Effective Agile “ソフトウェアリーダー”になるための28の道標』をチームで読書会をして、 その結果得られたものを紹介します。
読書会開催のきっかけ
slack でゆるっとチームメンバーに問いかけてみたのが始まりではあるのですが、 僕としては以下のモチベーションがありました。
開発速度の向上
- 自分たちのチームが今現在抱えている課題を見つめ直し、書籍から得られる情報で課題に対して何か Try したい
- 今のスクラム開発のやり方にとらわれることなく色々な手札を持った柔軟なチームにレベルアップしたい
僕の所属するチームでは日頃から開発パフォーマンスの計測を行なっており、元々関心の高い分野ではありました。
計測をもとに改善策や目標を立てたりしているのですが、書籍を読むことでよりパフォーマンスを上げるためのヒントを得られないだろうか、という思いがありました。
開発パフォーマンスの計測についてのプロダクトブログ1年間開発パフォーマンスを計測した話 もありますのでぜひご覧ください。
コミュニケーション改善
- 同じ書籍を読むことで共通認識・言語を増やしてコミュニケーションを円滑にしたい
- 特に職能間で生まれやすい認識・温度感のズレを減らしたい
特に職能間では完成物や完了の定義や作業の粒度などにズレが生じやすいと思っており、少しでも認識差を埋めたいなという気持ちがありました。
書籍の選び方
一度、みんなが読みたい書籍はないか？ を問いかけてどんな書籍がいいのか考えました。
今回は『More Effective Agile “ソフトウェアリーダー”になるための28の道標』に決定しましたが、以下に候補として出てきた書籍を一部紹介します。
- プロダクトマネジメントのすべて 事業戦略・IT開発・UXデザイン・マーケティングからチーム・組織運営まで
- 他者と働く──「わかりあえなさ」から始める組織論
- ソフトウェアアーキテクチャの基礎 ―エンジニアリングに基づく体系的アプローチ
- A Philosophy of Software Design
問いかけをして面白かったのは「エンジニアが PdM に読んで欲しい本を知りたい」といった会話も生まれたことです。
このスレッドの中では見積もりなどの分野はエンジニアとそれ以外の職能でズレが生じやすいのではないか？と話しており、以下の書籍も候補に上がっていました。
読書会の進め方
本題ではないのでかんたんに。
僕のチームではデイリースタンドアップ（昼会と呼んでいます）をお昼の 12 時から 15 分で開催しています。 毎週水曜日は昼会後の 1 時間を読書会の時間としてカレンダーに設定して読み進めました。
今回は事前に「次回は○章まで読んでおいてください」とアナウンスして、各自話したいことなどをメモしておく方式を取りました。
得られたこと
さて、本題の読書会で得られたことですが、今回は普段のプロダクト開発に特に役立ちそう・影響のある以下４つを紹介します。
- プロジェクトの性質と進め方の共通認識
- 効率が良い見積もり手法
- 品質の計測をすること
- プロジェクトのアウトプットを見つめ直す
プロジェクトの性質と進め方の共通認識
この書籍では Cynefin（クネビン）*1 という問題解決のためのフレームワークを取り上げて、複雑さと不確実さに対処する方法が挙げられていました。
Cynefin では以下図のように問題を分類しており、ソフトウェア開発においては大部分が「煩雑系」と「複雑系」に分類されます。
「煩雑系」と「複雑系」をすごくかんたんに解釈すると以下のようになるかと思います。
- 煩雑系 -> やるべきタスクがわかっていてあとは手を動かすだけ。
- 複雑系 -> まず調査をしないとそもそもやるべきことがわからない。
読書会ではこれまでやったプロジェクトや開発を控えているプロジェクトに当てはめて分類を考えてみました。
いざ会話してみるとPdM とエンジニア間、さらにはエンジニア内でも意見が割れるところがありました。
実際問題、調査・検討フェーズでチームとしての課題が上がってくることが多いです。
例えば、調査・検討に時間がかかり過ぎたり、手戻りが起きたりとさまざまですが、これらは プロジェクトの性質が複雑系なのに関わらず煩雑系として取り組もうとした結果、十分な調査ができていなかった ことが原因の１つであると解釈することができました。
アジャイルの良さは複雑系の問題にも柔軟に対応できるところにあるはずです。
この考え方をベースに「プロジェクトにおいて調査が必要なところ ＝ 複雑系」の部分を見極めて他社調査や技術調査を行い、複雑系の問題を煩雑系の問題に変換 してからタスクに落とし込んでいくようになりました。
効率が良い見積もり手法
見積もりが必要になるタイミングはさまざまですが、誰もが見積もり内にプロジェクトを完了させたいし、見積もりと実績が乖離しないようにしたい、と考えているはずです。
僕のチームでは見積もりをいくつかのレベルに分けて出しています。
- Lv. 1：肌感、あくまで雰囲気の見積もりレベル
- Lv. 2：予測の見積を出す概算見積もりレベル
- Lv. 3：実際の issue にポイントをつけるレベル
Lv. 2 の見積もりでは、ロードマップにどの期間でいつ載せるべきかの判断材料になることが考えられるため、ある程度正確なものが必要になります。
プロジェクトのサイズによってもちろん変わるものですが、基本的には実際の issue を想定したリストを作成してポイント付け -> バッファを掛け算したものを算出することが多く、 この方法だとLv. 3 並の見積もり算出コストがかかりエンジニア側の負荷が高くなったり、Lv. 2 の見積もりを早く出したいのに時間がかかってしまう課題がありました。
見積もりのプラクティスはさまざまありますが、この書籍の中では方法の１つとして Epic を予算として使う方法 が挙げられていました。
この方法で、且つ Epic をチーム全体で作成するなどして共通認識が取れていれば、見積もりを出す負荷と時間を抑えつつ精度の高い見積もりができそうだと考えました。
まだ実際に実践できてはいないのですが、タスクの優先度整理も踏まえて以下のようなストーリーマッピングを作成しようと検討しており、 まずは Epic の部分をワークショップで出していこうと考えています。
また、このストーリーマッピングは元々優先度を決める文脈の章（第14章 より効果的なアジャイル：要求の優先順位付け）で紹介されていたもので、遅延コスト（いわゆる Cost of Delay）も考慮した優先度決めの議論にも役立てることができるのではないかと期待しています。
品質の計測をすること
書籍の中ではチームが量ばかりに執着して品質を疎かにすることがないように品質も計測すべきだ、というメッセージが込められていました。
実際に僕のチームではパフォーマンスをもとに算出されたベロシティを元にプランニングを行なっており、ベロシティの推移も計測しながら開発をしており作業量の計測はできています。
が、品質の計測は行なっていませんでした。
実際に書籍では 手戻り率 を計測するようにプラクティスが記載されていましたが、まず初めの一歩として そのスプリントで手戻りは発生したか をベロシティを計測しているシートにメモするようにしました。
まだ数値分析的に計測はできていないのでこれから改善していきたいのですが、メモを取るようにするだけでも作業の品質を今まで以上に気に掛けるきっかけになっていると感じています。
プロジェクトのアウトプットを見つめ直す
単純にプロジェクトのアウトプット = 動くソフトウェアに感じられますが、ソフトウェアを作るチームの能力を向上させることも目的 の１つであるという大事な概念を学びました。
アジャイルマニフェストでは「持続可能なペース」という原則があり、これを守ればバーンアウトを減らすことはできるでしょう。
が、チームの生産性をより高めるためにはプロジェクトの中でチームの成長を支援することが必要で、結果的にモチベーションが上がり生産性の向上などのさまざまな恩恵が受けられるということを再認識しました。
実際に、モチベーション維持、バーンアウト（燃え尽き症候群）についての考え方を学んだことで、レトロスペクティブでは「スプリント疲れしていないか？」を確認したり、プロジェクトの振り返りでは「成長の観点ではどうだろうか？」といった問いをもとに議論ができるようになりました。
この本のオススメポイント
オススメできるところはたくさんあるのですが、特に良かったのは各章末に「推奨リーダーシップアクション」というものが用意されているところです。
推奨リーダーシップアクションはさらに「検査」と「適用」に分かれており、 検査ではそれぞれの章で解説されたことの重要なポイントが問いかけ形式になっており、「自分たちのチームはどうか？」の議論をスタートさせるのにもってこいでした。
適用は実際のアクションになっていて、必要であればそのまま Try できるようになっています。
実際に読書会を進めていく上で検査の問いかけをベースに議論が生まれたことが多かったように思います。
まとめ
表題のとおり、今回の読書会を通して「ぼくらのスクラムはまだまだ伸びしろだらけ」であることを実感しました。
実際に、開発速度向上のための Try を出せたり、 認識ズレなどのコミュニケーションロスや手戻りを減らす工夫 を考えることができて、冒頭に記載した読書会開催のモチベーションについても回収できたのではないかと思っています。
書籍から学んだことはもちろんなのですが、読書会というイベント自体がチームの成長にもつながる ということもわかりました。
1人で読むと目が滑りがちな内容や読み終えられなかったであろう部分も読書会として開催することで読み進めることができたと思います。
是非、機会があれば職能横断チームで読書会をやってみてください。そして、読む書籍に迷っていたら『More Effective Agile “ソフトウェアリーダー”になるための28の道標』をぜひ手に取ってみてください！
STORES ではチーム開発が好きな方、スクラムマスタとして活躍したい方など、一緒にスクラムの伸びしろを埋めてくれる方を募集中です！
*1:Cynefin：ソフトウェア開発のためのフレームワークというわけではなく、世に存在するすべての問題に対するセンスメイキングフレームワークです。 en.wikipedia.org
