スクラムチームを3年リードして得た学びと目線

この記事ははてなエンジニア Advent Calendar 20227日目の記事です。

昨日は id:utgwkk さんでした。

さて、今日はスクラムの話です。スクラムの導入とリードは自分のキャリアにおける重要な仕事のひとつで、気づけば3年ほどスクラムと取っ組み合ってきました。ここ1年くらいで、ようやく安定してテンポ良く開発が回るようになって、大仕事に一区切りついたような気持ちでいます。そうして少し肩の力が抜けた結果、最近はスクラムというフレームワークから一歩引いた位置に自分の目線が移動しつつある気がしています。自分の考えのスナップショットを取るには絶好のタイミングと思われるので、スクラムについての学びや、自分のスクラムに対する目線をまとめてみようと思います。

スクラム導入のキモ

まずは、自分が経験したり見聞きした様子から、スクラム導入のキモだと思う点を2つほど書いてみます。どちらも越えがたい難所ですが、スクラムを機能させるために避けては通れない部分だと思います。

言うとおりに全部やってみる

スクラムガイド2020では次のように述べられています。

スクラムの核となるデザインやアイデアを変更したり、要素を省略したり、スクラムのルールに従わなかったりすると、問題が隠蔽され、スクラムの利点が制限される。 場合によっては、スクラムが役に立たなくなることさえある

スクラムの実践では「言うとおりに全部やってみる」ことが推奨されています。自分のチームでも、人員配置等の都合から意図的にガイドから外している部分が課題に上がることが多く、後付けパッチのような泥臭い対策を何度もしているので、経験的にもよく理解できます。しかし一方でこの部分は軽視されがちな印象を持っています。どちらかというと以下のような部分のニュアンスを感じることが多いです。

スクラムフレームワークは意図的に不完全なものであり、スクラムの理論を実現するために必要な部分のみが定義されている

似た例としては以下です。

スクラムフレームワークの中で、さまざまなプロセス、技法、⼿法を使⽤できる。スクラムは既存のプラクティスを包み込む

こうした「自由度が高い」というニュアンスがひとり歩きして、スクラムのコアについても、はじめから部分的な導入に留めたり容易に変形しがちな印象を持っています。

しかしそうした進め方は、スクラムガイドが言うとおり成功しづらい道であると感じます。というのも、スクラムの構成要素は単体で著しい効果を発揮することは少なく、相互に作用することで真価を発揮するからです。例えば、スプリントゴールがあるからこそ、それを達成するために検査して適応するデイリースクラムが機能します。スプリントレビューがあるからこそインクリメントを確認する場ができ、完了の定義が重要な役割を果たします。こういった具合に、スクラムの構成要素にはシナジー効果が多くあるので、なにかひとつを導入して良くなるというよりは、カバレッジが一定ラインを超えた時に急激にチームが良くなるイメージを持っています。一部だけを導入しようとしても、他の構成要素との繋がりをチームに実装できないので、導入する理由を説明しづらく得られる効果も小さいため、スクラム導入は茨の道となります。手応えがないままチームに変化を起こし続けるのは大変なものです。

とはいえ、スクラム導入のような大きな変化が一晩で起こるはずもなく、結局少しずつやっていくしかありません。この現実がスクラムの性質とコンフリクトしていると感じます。ひとつひとつは小さな変化としつつも、スクラムの大部分を実装し切ることを狙って素早く動くのが望ましいということになってきます。これは非常に難しいことです。かくいう私も、始めは素朴にスクラムを少しずつ導入しようとし、手応えのない日々を過ごしました。その袋小路を脱出しチームを大きく改善するに至った経緯は、以下の発表で詳しく紹介しているので、興味のある方はご覧ください。

仕事をチームのものにする

スクラムはチームとしてゴールを達成することに重きを置いたフレームワークです。まとまった仕事を人に向けてアサインするのではなく、フィードバックを得られる単位のインクリメントを、チームで協力・分担して素早く作り上げます。そっちのメソッドは私が、あっちのコンポーネントは私が、ここは並行に進められる？ちょっと待った方が良い？、こういった具合です。リソース効率よりもフロー効率を重視しているという言い方もできそうですね。

このように仕事をチームのものにするやり方は、チーム内の知識格差を是正し、設計やレビューの手戻りを減らし、ユーザーに素早く価値を届けることに繋がります。スクラムを機能させるための重要な要件と言って良いでしょう。こうした考え方に移行しないまま、ひとり1プロジェクトのような世界観でスクラムを回そうとしても、スプリントの切れ目が進捗確認ポイントになるだけで、スクラムとしての恩恵を得るのは難しいと思います。

