社内でスクラムの勉強会をした話 - ecbeing labs（イーシービーイング・ラボ）

f:id:ecb_kwatanab:20191114211516j:plain

こんにちは、渡邊です。久しぶりの投稿です。
今回は社内でスクラム勉強会を開催した話を書こうと思います。

スクラムには華麗に騙される。フレームワークの中でも一番理解しやすい部類なのに、ちゃんと実現するのは最大級に難しい。

書籍「スクラム現場ガイド」（Mitch Lacey著／安井力、近藤寛喜、原田騎郎　訳）はこの言葉から始まります。
この「最大級の難しさ」にチャレンジしていくために、10月に社内でスクラム勉強会を開きました。

勉強会のきっかけ

僕たちプロダクト開発統括部では隔週でスクラムマスターランチ会を開いて、スクラムや様々な技術課題についてスクラムマスターたちと定期的に意見交換しています。

その中でたびたび話に上がるのが、スクラム開発を進めるうえでの難しさや課題。
チームごとにいろいろな状況や要因があってスクラムマスターたちから様々な悩みを聞くんですが、スクラムに対する知識不足や経験の差が原因になることも結構多いなとずっと感じていました。

忙しいスクラムマスターたちの負担も軽減したいし、新しく参画するメンバーにも都度トランスファーが必要になるので、参画メンバーの知識レベルのベースラインを揃えられるような教材が必要だなと思い、「スクラム入門」というタイトルでコンテンツを作りはじめました。

スクラムはシンプルだが簡単ではない

教材を作ろうと思い立ってから、改めて書籍を読んだり勉強会などに参加しながらコツコツとパワーポイントを書きはじめました。
これが7月のことなんですが、大切な原則や大事にしたい運用上のポイントやなどをいろいろ書き込んだ結果、気がつくと100ページもの大作になっていました。。

この背景にあるのが、スクラムガイドにも書かれている「軽量、理解が容易、習得は困難」というスクラムがもつ特徴。
頭で理解することは簡単だが実践には困難が伴う、というものです。

f:id:ecb_kwatanab:20191114212125j:plain — 理解は容易だが習得は困難

では実践しながらノウハウを積み上げるしかないのかというと、もちろんそれもありますがまず原理原則や本質をきちんと理解することが何より大切だということに気付かされます。
スクラム開発を採用している他社のエンジニアの方と話しても、うまく回していくためには変なカスタマイズをせずに「きちんとスクラムをやる」つもりで、チーム・プロジェクトの適性なども考慮して取り組まないとうまくいかない、という経験談も聞きます。
いわゆる「なんちゃってアジャイル」になってしまうと、タイムボックスやスクラムイベントに追われたり、ずっと全力疾走が続くようなプロジェクトの進め方になってしまい、チームがひたすら疲弊していくことにもなりかねません。
スクラムが適用しやすいプロジェクトやチームもあれば、そうではないケースももちろんあります。

これらを見極めるためには、スクラムの特徴、目指すもの、得意なものとそうでないものをしっかり知識として身につける必要があります。

アジャイルソフトウェア開発宣言と、その背後にある原則

前述の通り、スライドが100ページの大作になってしまったのはアジャイルソフトウェア開発宣言とその背後の原則にある、アジャイル開発の土台となる大切な理念から重要なポイントを多くとりあげたためです。

「デイリースクラムは15分でやる」「スプリントプランニングではスプリントバックログを作成する」というようなイベントやプラクティスの解説だけではなく、「なぜそれが必要なのか」「どこに注意するべきなのか」などをできるだけ多く盛り込むようにしました。

これらの「なぜ」は、その多くがアジャイルソフトウェア開発の12の原則に根ざしています。
このアジャイルソフトウェア開発宣言と原則は、アジャイル・スクラム開発に参画するメンバーはぜひ何度も読み込んでしっかり理解してほしいと思います。
アジャイルソフトウェア開発宣言
 アジャイル宣言の背後にある原則

12の原則のうち、個人的に特に重視しているものを引用します。

顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。

変化を味方につけることによって、お客様の競争力を引き上げます。

意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。

情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。

アジャイル･プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません。

技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。

最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。

ここに「価値のあるソフトウェアを早く継続的に提供する」とありますが、この「早く継続的に」というのが本当に大切だと感じます。
つまり、単にデリバリーのスピードを求めるのではなく「継続できること」が求められます。

今回の勉強会の中でも繰り返し「持続可能なペースの維持」「健康的で楽しい環境の構築」「ポジティブで生産的なチーム」について言及しています。
心身を酷使するようなひたすら苦しいこと、ネガティブなことは絶対続かないし、経験上パフォーマンスは絶対に上がらない（維持できない）。

ポジティブなチームの形成にはスクラムマスターだけではなく開発チーム全員が意識して取り組んでいくことがとても重要。
そのためにも、上述の原理・原則に対するメンバー全員の理解が大切だと考えています。

f:id:ecb_kwatanab:20191114211601j:plain — 伝統的手法とのピークの違い

f:id:ecb_kwatanab:20191114211610j:plain — 大切な原則

f:id:ecb_kwatanab:20191114211623j:plain — 振り返りによる成長の促進

実践者との意見交換

うちの部ではスクラムでの開発を推奨していますが、全員がスクラムを導入したプロジェクトに参画しているわけではありません。
まさにこれから導入するフェーズのプロジェクトもあり、講義そのものよりもその後の質疑応答のほうが有益な時間になったと思います。

僕の講義に先立ち、パートナー企業でスクラム開発を実践してきたベテランのスクラムマスターにもゲスト登壇していただき「スクラム開発のリアル」というタイトルで話してもらいました。
メンバーからのたくさんの質問に対してベテランスクラムマスターから実践的なナレッジを共有いただき、参加者全員の学習深度を深めることができたと思います。

スクラム開発を運用していく上での様々な課題に対しては、答えは1つではありません。
プロジェクトの性格、難易度、チームの熟練度やチームが置かれている状況など様々なファクターがあります。
だからこそ、ほかのチームの経験者との対話が重要になります。

今後も、内外の様々な実践者との対話を通じて、部門全体のスクラムリテラシーを高めていければと思っています。