こんにちは、開発2部のTashです。
本記事は、スクラム開発を取り入れたアジャイル開発に半年ほど関わった実体験をもとにしたまとめ記事です。
技術的な解説よりも、現場で感じたことや考え方の変化を中心に書いています。
半年間アジャイルに向き合ってみて
アジャイル開発（スクラム）に半年ほど関わってきました。
最初は戸惑いのほうが大きく、「本当にこのやり方で進むのだろうか」と不安に思う場面も少なくありませんでした。
それでも、スプリントを重ね、イベントを回し続ける中で、少しずつチームの動き方や自分自身の考え方に変化が生まれてきました。
この記事では、そうした変化を振り返りながら、アジャイルの良さと難しさ、そして今後に向けて感じていることを整理してみます。
アジャイルで「良かった」と感じたこと
完璧よりも、前に進むことが重視される
ウォーターフォール型の開発に慣れていた頃は、
「決め切ってから進める」「抜け漏れを極力なくす」ことに強く意識が向いていました。
一方、アジャイルでは、
今わかっている範囲で進め、違和感があれば早めに立ち止まって調整する、という考え方が前提になります。
このスタンスのおかげで、
「間違えないこと」よりも「気づける状態でいること」が大切なのだと感じるようになりました。
タイムボックスという考え方がもたらした変化
アジャイルの中で、特に印象に残っている考え方のひとつが「タイムボックス」です。
【アジャイル開発 #3】でも触れましたが、時間をそのままの長さではなく「どれくらい影響があるか」という割合で捉える視点は、それまで当たり前だと思っていた仕事の感覚を見直すきっかけになりました。
ただ、半年間このやり方で開発を続けてみて感じたのは、
タイムボックスは単なるスケジュール管理のテクニックではない、ということです。
時間を区切ることで、「どこまでやるか」「何をやらないか」を意識的に選ぶ必要が出てきます。
そして、その選択は個人ではなく、チームで行われます。
遅れが出たときも、
「誰が悪いか」ではなく、
「どこで見積もりが甘かったのか」「次はどう調整するか」という会話に自然と向かっていきました。
今振り返ると、タイムボックスは
「早く終わらせるための仕組み」ではなく、
チームで現実的な判断をし続けるための土台だったのだと感じています。
チームと自分に起きた変化
チーム全体としては、
「決まっていないこと＝悪いこと」という空気が、少しずつ薄れていきました。
分からないことや不確実な点があっても、
それを前提として話し合い、次の一手を考えることが当たり前になっていったように思います。
個人的にも、
要件定義の段階で「すべてを決め切らなくてはならない」というプレッシャーが和らぎました。
今スプリントで必要な粒度はどこか、
逆に、今は決めすぎないほうが良い部分はどこか。
そうした判断を、開発メンバーと一緒に考えられるようになったことは、大きな変化でした。
それでも難しさは残る
もちろん、アジャイルは万能ではありません。
要件の曖昧さに不安を感じる場面もありますし、
スプリントのリズムに慣れるまでは負荷が高いと感じることもありました。
また、関係者全員がアジャイルの考え方を理解していないと、
「決まっていない＝準備不足」と受け取られてしまうこともあります。
こうした点は、今後も試行錯誤が必要な課題だと感じています。
おわりに
これからは、イベントやプロセスを「回すこと」自体が目的にならないよう、
なぜそれをやっているのかを、これまで以上に意識していきたいと考えています。
アジャイル開発は、決まった正解がある手法というよりも、
チームや状況に合わせて選び取り続ける「考え方」に近いものだと感じました。
半年間の実践を通して得た気づきは、
今後別のプロジェクトや開発スタイルに関わることになったとしても、
判断の軸として活かしていきたいと思います。
これまでの記事
本記事は、以下の記事で紹介してきた内容を踏まえたまとめです。
【アジャイル開発 #1】 アジャイル開発の現場に入って、最初に感じた戸惑い
【アジャイル開発 #2】 スクラムイベントを通して分かった、チームの動き方
【アジャイル開発 #3】 スプリントプランニングとタイムボックスを実務視点で考える
クロノスでアジャイル開発に取り組みたい仲間を大募集しております！
少しでも興味を持っていただけた方はぜひカジュアル面談でお話しましょう！
