私たちのアジャイル開発が始まる：プロジェクトとチームの紹介（2024 Advent Calendar 2日目）

この記事は私をシニアエンジニアにしてくれた「真のアジャイル開発」体験記の2日目の記事です。このアドベントカレンダーは「ある機能開発チームでスクラム, XP, DevOps を一度に実践したら真のアジャイル開発ができた」という内容です。執筆者は全てプログラミングをするパンダです。

（本内容は2022年4-6月時点の情報であり、一部古い情報が含まれている可能性があります。ご了承ください）

本記事では、開発内容やプロジェクトの体制、開発の進め方を概観します。

私たちが担当したプロジェクトとは

2022年4月上旬、担当していた機能の開発が一段落した頃にマネージャーから次の開発をアサインされました。それはビジネスをより大きくするための社内のメンバーが利用する機能開発です。社内ツールとはいえ顧客の個人情報を扱ったり、これから新しい業務を始めるため仕様が全然決まっていなかったりと難易度は低くないと感じました。

しかもなぜかリリース目標の期限が決められていました。それは5月のゴールデンウィーク明け。1ヶ月しかありません。達成するしないに関わらず、期限を決められているのはエンジニアが最も嫌がることです。自分は率直に「期限が最初から決められているのはアジャイルではない」とエンジニアリングマネージャーに伝えました。彼も同じ思いだったのですが、とにかくまず見積もりをしようという話になりました。今から思うと彼自身ビジネスの人に流石に無理だと伝えることはできたものの、自分たちエンジニアの出方をある種試していたのかもしれません。

とにかくタイトなスケジュールと仕様が何も決まっていないという不確実性への対応が求められました。最終的にやはりゴールデンウィークには間に合わなかったものの、結果的に誰も疲弊することなく6月末にリリースを実現しました。しかもスクラムをうまく活用したためビジネスの方からは「遅れている」と急かされるどころか、開発が着実に進んでいることがわかり安心感があると言ってもらえました。この体験はステークホルダーと適切に関わった成功例だったと考えています。

プロジェクトメンバーの紹介

プロジェクトメンバーは、入社して1年ほどたったフルスタックエンジニアの自分、入社して2,3ヶ月目の二名（前職でゲーム開発をしていた方とDDDを実践していた方）、ISUCONの上位入賞チームのメンバーと業務委託の方が1名、またフロントエンドエンジニアが1名でした。

私はフロントエンドエンジニアとして入社して、このプロジェクトでもフロントエンドの開発でアサインされました。しかし元々バックエンドエンジニアとしてキャリアを始めていたこと、このプロジェクトではフロントエンドのタスクが少ないことが早々に分かったため、自分はバックエンドのコードを書くことにしました。

私たちのチームはバックエンドエンジニア5名、フロントエンドエンジニア1名、プロダクトオーナー1名、エンジニアリングマネージャー1名が所属していました。このように多様なバックグラウンドを持つメンバーでチームが構成されていたことで、チームの柔軟性と問題解決能力が高まる結果に繋がったと考えています。

スクラムマスターの下でスクラムを実践する

同じチームのエンジニアリングマネージャーは認定スクラムマスターでもありました。スクラム開発をチームに取り入れたいということで、私たちはまずスクラムガイドを輪読しました。

私は前職でスクラム開発が好きという方と同じチームになり、その方からスクラムの考え方を学んでチームでスクラムイベントをいくつか実施していました。しかしスクラム開発によって劇的にチームの状況が改善したと感じることができなかったため、当時はスクラム開発に対して懐疑的でした。ただし、スクラム開発の真髄に触れたあるきっかけから自分はスクラム開発の積極的な推進者になります。

4月はイテレーションを1週間に設定しました。仕様が決まっておらず着手できる開発タスクがほとんどなく、調査と仕様策定の会議が多かったためです。仕様が決まり始めたらエンジニア陣は開発に着手できます。するとレトロスペクティブ（振り返り）で「スクラムイベントのミーティングが多すぎる」といったフィードバックが出たため、5月からはスプリント期間を2週間に変更しました。

また、各種スクラムイベント（デイリースクラム、スプリントレビュー、レトロスペクティブ）を活用し、チーム内外のメンバーと密にコミュニケーションを取りました。特にレトロスペクティブでは振り返りの手法をKPTから「思ったこと、問題点、Next Action」に変えるなどチームで対話をして一つのやり方に固執せず柔軟に進めました。

各スクラムイベントや成果物の表現にどのようなツールを使い、どのように実践していたかは次回以降の記事で紹介します。

XP（エクストリームプログラミング）を導入する

XP（エクストリームプログラミング）はTDD（テスト駆動開発）で有名なケント・ベックが考案したソフトウェア開発手法です。私はTDDとペアプロが好きで前職から実践を続けており、ケント・ベックのXPもいつか腰を据えて実践したいと考えていました。そこでこのチームは社歴の浅いメンバーもいるため、チームビルディングも兼ねてペア・モブプログラミングを取り入れることを提案しました。

