トップ > 認定スクラムデベロッパー（CSD）になりました

認定スクラムデベロッパー（CSD）になりました

この記事はコインチェック株式会社（以下、コインチェック）のアドベントカレンダー19日目の記事です。

qiita.com

 

はじめに

先日、認定スクラムデベロッパーを受講し無事認定をいただきました。

この記事ではどういった研修だったのか、何を学んだのかを備忘録として紹介していけたらと思います。

認定スクラムデベロッパーに興味のある方やこれから受講予定の方など、参考にしてもらえると嬉しいです。

 

受講した経緯

ウォーターフォールでの開発からスクラム開発に移行して1年ほど経ちました。

その中で、

  • 本来のスクラムとはどうあるべきなのか

  • 現状のスクラムを改善するとして、方向性はこれで良いのか

など悩むタイミングが多々ありましたが、チームで協力しながら乗り越えられてきたと思っています。

しかし、基礎をしっかり習得しておけば今後より良い形でスクラムを実践していけるかもと思い受講しました。

 

認定スクラムデベロッパーとは

スクラムのフレームワークを用いてソフトウェア開発を行うためのスキルを持つことを証明する資格です。

この認定はスクラムに基づいたアジャイル開発の実践に必要な技術的な知識とスキルを有することを示します。

以下のような内容が含まれます。

  • スクラムの基礎：スクラムの役割やイベント（スプリント、スプリントレビュー、デイリースクラムなど）、アーティファクト（プロダクトバックログ、スプリントバックログ、インクリメントなど）の理解。

  • アジャイル開発手法：アジャイルの原則と価値に基づく開発方法の理解と実践。

  • 具体的なプラクティス：継続的インテグレーションやテスト駆動開発などの習得。

  • チームワークとコミュニケーション：スクラムチーム内での円滑なコミュニケーションと協力による効率的な開発の実現。

 

CSDは、スクラム開発の基礎を理解し、実際に使えるスキルを身に付けるためのトレーニングを経て取得します。

 

コース概要

スクラムの開発チームメンバーとして、正しくかつ効率的に恊働できる人材育成を目的として Scrum Alliance® により作られた、体系的ソフトウェア開発者の教育・認定プログラム。スクラムの原理原則を理解して、実際に恊働できる能力が Scrum Alliance® が規定した水準を満たしている事を証明します。スクラムの開発チームメンバーとして必要かつ効率的なコミュニケーション、技術力が Scrum Alliance® の水準を満たしている事を評価します。

odd-e.tech-kai.com

 

 

 

どういった研修だったのか

3日間のオンライン研修で、内容としては以下です。

  • アジャイル、スクラムとは の座学

  • テスト駆動開発（TDD）

  • リファクタリング

  • 良いテストコード

  • 継続的インテグレーション（CI）

  • ペアプロ

  • JIT設計

 

座学は一部のみで、半分以上はペアプロやTDDを実践する時間でした。

 

利用したツール

  1. Miro

  2. cyber-dojo

    1. ペアプロやTDDの実践で利用

    2. 言語はjava

 

1日目

1日目はアジャイルやスクラムの基礎を学びつつ、ペアプロでTDDの基礎を実践形式で学びました。

具体的には以下です。

 

1. アジャイルの名前の由来

ウォーターフォールに比べて「ライトウェイト」な開発をしている人達がいた。

だが「ライトウェイト」という表現が気に食わなくて、関係する人達が集まって名称を議論した。
そこで話し合って抽出された重視する事柄がマニフェストであり、「アジャイル」という名前がついた。

3Keys

  • 検査=>適応

    • スプリントを回しつつ、スプリント終わりに必ず成果物を出す

    • 成果物はみんなでレビューする

    • その後やることリスト（バックログ）に反映する

    • やることリスト（バックログ）を重要な順番に並び替える

    • 上記を繰り返す

      • インクリメンタル、イテラブル

  • 透明性

    • 検査するものが事実に基づいていないと、方向性が明後日の方向に行ってしまう

    • 検査するソフトウェアが必ず出ること（インクリメント）が、透明性につながる

    • スプリントの成果物で仕様書ができても透明性が検査できない

    • 1スプリントの中で成果物（インクリメント）を出すことで、設計〜リリースまで（全ての工程）を経験して、何がだめだったのか、チーム内で何が弱かったのか（設計がとか）を振り返ることでリスク（問題点）わかる

      • それを何度もくり返すことが重要

 

2. スクラムとは

現状把握を認識する（現在位置を把握する）フレームワーク　

→　問題を発見するフレームワークである。

 

Adaption（適応）することが目的。
Adaptionとは今の状況に応じて、適応するということ

→ 方向転換するスピードのあるチーム、アジリティが高いとも言う。

 

もしインクリメントができなかった場合は、それを問題だと認知して、なぜなのか・どうすれば良いのかを繰り返す。

（これをスクラムに問い続けられることになる）

 

2日目

2日目はTDDの実践がメインでした。それ以外にもスクラムチームやイベント、CIについて学びました。

具体的には以下です。

