こんにちは。PIVOTでソフトウェアエンジニア、スクラムマスターを務めて(いる|いた)@tawachanです。

この記事では、ソフトウェアエンジニアの役割が「作業者」から「エンジニアリングマネージャー」へ変化する中で、開発プロセスがどう変わったかを共有します。私たちのチームがスクラム寄りの運用からカンバン寄りの運用へ移行した経緯の記録です。

私たちのチームは、もともとアジャイル開発を実践する中で、厳密なスクラムフレームワークに固執するのではなく、常にチームに合う形を模索してきました。Notionのスプリント機能を活用し、各種スクラムイベントを運営するなど、スプリントベースの計画を重視していました。

しかし、AIによる開発支援が現実のものとなり、全員がAIをメンバーに持つエンジニアリングマネージャーというビジョンが掲げられると、働き方の前提が大きく変わります。この記事は、その前提の変化に気づき、開発プロセスを見直していった記録です。

AI時代の到来：業界全体の変化

開発ツールのAI化は進んだ：エージェントの時代へ

Ubie社がDevinの活用事例を公開したことで、日本でも「AIエージェントが実際に開発現場で使える」という実感が広がりました。テストコードをCIが通るまで自律的に書かせる、という実例は衝撃的でした。

これまでのGitHub Copilotのような補完系のツールから、エージェントとして自律的にコードを書くツールへの転換点でした。Devinをはじめ、Cursor、Windsurf、Clineなど、エージェント的にコードを生成するツールが次々と登場しました。

そしてGitHub Copilot自身もAgent Modeをリリース。自律的にタスクを実行してくれる機能が、ついに公式ツールにも入りました。

AIとペアプログラミングする、というよりAIに実装の大部分を任せる、いわば「バイブコーディング」の時代^[1]になりました。この変化が、開発のあり方を大きく変えていきました。

私たちのチームでも、他社と同様に、こうした新しいツールが登場するたびに積極的に試しています^[2]。個人で興味がある人が率先して情報を収集し、「これはよさそう」というものはチームでも柔軟に試せるようにしています。

開発そのものの効率化については、ソフトウェアエンジニアなら各自で試行錯誤しているはずです。これらのツールをどう活用するか、どう開発効率を上げるか、という話はまた別の機会に譲ります。

次のボトルネックは開発プロセス全体

開発部分がAIで最適化されていくと、次に見えてくるのは開発以外のボトルネックです。

迅速な意思決定：合意形成や方向性の決定に時間がかかり、実装着手が遅れる
タスク管理の手間：チケット作成や整理に時間がかかり、開発を待たせてしまう
品質担保：テストやレビュー、リリースの承認待ちで完了が遅延する
チーム運営：従来のプロセスや役割分担が開発速度に追いつかない

AIを使えば個人の開発速度は上がります。しかし、チームとしての動き方がAI時代に最適化されていないと、そこがボトルネックになるのは当然の流れです。

私たちのチームの挑戦

新しいビジョン：全員がAIをメンバーにもつ"エンジニアリング"マネージャーへ

この状況を受け、2025年6月頃、私たちのプロダクトマネージャーが以下のビジョンを掲げました。

「全員がAIをメンバーにもつ"エンジニアリング"マネージャーへ」

人間のソフトウェアエンジニアは少数だが、AIという部下を使いこなして効率的に動いていく。この考え方が、私たちのチームの方向性となりました。

では、これは何を意味するのか？

このビジョンについて、私たちは次のように捉えています。

従来：ソフトウェアエンジニア = 作業者

従来は、自分で実装する「作業者」でした。

一つのタスクに集中する必要がある
まとまった時間の確保が生産性を左右する

これから：ソフトウェアエンジニア = マネージャー

これからは、AIを使いこなす「マネージャー」です。

大きなタスクをやりつつ、細かい作業はAIに並行処理させる
状況が変わったら、リアルタイムにAIへの指示を変更する

この前提変更により、働き方の制約が変わります。集中時間の確保や差し込み対応のコストが相対的に下がり、より柔軟な対応が可能になります。

