自分たちの行動を整理するツールを作ってみたが上手くいかなかった話

## 書く内容

私たちはユニバ株式会社のチーム「Z1」として活動しています。今回の記事では、チームで開発した自社ツール「Z1ppy」の運用について、その成果と課題を振り返ります。
反省話と成仏してくれ〜記事です。
ちなみに私は Z1 の チームリードをしています。

書くこと
- 動機や Z1ppy の説明
- 実際使ってみた様子
- 上手くいかなかったこと
- 使わないでみた時の感想
- 分析 / 次のトライ

書かないこと
- 技術的な詳細。すごい特殊なことはしていないので、書かないです。

FB としてほしいこと
- 自分たちなら合いそうとか、そういうのがあれば
- 共感などあれば

## 背景と同期

Z1ppyを開発した動機には、主に2つの大きな理由がありました。

- 新入社員向けの教育
- チームの活動をより豊かにしたい

という2つの大きなモチベーションです。

**新入社員向けの教育**
これは非常にわかりやすい理由ですね。
Z1ppy は TODO 系のアプリケーションに属するので学習にはもってこいの課題でした。
ちょうど新しい子が入ったのもあっていっちょやってやるかという動きでした。

**チームの活動をより豊かにしたい**
Z1 は秋葉原にオフィスを持っていつつもリモートワークが中心です。
コミュニケーション以上にチームで仕事をどう進めていくかはとても重要な課題です。
その対応のアプローチの一つが Z1ppy 開発を行いました。

## Z1ppyの概要

Z1ppyは、プロジェクトの月間目標と1週間の個人目標を記入し、共有するアプリケーションです。

**主な機能**

- プロジェクトの概要を記入することができる。
- プロジェクトに参加しているメンバーは、各自の1週間の行動目標を宣言できる。
- 過去の1週間との比較を行い、行動を改善・見直すためのUIを提供する。

Z1ppy は半年 ~ １年ほど Z1 で利用し活用していたのですが、課題点が見えたので運用停止状態になりました。
この記事を書くことを通して振り返りながら区切りをつけたいと思います。

## Z1ppy が目指した世界

当時のチーム向け説明資料にこう書きました。

![Pasted image 20240619161603.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/68729/bf4a6151-d175-ca2f-0490-837735f8319b.png)

![Pasted image 20240619161354.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/68729/e98e96e5-0312-3d6f-d420-eb3794a20eb0.png)

![Pasted image 20240619161520.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/68729/9e318aeb-760c-3ef3-51c1-26897de26c97.png)

Z1 は 10人程度のチームです。そして受託開発メインの仕事をしています (お仕事待っています！)。チームメンバーは常に複数の案件を抱えています。
我々だけではないと思うのですが、プロジェクトに集中することと、俯瞰して物事を捉えるというスイッチは非常に高コストです。
その俯瞰の部分を取り扱うのを **Z1ppy** に任せる！という気持ちで制作をしました。

タスクベースで考えるのではなく、ありたい姿をゴールにしましょう。というのを書きました。
いわゆる、XX を終わらせる。というようなアクティブな表現にしてほしかった。というのが狙いでした (ただしここら辺が現実との差になると後で知る)。

タスクの細かい管理はプロジェクトチームにお願いするね！という割り切り方を当時はしていました。
あくまで Z1ppy は俯瞰した図を見るためのツールとしての立ち位置にしようとしたのです。


また、 Z1ppy を通してプロジェクトを見ることで、プロジェクトの不健全さも見ることができると考えました。

![Pasted image 20240619162017.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/68729/e66bf7f9-215f-8674-20c6-89d6205c1838.png)

上記のように定義し、週一回の MTG で不足した状態を把握する行為が、プロジェクトの不健全な状態を浮き彫りにしてくれる。と期待していました。

週一回の宣言の後は、それぞれのプロジェクトで 1週間集中して頑張ってね。最後に毎月のゴールと比べて失敗したら目標を修正しましょう。

以上が Z1 (というか PO の私) が考えたアプローチでした。

結果として運用停止したので、この考え自体が間違っていた。。。というわけではないと信じたい！
と思ってしまうのですが事実として俯瞰と集中の関係を上手く捌ききれなかった。というのが Z1ppy が理解させてくれたことでした。

自分が書いた資料を改めて見ると当時と今を比較することができて面白いですね。

## 出来上がったもの

これらの思想を喧喧学学話し合いながら Z1ppy は完成しました。

細かい機能は省いてメイン機能を画面ごとに紹介していきます。

- Planning
- Weekly Projects
- Project

についてお話しします。
(運用を停止してからだいぶ期間が経ったのもあり、データがほぼ入ってないです。)

![Group 4.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/68729/da3f088e-fe9d-080e-1c04-a6ce06084179.png)

Planning 画面では、その週の目標を書くことをフォーカスします。
自分がアサインされているプロジェクトの先週の状態を見ながら今週の着地点を書くことができます。

![Group 5.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/68729/34269948-881d-d45f-c421-e11c1b1782f3.png)

Weekly Project 画面では 各人が書いた今週の目標などをプロジェクト単位でサマリします。
ここでプロジェクトのリードは思い描いている着地点とずれがないか、進行自体に問題がないかを考えます。

![Group 7.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/68729/54a97ba7-2ab0-d461-84b2-2869854a77d4.png)

Project 画面では プロジェクトの概要と、各月の着地点を書けるようにします。

