私をシニアエンジニアにしてくれた「真のアジャイル開発」体験記（2024 Advent Calendar 1日目）
この記事は私をシニアエンジニアにしてくれた「真のアジャイル開発」体験記の1日目の記事です。このアドベントカレンダーは「ある機能開発チームでスクラム, XP, DevOps を一度に実践したら真のアジャイル開発ができた」という内容です。この記事はプログラミングをするパンダが全て執筆しています。
私をシニアエンジニアにしてくれたアジャイル開発を振り返る
本アドベントカレンダーの内容は、今から2年前の2022年には書き上がっていました。熱心に下書きを執筆したところまでは良かったものの、推敲と掲載の労力を考えるとどうにも腰が重くなりどこにも発表していませんでした。当時のマネージャーに見せたところ「もはや論文ですね」と言われるほど量が膨大だったのです。
まとめる気力を起こそうとカンファレンスのプロポーザルとして提出したことがあります。2度プロポーザルを書き、2度とも落ちました。「スクラム, XP,DevOpsを一気に全部やったら真のアジャイルチームになれた」というような内容だったのですが、運営の方は発表内容がぼやけると考えたのでしょう。実際、60分のトークであっても語り尽くせないほどの内容です。
それでもアドベントカレンダーという形式を借りて発表しようと思ったのには理由があります。2022年の「真に顧客志向に、真にアジャイルになれた開発体験」が現在の自分のキャリアやチームに対する向き合い方のターニングポイントになったことをひしひしと感じるからです。
スクラム,XP,DevOpsをチームで一度に実践するという取り組みとプロジェクトの成功をマネージャーから評価された結果、自分はシニアエンジニアという役職を貰いました。また、当時のプロダクトオーナーも今ではPdMのマネージャーに昇進しています。他にも当時のPJメンバーは現在も社内で人並みならぬ活躍をしていることからも、このチームでみんなが得た経験の大きさを感じています。
今でも私自身はどんなチームであれ、あの時チームに存在した好循環を産むことを目標にチーム作りをしています。その結果、当時とは異なるマネージャーと働いている今も「あなたに任せると安心感がある」と言ってもらえるチーム運営が出来ています。このため良いチーム作りは誰でも再現することは可能です。
個人的に何より嬉しいことはLeanとDevOpsの科学を読んでから、チームメンバーの誰も絶対にバーンアウト（燃え尽き）させたくないと強く思い続けています。実際、シニアエンジニアになってから自分と同じチームだった人で退職した人はいないというのはとても幸運なことです（業務委託の方は除く）。これが何より燃え尽きていない証拠だと言えるでしょう。
プロジェクト自体は3ヶ月という短い間でした。しかし、アジャイル開発の大切なエッセンスが詰まった実りの多い3ヶ月間でした。
このアドベントカレンダーを読み終えた頃には、あなたも真のアジャイルとは何か心で理解して貰えるでしょう。それでは少し長いですが、お付き合いください。プログラミングをするパンダによる「私をシニアエンジニアにしてくれた『真のアジャイル開発』体験記」です。
エリートチームを目指して
スクラムとXPとDevOpsを同時に実践したといえども全てが同列に置かれるわけではありません。「LeanとDevOpsの科学」を読んでFour Keysのエリートを目指すためには24のケイパビリティを発揮する必要があると学びました。
24のケイパビリティではリーダーシップやリーンな製品開発とマネジメント、技術への向き合い方が説かれています。全く新しい発見があるというよりは、良い会社の良いチームならできていることが書かれています。
私はこの本からムーンショットを打てというのではなく「基本を徹底するだけで他者と差別化できる」というメッセージを読み取りました。DevOpsといえば現代では知ってる人は多いものの、これらのケイパビリティを高いレベルで実践できてるチームは多くないのではないでしょうか。基本を徹底することでパフォーマンスは大幅に向上する。この本はそれらの基本を科学的な分析により導き出したのです。
DevOpsのFour Keys: 高パフォーマンスを目指して
Four Keysとは、デプロイ頻度、リードタイム、変更失敗率、復旧時間で構成される指標です。自分たちが担当するプロジェクトは新規の機能開発なので運用より開発が中心であるため、特にデプロイ頻度とリードタイムを向上させることにしました。
なぜデプロイ頻度が高いとハイパフォーマーと言えるのか、その理由は最初わかりませんでした。しかし、まずは「品質を高く保ちつつ高頻度でデプロイする」ことを目的にしました。その結果、デプロイ頻度が重要な理由が明らかになりました。
その効果を一つを紹介しましょう。デプロイ頻度を上げると、仕掛かり中の作業と完成した作業がはっきり分かれます。TODO, 仕掛かり中、完了した作業をチームにわかりやすく共有するためにスクラムのスプリントバックログをカンバン形式で作りたくなります。
カンバンを作るにあたり、チームは自分たちが一番効率的に使えるツールを自由に選定をします。このチームでは最初Miroを使っていましたが、後にFigJamとAsanaに、最後はFigJamのみを使うようになりました。スプリントバックログはスクラムイベントであるデイリースクラムやスプリントプランニングやバックログアイテムのリファインメント、レトロスペクティブなどでチーム全員が触れることになります。
カンバンはXPの言う「情報満載のワークスペース」になったためチーム間のコミュニケーション漏れがなくなりました。コミュニケーションはXPが示す価値の一つでもあります。リモートワーク全盛期の時代でもスムーズな開発に十分適応できました。デプロイ頻度を上げるとチーム内のコミュニケーションが盛んになったのです。
DevOpsのケイパビリティを発揮するためにスクラムとXPを実践する
他にも「LeanとDevOpsの科学」で書かれているプラクティスを実現するためにスクラムとXPを組み合わせた例を簡単に紹介します。
1.毎日デプロイすることを目指した結果、ベロシティが安定した
毎日デプロイを目指すにあたって、トランクベース開発を取り入れました。その結果、小さいPRでも良いからどんどんマージしていこうという雰囲気がチームで醸成され、プルリクエスト1つ当たりの変更行数が少なくなりました。すると、大きいタスクを次のスプリントに持ち越すということが大幅に減り、スプリントのベロシティが安定しました。
2.バッチ単位の作業を心がけた結果、情報の透明性が高くなった
毎日デプロイを目指してから、プルリクエストの変更行数を減らすためにタスクを小さく細分化することがチーム内で当たり前になりました。タスクの見積もりをするときに「5ポイントでも大きすぎるのでは？」という感覚をチームメンバー全員が持ち始め、リファインメントでは出来るだけ1,2,3ポイントになるまでタスクを分解することを心がけていました。
すると、プランニング時にみんなが想定していなかった新しい作業が出てきたらデイリースクラムできちんと共有する動きが生まれました。もしあるタスクに大きい5ポイントを当てていたら「少し作業が増えてもポイントの範囲内だ」としてあえてチームに共有されなかったかもしれません。結果的にチーム内の情報の透明性が上がりました。
3.情報セキュリティのシフトレフトにトライしたら、インシデントの予行演習を実施できた
情報セキュリティのシフトレフトは自分たちのチームにとって重要な要素でした。なぜなら、自分たちが開発するのは個人情報を扱う機能だったからです。法務とセキュリティチームに会議で開発する機能の懸念点について、プロダクトオーナーを中心に質問して守りを固めました。
のみならず、スプリントレビューに加わって貰うことで会議ではわからなかった考慮漏れに事前に気づけて対策を打てました。機能のリリース前には、個人情報に関するセキュリティインシデントが万が一発生した場合の予行演習を社内の各チームと一体になって行えたました。このことは今でも情報セキュリティのシフトレフトの極地だったと誇りに思います。
4.変更を小さくした結果、受け入れテストのスプレッドシート管理が廃止された
開発初期の1ヶ月間はプロダクトオーナーが各タスクの受け入れテストの項目をスプレッドシートで作成・管理していました。しかし、タスクが完了したらプロダクトオーナーにチェックしてもらっていたこと、また変更内容が小さいため差分がわかりやすかったことからスプレッドシートでの管理はなくなりました。デグレのチェックはスプリントレビューの前日に特に入念にやっていました。しかし、ほぼ毎日触ってるので何かおかしいことがあれば誰かが気づく体制になっていました。
アジャイルであり続けるために
ここまで良いことばかりを書いてきました。しかし、重要なのはDo Agile（Agileをする）ではなくBe Agile（Agileになる）です。一度ゴールに到達したとしても、その後もBe Agileであり続けることは難しいです。気を抜くとすぐに元に戻るからです。
例えばチームは成功体験を積んだ後も以下のようなことを経験しています。
- プルリクエストが肥大化してデプロイ頻度下がってしまうこと
- 燃え尽きないようにコンスタントに仕事をする方法を採用しているのに「見積もりが増えても私がなんとかハードワークをして解消します」という宣言をしてしまうこと（タスクはチームで分担しましょう）
- プロダクトバックログではタスクの着手順を決めているのに、その人の興味関心から優先順位が下の技術調査を進めること
- デイリースクラムで決めるべき事項が決められないまま、あわや「今日のデイリーは終わりですね」と解散しそうになること
- リファクタリングを継続しなくなる etc.
このような異変に気づいて「ちょっと待ってください」と軌道修正する人はチームに必要です。「真のアジャイルチームであり続ける」ことは一筋縄ではいかないのです。
DevOps、スクラム、XP - 基本の徹底がもたらす変化
DevOpsやXP、スクラムは表面的な取り組みだけでは効果が出ません。良いチームを作り上げ、チームをアジャイルにし続けるためには基本を徹底することが必要なのです。このアドベントカレンダーでは、真のアジャイルチームの一つのあり方を微に入り細を穿つような書き方で紹介していきます。読者の方が所属しているチームでも必ず真のアジャイルチームになる方法を再現できると信じているからです。
XP本に「夜遅くまで働いて疲弊しているチームよりも、うまくいっているチームが解雇される」と書かれています。うまくいくチームはトラブルが少ない上に仕事を早く終えているため、周りから楽をしているように思われるからです。自分たちのチームはプロジェクトが終わると解散させられるどころか、別のチームが合流してきてより大きな機能を作ることになりました。が、それはまたどこかで語るような別の話です。
次回は「タイトルを入れる」です。
Happy Coding 🎉
