プロダクト開発チームが陥った困難に対抗するためのワーキングアグリーメントとその実際

この記事は株式会社ビットキー Advent Calendar 2024 12日目の記事です。
製品開発本部エンジニアの @moroball14 が担当します。

チームでワーキングアグリーメントを設定した背景

僕が所属するプロダクト開発チームは以下の状況が見受けられました。

• 機能を提供しなければいけない締め切りに間に合わせるために、多少読みづらくても PR 作成者と 1 人の承認者が良しとしたらマージする
• あるひとつの PR でついでにここも直して、という内容がチームメンバーでばらつきがある
• 改善に着手したいのに着手できない、あるいは個々の頑張りに依存している

機能を提供しなければいけない締め切りに間に合わせるために、多少読みづらくても PR 作成者と 1 人の承認者が良しとしたらマージする

僕がもともと所属していた SET チームとの違いを明確に感じた部分です。

※ 弊社が明確に分けているわけではありませんが、ここではプロダクト開発チームをチームトポロジーで言うところのストリームアラインドチーム、 SET チームをチームトポロジーで言うところのイネイブリングチームのような役割とします。（参考: https://martinfowler.com/bliki/TeamTopologies.html）

SET チームに所属していた時期は、上記で言うような締め切りを強く感じたことがありませんでした。そのため 1 つ 1 つの PR をこだわり、またレビューをこなしていました。しかし、プロダクト開発チームでは締め切りという概念を強く意識していました。そうなると、その締め切りまでにマージすることが必須条件になり、それに引っ張られるように開発のスピードばかりが上がっていきました。承認しなければ良い、と思いましたが、承認者もまた締め切りを強く意識する人の 1 人なので、そううまくはいきませんでした。

しかし、結局質を重視した方が長期的なスピードが速くなることは様々な場所で言及されています。

このスライドの 48 ページでは、内部品質へ投資することは 1 ヶ月以内に効果があらわれる、と言及しています。長期で顧客への価値を届け続けることを考えたときに、チームの今の状況は改善すべきと考えました。

あるひとつの PR でついでにここも直して、という内容がチームメンバーでばらつきがある

いわゆる「ボーイスカウトルール」の認識の差によって発生していました。ボーイスカウトルールとは「来たときよりも美しく」というルールです。 1 ヵ所でも良くできれば良いのですが、どこをよくしたら良いかわからない、などもありますし、何より上で言及したスピードばかりを重視する開発だと考える余裕が生まれないこともあります。そのため、個々人で考えるように綺麗にしていっていいのはそのままで、困ったとき用のルールを設定すべき点だと感じました。

改善に着手したいのに着手できない、あるいは個々の頑張りに依存している

チームでは毎週振り返りを行ない、改善のためのアクション（この記事では KPT という振り返り手法をもとに Try と呼ぶこととします）を複数出しています。しかし

• 数が多く既に抱えている業務に手一杯で着手できない
• 着手できたとしても、個々人が少し業務時間を延長したりなど、継続的に改善に取り組める体制ではない

といった状況でした。

なぜワーキングアグリーメントなのか？

チームメンバーの認識の差が激しく、それが故に価値を提供する以外に考えてしまう場面が増え本質的ではない、と感じたからです。

ワーキングアグリーメントとは

スクラムチームがパフォーマンスを向上させ、対立を軽減し、気持ちよく仕事ができるようにチーム全員で決めたチームの約束事
ref: https://www.agile-studio.jp/post/apm-working-agreement

のことです。対立を軽減し、気持ちよく仕事をし、最終的に顧客に価値を届け続ける、ということを考えると、設定すべきだと考えました。チームメンバーで事実を整理し意見を出し合いながら設定する、という始めやすさも大きく起因しています。

設定したワーキングアグリーメントの意図とその実際

では、具体的にどのようなワーキングアグリーメントを設定し、それがどのような意図で実際にどうだったのかを、振り返っていきます。

Try は 1 振り返りに対してときめく 1 つだけに決める

意図

1 つだけに絞り、

• 深く考えること
• 必ず実践すること

の 2 点を行う状況を作りたいと考えていました。

当時は複数のアクションを設定していましたが、普段の業務と並行して取り組むのは現実的ではありませんでした。また、アクションを立ててから実際に取り組むまでに時間が空いてしまい、そのアクションの必要性を疑問視することもありました。これは、無意識のうちにアクションを立てること自体が目的になってしまい、深い考察が不足していたためだと考えられます。そこで、1つという制約を設けることで、本当に必要なアクションを慎重に検討し、実行可能な改善に繋げることを目指しました。「ときめく」というワードはこんまりさんから拝借しました。

実際

このワーキングアグリーメントを設定してからは、以下のような効果が見られました。

• Try は 1 つだけになり、必ず実行された
• 毎週の振り返りでずっと同じような問題が出なくなった

何も実行されない、という状況からは脱出できました。何か行動に移せることは、少なからず失敗を繰り返せる状況だということです。行動して失敗して振り返って計画をし直す、というサイクルを回せるチームになったことは良いと思います。ゆっくりと思うかもしれませんが、ゆっくりでも進まないよりは良い、と考えています。

また、行動することになって気づいたのは、その行動をどうやって評価するか、どのような結果が得られるか、を曖昧にしていたことです。ここに対しては再度振り返り、評価できる仕組みを整えていきたいです。

修正したファイルに deprecated のコードが存在した場合は、移行すべきコードへと変更する

意図

チームとしてのボーイスカウトルールが最低限決まっていれば、 PR であれもこれも、とやりとりが増えることはなくなり、かつ少しずつ非推奨のコードを消すことができます。価値の提供に集中しつつコードの改善が進みます。

