こんにちは、エンジニアの市川です。
11月7日のお昼に、「CoDMON TechTalk」と題したイベントを開催しました！今回のイベントでは、「アジャイル」をテーマに4人がLTを発表しました。
イベント中にslidoで質問を集めつつ、LT発表後に登壇メンバーが質問にお答えしたのですが、時間の都合上その場で返答できなかったものも多く、改めて質問へのアンサーを記事にします。
たくさん質問をいただき、ありがたかったです！
ペアプロ関連
質問1：ペアプロはどのようにしているか
ペアプロは具体的にどんな風にやっていますか？（リモート時のツール、ペアの決め方、ドライバー・ナビゲーター交代のサイクル、など）
リモートでのペアプロツール
- コミュニケーションのベースとしてはGather（参考：リモートワークが当たり前になったチームでのバーチャルオフィス活用法）
- ペアでコーディングするツールとしてはIntelliJのCode With Meか、VSCodeのLive Share
を用いています。
ペアの決め方
それぞれのメンバーが取り組みたいストーリーを選んで自然とペアが決まるか、ルーレットなどで決めることが多いです。(前日と同じペアになったら回し直します。)
余談ですが↑これはコドモンの杉山さんの個人開発したFlowzennというツールです。ルーレットやグループ分けができて良い感じです。ぜひご活用ください。
ドライバー・ナビゲーター交代のサイクル
チームや状況によりますが、ユニットテストのテストケース単位でスイッチするくらいの頻度を理想としています。
質問2：モブプロはしているか
ペアプロはされているかと思いますが、モブプロはしていますか？していない場合は、どういった理由がありますか？
チームで必要だと判断した際には、モブプロもしています！モブプロをするケースとしては、
- チームやプロジェクトの走り出しで、要件・技術面の共通認識があまり形成されていないとき
- 複雑度の高い要件の整理や設計方針の図示など、関わるメンバー全員の知見を結集すべきとき
などです。
質問3：すべてペアでプログラミングしているのか
すべてのプログラミングをペアでやっているのでしょうか？また、PRのコードレビューのようなステップは踏まないのでしょうか？
すべてペアでやっているか
プロダクションコードとしてリリースするものは、すべてペアで行うのが理想です。が、現状100%できているとは言い切れない状態です。
コードレビューはしているか
ペアプロは即時でコードレビューしているという前提なので、開発チーム全体としてはPRを非同期で確認する形でのコードレビューは必須とはしていません。
コードレビューをなくすためには、ペアプロだけでなく、受け入れテスト・テスト駆動開発・継続的インテグレーションなどのXPプラクティスも実現されている必要があります。それらに伸び代がある場合には、コードレビューのステップもはさんだ方が安心です。コドモンでは、チームがカバーしているプロダクトや機能によって、それらの伸び代の程度が異なるため、コードレビューの要否もチームによって異なります。
質問4：意見のコンフリクトをどう解決しているか
ペアやチームで意見がコンフリクトしたときはどうやって解決していますか？（話し合いが十分になされた前提で、どちらの意見も決定的でない場合）
ペアで意見がコンフリクトしたときは、同じチームの別レーンのメンバーたちも呼んで話したり、チーム外でもそのトピックに知見のあるメンバーに手を振る（Gatherでは手を振る機能があり、話したい相手に気軽にpingを送れます）などします。必要な観点をすべて並べ、それらの観点の優先度を整理し、意思決定します。
その観点として、コストやリターンなど一般的なものの他に、XPの原則を参照することもあります。
スクラム関連
質問5, 6, 7：スクラムではなくXPなのはなぜか
スクラムなどは採用されていないのでしょうか？アジャイルの実践の中で特にXPを取り入れた理由が気になります
XP導入前、2020年頃にスクラムを導入していました。なぜXPにスイッチしたかは次の質問に記載します。
スクラムではなく、XPを採用した理由はありますか？
スクラム導入時点ではアジャイル開発経験のあるメンバーが少なかったのもあり、以下のような課題感がありました。
- その頃のコドモンの状況では、スクラム開発がプラクティスの形式的な部分のみにフォーカスされがちで、イベントが形骸化しやすかった
- その頃のコドモンの状況では、スクラムマスターというポジションを置くことで、そうでない人がスクラムマスターに甘えてしまったり責任の切り分けが暗黙的に発生してしまい、チーム全体が自己組織化していきづらかった
それらの課題感がある中で、XPでの経験がありそれを広めたいメンバーがジョインしたのをきっかけに、以下のようなメリットを期待し、XPに移行することにしました。
- XPはプラクティスの他に原則や価値も定義されていて、プラクティスそれぞれを原則に照らし合わせながら実施することで、本質的にアジャイルな状態に近づくという設計になっている
- XPではスクラムマスターのような存在はおかず、全員が等しく「チームとプロダクトを成長させる」役割を持つため、チームの自己組織化が阻害されない
- もちろんマインドやスキルによってその役割を担う度合いにグラデーションはあるが、「全員が等しく役割を持つ」ことを明示することが重要
- XPの場合、技術面についてもプラクティスが定義されており、新たな技術負債を生まない/既存の技術負債を返却していくことも組み込まれている
スクラムマスターのような役割の方はいらっしゃるんですか？
前述のとおり、いないです。
XP導入
質問8：なぜXPを導入したのか
XPを導入する前の課題感はなんだったんでしょうか。また、XPの導入については、意識的に推進したのでしょうか。それとも、自然にXPになったのでしょうか。
XP導入の課題感は、質問5, 6, 7 に記載したとおりです。
XP導入の推進は、意識的に行いました。エンジニアの評価項目としても「アジャイル」という項目をおくことで、組織としてアジャイルやXPの理解・実践を重視していることを示しています。
質問9：XP導入で苦労したことはあるか
XPを導入するにあたって、苦労したことなどありましたか？
XP導入自体には、ハードルはなかったです。
導入後の難しさとして、「XPを知らない人がjoinして、チームに入ってみんなと動くことで体で理解していく」ことが実現できるほど、チーム全体のXP浸透度・成熟度がまだ高くないことが今も課題です。
質問10：XP導入によって対応できた変化としてどんなものがあるか
XPを導入することによって、対応できた変化にはどんなものがありますか？
チームのバックログの変化
クォーター開始時点でバックログになかったストーリーやエピックが、状況の変化によって唐突に最優先になるなどの変化がたまに発生しますが、それぞれのチームがバックログを柔軟に組み替えることでそれに対応できています。
XPを導入していない世界線でもその対応自体はできていたかもしれませんが、状況が変化することを前提にするという共通認識があることでアジャストしやすい組織になっていると思います。
体制・チームメンバーの変化
状況が変わってチームの組成をアップデートする必要が出てきた際の対応も、XPを導入していることでスムーズになっていると思います。 ペアプロによって属人化を防いでいるため、大きな業務の引き継ぎなどする必要がないためです。
「この人が休んだらこの作業は止まる」も発生しづらいため、体調不良や家庭の都合やその他私用などで休む/離席するハードルも低いです。
ちなみに、2021年以降、開発チームの男性育休取得率は100%です...!（男性育休の平均取得期間は、2023年3月時点で169日）
開発進捗による計画の変化
トレードオフスライダー（品質/期日/コスト/スコープ、をどの優先度で守るか）において期日が最優先とされる開発において、開発を進める中で「このままのベロシティだと期日に間に合わない」とわかった際の調整は、XPを導入していることで適切にしやすくなっていると思います。 「ベロシティを観測しながら計画を見直し続けることが重要」という共通認識があるため、バーンダウンチャートを参照しながら「このままのベロシティだと期日に間に合わない、だからどうするか？（スコープを絞るのか、人数を増やすのか、期日をずらすのか等）」を健全に議論できます。
質問11：「制度が変わります」「コードが複雑で半年かかります」をどう解決できるのか
途中「制度が変わります」「コードが複雑で半年かかります」というスライドがありましたが、結局アジャイルやXPを取り入れるとこの問題はどう解決できるんでしょうか
「制度が変わります」
制度が変わること自体はもちろん問題ではなく、問題なのは「制度の変化に合わせてプロダクトや開発計画などを変える必要があるが、その変化をチームがポジティブに捉えられずハレーションが起きる」などのケースです。
変化を前提としていないマインドセットの場合にそのようなハレーションが発生しやすいと思いますが、変化を前提としてアジャイルにアジャストしていくのが大事だと共通認識を持つことで、それを一定程度防げると思っています。
「コードが複雑で半年かかります」
これ自体はXPによって解決はしませんが、未来の「コードが複雑で半年かかります」をXPによって防げると思っています。XPプラクティスであるテスト駆動開発・ペアプロ・リファクタリング・シンプルな設計・受け入れテスト・継続的インテグレーションによって、それらを取り入れていない場合と比べると、保守しやすい状態に確実になっていくからです。
ビジネス関連
質問12：進捗管理や状況把握のためにどのような可視化を行なっているか
進捗管理や状況把握のためにどのような可視化を行なっているか、答えられる範囲で教えて欲しいです
進捗管理
バーンダウンチャートで進捗状況を可視化しています。
- クォーター開始時点で、そのクォーターのバックログにあるストーリー群に、粗くはあるがポイントをふっています
- 「そのポイントをこういう感じで消化していけると理想だよね」という理想線をひき、ベロシティの問題に気づきやすい状態にしておきます
- イテレーションがしまるたびに、そのイテレーションのベロシティを記録し、進捗状況をバーンダウンチャートで可視化しています
状況把握
各チームがイテレーションをしめたタイミングで以下をポストし、状況を共有しあうチャンネルがあります。
- そのイテレーションのWIN
- 次のイテレーションの目標
- その時点でのバーンダウン
質問13：経営層や他部門からの理解に課題はあったか
開発手法としてのXPの導入や日常における開発計画の変更など、経営層や他部門からの理解が必要に思えたのですが、このあたりの課題などは無かったのでしょうか？
XP導入にあたって稟議を通すなどの必要性は特になく、経営層や他部門を説得するようなアクションはなかったです。
評価制度をアジャイルを軸においたものにアップデートした際も、「これでいきたい」と人事と話しスムーズに決まったため、特に課題はなかったです。
質問14：ビジネスメンバーの理解を深めるために何をしているか
XPの開発プロセス・価値観に対して、ビジネスメンバーの理解を深めるためにどんなことをやってますか？？
開発部以外のメンバーに対して、アジャイルの基本理念やXPについての理解を深めるという活動は運用として確立できていないです。その前提で、開発部の取り組みに対して疑問を持つ人を見つけたら「自分たちが目指している姿と、なぜそれがXPで実現できるのか」を伝えるコミュニケーションをとることを心がけています。
たとえば「ペアプロじゃなく、強いテックリードが単独でささっとやっちゃった方が早くリリースできるんじゃない？」という質問をもらうことがありますが、それに対しては以下のように返答します。
負債も多い現状のプロダクトにおいては開発者の持続可能性が重要であるという前提で、ペアプロによって以下のような恩恵をうけることができる。
- 属人化を排除することができるため、安定してプロダクト開発をすることができる
- プロダクト開発と同時に、メンバーの成長促進を行うことができる
- 品質が向上する
- 負債に立ち向かうことができる（ひとりだと心が折れかけたりする）
短期的にみると、手が早い人が単独で開発した方が早くリリースできるという可能性はあるかもしれないが、中長期的に「より早くより安全により遠くにいけるプロダクトとチーム」でありたいから、ペアプロと足元のスピードをトレードオフすることは考えていない。
評価関連
質問15, 16：評価はどのように行っているか
チームやプロダクトの成果が第一ということに異論はないのは前提として、とはいえ人事考課の側面では個人を評価すると思うのですが、どのように行っていますか？
評価は、360度フィードバックでの評価を運用しています。
ペアプロにおける評価制度の詳細を教えて欲しいです。具体的にチーム評価や個人評価があるかも気になります。
評価の観点
360度フィードバックを「コンピテンシーとして定めている15項目それぞれについて、どんなレベルをどれくらいの再現度で実現しているか」という観点で集めます。
コンピテンシーは大きく3つのカテゴリから構成され、各カテゴリに複数の項目があります。イメージしやすいよう、以下に3つのカテゴリと、各カテゴリ2項目を抜粋したものを載せます。
- 業務遂行
- ドメイン理解
- プロダクトデバッグ
- エンジニアリングストレッチ
- ソフトウェアアーキテクチャ
- 開発者体験向上につながる仕組みやプロセス改善
- チーミングストレッチ
- 物事を進める力
- アジャイル
評価プロセス
評価の流れは以下のとおりです。
- 360度フィードバックを、関わるメンバー分記入する
- 出揃ったフィードバックを確認し、EMが必要に応じて追加ヒアリングする（「評価基準の理解度が異なることで発生する評価ブレ」や「記入者から見える範囲の違いによるブレ」をEMが調整するステップ）
- それぞれのコンピテンシー項目のグレードが決まり、最終的なエンジニアグレードが算出される（カテゴリごとに上位n項目の平均でカテゴリグレードを出し、3カテゴリのうちの最大値が最終グレードになるようなイメージ）
テスト関連
質問17：E2Eやフロントのテストはどうしているか
テスト自動化において、E2Eやフロントのテストはどうされていますか。どこまで担保して、どこまで切り捨てているかなども知りたいです。
回帰的なE2Eテストとしては、Gauge&PlaywrightとAutifyを導入しています。
コドモンのプロダクトには多くの機能があり、それぞれの機能内でユーザーの業務を細かいケースまでカバーしていますが、現時点ではそれらすべての仕様をE2Eで担保できてはいません。
「どこまで担保して、どこまで切り捨てているか」についても明確な基準は存在せず、各チームの判断に委ねられているのが現状です。
その他
質問18：どれくらいのペースでリリースしているか
現在どのくらいのペースで本番リリース出来ていますでしょうか？また、カナリアリリースなど、リリース前の検証ステップをどのようにしているのかと、不具合検知するためのメトリクスやロールバックの仕組みなどあれば教えて欲しいです
リリース頻度
プロダクト基盤によってペースは異なります。ほとんどの機能がのっているメインプロダクトはモノリス基盤であり、品質担保の難易度も高いため、リリースを一日2回と定めて運用しています。
マイクロサービスにおいてはリリース回数の制約はなく、一日に1~3回程度リリースしています。
リリース前の検証
QAを中心にテストケースを洗い出し、それを自動テストに落とし込んでいます。リリースブランチが作成されると各種回帰テストが実行され、主要なケースでデグレードが起きていないことが担保されます。
カナリアリリース
Fearture Flagを用いて段階リリースを実施しています。
不具合検知のためのメトリクス
リリースフローの最後で確認を必須としているのは以下です。
- AWS
- RDS Performance Insightsでのデータベース負荷
- NewRelic
- 各サーバーのスループット・トランザクション・サーバーエラー数・APIリクエスト/レスポンス数・応答時間・CPU利用率・Apache worker status・DB参照のレイテンシなど
質問19：「重要度」を適切に判断するためにどうしているか
「差し込み」の話。「だいじなこと」と「差し込み」を区別する「重要度」を適切に判断する取り組みは何かありますでしょうか。「デイリーリファインメント」のやり方？
チケットの受け入れ条件の確認と規模の見積もりをしたのちに、PdMを中心として全職種話し合いのうえ重要度・優先度を判断しています。期初にチームとしてプロダクトをこの期間でこの状態にしたい、という目標を立てるのですが、それを叶えるための内容か？という点を考慮して重要度を決めます。目標達成に関連しないものは重要度「低」として扱います。 (※前提として、目標自体が状況の変化を取り入れて変わることもあるので、そのときの最新の目標に照らし合わせます)
以上
TechTalkでいただいた質問へのアンサーでした。イベントにご参加くださった皆さま、質問をポストしてくださった皆さま、ありがとうございました！
