TesujiAIを使う人が速いだけでは、組織は速くならない
AIコーディングツールを使うと、個人の実装速度は上がります。しかしチーム全体で見ると、レビュー、仕様確認、テスト、リリース、引き継ぎで詰まれば全体速度は上がりません。
竹村也哉が取り組むAI・ゲーム・Web3領域でも、AIを単なる補助ツールではなく、開発工程そのものに組み込む視点が重要になります。
個人最適から工程最適へ
よくある使い方は、
- コードを書かせる
- 文章を要約させる
- バグ原因を聞く
といった個人単位の利用です。
一方、AI駆動開発として考えるなら、
企画 → 要件 → 実装 → テスト → レビュー → リリース
の各段階でAIが何を担当し、どこで人間が判断するかを決めます。
AIに任せやすい仕事
- 既存コードの調査
- 仕様の抜け漏れ確認
- 小さな機能実装
- テストケース作成
- ログ解析
- ドキュメント更新
これらは成果物や検証条件を定義しやすいため、AIへ渡しやすい領域です。
人間が握るべき仕事
一方で、
- 何を作るべきか
- どのリスクを取るか
- どの品質で出すか
- 顧客にどんな価値を返すか
といった判断は、事業や製品の文脈を含みます。
AIが提案できても、責任まで自動化されたわけではありません。
開発速度を測る
AI導入の効果を見るなら、生成コード量ではなく、
- 要件確定からPRまでの時間
- PRからマージまでの時間
- リリース後の不具合率
- 手戻り回数
- 人間が確認に使った時間
を見る方が実態に近くなります。
Tesujiで関係を残す意味
AI駆動開発という考え方と、実際に使うChatGPT、Claude Code、Unityなどを関係として残しておくと、『誰が何をどう使っているか』が見えるようになります。
単なるツール一覧ではなく、実践のネットワークとして蓄積できます。
次の一手
AI開発をさらに進めるなら、今週の実装タスクを10件だけ見て、各タスクについて『人間だけ』『AI補助』『AI主体』のどれで進めたかを記録する。
その上でリードタイムと手戻りを比べれば、AIを入れるべき工程と、むしろ人間が直接やるべき工程が見えてきます。