基本的に目標を入れていないものであったり、予定を超過したものはエラーとして扱い、データの修正を促すような UI にしています。

割とえいやーと作ったツールにしてはよくできているように思えます (自画自賛というかデザイナの人本当にすごい)。

## 実際の使用感と問題点

ここからが本題です。

Z1チームではこのツールを使用し、毎週月曜日の午前中に1時間の定例会議を行っていました。
初期段階では、プロジェクトの一覧を確認することで新たな気づきが得られるというポジティブな運用ができていました。しかし、次第にフラストレーションが溜まるようになりました。

以下まとめです

**運用していくうちに気づいた大きな違和感**

- 抱える案件が少ない人にとっては暇な時間になりがち
	- アサインが多い人・少ない人というのがチーム内にはありました。投資的なプロジェクトには専任してもらってリソースをほぼ投資してもらっています。このようなプロジェクトでは比較的プロジェクト内で目標管理が完結しているのもあって、そういう人にとっては自明な会議になっており、Z1ppy に書いてもなという態度になっていました。
	  (ちなみにそのプロジェクトはアジャイルでやっている。)
- 入れる内容に差がある
	- 目標という書き方になったときに、Github などの issue をそのまま入れる人が複数人いました。当初の Z1ppy ではその管理はプロジェクトの中でやってほしいという考えもありましたが、書き味としてはそちらの方が合っているというのが実態でした。その上で同じような内容を書くのも面倒だなという認識になりました。
- 月の反省会 / 目標設計が間に合わない
	- Z1ppy では 毎月の目標を書いておいて、それに対してタスクを割り振るという思想で設計されていました。ただチームとしてこれをフルで実践できるプロジェクトは多くありませんでした。単純にリソースが足りていないというのと、チーム全体で仕組み化できていないのが大きな理由だと思います。目標設計が崩れると雪崩式に他のプロジェクトにも影響が出てしまい、モチベーションが下がっていくというのがありました。

これらの理由が時間経過とともに溜まってきて、惰性の運用になっているのを感じました。

なので
**一旦使って見るのやめて困ったら必要だし、困らなかったらもっと合う運用があるんじゃない？**
と言って一旦使うのを停止しました。

(独り言になりますが、やる・やめるの判断はプロダクト開発においてすごい大事なことですよね。今回は辞めるという判断をしました。Z1 では割と極端な選択を取ろうと努力しています。)

作った側として残念な気持ちもある一方で、チームとして正しい選択をしないとなという気持ちでした。

## 停止後の状況

運用を停止してみた結果。

運用を停止した結果、**大きな問題は発生しませんでした** (ちょっと悔しいかも)。各プロジェクトが独自に頑張ることで、大きな問題は回避できているのが現状です。

ただ大きな問題が出なかった一方で気になる点が出てきました。

- 他案件・他人に関して無関心
	- 案件間の情報交換が行われる機会が失われたので、チームなのに他の案件の情報がわからない、わからないので手伝えないという状態ができました。
	- また技術的な相談の機会も相対的に少なくなったと思います。
- 稼働のコントロールへの責任が個人へ
	- 基本的に稼働のコントロールが個人ないし、特定のプロジェクト間で融通を直接話して解決してもらう方向へシフトしました。

これらは、個人の活動においては問題もさほど出ないのですが、チームとしては大きな課題であるなと私は捉えました。

当然と言えば当然の結果なのですが、わりとツールと自分たちの生活において、何がベストな選択肢なのかと考えさせられます。

## 分析 と次へのトライ

今回の経験を通して、Z1というチームとして重要なことが幾つか見えてきました。

- タスクベースの管理の方がしっくりくる
	- エンジニアリングとしてはタスクをこなす！という行為にフォーカスして自分を管理する方が都合がよさそう。
- 全体ペアワーク時間を増やす
	- Z1 では Gather というツールを使って、リモートながらも一緒の空間を体験するということにお金を使っています。このサービス上の空間で一緒に作業を行う。というのを増やしたいと思います。
		- 実際にこちらはトライ済みで、Z1ppy を辞めた以降に出たチームとしてネガティブな雰囲気も少し改善の方向が見られています。
- リードのより良い仕組み化
	- 基本的にチームの誰もがリードをできる仕組みを作らねばならないということですね。シニアというか歴が長い人がこの立場になることが多いのですが、もう少しタスクベースの管理に寄せて、誰もが実行できる形にしたいと思います。
- 毎月の反省会の仕組み化
	- ここはチームとして投資せねばなるまいと思いました。この記事を書いて思ったことでもあります。アジャイルのような頻度で回せるかはわからないですが、チームとして必要だと思っています。学びがないと所属して働く意味ないですもんね。

## 感想  - Z1ppy どうするの？

基本的には停止なのですが、この記事を書いてみて、やはりある種あっている部分もあるよなぁと未練がましく思ってしまうのです。

もし使ってみたいなという方があれば是非連絡ください。

おそらく
- リードという存在がしっかりいる
- リードとしてメンバーに能動的に発言してもらいたいと思っている
- 幾つかの案件をしているメンバーがいる

みたいなチームの人に使ってもらえると大変喜ばしいことだなと思います。
あとこういうプロダクトやチームマネジメントの悩みの話を聞きたいので是非何か機会があれば参加させてください！

以上、作ってみたものの上手くいかんかったプロダクトの供養記事でした。