💨

アジャイル開発の入門コースを受講した

2024/03/20に公開

はじめに

私は主にGo言語で開発を行っているバックエンドエンジニアです。
現職ではアジャイル開発が導入されているのですが、この開発手法を何となくでしか理解しないまま開発を行なっていました。しかしこれはよろしくないと考え、今一度基礎から勉強するため、現役アジャイルコーチが教える!半日で理解できるアジャイル開発とスクラム 入門編というコースを受講してみました。本記事では、このコースの紹介と、感想とともに簡単な備忘録として残したいと思います。

コースの紹介

今回受講したコースである、現役アジャイルコーチが教える!半日で理解できるアジャイル開発とスクラム 入門編は、藤原大さんという、10年以上のアジャイル開発経験を持つアジャイルコーチの方が作成したものです。書籍 リーン開発の現場の翻訳もされた方で、スタートアップから大企業まで様々な現場でのアジャイル開発の支援をされています。
このコースでは、アジャイル開発のとても基礎的な部分から解説をされており、アジャイルが全くわからない方でも問題なく受講できます。

コース受講による学び

アジャイル開発の基本の理解

スプリントレビューなどのアジャイル特有のイベントの説明から入るのではなく、アジャイル開発のもっと根本的な部分から説明されています。
アジャイル開発にはすでにある程度歴史があり、多様な開発手法(Evo, XP, TPS, Lean, SCRUM など)がアジャイルに合流することで形成されてきました。このコースでは、その経緯、そしてアジャイル開発がどのようにして現在の形に進化してきたのか、そしてなぜこれほどまでに多くの現場で採用されているのかが説明されています。
また、アジャイル開発においては、有名なものですが、以下のような指針があります。

アジャイルマニフェスト

  • プロセスやツールよりも個人と対話を
  • 包括的なドキュメントよりも動くソフトウェアを
  • 契約交渉よりも顧客との協調を
  • 計画に従うことよりも変化への対応を価値とする

アジャイルソフトウェアの12の原則

  • 顧客満足を最優先し、 価値のあるソフトウェアを早く継続的に提供する
  • 要求の変更はたとえ開発の後期であっても歓迎する
  • 動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースする
  • ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働く
  • 意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。
  • 情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすること
  • 動くソフトウェアこそが進捗の最も重要な尺度
  • アジャイル・プロセスは持続可能な開発を促進します。一定のペースを継続的に維持する
  • 技術や設計をレベルアップさせる意識が、俊敏(アジャイル)さを高める
  • シンプルさ(ムダなく作れる量を最大限にすること)が本質です
  • 自己組織化したチームのメンバーが協調して動く方が、パフォーマンスが高い。
  • 定期的な「ふり返り」により、開発チームのパフォーマンスをより高めるようにする

アジャイルマニフェストとその12の原則を知ることは、開発プロセスにおける優先順位を明確にするかの指針となります。特に、「プロセスやツールよりも個人と対話を」「計画に従うことよりも変化への対応を」などの価値観は、急速に変化する現代の開発環境において非常に重要であると感じました。
(もちろん、原則自体は抽象性を伴っているので、チームで議論することは求められると思います)

実際に開発を進めると目の前の作業で一杯一杯になりがちです。しかし振り返りのタイミングなどで各人が「アジャイルの原則に則っているか、改善の余地はないだろうか」などと考えるとより良い、強いチームになれる気がします。

また、特定のツールやメトリクスを使い、スプリントレビューなどの特有のイベントをこなしていればアジャイルな感じがしていましたが、そうではなく上記の原則に則りつつ、改善と価値提供を繰り返して初めてアジャイルと呼べるのだと理解しました。

従来型開発との比較

従来型のウォーターフォールモデルとアジャイル開発を比較することで、アジャイルがいかに柔軟性と迅速性を重視しているかが明確になりました。ウォーターフォールモデルが「一度に大きなリリースを目指す」のに対し、アジャイルは「小さく、頻繁にリリースすることで顧客価値を速やかに提供する」ことを目指しています。このアプローチの違いが、変化の激しい現代において、なぜアジャイルが適しているかを理解するのに役立ちました。

アジャイル開発への誤解

アジャイル開発に対する一般的な誤解について学ぶことで、自分自身の持っていた先入観を改める機会となりました。「アジャイル開発はドキュメントを作らない」「要件変更が自由にできる」「優秀な人材のみで構成されるべき」といった誤解は、実際には「必要最低限のドキュメントを作成し」「変更に柔軟に対応しつつもスプリントの目標は明確にする」「チーム全員の協力と成長を促す」ことをアジャイル開発では推奨していることを理解しました。
特に最後の「優秀な人材のみで構成されるべき」は私が一番強く思い込んでいたものでしたが、実際にはプロダクト開発、そしてチームに貢献しようと行動する人間が求められているのだと思いました。

全体の感想

コースを受講して、アジャイルマニフェストや12の原則を定期的に見直し、自分たちの開発方法が適切かどうか、改善点はないかをチェックすることの重要性を強く感じました。

また、アジャイル開発がただの方法論やツールの導入にとどまらない、チーム文化や思考の転換を伴うものであることが印象に残りました。自分たちのチームをいかにして「より自己組織化したチーム」にしていくかは、今後の大きな課題となりそうです。

アジャイル開発を採用する現場が増えている現在、開発者一人ひとりがアジャイルに対する理解を深め、その考え方を自分たちのプロジェクトにどう生かしていくかを考えることが求められていると思います。このコースを受講して、アジャイルの基本の再学習はできたと思っているので、実践で活かすための考え方など応用を学べる状態になったと思います。実際の開発プロジェクトに活かし、より良いプロダクト開発、より強固なチーム作りに貢献するためにも、さらに学びたいと思います。

Discussion