はじめに
こんにちは！ecbeingの浦…もとい蓑代です。
※結婚して名前が変わりました
今回は、こちらの記事の「新人編」の位置づけとして…。
blog.ecbeing.tech
ウォーターフォール型開発を知らない新人目線から、スクラム開発について感じた事を書いていこうかなと。
ちなみに、私のスクラム経験や開発経験について少し触れると…。
- スクラム開発=未体験
- ウォーターフォール型開発=未体験
- スクラム開発に携わる前は、保守開発を中心に行ってました
…というような感じです。
ウォーターフォール型は未経験といいましたが、職場の同期がウォーターフォール型開発であり…。
「設計書を作るの大変だー」とか「テスト項目書作るの大変だー」とかは良く聞きますが、まぁほぼほぼ知識0みたいなもんです。
そんな私がスクラム開発を通じてどう感じたのか…。
見ていきましょう！
新人目線でスクラム開発を振り返ってみて
まず、私がスクラム開発を振り返ってみて、まず感じる事は…。
「 開発がとっても楽しかった！ 」
…ということです。
金澤さんを含めたチームメンバーの方々の人柄がとても良かったという事もありますが、何より スクラム開発の良さを実感できたから という事が大きな要因に思えます。
具体的にどの辺りに良さを感じたのかをまとめてみると…:
- 恐れずに早く機能を作れ、リリースできる
- 誰か1人に機能開発の責任を押し付ける…という考えがなくなる
- 打ち合わせがいっぱいあるので、仲良くなれる機会が多い!
…といった所ですね。
これだけじゃ伝わらないと思うので、各項目がどういう事を指すのか、深堀りしてみようと思います！
スクラム開発の良さその1: 恐れずに早く機能を作れ、リリースできる
スクラム開発のやり方を見てると、「ドキュメントを作る必要がなく、機能実装と最低限の動確さえできれば開発完了」…という風に感じます。
勿論、大きめの機能を作る際はドキュメントを作ることもありますが…。
ちょっとした機能拡張(画面上に出力される項目を1つ増やす)程度であれば、ドキュメントなしに要件と受け入れ条件だけで開発が出来ちゃうのです。
このおかげで、 開発スピードが非常に早く感じられます 。
ちょっとした機能拡張であれば最短1日で終わるレベルの開発スピード…。
ウォーターフォール型開発をしている同期の方にこの話をすると、とても驚かれます。
((まぁ同期の方が開発するシステムは、私たちが携わるReviCoよりもずーっと大きなシステムというのもありますが
また、スクラム開発は「継続的なアップデート」をする必要がありますが…。
言い換えれば、「機能をアップデートできる機会がたくさんある」という事。
例えば不具合が起きた時でも、それが致命的な物でなければ直ぐにアップデートし、修復することが可能です。
このためか、特に「簡単な新機能を作る際」は「最低限の動作確認さえできれば後はOK」という形になっています。
※もちろん影響範囲が広いor大規模な改修であれば、ある程度綿密なテストを行います
重箱の隅を突く様な試験をする必要がないため、テスト工程にも時間を取られることはありません。
この事は、「恐れずにどんどん新規機能を作れること」につながっているのかなと…。
ちょっとした機能開発をするだけなのに綿密なテストをやっていたら、新規で機能を作成する気が起きなくなっちゃうんじゃないかなぁと。
(「この程度の機能開発でもここまでテストするのだから、新規機能開発のテストはもっと大変だろうな」と感じちゃう気がします)
スクラム開発の良さその2: 誰か1人に機能開発の責任を押し付ける…という考えがなくなる
スクラム開発では、機能を作るために必要な機能要件や受け入れ基準は「開発者の皆が合意したうえで行う」…という形になっています。
誰かが作った要件定義書や設計書を基に、機能を作る…なんてことはありません。
また、機能要件や受け入れ基準は「皆が納得するまで話し合う」必要があります。
この「皆で話し合って決める」おかげか、「あまり良くないソースコードが出来上がったり」「開発に予定外に時間がかかったり」しても、誰か個人を責めるのではなく「 機能要件や受け入れ基準が悪かった のかな」と考えるようになった…気がします。
こう考えられるようになれば、「どうして機能要件や受け入れ基準が悪かったのか」を考え、今後改善すべき点も明確になり…。
開発チーム内が成長できる土台も出来、いいことずくめのように思えます！
また、「何かの工程を人任せにする文化が無くなる」様にも感じます。
ウォーターフォール型開発をしてる同期と話すと、「先輩が設計書を作り切れてないからまだ開発できないんだよね～」という話を聞きますが…。
スクラム開発のように「皆で受け入れ基準や機能要件を話し合って決める」環境にいると、そういった縦割り工程の考え方をすることがなくなり(!)。
同期とその話になった時は、「ああそういう考え方もあるな…スクラム開発ではそういう考え方生まれないなぁ」という事に気づかされました。
個人的には、スクラム開発の考え方の方が好きです。
皆で責任なり工程なりを分担する方が健全だと思うのでね…。
スクラム開発の良さその3: 打ち合わせがいっぱいあるので、仲良くなれる機会が多い！
上の方の「スクラム開発とは」の項目にあるように、スクラム開発をするうえでは、たくさんの「スクラムイベント」があります。
プランニング、リファインメント、スプリントレビュー…。
このイベント毎に、開発チーム皆がオンラインorオフラインで会議を行っていきます。
スクラム開発が始まって当初は、「会議の回数がめちゃくちゃ多くて自タスクが出来ないなぁ」と感じていましたが…。
会議…もといスクラムイベントを繰り返していく中で、 開発チームの方々と仲良くなるスピードが速いな と感じるようになりました。
考えてみれば、スクラムイベントのおかげで毎週1~2回は直接orビデオ通話越しに顔を合わせて話すわけで…。
そりゃ仲良くもなるわって話ですけどね。
また、スクラムイベントを始めるための準備(PCをモニターにつなげたり)をしてる最中に 雑談がたくさんあった のも、仲良くなるスピード向上に寄与してるかなと。
「チーム間で仲良くなる」→「楽しく会議できる&質問や意見も気軽に言えるようになる」→「会議や会話を通じてもっと仲良くなる」→「もっと楽しく会議できる」…と、とてもいいサイクルを回せるようになったのかなぁと思います！
まとめ & おわりに
ちょっと短めでしたが、これにて新人編は締めくくろうと思います。
ウォーターフォール型開発を経験することなく、スクラム開発を経験してしまいましたが…。
スクラム開発は「人との繋がりを重視し、皆で「いいもの」を作り上げる」…そんな開発手法に感じました！
個人的にも、今回の経験を通じスクラム開発が非常に大好きになり…。
新人でありながら、とてもいい経験が出来たなぁと感じています。
(それに、開発チームの皆さんがもーっと大好きになりました！)
PMの金澤さんと同じく、まだまだスクラム開発ビギナーな私ですが…。
この経験も糧に、より良いエンジニアに成長していけたらなと！
それでは！
～ecbeingでは、経験を通じた学習と成長のサイクルと、何よりチームを大切にするエンジニアを大募集中です！～
careers.ecbeing.tech
