隙のないチームは、越境でつくる ── AIで空いた時間の使いみち
ハロー！AnotherBallでサーバーサイドエンジニアをやってるTsujiです。
普段はサーバーサイドの開発をやったり、インフラのアラートの深堀りからヤクの毛刈りを嗜んだりしています。
AI活用で生まれた余白をどうするの問題
エンジニアの皆さん、AI活用はどんな感じですか？
AnotherBallも例に漏れず、開発はもちろんそれ以外の場面でも全社的にAIを活用してます！
AI活用が進む“仕掛け” ── 会社をBAKUSOKU化した4つの取り組み
AI活用が進んだ先で思うことは、巷でよく言われる「人間は何をするべきなのか」ではないでしょうか。そしてさらによく聞くのが「利益に貢献する」とか、「本質的な価値を作る」などというものでしょうか。
これまでエンジニアチームの成果指標には、GoogleのDORAが提唱したFour Keys[1]が使われる事が多かったのではないかと思います。
DORAはGoogle Cloudが運営する研究プログラムで、「ソフトウェア開発チームが、速く・安定して価値を届けるには何が必要か」を継続的に調査しています。
しかし、先の話に照らすと果たしてFour KeysがAI時代に現役で有用な指標と言えるかは少し疑問に感じます。
実際、DORA公式も2023年から以下のようにいくつかの変遷を経ています。
- 2023年、MTTRが
failed deployment recovery timeに改名・再定義 - 2024年、5つ目の指標
deployment rework rateが追加され、指標は4つから5つに。群も Throughput / Instability へ再編 - 2025年、レポート名も改称：
Accelerate State of DevOps Report→State of AI-assisted Software Development Report - 出典: DORA’s software delivery performance metrics[2] ／ A history of DORA’s software delivery metrics[3]
指標そのものが「どれだけ速いか」から「どれだけ壊れていないか」へ重心を移している、とも読めます。こうした変化を踏まえると、生まれた余白をさらに開発に費やすのが正解だとは言い切れない気がしてきます。
開発が速くなると価値の提供も速まるのか
ここで疑問の正体について自問自答したいと思います。
先に結論を述べると「開発が速くなっても価値の提供は速くならないから」だと考えています。
皆さんはTHE GOALを読んだことはありますか？名著なのでぜひ会社の経費で買ってもらってくださいね。
こちらの書籍ではTOC（Theory of Constraints）という概念が用いられており、「仕事の流れの中にある制約」に対処しなければ成果に繋がらない、ということを意味します。
つまり、「開発」や「個人」の速度があがったとしても、それが制約でないのであれば組織全体の成果には繋がらない、ということです。
またDORAの話に戻りますが、「局所最適しても全体の流量は改善しない」ことが公式のレポートを見てもわかります。
- 2024年版：AI採用が25%増えると、デリバリのスループット −1.5%／安定性 −7.2%
- ところが同じ調査で個人レベルは軒並みプラス：生産性 +2.1% ／ フロー +2.6% など
- → 個人は速くなったのに、デリバリ全体は速くなっていない。THE GOALの主張と完全に同じ形
- 2025年版：スループットとの関係は負→正に反転。ただし不安定性との関係は負のまま
- 出典: Accelerate State of DevOps Report 2024[4] ／ State of AI-assisted Software Development 2025[5] ／ Announcing the 2025 DORA Report[6]
ただし、これらはサーベイをもとにした相関であって、因果を示すものではありません。それでも、個人の速度とデリバリ全体の速度がずれるという方向自体は、TOCの主張とよく一致しています。
そこでAvvy開発チームでは、スクラムを組み、ツールとしてLinearを使いつつ、独自のカンバンを用意することでボトルネックを発見できる仕組みを作っています。
チームの停滞と優先順位ズレに気づくカンバンをAIで作る ── Chrome拡張とAIコーディングによる可視化の実践
ボトルネックは日々変動するものなので一概にどれ、というのは難しいですが、Avvy開発チームではPdMに難易度、優先度の高い業務が集中するきらいがありました。
PdMの職責の重さ、難しさ
PdMなどの肩書きは組織によって意味する責務が違う場合が多いと思います。
Avvy開発チームにおけるPdMは会社のビジョン、プロダクトの哲学や思想、その期の目標、あらゆる変数を意識しながら抽象的な施策を具体に落とし込むという非常に難しい職責を持っています。
ちなみに抽象度の話はこちらの書籍が非常にわかりやすいのでおすすめです。
単純に考えれば、生まれた余白で手伝えばいいじゃん、となるわけですが、PdMの職責の難易度を考えるとそうも簡単に行きません。
また、仮に手伝えるとしても、主担当であるPdMがプロダクトや人の動きを把握できない状況を作るべきでもありません。
越境とその作法 ── 持ち場を空けない
AIが台頭する以前から常に感じていたことですが、職能横断のチームに大事なのは「職責は明確にする。職能は越える。」ことなのではないかと考えています。
ここでいう職能を越える、はよく「越境」と表現されているものと同じだと思ってください[7]。
そうは言うものの、先に挙げたように越境も簡単なものではありません。そこで、Avvy開発チームにおいて最近自然と越境の場面が生まれたので、その事例の紹介をしたいと思います。
事の発端は、社内向けの管理画面を使っているメンバーから「管理画面の改善案をまとめたから意見がほしい」と声をかけてもらったことでした。
社内向けの管理画面のようなものは、優先度が低いというより、そもそもバックログに載せる機会がないことがほとんどです。誰かがEpicの形に整えて初めて、優先順位をつける土俵に乗る。裏を返せば、整える人が現れない限り永遠に始まらない領域とも言えます。
先ほど紹介したカンバンで見つけられるのは、あくまで載っているものの滞留です。載っていないものは、そもそも見えません。
個人的にも気にしていたところだったので、PdM1名と開発メンバー2名で内容を確認しました。
見てみると、要件と設計をもう少し詰めれば低コストで高い価値を出せそうな内容でした。そこで「これは開発側で要件をヒアリングして、スプリントに入れるものを提案しますね」という話に持っていくことができました。
これは体制としては「開発メンバーが状況を把握してEpicを整え、結論をPdMに返却し、実行まで移す」という構図になります。PdMから始まりPdMに返すという意味では、AIでいうところのSubAgentと同義です。
ここで重要なのは、
- 最終的な判断はPdMに残ったままであること
- PdMが把握した上で開発メンバーが動いていること
- 自分の職責は全うすること
ということです。
特に3つめに関しては越境先であるPdMに対する敬意として絶対に守らなければいけない点です。
僕はアメフトについて全く詳しくないですが、昔から強く共感しているこのポストを引用させてもらいます。
アメリカンフットボールには「オーバーパシュート」というアンチパターンがあり、これは「自分の役割を逸脱してボールを止めにいくこと」なんですけど、社会人プレーヤーとしてこれをやってしまうのは本当に恥ずかしいことですよ。
— 全年齢リツイート先生 (@otiai10) May 26, 2019
逸脱が、ではなく、「チームメートを信頼していない」ことが、です。
自分の見えている範囲に自分のできることがあるとどうしてもやりたくなってしまうものだし、それは良いことだと考えがちですが、必ずしもそうではないと気づかせてくれたポストです。
Beyond Boundariesについて思うこと
僕はAnotherBallのビジョンであるこの言葉が好きで、CTOの@tatsushimに「境界は国境だけじゃなくてチームとかメンバーの間とかあらゆるところにあるから、もっと色んな場面で使うべきです」って話をしたことがあるくらいです。
この記事では越境と、その先にある価値について思うところを書いてきました。
決して簡単ではないし、境界の高さはそれぞれ違うし、越えられない境界、越えなくていい境界、越えてはいけない境界、様々あると思います。
ただ、その難しさを乗り越えてこそ得られる信頼関係だったりとか、成果だったりとか、やりがいみたいなこともあると確信してます。
こうやって越境が積み重なると、チームには穴がなくなっていきます。職責がはっきりしているから誰の担当か迷わないし、職能が重なっているから誰かが手を離しても別の誰かが拾える。隙のないチームって、たぶんこういう状態のことなんじゃないかなと思っています。
「職責は明確にする。職能は越える。」、とりあえずこの言葉だけ覚えて帰ってくれたら嬉しいです！
We’re Hiring
AnotherBallには、「とにかく良いものを作りたいし、良いチームにしたいんだ！」という感じのメンバーがたくさん揃ってます。扉は開いてますよ、話だけでもどうですか？