2026年9月4日、Microsoft がAIを使った開発の進め方をまとめた、という趣旨の日本語記事がはてなブックマークのテクノロジーのホットエントリに入った(GIGAZINE)。見出しは「AIでチーム全体を速くする」開発術。
導入前と導入後の数字が載っているのだろうと思って、元記事を開いた。数値は1つもなく、原文の中心にあったのは、個人が速くなってもチームは速くならなかったという失敗の共有だった。
原文に書いてあること
発端は Microsoft Inside Track が2026年9月3日に公開した記事だ(Microsoft)。原文でいちばん強い言い方をしている箇所は、成果の報告ではない。
We quickly identified that improving the individual productivity of a developer was not resulting in a boost to team productivity. That was our hard lesson.
開発者ひとりの生産性を上げても、チームの生産性は上がらなかった。それが痛い教訓だった、と書いてある。GIGAZINE の記事もここを落としておらず、「個人の生産性向上がチームの生産性向上につながらなかったことが大きな教訓だった」と訳している。本文まで読めば、原文と日本語記事の間に食い違いはない。
距離があるのは見出しと原文のほうだ。「チーム全体を速くする開発術」と読むと、速くなった結果が測られたように見える。原文にあるのは、速くならなかったので進め方を変えた、という順序の話だった。
仕様を中心に置く手法については、こう書かれている。
Spec becomes the shared source of truth for the entire team. Instead of handing requirements from one group to another, everyone collaborates
要件をグループからグループへ手渡すのではなく、仕様を全員の参照点にする。効果ではなく、進め方の説明だ。
見つからなかった数字
原文を読み返して確かめたのは、次の3点が書かれていないことだった。
- 導入前後で生産性がどれだけ変わったかの数値
- 対象になったチームの数や人数
- 取り組みの期間。時間に関する記述は “About a year ago” だけ
自分は数字を探しに行って、見つけられなかった。これは Microsoft が隠しているという話ではなく、そもそも測定結果を出す記事ではない、ということだと思う。Inside Track は自社の取り組みを紹介する場で、査読付きの報告ではない。
ただ、この記事を根拠として社内に持ち込むと、話が変わる。「Microsoft が効果を確認した」として使うには、確認した数値がここにない。
もう1つ見落としやすいのが、主体の範囲だ。原文の主語は Microsoft Digital で、これは Microsoft の社内IT組織を指す。Windows や Azure を作っている製品開発部門全体の話として読むと、範囲が広がりすぎる。
確度ごとの整理
ここまでで確かめたことを、確度ごとに分けておく。
| 主張 | 確度 | 根拠 |
|---|---|---|
| 個人の生産性向上がチームの生産性向上につながらなかった | 確認済み | 原文の “That was our hard lesson.” を含む段落 |
| 仕様を全員の共有の参照点にする進め方を採っている | 確認済み | 原文の “Spec becomes the shared source of truth” |
| 主体は Microsoft Digital という社内IT組織 | 確認済み | 原文の記述 |
| 取り組みは約1年前から | 報道と原文の双方にあり | 原文 “About a year ago”、GIGAZINE も同じ表現 |
| チーム全体の開発が速くなった | 未確認 | 原文に測定結果の記載がない |
| Microsoft の他部門でも同じ進め方を採っている | 未確認 | 原文は Microsoft Digital についてのみ書いている |
表の下2行が、見出しから受ける印象と原文の差にあたる。速くなったかどうかは、原文からは分からない。
Spec Kit との時期の重なり
もう1つ、読み始める前の予想が外れた点がある。仕様を先に書いてAIに投げる進め方を、Microsoft が新しく提唱したのだと思っていた。
実際には、GitHub が2025年9月2日に Spec Kit というツールキットをオープンソースで公開している(The GitHub Blog)。同じ記事に、この進め方の定義も書かれている。
Instead of coding first and writing docs later, in spec-driven development, you start with a (you guessed it) spec.
先にコードを書いて後からドキュメントを書くのではなく、仕様から始める。Spec Kit は /specify、/plan、/tasks というコマンドを提供していて、GitHub Copilot だけでなく Claude Code や Gemini CLI でも使えるとされている。
Microsoft Digital の記事にある “About a year ago” は、この公開時期とおおむね重なる。2026年9月の記事を新しい方法論の登場として受け取ると、1年分ずれる。
社内に持ち込む前に
この話を自分のチームで使うつもりなら、確認しておくとよいことを並べておく。
- 元記事を開いて、数値が載っていないことを自分で確かめる。二次記事の見出しではなく原文を見る
- 主体が Microsoft Digital であることを添える。製品開発部門の事例として紹介しない
- 手法そのものを試すなら、Microsoft の記事ではなく GitHub の Spec Kit のドキュメントを読む。コマンドと手順はそちらにある
進め方として筋が悪いと言いたいわけではない。仕様を共有の参照点に置く考え方は、自分にも納得のいくものだった。引っかかったのは、まだ測られていないものが、測られたかのような形で流れてくることのほうだ。
なお、GIGAZINE の記事は本文で hard lesson を訳出しており、要約として誤っているわけではない。見出しは短くする以上どこかを落とす。落ちた部分が今回はちょうど、根拠の有無だったということになる。