AIファーストチームという問い

では、この前提変更を踏まえて、プロセスをAIファーストで考えるならどうなるか？

ソフトウェアエンジニアが「マネージャー」として動くなら、チームのプロセスもそのビジョンに合わせて再構築する必要がある。単にAIツールを導入するだけでなく、AI活用を前提としたチーム運営に変えていく。

この問いは、AI時代を迎えた多くの組織が持ち始めているのではないかと思います。

私たちもまだ模索中ですが、これらのボトルネックに対して段階的にアプローチしています。この記事では、その取り組みの一要素として、タスク管理の手間とチーム運営の最適化にフォーカスしたスクラム寄りの運用からカンバン寄りの運用への変更について共有します。他の要素（意思決定や品質担保）への取り組みについては、また別の記事でお伝えする予定です。

従来の開発プロセス：スプリント重視

ソフトウェアエンジニアの働き方が変わったことで、アジャイル開発の方法論そのものに課題感が出てきました。そして、徐々に手を入れていく流れになっていきました。

私たちのチームは、これまでスクラム寄りの運用で開発を進めてきました。しかし、「マネージャー」として働くようになった今、本当にこのプロセスが最適なのか？徐々に模索していくことになりました。

従来の開発スタイル

私たちはこれまで、スプリントという定期的な計画と実行のサイクルで開発を進めてきました。

1週間スプリントで運用
スプリント計画で何を完成させるか確約
見積もり（SP）やリファインメントを実施
作業者として集中するための環境を確保

作業者として働く前提では、この方法論は理にかなっていました。1週間集中できる環境を確保し、その中で確実に成果を出す。これが重要でした。

何が変わったのか：感じ始めていた課題

しかし、マネージャーとして柔軟に立ち回れるようになると、この前提が変わります。

マネージャーとしてのパフォーマンス最大化

マネージャーになったことで、パフォーマンスの出し方が変わりました。

自分が集中するだけではパフォーマンスが最大化できない：部下（AI）をどう使いこなすかが重要
不確実な状況では、より早い検査・適応がベター：長期の固定計画より、短いサイクルでの調整

計測の意味がブレる

AIの使いこなし方は、マネージャーの采配と同じように個人差が大きく変動します。その結果、以下のような課題が見えてきました。

「作業者としてのベロシティ」を測る意味が薄れた：何を計測しているのか不明確に
タイムボックスで定点観測する価値が減った：AI活用の方針次第で作業スタイルが根本的に変わる
- 例えば、Claude Code/Codex CLIで同期的に直列で作業する場合と、Devin/Codexで非同期に並列処理させる場合では、生産性が大きく異なる
- 加えて、活用方法自体がまだ安定しておらず、ツールも日進月歩で進化している
- こうした状況では、活用方法が定着するまで定点観測の意義が限定的になる

スプリント固定計画のコストが逆転

事前に「このスプリントでこれをやる」と決める固定計画が、かえってコストになっていました。

計画変更のコストが実装コストを上回る

「次のスプリントで」と説明する労力 > AIに説明してやってしまう労力
タスクを切ってチケットに起こす労力と、AIに指示を出す労力が同等になってきた
- 「計画すること」と「実装すること」の境界が曖昧に
- 計画に時間をかけるより、実行してしまった方が早い

スプリントという枠が作業を間延びさせる

1週間のスプリントという枠があると、実際は3日で終わる仕事でも1週間かけてペース配分してしまう
「今週はこれをやればいい」という意識が働き、作業が膨張する（パーキンソンの法則的な現象）
早く終わっても、運用上「スプリントに入れたものを差し込まない」という文化があり、次に進みにくい

計画変更の心理的ハードルが高い

急な要望が来ても、「次のスプリントで」となりがち
スプリント途中で計画を変えるのは抵抗感がある
KPIに効く重要な施策があっても翌週に回してしまう

「スプリントに入れたタスクを差し込まない」という運用ルールは、本来チームを守るためのものです。しかし、AI時代の開発速度においては、この運用自体がコストになっていました。差し込みを受け入れて柔軟に対応した方が、実感として成果にもつながる場面が増えてきました。

