改めて「デイリースクラム」の重要性と難しさを痛感
「えーっと、昨日は...（Gitのログを見返す）...APIの実装をしてました。今日はその続きです」
毎朝のこれ。この「思い出す時間」と「事実の報告」だけで15分が終わってしまうこと、ありませんか？
本来、デイリースクラムは「報告会」ではなく、スプリントゴール達成のための「作戦会議（再計画の場）」であるはずです。
「過去の事実（Fact）の収集はAIに任せて、人間は未来（Future）と課題の話だけすればいいのではないか？」
そう考え、GitHub、Googleカレンダー、Slackのログを突合して、「日報の下書き」＋「議論すべきリスク」を毎朝自動でサジェストしてくれるBotをPythonで作ってみました。
何を作ったか
毎朝決まった時間に、以下のようなレポートがSlackに届くシステムです。
### 🤖 Daily Scrum Support: 11/21 (木)
**✅ 昨日 (Yesterday)**
* **実装:** 認証トークン失効処理 (PR #1024) → 実装完了・レビュー依頼済。
* **レビュー:** PR #1020 にセキュリティ指摘 (2件)。
* **稼働:** 14:00-16:00 は面接等のため離席。実稼働は4時間強。
**⚠️ 検出された課題 (Blockers)**
* **外部APIの仕様不整合:** Slackでの発言と修正履歴から、ドキュメントとの乖離に時間を取られています。PMへのエスカレーション推奨。
* **レビュー停滞:** PR #1018 (管理画面) が2日間止まっています。
**📢 発言用メモ (Copy & Paste)**
> 昨日は面接などで時間は限られましたが、認証機能の改修（PR #1024）は完了しました。
> **[相談]** 外部APIの挙動が仕様書と合わず工数を使っています。PMに確認依頼したいです。また、PR #1018のレビューをお願いします。
> 今日は、API調査と管理画面のテストを進めます。
単なる要約ではありません。
「コミットが少ない」という事実に対し、カレンダー情報から「会議が多かったから仕方ない」と擁護したり、Slackの発言から「技術的に詰まっているようだ」とリスクを検知したりします。
アーキテクチャ：3つの視点で「1日」を再構成する
私の「1日」を正確に再現するために、以下の3つのデータソースを突合（とつごう）することにしました。
- GitHub (Output): 何を作ったか（コミット、PR、レビュー）
- Google Calendar (Constraint): 時間を何に奪われたか（会議、面談）
- Slack (Context): 何を考え、どこで感情が動いたか（分報、スタンプ）
技術スタックはシンプルに Python + FastAPI (Batch処理) + OpenAI API です。
実装のアプローチ
1. 「事実」を収集する
まずは、AIに渡すためのコンテキストを集めます。
ここでは PyGithub や google-api-python-client を使用しますが、重要なのは「UTC/JSTの変換」と「ノイズの除去」です。
特にGoogleカレンダーの処理は重要です。「進捗が悪い」原因が「サボり」なのか「会議過多」なのかを区別するため、会議時間の合計を算出します。
# カレンダーから会議時間を計算するイメージ
def calculate_meeting_hours(events):
total_duration = timedelta(0)
for event in events:
# "辞退"した会議は除外する等のフィルタリングが必要
if event.response_status == 'declined':
continue
total_duration += event.end - event.start
return total_duration.total_seconds() / 3600
2. プロンプトエンジニアリング：AIに「スクラムマスター」を憑依させる
集めたログをただ要約させても、「昨日は会議と実装をしました」というつまらない文章しか出てきません。
System Promptで、AIに明確な役割を与えます。
System Promptの役割定義（抜粋）:
あなたは優秀なエンジニアチームのスクラムマスターです。
ユーザーの昨日の活動ログ（GitHub, Calendar, Slack）を分析し、デイリースクラムで共有すべき「日報」を作成してください。
特に、「進捗を阻害している要因（Blocker）」や「チームに相談すべきこと」があれば、ログの行間から推測して指摘してください。評価基準:
- コミットが少ない時間帯に会議が入っていれば、それは「正当な理由」として扱ってください。
- Slackで「辛い」「わからん」などのネガティブな感情や、長時間のエラーログ投稿があれば、リスクとして検知してください。
このように「複数のデータソースの相関関係」を見るように指示するのがポイントです。
3. 出力の構造化：Pydantic × Instructor
AIの出力がフリーテキストだと、Slackへの通知を綺麗にフォーマットできません。また、システム的に「アラート」を鳴らす判定もしたいです。
そこで、Pydanticモデルで構造化データとして受け取ります。
from pydantic import BaseModel, Field
class DailyInsight(BaseModel):
summary: str = Field(..., description="昨日の活動の客観的な要約")
meeting_load_hours: float = Field(..., description="会議に費やした時間")
blocker_detected: bool = Field(..., description="進捗を阻害する要因が検知されたか")
suggested_topic: str = Field(..., description="朝会でチームに相談すべきトピック")
motivation_score: int = Field(..., description="Slackの雰囲気から推測されるモチベーション(1-10)")
# OpenAI APIからこの形式のJSONが確実に返ってくる
insight = client.chat.completions.create(
model="gpt-4o",
response_model=DailyInsight,
messages=[...]
)
運用してみてどうだったか
Before
- 自分：「えーっと…（Github見る）…昨日は〇〇機能の実装をしました。進捗は30%くらいです。（以上）」
- チーム：「（なんか進み悪いけど、詰まってるのかな…？）」
After
Botが朝8時にSlackに通知を飛ばします。
🤖 AI Agent:
昨日は会議が合計4.5時間あり、コーディング時間は限定的でした。
その中で認証周りのPRを作成していますが、Slackで「トークンの有効期限がおかしい」という発言があり、ここで手が止まっている可能性があります。
推奨アクション: 詳しいメンバーに朝会で相談時間を設けること。
これを受けてのデイリースクラム：
- 自分：「…と、AIが言ってる通り、実はトークン周りでハマってて。Bさん、後で10分だけ相談いい？」
- Bさん：「OK、そこ癖あるからね。すぐ解決しよう」
- スクラムマスター：「会議多かったから進捗は気にしなくていいよ。ブロッカー解消を優先しよう」
考察
-
「思い出す」認知負荷がゼロになった
朝の脳のリソースを「事実確認」に使わなくて済むのは想像以上に快適です。 -
心理的安全性が高まった
「進捗が出なかった」ことに対して、カレンダーという客観的事実（Fact）がセットで提示されるため、言い訳がましくならずに状況を共有できました。 -
「隠れブロッカー」が見える化された
自分では「まだ頑張れる」と思っていても、AIに「お前そこで3時間詰まってるぞ」と指摘されると、素直にヘルプが出せます。
まとめと今後の展望
「ベターなやり方」を模索する中で、AIを単なる「コード生成ツール」としてではなく、**「チームの透明性を高めるエージェント」**として使う可能性を感じました。
現状は自分専用のBotですが、今後は：
- チーム全員分を集計して「スプリントゴール達成リスク」を可視化する
- 過去のベロシティと突き合わせてアラートを出す
といった機能を追加し、スクラムチーム全体を支援するツールに育てていきたいと思います