しかし、こうしたやり方はエンジニアごとに好みが分かれるところだと思います。自分もエンジニアなので、大規模な難しい実装をひとりで作り上げたい思いも理解できます。また、段取りとマイクロマネジメントとスクラム - yigarashiのブログでも述べたように、チームに仕事を展開しようと思うと、だいぶ細かいところまでチームで計画を話し合うことになります。ジュニアメンバーにとってはメリットが多いですが、シニアメンバーから見ると冗長で退屈に思えてしまうかもしれません。この部分をチームで合意してやっていくには、スクラム推進者の情熱やメンバー構成の運も必要になってくると思います。そういった点から、この「仕事をチームのものにするという」変化はスクラムの難所であると考えています。

逆に、この難所を越えようとした時に、自分たちがスクラムを必要としていないことに気づくケースも少なくないようです。シニアメンバーが集まっているなら、マイクロマネジメントなやり方にコストをかけてもリターンが少ないでしょう。フロー効率を追求する要請が特になければ、リソース効率を重視した別のやり方を選択するのも建設的だと思います。スクラムはあくまで道具のひとつであるということです。

スクラムの好きなところ

ここまでスクラムのハードな部分の学びを紹介しましたが、もう少しライトに、素朴に好きな部分について書いてみようと思います。

スプリントゴールに関する確約

スクラムの価値基準のひとつに確約（コミットメント）があります。これは、チームで協力してゴールを達成することを確約するもので、スクラムでは確約の対象となるゴールがいくつか明示されています。そのひとつがスプリントの目標であるスプリントゴールです。スプリントごとに設定された目標を達成するために協力し全力を尽くすということが、フレームワークに最初から織り込まれているのです。

スプリントゴールをうまく運用することで、チームは2週間程度の短いスパンで具体的な目標を持つことになります。よく例えとして言われる「次の電柱」が常に存在するので、走っていてもチームが迷子になりづらいです。また「スプリントゴールを安定して達成するにはどうするか？」という問いから、良いプレーがたくさん生まれます。定期的に成功体験を得る機会にもなり、ある種のゲーミフィケーションのような効果も期待できます。スプリントゴールがある生活は「退屈しないな」という印象で、とても好きな仕組みです。

バリューストリームを広く包括するプロセス

スクラムでは、主にプロダクトバックログのメンテナンスを通じて、何を作るか、つまりプロダクトマネジメントのプロセスにも踏み込んでいきます。スクラムガイド2020では「プロダクトゴール」というプロダクトの中期的な目標もスクラムの成果物として含まれるようになり、その色はさらに強くなっているように思います。こうした仕組みのおかげで、ある目標やアイディアが生まれてから、それがユーザーに届き、成果をふりかえるまでの一連のプロセスをスクラムの上で考えやすくなっています。プロダクトバックログをインターフェースとすることで、ディスカバリートラックとデリバリートラックを分けた、デュアルトラックアジャイルのような形式にもスムーズに対応できます。最終的にはプロダクトとしての成果を挙げたいわけですから、そうした全体像を形式的に議論できるスクラムは、思考に補助輪をつけてくれる仕組みとして気に入っています。

知の高速道路としてのスクラム

スクラムはアジャイル開発における最大手のフレームワークと言って良いでしょう。シンプルながらソフトウェア開発のバリューストリームを広くカバーしており、アジャイルにやりたい多くのチームで採用されています。SCRUM BOOTCAMP THE BOOKのような詳細まで補完した入門書も充実しています。これらと原典であるスクラムガイドを併読し、目の前のチームと課題にしっかりと向き合えば、多くの組織が合格点の開発プロセスを実装することができます。定石が多く変化のスピードを上げやすいのも嬉しいポイントです。また、スクラムはコミュニティが大きく活発です。スクラムというキーワードに多くのコンテンツが集まっています。それらを参照することで、ひとりではないという勇気を得ると共に、書籍等でカバーしきれない泥臭い課題の突破口すら見つけることができます。デリバリーマネジメント領域でこうした手札が1枚あるのは大変心強いことだと思います。

スクラムへの目線

こうした学びを得つつ3年ほどスクラムをやってきたわけですが、現在のスクラムへの目線はかなりフラットになってきました。もちろんうまくやれれば強力ですが、越えなければいけない難所もあり、誰にとっても楽しいわけではないかもしれません。チームやプロダクトの性質によって合う、合わないもあります。スクラムが銀の弾丸ではないということを、少し実感を伴って理解できるようになった気がします。

一方で、ではスクラムを選択しなかった時にどうするか、というのは自分の中でまだ回答の手札が少ない問いです。こればっかりは違う環境に身を置いてみないと分からないので、キャリアの今後の楽しみとしておこうと思います。

なんだかスクラム卒業のような雰囲気で書いてしまっていますが、実務経験3年なんてまだまだペーペーでしょうし、スクラムチームをリードする仕事も続きます。今はスクラムでの開発を楽しめており、条件が合う限りは今後もスクラムをやっていくと思います。また2年、3年と経過して、今とはまた違う面白い学びが得られることを期待して頑張っていこうと思います。

この記事ははてなエンジニア Advent Calendar 20227日目の記事でした。

明日は id:cockscomb さんです。