私たちのチームの状況（少人数・AI活用が日進月歩）においては、スプリントベースの固定計画という点が合わなくなってきました。

新しい開発プロセス：できるものから柔軟に進める

これらの変化を受け、私たちは運用を大きく変更しました^[3]。

変更の概要

今週やり切るべきタスクを全て固定・確約するのをやめました。大枠の方向性は握りつつも、詳細なタスクレベルでの確約をやめ、各メンバーのマネージャーとしての裁量を増やしました。

具体的には、以下の3つをやめました。

スプリント期間の固定をやめた：継続的なフローへ
事前のSP見積もりをやめた：見積もりより実行を優先
ベロシティの計測をやめた：変動が大きく意味が薄れたため

代わりに、次のようなシンプルな運用に変更しました。

Inboxに入ってきたタスクから優先度順に着手
できるものから柔軟に進める
完了したら次へ

変更の効果

各ソフトウェアエンジニアが、マネージャーとして部下（AI）をどう使うか、何から手をつけるかを判断します。ただし完全に委ねているわけではなく、都度チームで最低限の確認を行い、着手してみて出てきた課題や対応要否をチーム内で共有しながら、プロダクトの状況変化を意識して常に柔軟にウォッチしています。

これは、プロダクト開発の優先度・ビジネスインパクトを理解して動けるソフトウェアエンジニアがチームに揃っているからこそ実現できています^[4]。メンバー全員がビジネスを理解しているため、一定の裁量を持った意思決定を柔軟にメンバー間で行えています。

例えば、機能開発の前に技術的負債を解消した方がよいと判断したら、そちらを先にやることができます。従来は、こうした負債解消タスクもスクラムイベントで説明し、優先度を合意する必要があり、劣後しがちでした。

継続的なフローであれば、完了次第すぐに次へ進めます。優先度が変わればすぐに切り替えられます。

検査・適応のサイクルは維持

一方で、週次での検査・適応のサイクル（レビュー・振り返り・方向性の合意）は維持しています。作ると確約するサイクルは外しましたが、チーム全体で何を作ったか確認し、次に何をすべきか合意する場は残しています。

言い換えれば、作業サイクルをスプリントから切り離し、検査・適応のサイクルだけを週次で維持した形です。

週次で継続していること

週次のプロダクトレビューとプランニングは継続しています^[5]。

チームとしてのゴール設定
やるべきことの優先度の合意
作ったものの確認と認識合わせ

ただし、これらはタスクレベルの詳細な計画ではなく、荒いレベルでの方向性の共有です。

この運用がうまくいっている理由（少なくとも今のところは）

この時代にどんなチームにも合うわけではないので、文脈補足として、私たちのチームでうまくいっている理由・要因を挙げておきます。

Design Docによる大枠の理解

大きな機能開発時はDesign Docを作成
チーム内全員でレビュー
リファインメント的なものを手厚くやらなくても大枠が理解できている

各プラットフォーム一人体制

iOS、Android、Webそれぞれ、コアな意思決定に関わる正社員が一人ずつ責任を持つ（副業・業務委託で入っていただいている方はいます）
コミュニケーションパスが少なく、メンバー間の調整事項が最小化されている
各自が裁量で判断し、プラットフォーム間の齟齬は都度コミュニケーションと週次レビューで解決

ビジネス・プロダクトを全員で理解する取り組み

これも一つの課題として取り組んでいる点です。

プロダクトマネージャーだけでなく、ソフトウェアエンジニア全員がビジネス視点を持てるよう定例で議論
- プロダクトのグロース戦略、追うべきKPI、その数値目標
- プロダクトがビジネス的にどういう状況に置かれているのか
そうした理解を踏まえて、各自が実装する機能・実装の仕方・動き方を判断できる
日々チームを強くしていく継続的な取り組みの結果として、このスタイルが実現できはじめている

こうした状況のため、細かいタスクの計画は不要であり、チーム全体の方向性を合わせる場があれば十分と判断しています。

WIP制限については、まだ探っている最中

