この記事は Agent Grow Advent Calendar 2022 の記事です。

ごあいさつ

みなさん、おはようございます！
アドベントカレンダーは三年目になるのですが、ついに(？)今年は
お仕事関連のトピックで一本書こうと思い立ちました。¹⁾去年は燻製作り、一昨年は育休関連の記事

直近の案件で、Agile/Scrum開発を行うチームに参画して2年半。
チームがプロダクトに寄与した「成果」を測る指標²⁾Agile/Scrum開発の経験のある方ならご存知かもしれない「ベロシティ」に、
参画先独自の指標をプラスしたものが、
参画当初から300%アップしました?

どんなプロダクト・体制だったのか？
300%アップの背景には、どんな要素があったのか？
この間、チームと参画先にどんなことが起こったか？
現在はどうしているのか？

そんなことをふり返りながら、この2年半の歩みを綴りたいと思います！

この案件との出会い

くだんの案件に参画したのは、2020年1月から。
とあるCtoC販売サイトを運営する、事業会社さんの案件です。
参画前の打ち合わせでは「事業を加速させるために、Agile/Scrum開発を
導入したんですよ」とのこと。

これより1つ前に参画した案件で、初めてAgile/Scrum開発を経験して
チームメンバーがそれぞれ自主性をもってプロダクトを推し進めていくことに
魅力を感じたため、「この案件もきっと魅力的に違いない！」と思って、
参画を決めました。

そして待っていた洗礼

こうして意気揚々と入場を迎えたのですが、参画してみて分かったのは
なかなかハードなシチュエーションでした。

たとえば。

• 以前にあったスクラム開発チームは崩壊して解散しており、新しいチームが立ち上がったばかり³⁾自分の参画時点で、開発メンバーの
  7名中5名が参画から1ヵ月経ったところ
• プロダクトは数年にわたって開発されてきたのに、設計書がほぼ無い⁴⁾かろうじて存在するDB設定書なども、1年以上メンテされていない
• プロダクトの仕様を知る人がほぼ居ない⁵⁾プロパーのプロダクトオーナーが前任者から半年前に口頭で引き継ぎを受けたとのこと
• プロダクトにガッチリ一致するスキルを持った人が居ない⁶⁾Ruby on Railsの案件なのに、3年以上の経験がある人は一人だけ。半数以上はRails未経験
  (自分もRailsはこの時点で半年ちょっとの経験)
  AWSに精通する唯一のエンジニアも自分の参画から1ヵ月後に離脱が決まっていた
• 本番リリース作業が神頼み⁷⁾CircleCIで本番デプロイを実行しており、
  その前段として実行されるシステムテストが、時間がかかる上に一定確率で失敗する。
  失敗するとデプロイに進まない。
  祈祷力が試される⛩️

などなど。
…だいぶピンチな雰囲気ありませんか？

とはいえ、一度は引き受けてしまった案件。
しかも開発チームのメンバーは明るく士気も高い。
ここはひとまずやってやろうじゃないか！と、荒波の中へと飛び込んでいきました??

日々取り組んできたこと

いきなり不安なスタートではありましたが、PO⁸⁾プロダクトオーナー。プロダクトの運営に権限・責任を持っている人。
PdMやPMに近いかもは
「最初からバリバリの成果は求めていない」
「年単位の長い目で成長を考えてほしい」
「どう作るかはチームに任せるし、開発チームが良いと思ったことは
どんどん提案して欲しい」
と前向きだったので、Agile/Scrum開発の中で行えることはもちろん、
チームビルディングの領域でも、役に立ちそうなことは何でもやってみました?

※以下に挙げるものは、最初から自分だけが考えて提案したものではなく、
スプリントを重ねて振り返りを行い、チームとプロダクトを伸ばすには？と
考えていった中で、チームメンバー全員で考案したものも多数あります。

ビジネスモデルへの理解

2年半のあいだ、もっとも役に立ったと思えるのがコチラ。

• この会社は、このプロダクトを通して何がしたいのか？
• このプロダクトは、誰に/どういった目的で/どういった手段で利用されるのか？

ことあるごとにPOや他のプロパーを掴まえて聞き出し、背景を理解したことで
今後作る機能はナゼ必要になるのか、既存の機能にはどういった部分で影響が出るのかを
細かい仕様が分からなくても把握できるようになり、予期せぬデグレードを未然に防いで
プラスアルファの価値をリリースすることが出来るようになりました。

また、自分よりも後に参画してきたメンバーにも、各種機能をこまごまと説明するよりも
全体をふわっと説明しやすいため、新規メンバー追加時の教育・導入コストも
減らすことができました。

