改めて「デイリースクラム」の重要性と難しさを痛感

「えーっと、昨日は...（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ですが、今後は：

チーム全員分を集計して「スプリントゴール達成リスク」を可視化する
過去のベロシティと突き合わせてアラートを出す

といった機能を追加し、スクラムチーム全体を支援するツールに育てていきたいと思います。