カンバン手法の重要な要素としてWIP（Work In Progress）制限があります。同時に進める作業数を制限することで、ボトルネックを可視化し、フローを最適化するものです。

現時点では、私たちはまだWIP制限を明示的に設けていません。

AIでどれくらい並列処理できるか、まだわからない
人間側の疲労は確実に問題になる
- バイブコーディングが実用的になってから、人間側の疲労が話題になった^[6]
- 導入初期は特に、我々ソフトウェアエンジニアも強く疲労を感じた
- チーム内で出てきた課題を共有し、自主的に直列で仕事をするなど工夫していた
- 最近は慣れてきたのか問題性は薄くなっているが、燃え尽き症候群のリスクは注視している
確固たるルールにはしていない
- まだ最適解が見えていない段階
- 個人のやりやすいようにという方針

今後、運用を続ける中で見えてきたら、適宜制約をつけていくつもりです。

まとめ：N=1の問題として、自分たちに忠実に

私たちはまだ模索中です。外部環境の変化だけでなく、自分たち自身が使うツールも変化が激しい時代です。

だからこそ、意識的に自分たちの動き方も前例にとらわれず、自分たちが感じていることに忠実に、N=1の問題として取り組み、改善していきたいと考えています。

スクラムもカンバンも、手段であって目的ではありません。このような大きく状況が変わっている時代には、慣例に縛られすぎず、自分たちの状況に適切なものを採用していく姿勢が重要だと考えています。

この記事で紹介した運用も、暫定的なものです。すぐにまた全然別の見解に変わるかもしれません。それでも、今感じていること、今取り組んでいることを共有することで、同じような課題に向き合うチームの参考になれば幸いです。

もし質問やフィードバックがあれば、ぜひコメントやX（旧Twitter）でお気軽に声をかけてください。

脚注

「バイブコーディング」(Vibe Coding)は、Andrej Karpathyが2025年2月に提唱した用語で、本来はAIが生成したコードをレビューせずに受け入れて開発を進めるスタイルを指します。Simon Willisonは「LLMが書いたコードをレビュー・テスト・理解している場合はバイブコーディングではなく、LLMをタイピングアシスタントとして使っている」と区別しています。ただし本記事では、厳密な定義というより、人間が自分でコードを書かず、AIに主導権を渡して開発を進めるスタイルという広い意味で使用しています。私たちのチームでは、アーキテクチャレベルではコードを理解しレビューしていますが、純粋関数などの詳細なロジックは生成されたテストが通っていれば許容する、といった運用をしています。参考: Not all AI-assisted programming is vibe coding ↩︎
週次の勉強会で最近の活用方法を共有したり、デモを見せたりしています。 ↩︎
スクラムというフレームワーク自体を否定しているわけではありません。透明性・検査・適応の原則、定期的な振り返りとレビュー、チーム全体での合意形成のプロセスは今でも重要だと考えています。ただし、私たちのチームの現在の状況（少人数・AI活用が日進月歩・開発速度が安定しない）においては、スプリントベースの固定計画という点を調整する必要がありました。 ↩︎
私たちの会社PIVOTは、プロスポーツチームのような組織を目指しています。多様な強みを持つメンバーが、自立したプロフェッショナルとして協働し、成長と勝利を追求する姿勢を大切にしています。詳細はこちらを参照してください。 ↩︎
本文では触れていませんが、振り返り（レトロスペクティブ）も週次で実施しています。Miroを使ってチームの動き方の改善を継続的に行っています。 ↩︎
AIコーディング支援ツールの活用が進むにつれて、「AIエージェント疲れ」という問題が認識されるようになりました。AIが単純作業を肩代わりする一方で、人間が担当するのは高度な判断や複雑な思考が求められるタスクばかりになり、精神的なエネルギー消費が激しくなること、複数のAIエージェントを同時並行で進めることによるタスクスイッチングコスト、AIが生成したコードのレビューや修正作業など、新たな種類の疲労が生じています。参考: 「AIエージェント疲れ」の原因と対策 ↩︎

Discussion