デイリースクラム

進捗を確認したり、問題の共有や対策を行う短いミーティングです。

ここでは進捗が芳しくないPBI⁹⁾プロダクトバックログアイテム。機能の開発要件を細かく区切ったもの。
「リリースが可能な最小単位のもの」と解されることもありますについて
「誰か応援が入ったほうがいい？」や「今日はどこまで終わらせるつもりで
進めようか？」など、開発メンバーそれぞれが過度な負担を抱えることなく、
なるべく安心して開発完了まで持ち込めるように
メンバー全員が対等に発言し、協力できるような雰囲気になるよう努めてみました。

ペアプログラミング/モブプログラミング

2人以上が同じプログラムのコーディングを、一定のタイミングで
交代しながら行うプラクティスです。
ドライバー¹⁰⁾キーボードを触って、実際にコードを打ち込む担当の順番が回ってくると、どうしてもプログラミングに集中して
沈黙しがちになってしまう人が多かったため、自分はあえてドライバーで話しまくりました。

「いま、こんな感じのロジックを組もうとして迷ってる」とか
「ここを打ち終わったら次はコレをしようと思う」と言葉に出すことで、
ナビゲーター¹¹⁾伴走者とも呼ばれる。キーボードを触らずに、ドライバーの作業の内容を
チェックしてあげたり、全体的な作業の方向性を整えたりする担当の協力を引き出すようにしていました。

このプロジェクトの途中からは、コロナウィルスの影響でリモート勤務の比率が
増えていきましたが、リモート勤務中もGoogle Meetによるビデオチャットや
VSCodeのLive Share機能¹²⁾相手のマシンで開いているVSCodeのワークスペースへログインし、
共同でコード編集を行う拡張機能を駆使して
ペアプロ／モブプロを継続できる体制を整えました。

ペアプロ／モブプロを導入していないプロジェクトからすると
不思議に思えるかもしれませんが、このプロジェクトでは
一人でコーディングを進めるよりも、ペア／モブで進めたほうが
スピードも質も上がるようになっていきました。

参加するメンバーの情報交換の密度が上がり、自分が普段知らないようなロジックや
操作方法に触れることが出来て、コーディングの効率が上がったり、
リアルタイムでコードレビューをしているので、タイポのような簡単なミスに
気づくことはもちろん、悪影響を及ぼすコードスメルを嗅ぎとる鼻が多くあり、
未来の修正コストを抑える対策が出来たりしたのが、功を奏したのかもしれません?

内部レビュー

スプリントの最終日には、開発チームだけでなく、スクラムチームで行う
スプリントレビューがあるのですが、このチームではPBIごとに完成した時点で
開発メンバーだけが集まって内部レビューを行うことにしました。

自分たちが作った画面／機能だということは一旦忘れて、その機能を使う対象者¹³⁾一般のお客様であったり、社内の管理者ユーザーであったりの
ペルソナを被り込んで、「ここのUIが分かりづらい」「こういうケースも想定した方がいいんじゃない？」と意見を出し合い、スプリントの時間内で間に合うものはブラッシュアップしたり、間に合わないものはインクリメントとしてPBIを作ったりしていました。

この準備のおかげで、スプリントレビューが円滑に回るようになり、開発チームとしても
プロダクトを自分たちのものとして捉える意識が進んだように思います。

スプリントレビュー

スプリントの最終日に、POなどを含めてスクラムチーム全体で集まり、
スプリントの成果物をレビューして、次に繋げるためのイベントです。

特にコロナ以降でリモート勤務になって以降は、POを含めたビジネスサイドの人間と
なかなか一緒の時間を過ごすことが出来なかったため¹⁴⁾そもそもPOがPO以外の仕事も兼務して激務だったり、
開発チームもペアプロやモブプロで
頻繁にmeetで参加するルームを変えていたりもしたため、
スプリントレビュー時には、PBIに対するフィードバックだけでなく
実際のユーザーの声はどうなのか、今後の事業の方向性はどうなっていくのかを
ヒアリングする場としても活用し、何がいつ必要になるのかを考え、
開発チームからもPBIを提案していくきっかけ作りとしても活用しました。

スプリントレトロスペクティブ

スプリントレビューの後に、この一週間¹⁵⁾このチームのスプリントは一週間単位でしたの開発チームの取り組みについて振り返り、
どんな部分が良かったのか、あるいはうまく行かなかったことは何かを共有し
次のスプリントで、よりチームを良くするためのプラクティスを生み出すイベントです。

