はじめに
こんにちは、株式会社トラストバンクでフロントエンドエンジニアをしております岩上です。トラストバンクには入社して1年半と少しになります。
今年は業務上で新しい事に挑戦することが多く、様々な試みがありましたが、中でも一番四苦八苦したのはスクラム開発手法の導入でした。
自分はスクラムマスターやPOではなく、いちエンジニア（スクラム未経験）として参加しているのですが、そこからの視点における、スクラム導入から今に至るまでの道のりを、順を追ってお話しできればと思います。
ちなみに現在も、スクラムの開発体制が完成しているとも安定しているとも言えず、未だ道半ばの状態です。試行錯誤している途中ではありますが、お読みいただければ幸いです。
スクラムとは
まず、スクラムの説明から簡単にさせてください。
スクラムとはシステムやソフトウェアなどの開発手法の一種で、設計や実装、テストなどの開発工程を「スプリント」という周期の中で回し、優先度が高い順から細かい機能単位で開発を行うのが特徴です。
ちなみに、スクラムは「アジャイル開発」の中の開発手法の一つで、アジャイル（agile）は英語で「俊敏な」「素早い」といった意味合いを持ちます。
現在では導入している企業やチームも多く存在しますが、意識的にスクラムを導入しない限り、基本的に採用されている開発手法はウォーターフォールではないでしょうか。
ウォーターフォールは要件定義から開発、テストまでの工程を順番に行います。
スクラムとウォーターフォールをロボット開発に当て込んで例えてみます。
ウォーターフォールでは最初に設計を詰めて、開発フェーズに移ったら頭、胴体、腕、脚…など順番に作って行き、全てのパーツが出来上がった段階を完成の定義とします。
対してスクラムは、完成の定義をそれぞれのパーツ（機能）にそれぞれ持たせます。胴体の設計→開発→テスト→完成！次に腕の設計→開発→テスト→完成！…という風に、それぞれのパーツが出来上がったことを完成の定義とします。
スクラムの特徴としては、細かい単位で開発を行うため、仕様変更などがあった際などに小回りが利く、機能単位でのリリースが可能なためビッグバンリリースを避けられるなどが挙げられます。
両者の開発手法においては優劣は存在せず、案件規模やその特徴などによってどちらが適しているかは異なります。
いざ始めるぞ！の瞬間
そして、我がチームでもスクラム開発を取り入れる瞬間が来ました。が、やはり問題は山積みでした。なぜなら、チームの中でスクラムを経験したことのあるメンバーというのがほぼいない状態だったのです。
自分としては、まず概念自体が色々と落ちてきませんでした。
- SP（ストーリーポイント）って何？
- ストーリー単位でタスクを切るとは？「設計」「実装」「テスト」だけでは駄目なのか？
と、個人としても何から手をつけていいか分からない状態でした。
問題の浮上とトライアンドエラー
そうして不安定な足場のもと始まったスクラムでしたが、進めていくごとに問題はどんどん浮上してきます。
以下ではそうして浮上した問題の一部をご紹介します。
人数が多すぎる
まず、チームの人数が多すぎました。色々と事情があり、最初期は数十人いる大所帯となってしまったのですが、これだとスプリントが上手く回らない（スクラムでは、適切なチーム人数は10名程度までとされています）のと、単純にスプリントの中で関与していない人が発生し、ただただMTGに時間を潰されていく無駄が発生しました。
そのため、開発メンバーはマストで抑えるものの、それ以外は必要なMTGだけ参加してもらう形にし、コアメンバーとして10名程度でスプリントを回すことができるよう体制を整えました。
SPの算出に慣れていない
そして次の立ちはだかるのは、SP（ストーリーポイント）の概念です。
今まで自分や他の多くのメンバーは開発工数を出す際、人日や時間単位で算出していました。
SPは単純な時間計算ではなく、タスクの複雑性や不確実性など多方面から鑑みて割り出します。
慣れてきた今となってはこの算出に割く脳のリソースが減りましたが、当初はかなり苦労しました。
様々な兼ね合いが頭の中で絡まり、算出しようにも「2...いや3...？でも3で提出して5かかったらどうしよう…」など色々考えていました。
ただ、SPというのは完全でなくてもいいのです。
スプリントの終わりに、今回のスプリントで消化したSPを計算し、平均値（velocity）を出します。このvelocityに沿って自分のチームにどれくらいの力があるかを測り、そこからまた次のスプリントで調整をかけていきながらチームは育って行きます。
他にも、SPの算出が個人（たとえばエンジニアチームのリーダー）に偏ったりすることを問題視し、プランニングポーカーを導入したり、もっと時短のために「せーの」でSPを全員で出し合ったり…色々試しました。
育ってきた「チーム意識」
スプリントゴールが達成できない
スクラムでは、スプリントプランニングの際に「今回のスプリントゴール」を設定します。
今回のスプリントで達成したい目標で、たとえば「案件Aがリリースできる状態になっている」「案件Bのテストが終わっている」といったようなものです。
スクラムを始めた初期〜割と最近まで、スプリントゴールを達成できないことがままありました。
これは、タスクが個人に依存しているところに大きな原因がありました。
スクラムにおいて、「タスクAはXさんの担当物である」と考えるのは危険です。なぜならタスクAはXさんの課題ではなく、チームで達成すべき課題だからです。
XさんがタスクAに躓いて煮詰まっている…という場合は、自分のタスクが終わってもすぐ他のタスクに取り掛かるのではなく、他のメンバーとペアプロしたり相談したりと…とにかくゴールを達成させることを目指しました。
また、デイリースクラムのやり方にも手を入れました。
それまでは個々人の現在取り組んでいるタスクや相談ごとなどを確認する場として進めていましたが、「スプリントで設定したゴールがそれぞれ現在どんな状態になっているか」ということを確認する方式に変更しました。
毎日ゴールを確認することによって、以前よりゴールを意識するようになったのではないかと思います。
タスクの切り方の粒度やあり方
スクラムを始めた当初、タスクは「実装」という単位で切られていました。
これは完全に間違いという訳ではないのですが、スクラムにおいてタスクはできるだけストーリーで分解する、という指標があります。
ストーリーというのはたとえば「xxxの項目が選択できるようになっている」や「xxxの機能が動くようになり、xxxすることができるようになっている」などといったシナリオ方式の分解です。
こちらの方がゴールとして明確であり、スプリントが終わることにある機能や段階が完成している、というゴールを達成できます。ここではフロントエンドとバックエンドを分けることはあまり好ましくはなく、フロントとバックどちらも合わせて一つの機能を完成させる形でゴールを設定することが望ましいと言えます。
最近ではこういったストーリー型のタスク分解を心がけてはいますが、なかなか理想的な形で切ることができない場合もあり…まだまだ試行錯誤中です。
スクラムを導入してよかったなという点
スクラム体制での開発を始めてから半年以上が経ちましたが、本当に少しずつではありますがこの形での開発にも慣れてきて、スクラムを導入して良かったなと思うことも増えてきました。
チームの健康状態をこまめに確認できる
こちらにおいてはスクラムに限った話ではないのですが、スクラムを導入してからデイリーでタスク（ゴール）の進捗状況を確認したり、スプリントごとにレトロスペクティブを行って今回のスプリントを振り返ることができるというのは、良いきっかけでした。
特にレトロスペクティブでは、開始当初は個人でのkeepやproblemが多かったのに対して段々チームとしての成功譚や反省点が多く上がってくるようになったと感じています。
まだまだproblemの多さが目立つ（上がること自体は決して悪いことではないです！）ので、これから同じくらいkeepも挙がるようなチームになっていけたら…と思っています。
個人ではなくチームでのゴールを目指すために全員で取り組む意識が持てる点
意識として、タスクを「個人で持つ」のではなく「チームで持つ」スタイルに変わって行ったことは上でも話したかと思います。
結果として、案件における情報を個人で完結させるのではなく全体に共有しよう、全員が持っている情報量をイコールにしようという風土が出来上がりました。
このことは上述したように誰かがタスクに詰まった時ヘルプに入りやすいということや、急な休みなどに臨機応変に対応しやすいということ、また案件関連の連絡やコミュニケーション上のコスト削減にも繋がり、スクラム観点でもそれ以外の観点でも良いことしかないな…というのが個人的な感想です。
終わりに
今回は、全くの未経験からスクラムを導入して今に至るまで…の道のりをまとめてみました。
繰り返しとなりますが、私のチームもまだまだ発展途上中であり、方向性を誤っているところや改善点など大いにある状態です。
ただ段々とチームの意識変化やスクラム慣れを感じてきたのも事実で、これから伸び代だらけなのだからどんどん進んでいこう！と思いつつ、本や記事を読んでみたりあれこれ実践しています。
この記事を読んでスクラムに興味を持ってくださった方が少しでもいれば幸いです。
弊社ではエンジニアを絶賛募集中です！
気になる方はぜひwantedlyを覗いてみてください↓