1. ホーム
  2. ブログ
  3. 認定スクラムデベロッパー（CSD®）研修を受講した

認定スクラムデベロッパー（CSD®）研修を受講した

スクラム
認定スクラムデベロッパー（CSD®）研修を受講した
記事内に商品プロモーションを含む場合があります

株式会社Odd-e Japan様主催の認定スクラムデベロッパー研修（CSD®）に参加したので、研修の内容とそこから学んだことをまとめます。

目次

認定スクラムデベロッパー（CSD®）研修とは

本トレーニングは、スクラムチームの開発者として、正しくかつ効率的に恊働できる人材育成を目的としてScrum Alliance®により作られた、体系的ソフトウェア開発者の教育・認定プログラムです。高い技術力を持つエンジニアへ成長させ、参加者が良いスクラムの実践者となれるようにサポートします。理想的なスクラムチームの1週間のスプリントを体験する過程で、小さなアプリケーションを構築しながら、適切な知識や技術、チームとして効率的に働く習慣を得ます。トレーニング中にアジャイルコーチからコーチングも受けられるので、実践での悩みも相談できます。

認定スクラムトレーナー（Certified Scrum Trainer®：CST®）という、厳しい審査を経て資格を獲得したトレーナーによるトレーニングを受講し、受講状況に応じて適性が認められた場合のみ、認定スクラムデベロッパー（Certified Scrum Developer®：CSD® ）の認定証が発行されます。高い技術力を求められる近代市場において、有益な能力を保有している証明、継続的な技術力向上能力・改善能力の証明につながります。

認定スクラムデベロッパー（CSD®）研修・トレーニング から引用

受講の経緯

自分自身、スクラム開発を行う中で、デイリースクラムやスプリントレトロスペクティブなど各スクラムイベントを惰性で行なってしまっている感覚がありました。

しかし、改善は必要だと思いながら、本来のスクラムのあるべき姿や改善の方向性がわからず動きようありませんでした。

そんな状況から脱却すべく、スクラム開発を体系的に学べる場でスクラム開発について学び、実践に落とし込んでいきたいと思い本研修を受講しました。

研修について

マインドマップツール Miro と Zoom を使用した3日間(計18時間程度)のオンラインの研修でした。

Miro は研修資料の展開や、各種振り返り等を行うために使用しました。

研修は座学中心ではなくTDD実践が多く、割合は、講義 40 %、TDD実践 60 %程度で、TDD実践は cyber-dojo というWebブラウザで利用できるコードエディタを利用して行いました。

各テーマごとに受講生全員で振り返りを行う時間が設けられ、学んだことや質問したいことの共有を行いました。

研修の内容

受講した時のアジェンダは以下の通りでした。

◾️1日目

  • アジャイル
  • スクラム
  • テスト駆動開発

◾️2日目

  • テストコードリファクタリング
  • スクラムのOverview（スプリントの流れ）
  • ペアプログラミング
  • CI（継続的インテグレーション）

◾️3日目

  • リファクタリング
  • Object Oriented（オブジェクト指向）
  • Simple Design

上記の内容について講師の方がライブコーディングも交えながら講義をしてくださり、合間合間で2人1組になってペアプログラミングを行いました。

コーディングは、FizzBuzzやポーカーをTDDで実装していく内容で、言語はJavaを使いました。

学んだこと

TDD の重要性

TDD は以前本でインプットしたこともあり知識として知ってはいましたが、実際に仕事で使うことはありませんでした。

理由は、開発スピードが遅くなってしまいそうという懸念があったことと、実践に落とし込めるほど理解できていなかったからです。

しかし、実際に講義を通して体験すると印象は大きく変わりました。

TDDを体験する前は、テストコードは自分の中では「追加実装」であり、必要ではあるもののめんどくさいものであるという認識でした。

