この国では犬が

本と芝居とソフトウェア

スクラムで半年開発やってみた感想

開発者として、スクラムチームでの開発を去年の 8 月半ばから始めたのですが、この 1 月いっぱいでいったんチームから抜けるので、ざっくりざっくり感想をまとめてみます。

前提として、スクラムには 3 つの役割*1があり、それぞれの役割から見たとき、それぞれの感想があるものと思います。
この感想は、ある一人の開発者から見たものです。

本当によくできたフレームワーク

スクラムは、本当によくできたフレームワークです。

スクラムがそのはじまりからそうだったのか、どうかは知りませんが、少なくとも、2016 年 8 月に認定スクラムマスター研修で教わったスクラムは、

  • 人間という生き物の心理的特性をよく理解し、活用している
  • 薄すぎず、厚すぎず、絶妙なバランスのところでフル活用できるフレームワーク

でした。

スクラムを知ってから、興味を持った関連分野の書籍(主に心理学の研究に根ざしたもの)を読めば読むほど、スクラムがその特性を活かしながら人間の集まりの活動をサポートするように設計されていることを思い知ります。

たとえば、こういった本です。

半年で遠くまで来た

また、この(たったの)半年で進んだ距離を思うと、めまいがします。

  • 本物の「チーム」ができた
  • チームメンバーのさまざまな知見を学んだ
  • チームメンバーにたくさんの知見を共有した
  • 安全を感じながら、敬意を持って意見を交換し合う文化ができた
  • 精神的に健やかになった
  • 残業が減った
  • (おそらく)前回のプロジェクトよりも速いスピードで、前回のプロジェクトよりも価値の高いものを、前回のプロジェクトよりも高い品質で開発した

等々。

自覚していなかったり、覚えていなかったりするだけで、実際には、もっともっとたくさんのことを学習し、達成したのだと思います。

組み合って進むということ

スクラムは、まさにその名前にも表れているように、チーム全員で組み合って一緒に進むシステムです。

スクラムを、崩さずに、まじめに取り組むと、「チーム内で突出したプレイヤー」は足かせをはめられたように感じることがあると思います。

僕は自分が「突出したプレイヤー」だと言うつもりは微塵もありません。ただ事実として、チームメンバーの中では会社および製品との付き合いが長い方に属しています。そのこともあり、個人の開発生産性という点では、(おそらく)高い方に位置していたと思います。

正直にフラットに言うと、一人でやったほうが(局所的な)生産性/アウトプットの量は大きい、と感じる瞬間は何度もありました。特に最初の頃は。

それでも、スクラムというシステムは、組み合って一緒に進むことをゴリゴリ推してきます。
オーケー、そう言うならそうしよう。

そして結果としては、「チームとしての」生産性が高まった、のだと思います。
さらにその結果として、かつて「一人でやったほうが(局所的には)速い」と感じて、多少のフラストレーションも感じていた僕は、今や満足しています。

スクラムが問うこと

ここに二つの問いが存在しています。

  • 本当に(文字通り)「突出した」プレイヤーは、スクラムのシステムのなかでうまくやっていけるのか
  • 平均より上のプレイヤーが、いよいよスクラムに慣れたとして、「チームの生産性」で満足できるのか

前者については、正直なところ、わかりません。
少なくとも自分はそうではないし、チームの中にもそういう人はいないので。

これについて考えるのは、別の機会に譲ります。

後者については、難しい問題です。
僕は以前から「チームの生産性」に強い関心があって、それが達成された(されようとしており、また、これからさらにそうなっていくであろう)ことに、深い満足を覚えます。*2

しかし、そうでない人はどうか。
僕の考えでは、「チームの生産性」に(深いところで)興味がない人は、原則として「いない」と思います。しかし、(少なくとも、表面的なところでは)「チームの生産性もいいが、個人の生産性の方が大事だ」という人なら、いると思います。

ここで大事なこととして、人の考え方や表明する意見というのは決して「生まれつき」の「絶対的」なものではなく、環境によって変化する、ということがあります。
スクラムによる開発では、メンバーが「チームの生産性」にフォーカスするように組織の文化を育て、評価・報酬を含む周辺制度も設計していくことが重要になるのかもしれません。

スクラムの先はあるのか

さて、たかが半年、されど半年、スクラムで開発をやってきました。

当然、我々のスクラムの活用はまだまだ道半ばなわけですが、ここで少しだけ、「スクラムの外」あるいは「スクラムの先」のことを考えてみます。

「マネジメント」のフレームワーク

白状すると、8 月に誘われて研修を受けるまで、僕はずっと(5 年くらい)スクラムは「マネジメント」のフレームワークだと思い、なんとなく避けていました。
また、ガチガチのシステムであり、融通が利かない、よって、開発者にとってはつまらない、とも。

結果としては、間違っていました。

スクラムは、「チームの」フレームワークです。
そして、たしかに厳格なルールはあるものの、フレームワークとしてはとても薄く、人をサポートするもので、これを守りながらも、十分な主体性が発揮できます。「楽しい」システムだと言ってしまってもいいと思います。*3

スクラムの外には

スクラムのほかにも、世の中にはさまざまな開発スタイルがあります。

最近活発なのは、リーンスタートアップの基礎ともなっているリーンの考え方、具体的な手法の代表としては、カンバンでしょうか。

余談ですが、2014 年に出た『エッセンシャルスクラム』では、スクラムフレームワークそのものの説明だけではなく、かなりリーン/カンバン的な考え方・手法も紹介されていて、なるほど、と思った記憶があります。

