アジャイルチームの約束事、『作って終わり』から『日常に溶け込む運用』へ

# はじめに
　最近私のチームではアジャイルを意識したチームづくりをしており、その1つのプラクティスとしてある **「ワーキングアグリーメント」** を作りました。

 その中でチームとして導入してどうか、そしてそれをどのように運用しているか、せっかくなのでまとめてみようかと思います。

:::note info
下記読者にはちょっとだけタメになるかもしれないです
- アジャイル・スクラムを実践するチームのメンバー
- チーム文化改善や自己組織化に興味がある方
- Slackやスプレッドシート、GASなどでチーム改善用のツールを作ってみたい方
:::


# そもそもワーキングアグリーメントって？ 
そもそもワーキングアグリーメントって何・・・？という方もいらっしゃると思うので、
簡単に説明できればと思っております。（[こちらの記事](https://www.agile-studio.jp/post/apm-working-agreement)が参考になるかと思います！）

簡単に言えば、
***「気持ちよく仕事ができるようにチーム全員で決めたチームの約束事」***
かなと思っています。

チームとして働いている場合、文字としては書き起こしていないものの、
なんとなくの約束事はあるかと思います！

私たちのチームでは
- 毎日のデイリーは15分で終わらせる！
- レビュー依頼のプッシュに遠慮はいらない！
- 良いことに対して良いって言おう！      etc...

みたいなものがあったりします！

こういった約束事を、気づけば忘れてるだったり、誰も守らなくなってしまったり・・・
とならないよう、そして**暗黙の期待とならないように明示的にする**という狙いがあります。


## ワーキングアグリーメントの何がいいか

現状、私の中では１つ大きなメリットを感じています。

ズバリ
**チームの当たり前が定着して、どんどん増えていくってなんかいい**

ということです！（結構マジです）

単純にチームの中で共通理解が強化（解釈不一致が減る）されますし、
**自分たちのチームの当たり前が増える**ことで結束力も強まると思います！

他にも、メリットはたくさんあると思っています
- 新しく入ったメンバーに、チームの約束事をすぐ共有できる
- チームとして決めたものなので、自分たちのチームらしさ・文化の醸成に繋がる
- ワーキングアグリーメントを整理することで、定期的にチームの検査もできる
などなど



:::note warn
注意点として、必ずチーム全員で約束事を決めましょう。
一部の人だけで決めてしまうと、「私は聞いていない」という状況が出かねません。
:::

# 運用方法
もちろん作っただけでは意味がありません。

継続的に見直し、そしてアップデートしていかなければ
形骸化し、**あるにはあるけど誰も意識していない紙切れ**みたいな扱いにもなりかねません。

とはいっても、なかなか継続って難しいですよね。

業務が立て込んだりして、気がつくと2ヶ月、3ヶ月とそのまま放置されてしまうことも
可能性としてはあります。
振り返りのたびに見直そうと決めていても、結局は時間がなく触れられなかったなど

実際に私のチームでも、振り返り自体はするけど、振り返るときに初めて、
「確かにこんな約束事あったなー」みたいに状況となっていました・・・・

ということで、ここは**エンジニアらしく仕組みで解決します！！！**

## どう仕組み化したか

ここからは、実際にどのように仕組み化して運用しているかを紹介できればと思います！

まず作り始める前に、以下２つのことを意識して作りました。
1. 毎日振り返れるような仕組みにしたい。
2. 月末の振り返りでワーキングアグリーメントを検査するために、定量的に判断できる
仕組みにしたい。

基本的には GAS✖️Slack API を活用しています。（便利すぎ）
その上で簡単にMermaid.jsで処理の流れをまとめてみました！（便利すぎ）

（[SlackAPIについてまとまったQiita](https://qiita.com/organizations/slack)もありましたので参考になれば）

``` mermaid
sequenceDiagram
    participant GAS as Google Apps Script
    participant SS as スプレッドシート
    participant Slack as Slack
    participant SlackAPI as Slack API (Conversations, Chat)
    participant User as ユーザー

    Note over GAS: 毎日17時にトリガー発火
    GAS->>SS: ワーキングアグリーメント一覧取得
    SS->>GAS: ワーキングアグリーメント一覧
    GAS->>GAS: ランダムで1つ選択
    GAS->>SlackAPI: chat.postMessage(ワーキングアグリーメント + ボタン)
    SlackAPI->>Slack: メッセージ表示

    Note over User: ユーザーが評価ボタン押下(3段階評価)
    Slack->>SlackAPI: 評価ボタン押下
    SlackAPI->>GAS: payload(押下ユーザー、評価結果、メッセージts等)
    GAS->>SS: 評価結果を書き込み
    GAS->>SlackAPI: chat.update(評価結果反映したメッセージに更新)

    Note over GAS: 毎週金曜日トリガー発火
    GAS->>SS: 過去に送信済みのメッセージts一覧取得
    GAS->>SlackAPI: conversations.replies(tsでスレッド取得)
    SlackAPI->>GAS: スレッド内メッセージ一覧
    GAS->>GAS: 理由（評価の根拠）を抽出 (bot投稿は除外)
    GAS->>SS: 理由をスプレッドシートに追記
```

大まかな流れは
1. 定期的（毎日17時）にワーキングアグリーメントをSlackに通知
   └ 毎日目にする形にすることで、常に意識できる状況を作る。

2. ３段階評価をする
    └ ３段階評価にすることで、定量的に判断できるような仕組みにする。

3. 評価理由をスレッドに書き込む
└ どうしてこの評価にしたのか理由を書き込んでおくことで、振り返る際の要素として活用できる。




![プレゼンテーション ①.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/701865/bec9838c-89bf-6fde-4781-75d061900289.png)

<br>
4. 評価した内容をスプレッドシートに吐き出す
<br>
  └ slack上で「できなかった」「できないこともあった・・・」「できた！！」のどれかの<br>ボタンを押すと、その結果がスプレッドシートに自動的に書き込まれます。（下記画像参照）

評価理由に関しては、毎週金曜日にslackメッセージのスレッドを見にいくトリガーを設定しているので、そこで取得し、スプレッドシートに後付けで出力しています。


![スクリーンショット 2024-12-15 11.27.22.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/701865/97749437-fae6-c1d3-d240-49945b0a2ea9.png)


# 実際に運用してみて
 ワーキングアグリーメントをチームで作った当初は特に運用面の事を考えておらず、
 毎月の振り返りの際に「こここうだったよね〜」のような振り返りをしていました。
 
 ただそうすると、**何をもって達成できた、できなかったかを感覚に頼っていた部分がありました**。そこで、今回仕組み化して毎日目に触れることになったことで、「***意識するきっかけ***」はついたのかなと思っています！

 プラスして、定量的に何が達成できていなかったのか、どんなところが達成できていなかったかを把握できるようになったことで、**改善策を考えたり・NAを取りやすくなった**ように思えます。

 日々の忙しい業務の中でも、**チームとしてのあり方について考える時間を取ってみたい**と思う方はぜひ導入してみるといいのかなと思います！


# 参考文献
https://www.agile-studio.jp/post/apm-working-agreement

https://ishitonton.hatenablog.com/entry/2019/02/14/193423

https://qiita.com/organizations/slack