また、普段の業務がある中で進めるには、少しずつ無理のない範囲でやると良さそう、と思い、「無理のない範囲」を言語化することで誰もが改善に着手できるだろう、と推測しました。

実際

継続してできていて、このルールを導入以降着々と derecated なコードを参照するコードが減っています。 knip を導入しているので、参照がなくなったタイミングでの削除は考えなくていいのも嬉しいです。

とはいえ、スクリプトを書いた方が速いのでは、と思うこともあります。顧客に価値を届け続ける、といった観点を持つと、少しずつ直す、がちょうど良いとも思うので悩ましい部分です。

リファクタリングは機能追加やバグ修正前に行う

意図

人は先延ばしにしたくなる生き物です。しかし、構造が良くないことが修正のしにくさに繋がるので、先にリファクタリングする方がトータルで考えると速く終わります。たまに「後でやる」といった言葉を見かけますが、大体はやらないので、必要と思ったタイミングで着手すべきです。そのためこのルールを設定しました。

また、機能開発やバグ修正とリファクタリングが 1 つの PR で行われるとレビューが難しいです。どこをリファクタリングしたのか、どの差分が機能開発か、の見分けをつけてのレビューはできないことはないですが、やはり頭を切り替えながらレビューすると漏れがあります。 PR を分けることをチームで意識するためにも、こういったルールにしました。

実際

ほぼできていませんでした。

事前にチームメンバーにアンケートをとったときは、できている、といった認識でした。しかし、このルールを設定してから Close された PR を眺めてみると片手で数えるほどしかありませんでした。

• リファクタリングが必要なタイミングがないかもしれない
• リファクタリングが必要なシーンと見極めることができていないかもしれない

といったことがまずは考えられます。まずは自分たちは必要なシーンを見極めることができているのか、を改めて確認すべきだと感じました（ 『リファクタリング』などリファクタリングの参考にできる書籍や情報はこの世にたくさんあるのでチームで輪読会してみるのは一つの案 ）。

20% の改善活動は第一優先にする

意図

強制的に改善活動の時間を設けることで、振り返りで「時間がないから直せない」といった声があがるのを防ぎたかったです。

時間はすごく言い訳にしやすいですが他責にしてもチームの能力は向上しないので、どうしたら短時間で実装ができるか、と自分に矢印を向けることを意図しています（自分自身に対しても思っている）。

実際

ほぼほぼ第一優先にできていますが、やはり納期のことを考えて改善活動の時間を削って機能開発にあてがってしまうシーンがあります。自分たちの能力に対して、開発すべき機能が多そうに見えると、 チームの約束事という強制力 < 納期のプレッシャー という構図になってしまうようです。正直ここは気持ちが大事、以外に対策がチームで思いついていない（対策になっていない）のでもし「同じ状況だったけどこんなふうに対策したよ」など意見がありましたらコメントお待ちしています。

実装にこだわりを持つ

意図

「こだわっているか？」と常に自分に問い続けることで、少しでも良いコードに繋がる、という願いと、こだわるなら手を動かす前に自然と設計する、という手順を踏むだろう、という推測がありました。

早くマージしたい、という気持ちで書いたコードが自分たちを苦しめている、と再認識しました。「実装前に設計する」といったルールにする可能性もありましたが、それでは「設計しました！」って言われたら今度は設計に関する細かくルールを決めなければいけなくなりそうで、ルールが自分たちを苦しめそうな予感がしました。なので、ワーキングアグリーメントにおいては「こだわり」といった言葉に集約することとしました。

実際

メンバーそれぞれの主観ではあるが、こだわりを持って開発するようになりました。実際自分自身もこだわる、という意識を明示的に持つようになったことで、納得するまでに思考を繰り返すようになりました。

また、わかっていたことではありますが「こだわる」という意識が良いコードに繋がるわけではない、こともあらわれてきています。「リファクタリングは機能追加やバグ修正前に行う」というルールの実際で出たアクションと似たようなアクションが必要です。

振り返ってみてのまとめ

振り返ってみてのまとめです。

• いくつかの壁を乗り越えることができ、いくつかの新たな壁を認識することができた
  • 1人だと後回しにしてしまいがちな行動を、チームの約束事による強制力で後回しにすることを防ぐことはできた
  • 一気に進もうとすると全く進めないが、少しずつ進もうとすると進む
    • Try はひとつだけにすると取り組める
    • deprecated な定義を利用するコードの移行も、一気に進めると影響範囲も広く検証にかける工数も大きくなってしまうが、本来行いたかった修正のついでだと、新たな影響範囲を考慮することもなく無理せず deprecated なコードの参照を消すことができる
  • 知識不足による課題への対策は必要
• 一回設定するだけでは改善がすぐに止まる（新たな壁を認識することができない）ので、ワーキングアグリーメント自体の振り返りも必要

ワーキングアグリーメントを設定する前と比べて、確実にチームやコードは良くなっている自信があります。今後もチーム状況や外部要因を考慮しながら、価値を届け続けるチームでありたいなと思います。

もちろん、ワーキングアグリーメントが全てを解決するわけではありません。しかし、今すぐにでも始められ、チームで話し合って決めるのでお互いの価値観を知るきっかけにもなります（話し合う前に信頼関係が構築されていた方がスムーズなので、もしかするとジョハリの窓や偏愛マップ、ドラッカー風エクササイズなどいくつかのワークショップを行った方がいい可能性はあります）。

導入しておらず、もやっとした気持ちを抱えているチームがあれば、 1 つだけでもワーキングアグリーメントを設定してみてはいかがでしょうか？

明日の株式会社ビットキー Advent Calendar 2024は、maruware が担当します。