カンバンがスクラムと異なるところは色々ありますが、その大きな部分の一つは、「スプリント(イテレーション)のベロシティ」ではなく「リードタイム」(あるいは、バリューストリーム)に注目する、というところでしょうか。*4
本旨から逸れるので詳細な比較はしませんが、「どちらを採用するのがよいか」という議論がとりあえず可能な程度には、異なっている手法だと思います。

カンバンが注目されるようになったのは、スクラムより後です。
してみると、カンバンがスクラムより優れていたとしても、不思議ではありません。

スクラムの先へ

このとき、自然と「スクラムの先」を考えることになります。

スクラムは本当によくできたフレームワークで、一方、課題もあります。

スクラムをやっていなかったら、ここにいなかった」と断言できるくらい、スクラムに助けられてここまで来ました。

一方で、このまま「スクラム」を続けた先に何があるのか、いいことか、よくないことか、不透明な部分もあります。

他の選択肢もあります。

『エッセンシャルスクラム』が示したように、スクラムに「スクラムそのもの」には含まれない要素や考え方を組み込むこともできるでしょう。

スクラムは「ルール通り」にやるのがおすすめ

ところで、これまでの話の流れに反するようですが、もし新しくスクラムに取り組むチームがいるとしたら、僕はまずは「ルール通り」にやることを強くおすすめします。

「カスタマイズしたスクラム」ではなく、「スクラムフレームワークで定められたルールを厳格に適用したスクラム」です。

なぜなら、スクラムのよくできた設計、その効果が最大限に発揮されるのが、「ルール通りにやったとき」だと思うからです。

Daily Scrum を毎日同じ時間・同じ場所で欠かさず 15 分以内でやり、
Product Backlog Refinement をスプリントの 10% 以内の時間を使ってやり、
Sprint Planning では PBI を「ロック」し(Sprint 中の PBI 追加はしない)、
スプリント中は Sprint Backlog の上から順に着手・完了させていき(Sprint Backlog に載っていない作業はしない)、
毎スプリントの終わりには Sprint Review と Sprint Retrospective をやって、製品とチームの状態にすばやく適応します。

これをやった感想は、これまでに書いた通りです。

もし、ルールを「都合よく崩して」運用したとすると、スクラムのメリットを引き出せないまま「うまくいかないからやめる」となってしまう危険性がかなり高いのでは、という感覚が、半年やってみての実感としてあります。
なお、研修講師の江端さんという方は、「まずはルール通り 3 ヶ月やってみてから判断すべし」と言っていました。*5

ただ、これは一種の理想論で(我々は実際にやっているわけですが)、「ルール通りにやろうとしたらクビになる」とか「法律が許さない」といった場合もあるかもしれません。

本当に?

以下のナイスなプレゼンテーションにも示されたように、やり方は色々あります。
「ルール通り」にやるのがおすすめですが、「ルール通りにやろうとする」とき、「ルール通りにやろうと言う」だけが方法ではありません。

ルールを「より厳しく」捉える必要もありません。

スクラムは薄いフレームワークで、ルールの遵守は求めますが、定められていない部分には柔軟に適応してかまいません。

もちろん、より厳しくすることでうまくいきそうだと思えれば、そうしてもかまいません。
僕が所属するチームは、どちらかというとこちらのやり方でうまくいってきたように思います。少なくとも、これまでは。

そして、スクラムの先へ

ルール通りにやった結果、スクラムのいいところがビシバシわかります。

そして同時に、スクラムのイマイチに思えるところも見えてきます。

それは、チームのイマイチなところかもしれません。
その可能性の方が高いと思います。

チームのイマイチなところは、継続的に改善していきます。
するとまたイマイチなところが出てきて……以下繰り返し。

繰り返していくと、いよいよ「ルール通りの」スクラムのイマイチなところが浮かび上がってくるのかもしれません。
その時が、「スクラムの先」を考えるタイミングなのだろうと想像しています。

まとめ

ざっくりざっくりと言いながら、やや語りすぎてしまったようです。

改めてざっくりまとめると、以下の 3 点に集約されるかなと思います。

  • スクラムは本当によくできたフレームワーク
  • 「チームとして組み合って」進むのは楽しいことも多いが、課題も投げかける
  • スクラムははじめはルール通りにやるのがおすすめ、とはいえ、その先もあるのかもしれない

補足 : ここに書かれていないこと

この記事では、あえて触れなかったことや、語り落としたこともそれなりにあります。
気づいていないこともあると思います。

取り上げなかったけれども、とても重要だと考えているトピックの一例を上げておきます。

  • チーム内でのスキルセットの違いについて(特に、テストエンジニアについて)
  • チーム内で平均よりも経験が少ない開発者がどう感じているか
  • 開発者以外の役割(プロダクトオーナー、スクラムマスター)の人がどう感じているか
  • スクラムチーム外との関係について

これらのことについては、また折をみて考えていけたらと思っています。

*1:プロダクトオーナー、スクラムマスター、開発者

*2:一方で、にもかかわらず、当初は「個人の生産性が最大限発揮されないことへの不満」も持っていた、という興味深い事実もあります

*3:これはややセールストーク的で、実際には、楽しいかどうかは、どう取り組むかによる、というのがフェアな言い方だと思います

*4:なお、前出の『エッセンシャルスクラム』でも関連する概念である「WIP」や「作業の手待ち」は紹介されており、相反する考え方というわけではありません

*5:ただここに一つだけ物言いがついて、僕が所属するチームでは Sprint Planning の時間はスクラムガイドに示されたタイムボックスをはみ出しています。詳細が気になる方は わたしたちがスクラムのスプリント期間を 1 週間にし、タスクを 1 時間以下の単位に分割するのはなぜか - Appresso Engineer Blog を見ていただけると幸いです