1. Test Code Refactoring

3A

  • arrange：given

    • テスト対象の振る舞いを実行するための準備

  • act：when

    • テスト対象の振る舞いの実行

  • assert：then

    • 振る舞いによって引き起こされた結果の検証

testing.googleblog.com

enterprisecraftsmanship.com

 

 

2. Scrum OvewView

Just In Time

ウォーターフォールだと要件を決め切って開発を着手した時に当時の情報の鮮度が落ちている可能性がある。
なので小さく作ってリリースして行くのはどうかという提案。

  • PBL

    • product backlog List

  • PBI

    • product backlog Item

    • 一番下に追加していく

  • product backlog

    • 常にダイナミックになっている必要がある

 

scrum team

  • 10人以下であるべき

  • feature team

    • 1つの領域しか持たない人たちのチーム

    • Front 1人　back1人　DB 1人

  • cross functional team

    • みんなフルスタック

  • component team

  • self management team

    • 自己管理チーム

 

sprint planing

development teamが実施する。

  • タスクサイズは1日で終わるサイズにすべき

    • 透明性に繋がるから

      • 昨日と同じことをやっている人が出てくる

      • 何かしらやっているはずだが、進捗が見えない状態になる

sprint review

  • インクリメントを見せて、何かしらアイデアを出す

  • 何かしらのフィードバックをもらう

  • バックログをアップデートする場

 

3. 継続的インテグレーション = CI

CIとは、常に結合していることである（小さいコミットを続けている状態）

全員が1日1日全てのコードを結合している状態。

bliki-ja.github.io

martinfowler.com

 

3日目

3日目は半分がTDDの実践で、他にリファクタリングや設計について学びました。

具体的には以下です。

1. リファクタリング

リファクタリング=外部から見た振る舞いを変えずに内部の構造を改善する ための統制の取れた手法。

「コードを綺麗にすること != リファクタリング」である。

リファクタリングは、baby step（= 小さい変化を繰り返して大きな変化にたどり着く）でやっていく。

リファクタリングはいつやるのか？ → 必要な時に必要なだけする。

 

code smellを取り除く
静的解析(リアルタイムでやる)

  • long method < 30

  • deep nest(arrow) < 3

  • 循環的複雑度 < 10

  • 認知的複雑度 < 10

  • Big Class < 100, 200

  • long parameter < 3, 4

  • duplicate code

  • loop => for 手続型 => pipeline(宣言型)

  • global valuable => small scope => local valuable define before use

  • tmp field(var) => 1度しか使わないものをなくす => inline

  • HOW => what => self explain code => naming => method

 

2. Simple Design（just in time design）(設計に対する捉え方)

  • 必要な時に必要なだけ設計する != Up Front Design

  • Refactoring == 再設計 == 設計である

  • ウォーターフォール

    • Design => implement => Test => Debug & Fix

  • アジャイル　※設計のタイミングを変えている（遅延させている）

    • Design(必要十分) => TDD.........

 

設計

  • sprint A

  • sprint B

があったとして、Aのスプリントの時にどれだけBのことを考えるか？
XP（エクストリームプログラミング）の人はBのことは考えない。

  1. A Design | A implement
  2. BにfitするためのRefactoring(事前リファクタリング)（設計）
  3. B implement

となることが多い。

※「事前リファクタリング == 設計」になる。

 

なぜこのBのタイミングで設計することに価値があるのか？

→ 必ずBをやることの保証がないから。


もしかしたBはやらないかもしれず、お荷物になるかもしれない。

  • kentBeck: 簡単に変更できるようにして、簡単に変更する

 

tidyfirst.substack.com

 

認定スクラムデベロッパーを受講してみて

私自身この研修に参加する前に約1年ほどスクラム開発を経験していましたが、とても学びや気付きの多い研修でした。

特に以下2点が印象に残っています。

  1. スクラムとは、問題を発見するフレームワークである

  2. CIとは、常に結合していることである

 

「問題を発見するフレームワーク」という定義は、この研修の中で自分にとって最も印象的であり、実務においても重要な判断軸となっています。

実際にスクラム運用で改善したいことがあった際には、「どうすれば問題を発見できるか」の観点で運用を見直すようにしています。

 

また「CIとは、常に結合していることである」ですが、私は「CI=継続的に自動テストまで行う」くらいの認識しか持てていませんでした。

今では小さなコミットを続けてそれらを結合することこそがCIであるとの認識の元、日々の開発において品質を保ちつつリリースサイクルを早めるにはどうすべきかという意識を持つようになりました。

 

それ以外にもTDDは設計上の考慮漏れやカバレッジ不足を減らすことができるので、まだ訓練は必要ですが実務でどんどん活用していければと思っています。

（講師の方は3ヶ月くらいは訓練したそうです）

 

さいごに

弊社コインチェックでは、他にも様々なお役立ち記事を公開しています。ぜひCoincheck Tech Blogも覗いてみてください。

また、コインチェックでは一緒に働くエンジニアを募集中です！興味をお持ちいただける方はこちらまで！

corporate.coincheck.com