しかし、講義やTDD実践を通して、TDDの文脈ではテストコードは「コードを実装していく中で自然と出来上がるもの」であり、

  • 「Red：失敗パターンのテスト」
  • 「Green：Redのテストを通す」
  • 「Refactoring：コードの改善」

の小さなサイクルを回しながら、細かく細かく積み上げていって仕様を満たしていく方法であると実感できました。

また、テストコードをプログラムとともに成長させていくことで、リファクタリングのしやすさが段違いに変わってくることや不具合が出てデバッグをする必要が生じたときに手戻りのスコープを小さくできることを体感することできました。

これからは

  • 「仕様確認」 → 「実装」→「テストコード実装」

ではなく、

  • 「仕様をテストとして書く」→「実装」→「リファクタリング」

というサイクルを小さく回せるように、業務内外で意識しながら実践していきたいと思います。

リファクタリングについて

リファクタリングについても講義を通じて解像度が上がりました。

リファクタリングは「外からの振る舞いを変えずに、内部の構造を改善すること」ではなく「外からの振る舞いを変えずに、内部の構造を改善するための統制の取れたアプローチ」であり、BABY STEP でリスク小さく、小さい変換を繰り返して大きな変更に辿り着くことが望ましいそうです。

講義では実際にTDD実践を通じてコードをリファクタリングしていきましたが、小さくコードを修正していき、最終的に全体最適化する過程を体験することができました。

また、前述しましたが「リファクタリングはテストがあるから為せる技である」というところは、実際にTDDをしてかなり実感しました。小さくリファクタリングしていくためにも実装と一緒にテストコードを育てていくことは重要です。

また、講義ではメソッド分割についても触れていました。その中で、講師の方が言っていた「コード(メソッド)自体に自分自身が何をしているのかを喋らせる」という表現はとてもしっくりきました。

コード自身に何をしているのかしゃべらせるという意識を持っていれば、的確な粒度で細分化できたりコードの可読性も良くなりそうなので、今後はこの意識を持って実装に取り組みたいと思います。

スクラムイベントについて

講義でスクラムイベントについて一通り体系的に学習したことで、スクラムイベントのあるべき姿を理解でき、今チームで行っているスクラムとのギャップが明確になりました。

例えば、プロダクトバックログアイテム（PBI）は本来以下の3つのVを満たしている必要がありますが、

  1. valuable (単体でリリースして価値ある単位になっている)
  2. visible (ユーザーから見える単位になっている)
    • APIを作ったり、DBスキーマを整えたりするのはユーザーには見えない
  3. vertical (UI/API/DBをまとめて切り出す)
    • UI、API、DBをまとめて切り出す

今までのチームでは、PBIの切り方として「API設計」「DB設計」のような切り方をしていたので、ここは改善点であることがわかりました。

また、デイリースクラムは「変化を起こしたり、問題発見をする場」が理想だが、現状はただの進捗報告会になってしまっているので、こちらも改善が必要そうです。

今までは、自分たちのスクラムには課題があるのではないかと思いつつ、「本来のスクラムはどうあるべきなのか」「今のスクラムとのギャップ」「現状のスクラムを改善するための方向性」の3つが理解できずにいましたが、研修を通じて多くの改善のヒントを見つけることができました。

今一度それぞれのスクラムイベントを整理して、実践に落としこんで、チームとして少しでもギャップを埋めていければと思います。

まとめ

本研修は、座学中心ではなく、ペアプログラミングやTDDについて実践を通して学ぶアウトプット中心のスタイルです。

3日間という短い時間ですが、アウトプットが多い研修なのでしっかりと意識高く受講すればかなり多くの学びを得られるようになっていました！

自分自身もこの3日間で得た学びを振り返って、少しずつ実践に落とし込んでいきたいと思います。

認定スクラムデベロッパー研修に興味を持たれた方は、ぜひ受講してみてください！

認定スクラムデベロッパー（CSD®）研修・トレーニング

# スクラム # アジャイル # テスト駆動開発