はじめに
こんにちは。弁護士ドットコム株式会社エンジニアの砂川です。 社名と同じ弁護士ドットコム事業本部の開発部でエンジニアリングマネージャをしています。
弁護士ドットコムではいくつかのプロジェクトチームに分かれてそれぞれのミッションに取り組んでいます。 その中で今回は掲題の Working Agreement 1 2 を作成しながらチームビルディングをしていった話をご紹介します。
導入
Working Agreementってなに？
Working Agreement とはチームで仕事をするときの約束事を書いたものです。会議をいつ行うのか、流れはどのように実施するか、実装時の確認フローはどうするのかなど。チーム活動をするうえで必要なルールを Agreement（同意事項） としてまとめたものになります。主にスクラム開発の文脈で出てくることが多いですが、 Working Agreement 自体はスクラムの一部ではないのでどんなチームでも取り入れることが可能です。
以下 スクラム実践入門 P189より抜粋
このような、スクラムチーム全員が合意したルールのことを「ワーキングアグリーメント」と呼びます。ワーキングアグリーメントにはどんなルールを記載してもかまいません。たとえば、日々の出社時間、ミーティングの進め方ドキュメントの保管場所などが考えられるでしょう。ワーキングアグリーメントはスプリントレトロスペクティブのたびに見直しましょう。
スクラムそのものについては本記事では解説しません。スクラム開発をやったことがない、もしくはあまり詳しくないという場合は、Webで公開されているスクラムの大原則 Scrum Guides をご確認ください。
導入の背景
2021年6月に社内のプロジェクトチームへと参加することになりました。当時のエンジニアのチームリーダーがプロジェクトを抜けることとなったため、入替えでの参入でした。このときのチームは以下のような状態でした。
- ディレクター（プロダクトオーナー）、エンジニア、デザイナーと多職種で構成されている
- 経験年数の浅いメンバー比率が高くフレッシュ感がある
- 4月に形成されたチームであり、走り出して2か月が経過している
- 大きめの組織変更があったため、半分くらいのメンバーは今回のチームではじめましての関係性
チームの状況について引き継ぎを受けたところ「チームとしてはまだまだうまくいっていないと感じている、課題はたくさんある」とのことでした。毎週KPT（Keep Problem Try）法を用いてふりかえりを実施していましたが、一時的や部分的に改善されることはあってもなかなか根本的な解決へ繋がっていない状態でした。
毎週新たな改善案自体は生まれているので、それを上手くチームに蓄積してゆける仕組みがあれば良いと思い、 Working Agreement の導入をすることにしました。
導入の流れ
KPTの実施実績があったため、その流れを活かすことにしました。KPTでTRYとして出たものを Working Agreement に追記していくようにします。 3
KPTによるふりかえりはGoogle Meet を繋ぎながら miro（レトロスペクティブツール）上で作業をするようにしました。
esa（ドキュメント管理ツール）でチームのWorking Agreementのページを作成し、ここで出たTRYの結果を蓄積してゆきます。miroで完結させても良かったのですが、ドキュメント管理ツールのほうが定期的に確認するのには手軽で良いなと思いました。
ページ構成は以下のような形にしました。
# XXXチームWorking Agreement ## これはなに？ - Working Agreement とは何かについて書く ## 運用ルール - Working Agreement 自体の運用ルール ## チームの Working Agreement（同意事項） - TRYとして実行して効果の見られたもの、今後も継続して実施していくものを追記していく - 適宜セクションわけすると見やすい ## 現在TRY中のもの - チェックリスト形式でTRYの項目を記述 - 週次で確認をしてTRYが実行できたらチェックをする
実践
導入初期
はじめて追加されたAgreement（のうちの1つ）は以下のようなものでした。
## デイリースクラム（朝会）運用ルール - 時間は15分とする - ファシリテーターは持ち回り制とする - ファシリテーターはタスク管理ツールのアクティブスプリントの画面を共有しながら進行する - 言うべきこと - 昨日したこと - 今日やること - 困っていること
これを見てどんな感想を持ったでしょうか。「簡単すぎる」「わざわざ書くほどのことでもない」と思う方もいるかも知れません。しかし実際の現場では「相談したいことがあるけどどこの場でやれば良いのかわからない」「朝会だとみんなの時間を奪ってしまうので躊躇われる」などの声がありました。あるメンバーは「朝会は相談などには適した場」だと思っていましたが、別のメンバーの考えは違いました。人の考えは思ったよりも各自それぞれです。そういった認識齟齬を防ぎ、チームとして 共通認識 を作るためにはどんなに小さなことでも Working Agreement にきちんと明文化しておくのが良いと思います。 4
また 具体的 にすることも大事でした。例えば「ミーティングの開始時刻に人が揃わず遅れがち」という課題が有り「遅れないようにする」という対策を考えたとします。間違ってはいないはずなのですが、そこには遅れないための具体的なアクションをどうすればよいのかは含まれていません。「ミーティングは開始時刻の一分前に入室する」などの具体的な要素を入れたほうが実践をしやすく改善に繋げやすかったです。TRYやルールに落とし込む際にはなるべく具体的にするように心がけました。
当時チームには朝会などの定例ミーティングはいくつか設定されていましたが、実際にそれぞれをどう運用したら良いのか理解度や認識がバラバラになっていました。そこでまずはそれぞれの会議体の役割やそこで何を話すべきなのか、どのように進めるかについて共通認識を作ることにしました。初期はとにかくチームが上手く回るように、ミーティング・チームの運用やタスク管理のルールなどが追加されることが多かったです。
追加されたルール例
※一部実際と内容を少し改変しているものがあります
| Problem | Try | ルール |
|---|---|---|
| スプリントプランニングに時間がかかり予定の時間をオーバーしてしまう | プランニングと別にリファインメント（プロダクトバックログを整理する活動）を行いタスクを具体化しておくようにする | 毎週火曜日14:00〜15:00にリファインメントを実施する |
| タスクのスプリント繰越が発生している | 繰越タスクに★マークを付けて状況を可視化する | タスクを繰り越す際にはチケット名の先頭に★を追記しておく |
| ワクチン接種などもあり各自の休みの状況を把握しづらい | 勤怠共有用のカレンダーを作成して勤怠スケジュールを可視化する | お休みの予定を勤怠カレンダーに 名前：休み 形式で登録する |
導入から3か月
チーム運用のルールが整ってきて、完全にどうしたらいいかわからないという事態はあまりなくなってきました。
この頃から Working Agreement への追記やチェックなどの運用管理の作業を持ち回りで行うようにしました。もともと朝会などの司会は週替わりで回すようにしていたので、その流れと合わせるようにした形です。
はじめから持ち回り制にしたかったのですが、進め方の型ができる前に持ち回り制としても混乱を招くと思い、最初は自分とプロダクトオーナーのみで管理をしていました。段々と型が出来てきたところで、持ち回り制へと移行するようにワンクッションを置きました。 結果としてこのハイブリッドのやり方はスピード感と安定性を両立するのに良かったなと感じています。
最終的に目指す姿は 課題を解決する ことではなく 課題を解決できるチームをつくる ことです。そのためには特定の誰かではなくチームとして対応できる体制を作っていく必要があります。各自が運用を担当することで Working Agreement をより自分（たち）のものとして取り組めるようになりました。ここでようやっと 課題を解決できるチーム を目指すためのスタートラインに立てたのかなと思っています。
Working Agreement へ追加されるルールはタスクの進め方に関するものが増えてきました。これらの課題はこの頃に発生したものだけではなく、初期から存在していたなぁと感じるものも多くあります。チームの地盤つくりの課題が解決出来てきたことで、やっと対応する順番が回ってきたんだなと感じました。
追加されたルール例
※一部実際と内容を少し改変しているものがあります
| Problem | Try | ルール |
|---|---|---|
| 見積りの精度が良くない、見積り値がいつも同じような値になってしまう | チーム内でStory Pointの基準を握る | チームのStoryPoint基準に従って見積りを行う |
| レビュー依頼が特定の人に偏りがち | ランダムアサインbotを作る | レビューは原則としてランダムbotを利用してアサインする |
| 施策での情報が各種ツールに散らばってしまう | Jiraにしかない情報がないようにする、最新の情報は必ずesaに追記する | 施策の情報はesaに集約する。デザインツールなど他のツールを利用している場合は必ずesaにリンクを貼っておくようにする |
導入から半年
状況の変化により不要になるルールが出てきました。例えば『毎週リファインメントを行う』というルールを以前追加したのですが、チームがサービス領域に詳しくなり話し合うべきポイントも明確になったことにより、リファインメントの時間をとらなくても、スプリントプランニングの枠内で話し合えば十分になっていました。
そこで最新の状況に合わせてこれまでに追加されたルールの精査を実施し、不要なものの整理を実施しました。Working Agreement をある程度の期間運用していくと、定期的にこういった作業は必要になりそうです。
追加ルールは、以前よりも少し細かいものが増えました。既存のルールの詳細化や追加や変更、特定のケースの際の対応なども出てくるようになりました。
追加されたルール例
※一部実際と内容を少し改変しているものがあります
| Problem | Try | ルール |
|---|---|---|
| Working Agreementに現在は不要なルールがある？ | 一度棚卸しをして整理する | 四半期ごとにWorking Agreementの状態を確認し整理を実施する |
| 実装レビュー待ちで時間がかかることがある、ランダムのため複数のレビューが同時にあたってしまい一時的にレビューで手一杯になることがある | 手持ちのレビューが多い場合は別の人にアサインし直してもらうようにコミュニケーションを取るようにする | レビューを複数同時に抱えるときは他の人に回してもらうことを検討する |
| タスクのスプリント繰越が多い | スプリントを2週間にする | スプリントの期間は2週間とする（これまでは1週間） |
スプリント期間について補足。毎週金曜日はTech Focus Dayという負債解消のための活動をしているのでプロジェクトの稼働時間は週に4日でした。Tech Focus Dayに関しては 弁護士ドットコムでの技術課題への向き合い方 -Tech Focus Day- - 弁護士ドットコム株式会社 Creators’ blog を参照ください。
導入から一年
チーム運用は自然に回せるようになりました。途中メンバーの入れ替えなどもありましたが、 Working Agreement に明文化されたルールが存在しており、それをベースに説明ができるのでオンボーディングがしやすかったです。
この頃には項目も増え、 Working Agreement のメンテナンスはだいぶコストが増えたなと感じました。半年の項に書いた整理の作業もちょっとサボり気味でした。ボリューム感の参考に下記は1年経過時の Working Agreement の目次です。
ふりかえりでは、過去に出たものと似たような課題が繰り返し出ることがありました。これは以前のTryが解決策になっていなかったことも考えられますが、1つの課題に対して原因がいくつもある様なケースもありました。例として『見積りの精度』に対する課題に関しては
- 見積りの数値基準が明確になっていない
- それぞれ能力が違うので見積りの予想に幅ができてしまう
- 人間は経験したことのない作業に関して正確に見積りができない
など、いくつもの原因が考えられます。どれも間違いではないのですが、1つだけを解決しても課題が完全には解消されません。課題として顕在化するたびに原因を特定し対策を打っていく必要があるんだなと感じました。
追加されたルール例
※一部実際と内容を少し改変しているものがあります
| Problem | Try | ルール |
|---|---|---|
| 実装にかかった時間が見積りから大きくずれてしまった | 必要に応じて調査チケットを切る | チーム内に知見のない領域に関する実装の場合は、まず調査を実施するようにする |
| ブランチ戦略が難しいことがある、コンフリクトが起きてしまった | masterにマージして問題ないものは切り出してマージするようにする | 開発ブランチを育てすぎないmasterにマージできるものは積極的にマージするように |
まとめ
1年間 Working Agreement を育てながらチームビルディングをしてきた気付きは下記のとおりです。
- 単純なことでも意外と 共通認識 になっていないことが多かった
- 追加するルールはチームに必要であればかんたんなことでも何でも良い、 明文化 は大事
- TRYやルールは 具体的 なアクションがわかるようにする
- ときには少数で、ときにはみんなで進めていくと、早く遠くへ行ける
- Working Agreement は定期的に整理をする必要がある（でもやっぱ忘れることもある）
- ルール数が増えてくると整理のコストはだんだんと上がってくる
- 課題に対して単独の対応では解決できなかったことも 対応を積み重ねる うちに改善できることがある
チームではいまだに毎週さまざまな改善案が出てきますし、まだまだこれからも成長途中です。しかしながら一年前に比べると、自律的に活動できるチームになったなぁと感じています。その甲斐もあってか、先日の四半期総会ではベストチーム賞をいただくことが出来ました。
ここまで一年間 Working Agreement を作りながらチームとして歩んできた経験と気付きを書いてきました。成功したところだけきれいに書こうかなとも思ったのですが現実にちょっと大変だったりうまく行かないこともあったのでそれもちらほらと書いてみました。私たちのチームの経験がどこか別のチームビルディングの参考になれば幸いです。
- 作業合意 | Atlassian↩
- Working agreements are a powerful teamwork tool. Here’s why - Backlog↩
- Working Agreement へ項目を追加していく方法は自由なので、相談する、ブレインストーミングで出すなどチームに適した方法を用いると良いと思います。↩
- 実際相談内容によっては話が長くなってしまうようなケースも有るので、そういった場合には朝会の二次会を用意してそちらで実施するようにしました。↩
