8人から4人、しかしチームは倍になった——AIネイティブ・アジャイルチームの一日

8人が4人になった。しかし解雇ではない

あるチームが、8人から4人になりました。 普通なら人員削減のニュースですが、このチームは違います。 抜けた4人は解雇されたのではなく、新しく分裂したもう一つのチームを率いています。 組織全体で見れば、チームの数はむしろ倍になりました。

以下は、そういうチームの一日を描いた、一つの理想形（アイデアルタイプ）です。 実在の企業の事例報告ではなく、 前回の記事で扱った 「AI-Native Agile Manifesto」の6原則や、 TDDに関する前々回の記事の議論を、 もし実際のチーム運営に落とし込んだらどうなるかを具体化した思考実験として読んでください。 それでも、この解像度まで具体的に描くと、見えてくるものがあります。

朝：エージェントの夜間作業をレビューすることから始まる

メンバーが出社してまず開くのは、昨夜のPR（プルリクエスト）一覧です。 前日の終わりに方向づけした3つのタスクが、それぞれ実装として上がっています。 テスト、型チェック、セキュリティスキャン、パフォーマンス回帰—— 機械的に判定できることはすべて、人間が見る前に通過済みです。

だから人間のレビューは、実装の一行一行を読み解く作業ではありません。 問われるのは、もっと質の高い判断です。

「この抽象化は半年後も耐えるか」「この仕様解釈は、本当にユーザーの意図に合っているか」

前々回書いたように、 テストという合格基準が先にあるからこそ、 この「動くかどうか」の確認を人間が肩代わりする必要がなくなっています。 人間に残るのは、機械には委ねられない設計判断とプロダクトとしての正しさだけです。

デイリースクラム：5分で終わる、報告のない朝会

デイリースクラムは残っています。しかし中身は別物になりました。 「昨日やったこと」の報告はありません——全員がダッシュボードで見えているからです。 話すのはただ一つ、「今日、人間の判断が必要な箇所はどこか」だけです。

スプリントは廃止された。しかしリズムは残った

スプリントという2週間の箱そのものは廃止されました。 それでも、週に一度ステークホルダーと動くプロダクトを触りながら方向を決める場—— 旧スプリントレビューの後継となる儀式は残っています。

ただし、そこで見せるものが変わりました。 「完成した機能」ではなく、並行して作られた複数のバリエーションです。

「A案とB案、両方動くものがあるので、ユーザーテストの結果と一緒に見てください」

これは会話としてはもう珍しくありません。 実装がほぼ無料に近くなった世界では、 一つの仕様を議論で決め打ちするより、複数案を並行して作り、 実データで選ぶ方が速く、かつ正確だからです。

見積もりの会議も消滅しました。理由はシンプルです。 作って確かめる方が、見積もるより速いのです。 代わりに練度を測る指標になっているのは、 「これはエージェントに任せられる仕事か、人間が張り付くべき仕事か」という 仕分けの精度です。

レトロスペクティブ：「話し合い」から「チームというシステムのデプロイ」へ

数あるセレモニーの中で、このチームが最も重く扱っているのがレトロスペクティブです。 振り返りの対象は、プロセスだけではありません。 エージェントへの指示の出し方、コンテキストの整備状況、評価基準の質まで含みます。

そして何より特徴的なのは、改善のアウトプットの形です。 「次からはこうしましょう」という口約束（チームの申し合わせ）ではなく、 リポジトリ内の設定ファイルやガイドラインファイルの更新として、直接コミットされます。

つまりプロセス改善そのものがバージョン管理され、 エージェントの振る舞いに即座に反映される。 レトロスペクティブは「話し合いの場」から、 「チームというシステムをデプロイする場」へと役割を変えています。

ドキュメントとコードの境界が溶ける

アーキテクチャ決定記録（ADR）、仕様、制約条件—— これらはすべて構造化されてリポジトリに置かれています。 それは同時に、エージェントが参照するコンテキストであり、 新メンバーのオンボーディング資料でもあります。

長年アジャイルの現場を悩ませてきた「ドキュメントが陳腐化する」問題は、 ここでは自然に解消されています。 ドキュメントがエージェントの動作に直結しているため、 間違ったドキュメントは、間違った実装として即座に顕在化するからです。 ドキュメントは書いて放置される成果物ではなく、 常に検証され続ける「生きた知識」になっています。

このチームの誇りは、速度ではない

ここまでの変化は、すべて「速くなった」という話に見えるかもしれません。 しかしこのチームが本当に誇っているのは、速さそのものではありません。

「間違った方向に全力疾走しない」こと。

実装がほぼ無料になった世界では、間違った機能を作ることのコストも、 皮肉なことに極めて低くなります。だからこそ彼らが守っている一線があります。 ユーザーからの学習を経ていない機能は、本流に入れない。 作れることと、作るべきことは別だという当たり前の規律が、 実装が高速化した今こそ、チームの品格を分けています。

前回の6原則との対応

この一日の描写を、前回の記事で紹介したAI-Native Agile Manifestoの6原則に当てはめると、 理論が具体的な現場の姿としてつながって見えてきます。

おわりに

8人だったチームが4人になり、組織のチーム数が倍になった—— この変化を「効率化による人員削減」と読むこともできます。 しかしこのチームが体現しているのは、もう少し違うものです。 意思決定できる人間の数がボトルネックだった組織が、 そのボトルネックを解消して、より多くの方向に同時に賭けられるようになった、 という変化です。

スプリントという箱がなくなっても、儀式は消えませんでした。 むしろレトロスペクティブのように、重みを増した儀式さえあります。 変わったのは、儀式が守っていたものです。 「計画通りに進んだか」から、「正しい方向に、正しい速さで学び続けているか」へ。 それは、Agileが最初から大切にしてきた問いそのものかもしれません。