PHPStormのコードを共同で編集できる機能であるCode With Meを活用したペア・モブプログラミングを皮切りに、必要最小限の設計を行った後に実装を進める「インクリメンタルな設計」や、「リファクタリング」をスプリントの初めに実施して品質向上を図ったり、オンラインコミュニケーションツールであるGatherを活用して「全員同席」を実現するなど、XPのプラクティスを導入していきました。

XPは技術プラクティスだけと思われがちです。しかし、実際そうではありません。またかつては「アジャイル開発といえばXPかスクラム」という位置付けだったそうですが、スクラムとも対立するどころか被るところも少なくありません。

例えば、「情報満載のワークスペース」はスプリントバックログアイテムやバーンダウンチャートを表現したFigJamがそれに当たります。「計画のストーリー」はストーリーポイントでの見積もりであり[^1]、「週次サイクル」はスプリントそのもの、「本当の顧客参加」はスプリントレビューで実現されるものです。

このように、スクラムとXPを組み合わせることは何らおかしなことではないのです。アジャイル開発を実現するためにエンジニアリングマネージャーがプロジェクト管理の側面が強いスクラムを推進する一方、エンジニアである自分はXPをチーム全体に導入したのは自然な流れでもあります。

様々なツールの活用

このプロジェクトでは、いくつかのツールを組み合わせて使っていました。現在では社内でNotionやGoogle Meetsが活用されているため、ここにはもう使っていないツールも含まれています。

タスク管理には最初Asanaを使っていましたが、後にFigJamに移行しました。カンバンを作って作業状況の可視化を促進するためです。コラボレーションツールにはGatherを活用しており、業務開始から退勤するまでみんなGatherに集まって通話を繋いでいました。この時はコロナでリモートワークが始まって1年目が経った頃だったので、フルリモート下でのコミュニケーションの重要性が強調されていたからです。

「話した方が早い」という場面ではすぐにGatherで集まる運用を定着させました（ただし、今ではGatherではなくSlackのhuddleを活用しています）。

Four Keys - DevOpsのメトリクス

Four Keysについても触れておかねばなりません。Four Keysの4つの指標はそれぞれ「デプロイの頻度」「変更のリードタイム」「変更失敗率」「平均復旧時間」です。しかし今回の開発は新規開発が9割で既存機能の改修が1割であり、社内メンバーだけが使えるシステムに機能を追加するものだったため平均復旧時間と変更失敗率は特にトラッキングしませんでした。

DevOpsのFour KeysといえどもOpsではなくDevの指標のみに注目していたことになります。今回のプロジェクトでは、24のケイパビリティの中から特にトランクベース開発を意識して導入しました。これによりデプロイ頻度が向上してリードタイムを短縮でき、以下の成果を得ることができました。なお、指標の期間はキックオフからリリースまでです。

デプロイ頻度

デプロイ頻度について、仕様策定が多かった4月を除くと5,6月の営業日では実に95%の日でデプロイをしています。5月は毎日デプロイをしました。デプロイ頻度を上げることで、着実に前に進んでいるという実感がチーム全体に広がっていきました。

1日あたりのデプロイの数は1日1回が多いものの、1日に4回デプロイできた日は「自分たちは開発を大きく進めた」ということでチームメンバー全員の士気が大幅に上昇したことを覚えています。

変更のリードタイム

変更のリードタイムはファーストコミットの時刻からマージした時刻を集計するとチームで決めていました。マージまでにかかった日数とプルリクエストの数を見ると、なんとコミットからマージまで翌日に持ち越さなかったプルリクエストは27件、1日しか溜めなかったものは34件で前プルリクエスト数の大半を占めます。

さらに、マージまで6日かかったプルリクエストの2件は開発初期にしか発生していません。ゴールデンウィークが明けた5月6日以降は2日の例外を除いて、全て最大プルリクエスト保持期間が2日以内に収まっています。

しかも5月30日以降は1日を除いて全てのプルリクエストを翌日以内にマージしています。全体を通してみてもプルリクエストの保持期間が短くなっていることが顕著にわかります。

1つのプルリクエストを小さくする意識が浸透したことから、時間が経つにつれてプルリクエストのコメント数が減少していることがわかります。チームでペアプロ・モブプロが浸透したりコミュニケーションを密に取った結果、レビューコストが軽減されたことを見て取ることができます。

このように、各種指標からも時間と共に開発が効率化できたことがわかります。それに伴ってチーム外からは効率的で信頼性の高いチームだと認識され、チーム内でもレビュー待ちやレビューコメントが減少してメンバー同士の信頼関係が醸成されていきました。

では、私たちはアジャイル開発のプラクティスをどのように運用したのでしょうか。次回からは7記事に渡って私たちが実施したスクラム開発の実施方法を詳説します。

[^1]: そもそもストーリーやストーリーポイント自体がスクラムではなくXPのアイデアであると、XPの考案者の一人である Ron Jeffries 氏は自身のブログStory Points Revisitedで語っています。