突然ですが、スクラム開発をご存じでしょうか？
スクラム開発とはアジャイル開発のフレームワークの一つで聞いたことがない、馴染みがないという方も多いと思います。アメリカのシリコンバレーでは当たり前のように行われていますが、日本では普及率が悪いようで、客先常駐エンジニアとして働いている私でもあまりお目にかかることができず、経験することが難しい開発手法であると実感しています。
それでも奇跡的に過去にスクラム開発に1年ほど関わることができました。
無能のエンジニアの私だからこそ、感じた良かったこと、悪かったことがありますので、この記事では私が感じたことを紹介していきたいと思います。あくまでも個人的な観点になりますので、ご了承いただけますようお願いします。
スクラム開発とは？
スクラム開発とは、アジャイル開発の亜種とも呼べる開発手法で、チームを組んで役割やタスクを分散しつつ、コミュニケーションを取りながら行うという特徴があります。
スクラムという由来はラグビーにスクラムから来ていて、チーム間のコミュニケーションがより大切になる開発手法なのが特徴です。
チーム毎にスプリントと呼ばれる一定の期間を指定し、その期間にバックログリファインメント、スプリントプランニングを行い、スプリント期間で開発をおこなって、スプリントレビューを行います。スプリントでこれの繰り返しを行って、最終的なプロダクトのゴールを目指していきます。
それでは、私は過去にスクラム開発をやっていたときに良かったことと悪かったことを挙げていきたいと思います。
スクラム開発で良かったこと
さまざまなタスクを担当できた
私がスクラム開発をしていたチームでは、バリバリの正統派のスクラム開発だったので、各タスクはホワイトボードに紙の付箋として貼ってあって、そこから自分が担当したいタスクを取って業務を行っていました。
そのため、自分が担当できそうなタスクを自分で取って仕事をこなしていましたので、自分の得意分野を生かして仕事を進めることができました。
また、仕事の状況や残タスクの状況によっては自分の得意なタスクだけでなく、難しいタスクや不得意なタスクを取ることもありましたが、それはそれでエンジニアとしての成長や苦手な部分の克服につながったり、どうしても自分には難しいタスクでもチームメンバーと協力しあって仕事を進めることができたのが良かったです。
レトロスペクティブで振り返りができた
スクラム開発ではスプリントごとにレトロスペクティブ（通称レトロ）を行います。レトロではスプリントの振り返りを行い、「良かったこと」、「悪かったこと」、「改善したいこと」をチームメンバーで議論します。議論といっても堅苦しいようなものではなく、メンバー同士でお菓子をつまみながら気軽に話していました。
「良かったこと」では、メンバーが困っていた時に助けてくれたことなどを自由に言い合います。
私は無能なエンジニアなのですが、スクラム開発をやっていたときはレトロの場で何度か褒められたことがあってとても嬉しくて今でも思い出として残っています。炎上プロジェクトでは振り返りをする時間がないので、メンバーから助けられたエピソードが表面化してくることはほとんどありません。
しかし、スクラム開発でレトロは1時間程度の時間をとって必ずスプリント毎に行われるので、メンバー同士で褒めあうことはモチベーションの向上にも繋がって良かったです。
ちなみにスプリントの期間はプロジェクトごとに異なりますが、私がやっていたプロジェクトでは1週間ごとだったので、1週間の最後にレトロをやってという感じでした。
「悪かったこと」も言い合いますが、メンバーを責めるようなことはなくて「改善したいこと」に繋げるアクションとしての洗い出しになるので、それも良かったです。
改善したいことは次のスプリントで必ず行動するというルールとして定められることになりますので、スプリントごとに確実に成長して構造になっていました。改善したいことの一例としては、テスト漏れがあったというようなことがあったときは「チェックリストを作ってミスしないようにする」、プログラミングの変数でスペルミスが多発したときは「静的チェックツールを導入してスペルミスが機械的に起きないようにする」といったような感じです。
プロジェクトを振り返ることをしなければ同じ失敗を繰り返し続けることになりますが、スクラム開発ではレトロをすることで、同じ失敗は二度と繰り返さないようになって、スプリントごとにレベルが上がっていくような感覚が良かったです。
チームで協力しあって仕事ができた
スクラム開発では、チームを組んで役割やタスクを分散してコミュニケーションを取りながら行う特徴なので、チームで協力してというところが良かったです。
私が過去にいた典型的なブラック企業でエンジニアをやっていたときは、上司から仕事を振られてできていなかったときはひたすら罵声を浴びせされて怒られるだけで、分からないことがあってもパワハラが酷かったので、意見しにくいような環境でした。
そういった環境ではチームで協力して仕事をしているとはお世辞にも言えませんでした。また、属人化されているプロジェクトで私が一人で仕事をやっていたときも孤独感を感じていましたが、スクラム開発ではそういったことはなく、誰か一人に責任を押し付けることもなく、メンバー同士で助け合ってチームで仕事をしている感が良かったです。
スプリントごとにモノができていくことが実感できた
私はウォーターフォール開発のプロジェクトに携わることが多かったのですが、アジャイル開発の亜種であるスクラム開発になってから、スプリントごと、私のいたプロジェクトでは週ごとにモノができていくのが実感できたのが良かったです。
ウォーターフォールでもモノは出来上がっていくのですが、長い期間をかけてWBSを引いて要件定義から設計、プログラミング実装とモノができるまでにそれなりの時間がかかります。
しかし、スクラム開発ではスプリントごとにお客様へのレビューがあるので、最初のスプリントから目に見える成果物をできていきます。なんで最初からできているの？という疑問があるかと思いますが、私がスクラム開発にいたプロジェクトはWebアプリケーションの開発だったので、まずはお客様の要望通りの画面であるかを確認するため、HTMLのみで作成されたモック作成から始まります。
これが重要でウォーターフォール開発の場合は、要件定義から設計、プログラミング実装、単体テスト、結合テストを経て受け入れテストでようやくお客様の目に初めて触れることになり、出来上がったものに対して指摘を受けることが多いのです。そのため、そこで指摘を受けてしまうと内容によっては大幅に設計や実装内容を修正しないといけなくなってしまうので、一部テストのやり直しが発生してしまうこともあります。
でもスクラム開発の場合は週ごとにお客様と仕様を確認して進めていくので、最後の最後でちゃぶ台返しをされてしまうようなことはウォーターフォール開発と比べて圧倒的に少なくてリスクを回避することができます。
そして、スプリントごとにモノができるので開発のスピード感があったところも好きでした。
毎日定時に帰れることができた
全てのスクラム開発がそうだと限りませんが、私がいたスクラム開発のプロジェクトでは1年間在籍していたのですが、残業をしたことはありませんでした。本当に一日もしたことはなく、毎日必ず定時に退社していました。
一般的なITエンジニアの人が聞いたら
それはさすがに嘘
と思われる方もいらっしゃるでしょう。
しかし、本当です。現実です。こんなことがありえるんです。
残業がなかった理由は、私を除いてメンバーのスキルが高かったというのもあったと思いますが、スクラム開発では見積もりをみんなで決めるので、精度が高いこと、もし残タスクが出てしまった場合は翌週に回して調整することができたり、メンバーが予定休で休む場合にはあらかじめスプリントの始まる前に休んだ分のタスクは積まないようにする工夫がされていたり、残業をすることはなく、炎上プロジェクトのように残業が必要になってしまうようなことはありませんでした。
1年間のスクラム開発で一度も残業がないなんて炎上プロジェクトにいたときはありえないことでしたが、健康的で心も体も安定していたことが何よりも良かったことです。
レビューをし合うことができた
炎上プロジェクトや忙しいプロジェクトに参画してしまうとスピード重視になってしまうので、レビューが疎かになってしまったり、そもそもレビューを行うという文化がありませんでした。
私がいたスクラム開発ではみんなでレビューをし合って仕事を進めるという文化があって、ソースコードレビューを行う経験がなかったのですが、レビューを行う習慣が付きました。
レビューを行うことでスキルアップになることはもちろん、自分が実装した以外の部分の仕様の理解も深めることができたので、プロジェクト全体のことを知ることができるというのが良かったです。それがあったおかげで体調不良でメンバーが休んでしまった場合でもレビューをして知っている箇所だったら他の人でも対応することができるということになりますので、レビューをし合う文化は良かったです。
メンバーで上下関係がなかった
スクラム開発で私がいたプロジェクトメンバーは20代、30代、40代と様々な年齢層が入り混じっていましたが、上下関係なかったです。そのため、心理的安全性があって、レトロでも言いたいことを言い合えて良きプロジェクトでした。
上下関係という壁を作らないためか、POの提案でプロジェクトが最初に始まったときにみんなであだ名で呼び合おうと決めていたのも良かったんだと思います。
ペアプロを気軽にできた
ペアプロとは、2人のプログラマーが1つのプログラムを共同で開発する手法でスクラム開発していたときによく行っていました。
アジェイル開発でよく採用されているので、確かにウォーターフォール開発をしていたときにペアプロなんてしたことはありませんでした。というより、炎上プロジェクトでペアプロなんてやっている時間はありませんよね…。
一人でやった方が早いんじゃ？
ということで確かにゆとりがあったからこそ、ペアプロができたのかもしれませんが、二人で実装することで高品質なコーディングを行うことができますし、バグの早期発見にも繋がって、チームメンバー会話をし合って行うのでチームワークの向上にも繋がっていいことだらけの手法だと実感しました。
スクラム開発でペアプロを経験できて良かったと感じています。
リファクタリングを定期的に行うことができた
炎上プロジェクトで言えることは納期まで時間がないし、緊急の障害対応で不具合を修正したときにも時間がないしで、とりあえず動けばいいになってしまいがちになります。そうなってしまうと、その場しのぎのクソコードが大量生産され続けるプロジェクトになってしまいます。おまけにテストコードもないという…。だからリファクタリングなんかすることはないといっても良いでしょう。
しかし、スクラム開発ではスプリントが始まる前に開発者からリファクタリングをしたいとPOに提案すれば、相談した内容次第でお客様と調整したり、優先度を構成し直したりして、リファクタリングの時間を作ってくれます。
リファクタリングは汚いコードを綺麗にして保守運用しやすくしたり、場合によっては性能が改善できたりするので、やらないよりはやったほうがいいことになります。
炎上プロジェクトにいたときにリファクタリングをやる機会は私の場合は皆無だったので、とても新鮮で充実したエンジニアとしての仕事をしている感覚があって良かったです。
見積もりの精度を上げることができた
スクラム開発ではみんなで見積もりをやります。
やり方はいろいろあると思いますが、私がいたチームでは、付箋に書かれたタスクに対してじゃんけんぽんの合図でＳ、Ｍ、Ｌのサイズをそれぞれ出して、多かった意見を採用します。少なかった意見でも
これこれこういう理由で考慮しなくてはならない点があるので、Ｓではなく、Ｌになるのでは？
と提案することで
確かにそうですね
という流れで見積もりサイズが変更されていきますので、一人で決める見積もりよりも精度が確実に上がります。
精度が高い見積もりの中で仕事を進めて言うことになるんで、工数のズレや漏れが少なかったことが良かったです。
スクラム開発で悪かったこと
無能がすぐにバレる
スクラム開発ではホワイドボードに貼られた付箋に書かれたタスクをこなしていきます。そのため、今だれがどのタスクをやっているかがホワイトボードを見れば誰でも見れるようになっています。
つまり、タスクをとって作業中から動いていなければ仕事を進んでいないのがバレて……分かってしまいます。タスクがメンバーが考えている以上に難しくて進まなかったということであればまだいいのですが、無能で仕事が進まないということであれば、無能がバレます。そして、スクラム開発ではスプリントごとにそれが続いていくので一度や二度ならいいですが、毎回タスクの進みが悪いとなれば無能の烙印を押されて最悪、プロジェクトに居られなくなります。
メンバー同士助け合うということはスクラム開発のいいところなので救済処理もありますが、あまりにもスキルが低すぎると退場を勧告される可能性があるので、無能にはツライかもしれません。
コミュニケーションが苦手だと不向き
良い事として挙げましたが、スクラム開発はメンバー同士協力し合って仕事を進めたり、レトロで上下関係なくフランクに話さないといけないので、コミュニケーションが苦手だと苦痛です。
属性化されたプロジェクトにいたときは黙々と一人で仕事をしていましたので、コミュニケーションを取る必要はあまりなかったので、コミュニケーションを取って仕事をするのが苦手な人やコミュ障の人にとっては不向きかもしれません。
面倒くさがりだと続かない
スクラム開発はスプリントごとにバックログリファインメント、スプリントプランニング、レトロスペクティブというイベントが必須であるので忙しいです。しかもレトロスペクティブで改善することにもメンバーで鉄の掟を作ってルールを守らなければならないので、めんどくさがりの人には向いてないかもしれません。
一定以上の経験とスキルがないとチームメンバーにないと崩壊する
スクラム開発では少数精鋭で進めることが多いのですが、一定以上の経験とスキルを持つPOと開発者が求められます。
私がいたスクラム開発のチームでは新規プロジェクトで要件のレベルが高かったのですが、有能な開発者がそろっていたので、最後までプロジェクトを遂行することができました。
メンバーの中でも私が一番無能だったのですが、私レベルの無能な開発者だけで構成されていたら間違いなくプロジェクトは崩壊して頓挫していたと思います。5～6名体制の少数精鋭の場合、少なくとも有能な開発者が1～2人と有能なPOとスクラムマスターがいないとプロジェクトの進行は難しいでしょう。
まとめ
この記事では、無能なエンジニアがスクラム開発を経験して良かったこと、悪かったことについて紹介しました。
私はウォーターフォール開発と一般的なアジャイル開発、本記事で紹介したスクラム開発まで経験して、今はウォーターフォール開発に戻ってしまっていますが、振り返ってみるとスクラム開発にはスクラム開発の良さがあって、またスクラム開発をやってみたいななんて思うことはたびたびあります。とはいえ、シリコンバレーと違って今の日本では古い開発手法や古いフレームワークに拘りがあって非効率な方法で開発を行っている現場は多く、純粋なスクラム開発を経験できるプロジェクトは少ないと思います。
でも正直言ってスクラム開発の良かったことで紹介した通り、スクラム開発は最高です。経験したことがない方はぜひ、一度は経験して欲しいという開発手法になりますので、興味を持たれた方は案件を探してみて参画を検討してみてはいかがでしょうか？
この記事はそのきっかけになったら幸いです。