「TDD¹⁶⁾テスト駆動開発。テストをまず初めに書いてから、プロダクトコードの開発に入る手法が良い感じに決まった時の○○さんのドヤ顔が良かった」や
「この手の機能の担当者が偏りがちになってきている」など、
スプリント中には拾いきれなかった話題やアイディアをメモしておき
良い点をさらに伸ばせる ＆ 問題を解消して次に繋げられるようなプラクティスを
生み出していきました。¹⁷⁾前述した内部レビューだったり、後述するTDDの勉強会だったり

テストの改善

Agile/Scrum体制に入る以前の開発者たちが書いていたテストは一応あったのですが
プロダクトに機能が追加されるたびに、建て増しのようにテストが付け足されて
可読性が悪かったり、複数個所で同じ目的のテストを行っていたり、
期待する挙動は正しいのに、ときどき失敗する¹⁸⁾ブラウザを仮想的に立ち上げて画面要素の確認をするテストで
画面要素のロードを待ちきれずに、テストが先に動いて
期待通りの画面表示ではない扱いになるなどようなものでした。

このテストを残したままでは、挙動を保証するどころか、プロダクトの歩みを
阻害する要素のほうが大きいと思われたため、時にはPBIの中でボーイスカウト的に
可読性の高いテストに書き直してみたり、時には思いきって既存のテストを捨てて
期待する挙動を説明できるドキュメントのようなテストになるよう、作り直しをして
開発チームにとって「このテストが通っているんだから品質は大丈夫」と思えるものに
していきました。

また、ときどき失敗してしまうテストについては、毎回期待通りに実行されるように
適切な待ち処理を入れるなどして、100%成功するテストになるように修正していきました。

CI/CDプロセスの改善

プロジェクトに参画した時の、テストの構成の問題に加えて
CircleCIで実行していたCIプロセスについても、すべてのテストが完了するまでに
25分以上掛かっていたため、こちらも改善を行いました。

フロント側で導入していたライブラリで不要なものを削除したり、軽量なライブラリに
置き換えることでバンドルサイズを削減して、ビルド時間を減らしたり
Dockerレイヤーキャッシュを活用して、イメージのプル回数を絞ったり
テストジョブを実行するリソースクラスや、並列実行数を調整して
最適な組み合わせを検証したり…

プロジェクトの後半では、これらの地道な改善が実って
プロダクトのテスト数は5割以上増えたのに、1回あたりのCIプロセスは
平均11分強で回せるようになっていきました?

また、本番環境やレビュー環境へのデプロイを行うCDプロセスについても
以前は(不安定な)テストを実行し、すべてのテストが通ったら
ビルド実行→各種環境へデプロイするようになっていたところを
CIプロセスが通った時点で、デプロイ用の資材を確保しておき
デプロイしたい時に、コマンド一発で実行されるように修正していきました。

これによって、本番環境へのリリースやhotfixについても、お祈りが不要になりました?

保守作業

お客様や運用部門から、サービスの挙動に関する問い合わせや
データメンテナンスなどの依頼が時折発生し、いわゆる保守作業を行うこともありましたが
これらの依頼のなかにも、プロダクトの質をより高めていくためのチャンスがあると考えて
同じカテゴリの問い合わせを減らすための機能開発を提案したり、
誤操作や誤解を招きかねないUI/UXの改善などにも取り組みました。

実際にサービスを利用しているユーザーの声を聞くことは、サービスをより良いものに
進化させていくための貴重な材料になり、開発側が作りたいものを作って
満足するだけのものにならないよう、活用することが出来ました。

ドキュメント化

参画した時に存在したドキュメントといえば、プロジェクトの環境を
ローカルで起動するための簡単なREADMEや、保守対応についての
簡単なマニュアルがある程度で、設計書などは一切存在しませんでした。

企業のスタイルもあるし、細かいところは仕様が頻繁に変更されるうえに
とにかくリリース最優先という気風があるところだったので、
カッチリした設計書などを作っても仕方ない、という事情もあったのですが
いかんせん、ドキュメントが無さ過ぎて、何もかもをソースから探り当てるのは
効率が悪かったため、ソースを解析して分かったことは
片っ端からwikiにメモして、同じ作業を何度も繰り返さなくても済むようにしました。

ドキュメントに起こす際は「なぜ、この機能が存在するのか？」や
「他の機能と(ビジネス的な側面も含めて)どう関連しているのか？」に重きを置いて
あとで読み返したメンバーがこのドキュメントを元に、次に起こすべきアクションが
分かるようになることを心掛けました。

勉強会

