「ちゃんとやって」と思ったら AI チャンス！ 人間同士のゼロサムゲームから抜け出そう！

こんにちは、鈴木です。

プロジェクトメンバーに対して「ちゃんとやって」と思ったことはあるでしょうか。特にプロジェクトマネジメントなど管理系のタスクが多く発生する役割のときに、「チケットの本文をちゃんと書いてくれていない」、「期限の設定が漏れている」、「ちゃんとやってー・・」と思ったことが。

「指摘するのは精神がすり減るなぁ」、「自分で直しちゃおうかな」「いやでも作業の肩代わりするのは釈然としないし」「そもそも最初からちゃんとやってくれたら問題ないのに」、モヤモヤモヤ・・・、ということが。

この記事では PM 業務に AI を使うことでモヤモヤを乗り越えた話をします。そのカギとなるのは、頭の中で発生する「人間同士のゼロサムゲーム」を捨てることでした。

「ちゃんと」の状態は知っている

「ちゃんとやって・・」と思うとき、実は自分自身が「ちゃんと」の状態を分かっていることが結構あります。

  • issue の本文が書かれていない
    • → この前の MTG 議事録を見れば分かる
  • issue の期限が設定されていない
    • → 今のイテレーションのタスクだから来週火曜日が期限だと分かる
  • issue の担当者が設定されていないけどステータスが進行中になってる…
    • → issue の更新者や Pull Request を出した人を見れば分かる

正解が分かっているからこそ、なおさら「ちゃんとやって・・」という感情が芽生えるのかもしれません。

頭の中で発生する「人間同士のゼロサムゲーム」

「ちゃんとやって」というモヤモヤの正体は何でしょうか。それは、頭の中で発生する「人間同士のゼロサムゲーム」だと思います。

相手がちゃんとやっていればチクチク言う必要もないし、言いづらいからと黙って自分で直すということもない。本来は他者が負うべき負担が自分に降りかかっていると感じてしまう。自分が損してる気分だ！

しかし、人間はミスをします。忘れることもあれば、面倒くさがって後回しにすることもあります。プロジェクト全体で考えると誰かがやらなければならない。だから、「ちゃんとやって」とチクチク言うか、言いづらいから黙って自分が直すか選ばなければならない。どちらを選んでも自分が損してる気分になる！

少し落ち着いて考えると、これってゼロサムゲームと同じですよね。A さんがちゃんとやらなかった。その分だけ A さんはプラス。自分はチクチク言うか、黙って直す。その分だけ自分はマイナス。頭の中でゼロサムゲームが発生している。

しかも、このゼロサムゲームは「人間同士のゼロサムゲーム」。

そこで AI の出番です。AI を使って仕組みを作ります。例えば、Agent Skills を作ったり、プロンプトを定期実行させたり。「ちゃんと」の状態を知っているなら出来るはずです。「人間同士のゼロサムゲーム」を解消しましょう。具体例をいくつか紹介します。

PM 業務を支援する Agent Skills を作成する

以下のような Agent Skills を作成しました。

---
name: pm
description: |
    Project Management スキル
    このスキルは "/pm" で実行する
    このスキルは明示的に指定された場合のみ実行する
---

...

## Skills

### Issue 作成時の親（エピック）紐づけ

- Issue 作成時、親となる Issue（エピック）がある場合は **本文の「## 親 Issue（エピック）」セクションに `#123` のように番号を記載**する。
- **Cursor**: `.cursor/commands/make-issue-template.md`（および make-feature-request / make-bug-report）の手順に従うと、親番号を聞いて body に記載し、CLI の場合は addSubIssue でリンクする。`gh auth login` で認証。**Devin**: GitHub Apps で `GH_TOKEN` などを設定すれば同じ CLI 手順で実行可能。認証が無い場合は GitHub Web UI で作成すること。
- GitHub の Issue 作成 UI でテンプレートを使う場合、同セクションに `- #1539` のように記載すると、`.github/workflows/link-issue-to-project.yml` が addSubIssue で親子関係を自動設定する。

### list-orphan-issues (親を持たない issue を表示する)

 1. /list-orphan-issues を実行する

### move-to-dev2-children ("開発 #2" の子に移動する)

 1. 移動する issue の指示を受ける
 2. 指示された issue を https://github.com/.../.../issues/392 の子に移動する

### assign-project (プロジェクト未設定の issue を "〇〇" プロジェクトに移動する)

 1. /list-no-project-issues でプロジェクト未設定の issue を取得する
    - 対象の issue が無ければ処理を終了する
 2. プロジェクト未設定の issue を "〇〇" プロジェクトに移動する
    - コマンド: gh project item-add <project-id> --owner ... --url <issue-url>
    - <project-id>: プロジェクト URL から取得する
    - プロジェクト URL: https://github.com/orgs/.../projects/68

## Commands

### /list-orphan-issues
...

### /list-no-project-issues
...

汎用性を捨てているところがポイントです。「https://github.com/.../.../issues/392 の子に移動する」や「https://github.com/orgs/.../projects/68」のように固定の URL を書いています。

このままでは他のプロジェクトで使えませんが、それは解決したい課題ではないので問題ありません。このプロジェクトの、今目の前で発生している具体的な課題を解決することが目的です。

定型化するほどではない作業は都度 AI に依頼する

細かい作業を Slack 経由で Devin に「よろしく！ #777」のように依頼することが多くありました。

Devin に大量のタスクを依頼する

このようにすると、担当者未設定のまま issue のステータスが変わっていくという現象が頻発します。

ブラウザで GitHub を開いているときに誰かが 10 並列で Devin にタスクを投げる。すると担当者未設定の 10 個の issue が目の前で突然動き出す。In Progress になり、しばらくすると Done になる。怪現象だと思いました。

そういうときは AI に対して一言、「担当未設定の issue があるので Pull Request をマージした人を担当者に設定して」。とても楽です。

Devin に issue の担当者を設定してもらう

まとめ

プロジェクトマネジメントとは、自分では完全にコントロールできない物事を抱えながらプロジェクトを成功に導く仕事です。AI という強力な味方ができた現在、プロジェクトマネジメントのスタイルを見直すタイミングなのだと感じます。

そこでカギとなるのが、頭の中で発生する「人間同士のゼロサムゲーム」に気付くことでした。それを AI を使って解きほぐす。AI を活用しつつ、人間も変わらないといけない、という学びがありました。

弥生では一緒に働く仲間を募集しています。
www.yayoi-kk.co.jp

弥生のエンジニアに関する note 記事もご覧ください。
note.yayoi-kk.co.jp


弥生エンジニアの公式Xのフォローもよろしくお願いします！