独学VBAerが開発部に異動して学んだ開発プロセス②
こんにちは、みなとやです。
前回の記事でアジャイルのカンバン手法での開発プロセスをまとめましたが、実は所属チームでは私が異動した2022年10月までスクラム手法での開発を行っていました。スクラムでの要求整理からリリースまでの実際の流れもまとめたうえで、なぜ開発手法を変えたのか、その効果などをPOやスクラムマスターに聞いてみました。なお、開発プロセスは現場や会社によって微妙に異なるため、参考程度にご覧ください。
アジャイル開発の手法
一言で「アジャイル開発」と言っても、調べてみるとさまざまな手法が存在しているようです。
①スクラム手法
スクラム手法はアジャイル開発の中で最も有名な手法です。
ラグビーで肩を組んでぶつかり合うフォーメーション「スクラム」が名前の由来となっており、チームメンバーのコミュニケーションを重視しています。主な特徴としては、1週間から最大4週間の「スプリント」を繰り返して機能単位で開発を進める、毎日開催する「デイリースクラム」などのスクラムイベントを通してコミュニケーションを取りながら開発を進めます。
②カンバン手法
「カンバン」は日本語の標識や看板のことで、行動のきっかけとなる視覚的な信号を意味します。
作業項目が視覚的にカンバンボードに表示されていて、メンバーはいつでも全ての作業の状況を確認できます。スクラム手法のようなスプリントの縛りがなく、現在進行中の作業が完了するとカンバンボードから新しいタスクを取り出して順次取り組んでいきます。
その他、以下のような手法もあります。
③エクストリーム・プログラミング手法(XP)
④クリスタル手法
⑤デブオプス手法（DevOps）
⑥リーン手法（Lean）
⑦ダイナミックシステム開発手法（DSDM：Dynamic Systems Development Methodology)
⑧受入テスト駆動開発（ATDD：Acceptance Test-Driven Development）
⑨テスト駆動開発手法（TDD：Test Driven Development）
⑩行動駆動開発手法（BDD：Behavior-Driven Development）
⑪機能駆動開発手法（FDD：Feature-driven development）
⑫実験駆動型開発手法（EDD：Experiment-Driven Development）
それぞれの詳細については以下の記事に詳しくまとめられていましたので、ご覧ください。
アジャイル開発でよく使われる12の手法とは？特徴・効果について解説！
所属チームの開発プロセス
冒頭に書いたとおり、所属チームでは私が異動した2022年10月までスクラム手法での開発を行っていました。
1sprintを2週間、稼働日数を10日と定義して「スプリントプランニング」「デイリースクラム」「スプリントリファイメント」「レトロスペクティブ」の4つのスクラムイベントを実施しながら開発を進めていました。具体的な開発プロセスは以下のとおりです。
要件定義（PO/Dir）
「なぜやりたいのか」「何をやりたいのか」といった要求を整理し、その要求を叶えるために何が必要か、システム的に必要な要件を整理します。『Confluence』のドキュメントに概要やユーザー操作イメージ、修正対象画面、UI、発生する可能性のある条件分岐、エラー時の挙動、データパターン、テスト観点などの要件を整理してまとめ、仕様書をつくります。
スプリントリファイメント（PO/Dir/SM/PG）
スプリントの後半に開催するスクラムイベントです。ここでPOやDirが次のスプリントで着手したい企画について、概算見積りができる程度の説明をして、PGがDB仕様やIF仕様などの内部設計を行い、要件定義に基づいてシステム的にどうやって実現するかを決める基本設計を進めます。
スプリントプランニング（SM/PG）
スプリントの最初に行うスクラムイベントです。着手する企画の詳細なすり合わせを行います。スクラムの進行役、スクラムマスター（以下、SM）がプログラマー(PG)に対してプランニングポーカーを実施し、ストーリーポイント(作業量)の見積もりを行います。
結合観点の作成（PG）
仕様書に記述されている内容に沿っているか、機能要件と非機能要件に対しての動作や振る舞いが合っているかを確認するための結合観点を洗い出し、Excelにまとめます。
結合観点のレビュー（PO/Dir）
上記が仕様書に記述されている内容に沿っているかをDirが1次レビュー、POが2次レビューを行います。
実装作業（PG）
設計に基づいたコーディングと、それらの動作確認を行います。動作確認ではコーディングしたプログラムの品質を担保する「コードレビュー」や、コーディングしたものが意図通り動作するかの確認と、要件漏れがないことを担保するための「単体テスト」を行います。また、毎朝全員でデイリースクラムと呼ばれるイベントを実施し、前日の作業報告や困りごとがあれば相談しコミュニケーションをとります。
結合テスト（PG）
個々に作成したプログラムを組み合わせた時、実業務と同様のユーザーシナリオでも期待通りに動作するかを担保するための「結合テスト」を実施します。
受け入れテスト（PO/Dir）
要求通りに作られていることを確認する「受け入れテスト」を実施します。
リリース日の調整/広報（PO/Dir）
問題がなければ、PGとリリース日の調整を行い、社内にメンテナンス日時を広報します。
リリース（PO/Dir/PG）
リリース日当日の朝8時にリリースします。リリース直後に担当PGとDirは初動確認を行い、連携先の社内システムにデータが反映されているかなどの動作確認をします。問題がなければ、社内にメンテナンス完了の投稿を行います。
レトロスペクティブ（PO/Dir/SM/PG）
隔週金曜日に振り返り会を実施し、全員でKPTを行います。開発工程でのProblemがあれば共通認識をもち、翌週以降に選んだTryを実施して改善を図ります。
以上がスクラム手法での開発プロセスです。
ではなぜ、スクラム手法からカンバン手法に変更することになったのか。POとスクラムマスター（現 開発PM）に聞いてみました。
なぜ、カンバン手法に変えたのか？
主な原因は以下の３つでした。
コアメンバーがいなくなった
業務委託メンバーが中心
進捗が追いにくかった
初期リリース後に体制が変わり、コアメンバーが別のプロジェクトに移ったことがひとつ目の理由です。
スクラム手法はコミュニケーションを重視した開発手法であり、独立して自立した人々がフォーメーションを組んでコラボレーションすることで円滑に進むものであるとされています。
語源となったラグビーの「スクラム」では、最前列で相手フォワードと組み合う「フロントロー」の3人がおり、その後ろから残りのメンバーが支えてスクラムを組みますが、最前列の方が崩れてしまうと全体が崩れます。
スクラム手法でも同様に、コアメンバーがいなくなると崩れてしまいます。初期リリースが終わった後、業務委託メンバー中心になり、企画と開発をつなぐブリッジ役のメンバーが不在となりました。そういったチーム体制の変化から基盤が崩れたため、スクラム開発でのタスク管理が難しくなりました。
また、スクラム手法ではタスクが並行して走るため、タスク管理が上手くできていないと完了まで時間がかかるという課題もありました。
上記の理由から、現在のチームにはカンバン手法の方が適していると判断し、スクラム手法からカンバン手法に変更することを検討し始めました。
手法を変えたことによる変化は？
主に以下のポジティブな効果がありました。
形骸化していたスクラムイベントがなくなった
開発PMがハンドリングできるようになった
カンバンボードによって進捗を可視化できるようになった
ワークフローをカンバン化したので不要なタスクを除外できた
マルチタスクを抑制できるようになった
スプリント内に達成することにフォーカスをおいて品質が落ちていたのが改善した
基盤が崩れたため、スクラム手法におけるタスク管理が難しくなり、コミュニケーションをとるためのスクラムイベントも形骸化していました。しかし、カンバン手法に変えたことで、開発PMがハンドリングできるようになり、進捗を可視化することができるようになりました。また、タスクが並行して走らないため、マルチタスクを抑制でき、スプリント内での品質にフォーカスすることができ、品質の向上につながりました。
感想
開発プロセスは、想像以上に様々な手法が存在することがわかりました。
アジャイル開発と一言で言ってもスクラム手法やカンバン手法などがあり、Googleで検索していると同じ手法でも微妙にプロセスが異なっていました。どの手法がチームに合っているのかは、プロジェクトの目的や期間、メンバー構成などの環境によって異なり、試行錯誤がされているようです。
今回スクラム手法とカンバン手法を経験しましたが、引き続き社内の開発プロジェクトに携わって学びながら、将来チームを率いる機会があれば、最適な手法を選び、もし運用上の課題があれば違う手法に変えることも検討しながら、チームにあった手法でプロジェクトを進めたいと思います。
この記事が気に入ったらサポートをしてみませんか？