開発メンバーそれぞれで得意分野が異なっていたため、メンバーそれぞれが
どんなPBIでもこなせるように、お互いの得意分野を教え合う勉強会を開いたり
みんなで同じ技術書を買って、リモートで輪読会を行ったり、TDDの練習を行ったりと
スキルアップにも取り組みました。

「始業から1時間は、各自でプロダクトに役立つと思った分野の学習時間に充てて良い」という
参画先から贅沢極まりない時間をいただいており、ここをフルに活用させていただきました?
学習で得たものを、参画先のSlackで頻繁にアウトプットしていたため
他のチームにとっても参考となる話題/事例を提供できたこともありました。

コミュニケーション

開発メンバーそれぞれの趣味や開発スタイルの好み、多用するフレーズを
出来るだけ覚えておき、ペアプロ／モブプロを行う際や、みんなで決めごとをする際に
メンバーごとに響きそうな言葉を選んで使うなどして、円滑にコミュニケーションが
進むようにしていきました。

フランスやベトナム、中国・韓国のエンジニアも参画していた時期があったため
それぞれの国の簡単な挨拶や単語を覚えたりするのも、コミュニケーションに役立ちました✌

また、コロナ禍の状況でリモート勤務の割合が高まってからは、meetやgatherで
全日ビデオチャットしながら開発を進めているものの、どうしても業務時間中の会話は
取り組んでいるPBIの話題に集中しがちで、閉塞感を感じそうになることもあったため
開発ペースに余裕があるときは、意図的に脱線して、雑談を挟むこともありました。

そんなときの雑談の中で、リラックスしてお互いのことを話せたり
いまのプロダクトの状況に対するぼんやりとした要求、要望が出て来たりして
メンタルヘルスに気を配りながらも、日々前向きに取り組んでいける雰囲気が作れました。

そんなこんなで成果が出た

ここまで挙げてきたような、スクラムのイベントやそれ以外の色々な取り組みもあって
チームとプロダクトは継続的に成長し、参画から2年を過ぎた頃には
参画先の企業内で、スクラムチームの取り組みをアピールするための成果指標が
参画当初の300%ほどまで上昇するようになったのです?

参画当初は、ビジネスのコンセプトの理解もあまり進んでおらず、POが作るPBIを
開発メンバーみんなで覚束ない手つきで開発し、神頼みでリリースしていたようなチームが
自分たちの判断でPBIにプラスアルファの価値を与えてリリースしたり、
時にはプロダクトに有用なPBIを開発メンバー自ら作成したり、誰かが急に休んでも
途中から引き継いで難なく開発が続けられるような、自律したチームへと
成長していきました。

ここまでやってこられたのは、さまざまな取り組みを行うにあたって
「まずはやってみよう」の精神で前向きに取り組んでいった、開発メンバーの人柄や
辛抱強く応援してくれた、スクラムマスターの影響も大きかったと思います。

そしてチームは次のステップへ

チームとしては良い感じに成長してこられましたが、諸般の事情により
担当していたプロダクトは、2022年の夏ごろに新規の開発を終了し、
保守運用フェーズに入ることになってしまいました?

そしてスクラムチームも解散…かと思いきや、今度は参画先の企業内で進行中の
別のプロジェクトを、これまでのメンバーでそのまま担当することになりました。¹⁹⁾聞くところによると、取締役クラスの方が
チームの取り組みに着目していて、「今のプロジェクトが停止しても
チームは解散せずに、社内の別のプロジェクトで活躍してほしい」と
お声が掛かっていたのだとか

当初参画していた案件で求められていたスキルセットとも異なる技術領域²⁰⁾Ruby on Railsではなく、フロントもバックもインフラも
TypeScriptで構築していく案件。
もちろん(？)、自分は未経験でしたで、
当初は苦戦することも目に見えていましたが、開発チームのメンバー全員が
「このチームなら何とかしていけるでしょ」と、継続していくことを選択しました。

新しいプロジェクトに移ってからは、これまでの技術的な経験値はリセットされ
予想通りに四苦八苦する日々が続いてはいますが、それでも開発チームは
楽しく前向きに毎日取り組んでいて、何か良いことを成し遂げていけそうな
ムードがあります。

おわりに

自分はエージェントグローに入社するまで、Agile/Scrum開発を経験したことがなく
未知の出来事だらけだったのですが、こんなにも変化と成長の大きな取り組みを
経験することが出来て、毎日充実しています。

「うちのスクラムチーム、すごいんだぜー！」的な話題を、とりとめもなく
語ってしまいましたが、この記事をご覧いただいた皆さんの参画先でも
何か役立ちそうな要素が入っていれば幸いです?‍♂️

それでは皆さん、引き続きよいエンジニアライフをー！