--- title: "バトンリレーから、みんなでパン作りへ：AI時代のITチームの働き方" url: https://www.stacklogs.io.vn/ja/keiken/ai-jidai-no-chimu-no-hataraki-kata/ language: ja author: "Nhu Duy Thin (Thinnd)" published: 2026-10-29 updated: 2026-10-29 section: "経験と教訓" tags: ["チームワーク", "AI", "プロセス", "トレンド", "経験"] summary: "多くのITチームが、仕事を何工程にも回す形から、AIアシスタントのおかげで一人ひとりが遠くまで進める小さなチームへ移ろうとしています。会議を重ねる代わりに背景を紙に書きます。ボトルネックは書く工程から確認する工程へ移るため、レビューの決まりと十分なテストが必要です。" license: "Cite with the author name and the canonical URL above." --- # バトンリレーから、みんなでパン作りへ：AI時代のITチームの働き方 > ITチームの中や近くで働くすべての人に向けた文章で、プログラミングの知識は不要です。どの用語にも日常の例による説明を添え、全体を通して「パン屋さん」という1つの絵を使います。 > > これは新しく、速く変わっている流れです。数字は末尾に挙げた公開レポートや調査によるもので、多くはテクノロジー企業自身が発表したものです。「例」と書いたものは、イメージしやすいように組み立てたもので、特定のチームや会社を指すものではありません。 --- ## 要点 - **これまで**は、仕事をベルトコンベアのように流す（分析、設計、開発、テスト、運用）のが一般的でした。**これから**は、AIアシスタントのおかげで一人ひとりがより遠くまで進める小さなチームへ向かう現場が増えています。 - **これまで**は、情報を伝えるために会議を重ねました。**これから**は、「完成とは何か」を書き出し、背景を紙に残す方向です。よい手引きは人にもAIにも役立ちます。 - **これまで**はコードを書く工程がボトルネックでした。**これから**は、読んで確認する工程へ移っています。大規模なデータ分析では、AIをよく使うチームは多くの変更を統合できた一方、レビューにかかる時間も大きく増えました。 - 新しいやり方にも落とし穴があります。レビューが追いつかないこと、1人に1つのアシスタントで意見がばらばらになること、新人の練習の機会が減ることです。GoogleのDORAレポートはAIを増幅器にたとえています。よいチームはよりよく、混乱したチームはより混乱して聞こえます。 - 手短に言うと：小さなチーム、明確な作業の説明、共通の手引き、レビューの決まり、そしてコードの行数ではなくチーム全体の成果を測ることです。 --- ## むずかしい言葉をやさしく | 用語 | やさしい意味 | |---|---| | **ハンドオフ**（バトンの受け渡し） | 1人が自分の分を終えて次の人に渡すこと。リレーでバトンを渡すようなもの。 | | **ボトルネック** | 全体の中でいちばん遅い場所。瓶の首のように、どれだけ速く注いでも、水は首の速さでしか出ない。 | | **エージェント**（自分で作業を進めるAI） | 答えるだけでなく、プロジェクトを読み、何か所も直し、動作を試すといった一連の作業を自分で進めるAI。 | | **スペック**（作業の説明書） | 何をするか、「完成」とは何かを書いた1ページ。人とAIが同じように理解できる。 | | **コードレビュー** | 1人目のコードを、製品に入れる前に2人目が読むこと。売る前にケーキを味見する人のようなもの。 | | **コンテキストファイル**（AI向けの手引き） | AIが作業前に読む、プロジェクトの決まりを書いたファイル。よくある名前はAGENTS.mdやCLAUDE.md。 | | **増幅器** | 入ってきた音を、美しい旋律でも雑音でも大きくする装置。 | --- ## 1. これまでのやり方：ベルトコンベアのパン工場 5つの机が一列に並んだパン工場を思い浮かべてください。1つ目の机は注文を受け、2つ目は生地をこね、3つ目は焼き、4つ目は飾り付け、5つ目は箱に詰めます。各人は1つの机が得意で、自分の分しか見えません。多くのITチームは、まさにこのように働いてきました。分析、設計、開発、テスト、運用と、工程ごとに担当が分かれ、チケットや文書で受け渡しをします。 このやり方には、もっともな理由があります。管理しやすく、誰が何をするかが明確で、コードを書くのが遅くて手間だった頃には、仕事を分けるのが理にかなっていました。問題は、机と机のあいだの隙間をよく見たときに現れます。 ### 1.1 1枚のチケットが5人の手を渡る（例） 小さな依頼：「注文ページに注文キャンセルのボタンを追加する」。 | 曜日 | 起きること | 誰が作業し、誰が待っているか | |---|---|---| | 月曜 | 分析が要件を書く（半日） | 後の工程が待つ | | 水曜 | 設計が画面を描く（半日） | 分析は終了、開発が待つ | | 金曜 | 開発者が作る（1日） | 設計は終了、テストが待つ | | 翌週火曜 | テストが半日で気づく：「キャンセルしたら返金は？」要件に書かれていない | 開発が回答を待つ | | 翌週木曜 | 開発が半日で修正し、チケットを閉じる | 待ち時間が終わる | 要件を書いてからチケットを閉じるまで9営業日で、そのうち実際の作業は約3日、待ち時間は約6日です。これはイメージしやすいように組み立てた例で、数字は例示ですが、「作業は少なく、待ちが多い」という形は、何工程ものプロセスで働いたことのある人にはおなじみです。 ### 1.2 連絡の線の謎 人が増えるほど、話し合わなければならない組が増えます。n人のあいだの組（連絡の線）の数は、nかける（n引く1）を2で割った数です。計算してみましょう。 | 人数 | 連絡の線の数 | |---|---| | 3 | 3 | | 5 | 10 | | 10 | 45 | | 20 | 190 | 5人から10人へ2倍にすると、線はほぼ4倍になります。これが、業界で有名な「ブルックスの法則」の理由の一部です。『人月の神話』（フレッド・ブルックス、1975年）から導かれたもので、遅れているプロジェクトに人を足すと、新人の指導が必要になり、やり取りの数が急に増えるため、かえって遅れやすいというものです。この法則には異論もありますが、「料理人が多すぎると互いにぶつかる」という絵は誰にでも伝わります。 ### 1.3 これまでのやり方の限界 - **待ち。** 仕事が作業される時間より、列で待つ時間のほうが長い。 - **背景の脱落。** 受け渡しのたびに「なぜ」の一部が置き去りになる。次の人は意図ではなく文字どおりに作る。 - **遅いフィードバック。** 誤解は最後の工程でようやく見つかり、直すのに最も費用がかかる。 - **責任の薄まり。** 誰でも「自分の分は要件どおりだった」と言える。 - **隙間をふさぐための会議。** 1ページ書けば済むのに、情報を回すだけの会議が多い。 --- ## 2. 新しいやり方：小さなパン屋とAIの助手 次は、職人が3人の小さなパン屋を思い浮かべてください。各人がケーキを最初から最後まで焼きますが、そばには手の速い助手がいて、生地をこね、試しに焼き、レシピを書き留めてくれます。助手はとても速いものの、ときどき砂糖と塩を間違えるので、職人が**どのケーキを作るかを決め、毎回味見をして、それから売り場に出します**。 これが、多くのITチームが向かっている流れの絵です。公開レポートから単純化したもので、実際には現場ごとにやり方が違います。 ### 2.1 流れのしるし - **AIが基本的な期待になる。** 2025年4月、ShopifyのCEO（トビ・リュトケ）が社内メモを送り、のちに自分で公開しました。内容は、AIを上手に使うことは全員への基本的な期待であること、人員を増やす前にAIでできない理由を示すこと、AIの利用に関する質問が評価に入ることです。これは1社の方針であり、一般的な決まりではありません。 - **新しいコードの一部はAIが書く。** 2024年10月、AlphabetのCEO（サンダー・ピチャイ）は、Googleの新しいコードの4分の1以上をAIが生成し、エンジニアがレビューして承認していると述べました。この数字が「入力中の自動補完」を数えているのか「AIが丸ごと書いた部分」を数えているのかは不明で、2024年の数字です。 - **人とAIアシスタントのチーム。** Microsoftの2025年版Work Trend Indexは「フロンティア企業」を描いています。チームは人とAIアシスタントで構成され、各人は「エージェントボス」（アシスタントの上司）の役を担い、硬い組織図は目標に応じて変わる「ワークチャート」に置き換わります。これはテクノロジー企業が実施し、自社製品も宣伝している調査です。 - **AIはすでに業界に広まっている。** GoogleのDORA 2025レポート（約5,000人のソフトウェア専門職への調査）は、約90%が仕事でAIを使っていると示しています。 1つ1つのしるしだけでは何も証明できませんが、合わせて同じ方向を指しています。より小さなチーム、より多くの工程を担う一人ひとり、そしてチームの一員として数えられるAIです。 ### 2.2 人がすること、AIがすること | 作業 | 人が持つことが多い | AIに任せる（そして人が確認する）ことが多い | |---|---|---| | 何を作るか、なぜかを選ぶ | 人 | AIが案を出す | | 「完成とは何か」を書く | 人 | AIが下書きを手伝う | | コード、テスト、文書を書く | 人が見直す | AIが最初の版を書く | | 読んでレビューする | 責任を持つ人 | AIが小さな誤りを先に探す | | リリースを決める | 人 | 任せない | | 間違ったときに責任を負う | 人 | できない | ### 2.3 会議の代わりに文書 AIアシスタントがいると、あるものがとても価値を持ちます。**紙に書かれた背景**です。AIは会議に出ず、「私の言いたいことは分かるでしょう」を聞き取れません。書かれたことしか知りません。だから、新しいやり方のチームには、よくこの2つがあります。 - **作業の説明書**（スペック）：何をするか、誰が使うか、「完成」とは何か、やらないことは何かを書いた1ページ。 - **AI向けの手引き**（コンテキストファイル）：プロジェクトの決まり、動作の試し方、禁止事項を書いたもの。AIへの指示であり、新人のためのプロジェクト資料にもなります。 小さな手引きは、次のようなものです。 ```text プロジェクト：注文ページ 動作確認：npm test 決まり：関数名は英語、利用者向けメッセージはベトナム語 禁止：レビュー担当なしで /payments フォルダを編集しない 完成とは：テストがあり、画面の写真があり、レビュー担当が読んだこと ``` ### 2.4 小さな隊の、ある午後（例） 上と同じ「注文キャンセル」の依頼を、新しいやり方の3人チームが扱った場合です。 | 時刻 | 起きること | |---|---| | 13:00 | ラン（担当者）が、「キャンセルしたら返金は？」を含む1ページの説明を書く | | 13:30 | AIアシスタントが、プロジェクトの手引きに従って画面、コード、テストを作る | | 15:00 | ミンが読んでレビューし、AIが決まりを取り違えた2か所を直す | | 16:00 | チーム全員で動くものを見て、リリースを決める | 全体で約1回の午後で、2週間ではありません。これは組み立てた例で、すべての機能がこのようにすっきりするわけではありません。要件があいまいなほど、また支払いや安全に近いほど、より多くの目が必要です。 --- ## 3. 新しいやり方にも落とし穴がある 小さなパン屋も完璧ではありません。触れておきたい落とし穴が4つあります。 ### 3.1 2倍の速さで焼いても、味見する人は1人のまま Faros AIの「AI Productivity Paradox」レポート（2025年7月）は、1,255チームの1万人超の開発者のデータを分析しました。AIをよく使うチームは、約21%多くのタスクを終え、約98%多くの変更（プルリクエスト）を統合しました。しかし変更1件あたりのレビュー時間は約91%増え、変更の大きさは約154%増え、1人あたりのバグは約9%増えました。会社全体のレベルでは、AIの利用度と成果指標のあいだに明確な関連は見られなかったとされています。 注意して読んでください。これは測定ツールを売るベンダーのデータで、相関であって因果とは限らず、私は要約記事を読んだだけで原典は読んでいません。それでも絵は分かりやすいです。**職人が2倍の速さになっても味見する人が1人なら、味見待ちの列が伸びます**。ボトルネックは作る工程からレビューの工程へ移ります。 ### 3.2 AIは増幅器 GoogleのDORA 2025レポートは、AIの主な役割を**増幅**だと述べています。しっかりした土台（自動テスト、速いフィードバック、明確なプロセス）のあるチームは恩恵を受け、もともと混乱しているチームはより混乱します。拡声器のようなものだと考えてください。上手な歌い手は素晴らしく、音程の外れた歌い手は外れたまま、より大きく聞こえます。チームにテストと明確なプロセスがなければ、AIを足しても事態がよくなるとは限りません。 ### 3.3 1人に1つのアシスタント、1つにつき1つの意見（例） 2人の職人が、それぞれ自分のアシスタントに「注文はどう保存すべき？」と尋ねます。ランは「リレーショナルな表を使う」、ミンは「ドキュメントストアを使う」と言われます。どちらももっともらしく、各人が自分の答えに従い、2週間後にはシステムに2種類の保存方式ができています。これは、AIが聞くたびに違う答えを返しうることから来ており、[AIを鵜呑みにしてはいけない理由](https://www.stacklogs.io.vn/ja/gijutsu/ai-wo-unomi-ni-shinai-riyu/)で詳しく述べています。 **避け方：** 共通の決定（データの保存方法、命名の決まり）は共通の手引きに書き、すべてのアシスタントが同じ情報源を読むようにします。決定を個人のチャットの中に置かないでください。 ### 3.4 新人はどう学ぶのか 以前、新人は小さな仕事で仕事を覚えました。軽いバグの修正やテストの作成です。AIがそうした小さな仕事を素早く片づけると、新人は練習の機会が減るかもしれません。これについて確かなデータはまだ多くないため、結論ではなく、開かれた問いです。チームが試せることの例として、新人にAIが書いたコードを説明してもらう、レビューに参加してもらう、練習用に小さな仕事を少し残しておく、があります。 --- ## 4. 新旧の比較 | | これまで：ベルトコンベアの受け渡し | これから：AIと働く小さなパン屋 | |---|---|---| | 仕事の流れ | 多くの工程、多くのチケット | 1人または小さな隊が、アイデアから動くものまで進む | | チームの規模 | 大きく、工程ごとに分かれる | 小さく、各人が複数の工程を担う | | 伝え方 | 会議と長い文書 | 短い作業の説明と共通の手引き | | ボトルネック | 工程間の待ち | レビューと確認 | | 主な限界 | 待ち、背景の脱落、遅いフィードバック | レビューが追いつかない、決定がばらばら、新人の練習が減る | | 好まれる問い | 「誰の担当？」 | 「誰が味見して、誰が責任を負う？」 | --- ## 5. チームが試せる7つのこと 1. **チームを小さく保つ。** 1つの製品や領域につき2人から5人。連絡の線が少なくて済みます。 2. **始める前に「完成とは何か」を書く。** 1ページで、やらないことも含めます。 3. **人とAIで1つの手引きを持つ。** 共通の決定は、1か所に1回書きます。 4. **レビューの決まりを作る。** 小さな変更は素早く、お金や実データに触れる変更は2人で見ます。小さくて読みやすい変更を優先します。 5. **チーム全体の成果を測る。** コードの行数や1人あたりの変更数ではなく、アイデアから顧客の前で動くまでの時間と、すり抜けたバグを測ります。 6. **AIの使い方を共有する。** 週に10分、どの工夫が効き、どれがバグを招いたかを皆で話します。 7. **新人が練習する余地を残す。** 手を動かす練習用の小さな仕事と、皆でコードを読む時間を残します。 --- ## 6. バランスの取れた見方 この文章を「AIと働く小さなチームは常に優れている」と読まないでください。データはまだ初期のもので、多くはAIに利害のある企業の調査やレポートによるもので、チームによって結果は大きく違います。増幅器の絵のとおりです。安全面や法的な制約の大きい大規模な製品には、今も多くの目が必要で、変わるのは組織の仕方かもしれません。 かなり確かに思えるのは、**下書きを作る費用は下がっているが、確認する費用はそれに伴って下がっていない**ということです。だから、チームワークの技能は、はっきり書くこと、丁寧にレビューすること、背景を共有することへ重心が移っていきます。これは[開発者という職業の変遷](https://www.stacklogs.io.vn/ja/kosatsu/kaihatsusha-no-ayumi/)で述べた方向とも重なります。 --- ## 7. チームへの10の質問 1. 小さな作業が、アイデアから顧客の前で動くまでに何日かかり、そのうち待ちはどれくらいか。 2. 典型的な作業には、いくつの工程と受け渡しがあるか。 3. 定例会議のそれぞれを、1ページの文書で置き換えられないか。 4. チームの「完成」はどこに書かれているか。 5. 共通の決定は、共有の文書にあるか、個人のチャットの中にあるか。 6. 誰がレビューし、1日に何件見られ、レビュー待ちの列は長いか短いか。 7. AIの下書きを信頼できるだけの自動テストが、チームにあるか。 8. どの変更に2人の目が必要か。 9. 新人に練習用の小さな仕事はあるか。 10. 問題が起きたとき、チームは「誰が間違えたか」と聞くか、「プロセスのどこがすり抜けさせたか」と聞くか。 --- ## 8. 結論 かつては、どの工程にも費用がかかったので、チームをベルトコンベアのパン工場のように組みました。AIが下書きを安くしたいま、多くのチームが別の形を試しています。小さなパン屋で、一人ひとりがより遠くまで進み、そばにAIの助手がいる形です。待ちも背景の脱落も減りますが、重さは味見、つまり読むこと、レビューすること、責任を負うことへ移ります。 拡声器を思い出してください。AIは、混乱したチームを優れたチームに変えるのではなく、チームがすでに持っているものを大きくします。アシスタントを足す前に、土台（明確な作業の説明、テスト、共通の手引き、レビューの決まり）を整えましょう。バトンを渡すより、みんなでパンを焼くほうが楽しいのですが、それは売り場に出す前に店全体で丁寧に味見をするときに限ります。 --- ## 参考資料 数字は2026年10月時点の公開情報によります。多くの出典はテクノロジー企業のレポートや要約記事で、数字の伝わり方が少し違うものもあるため、引用する前に原典を開いて確認してください。 - フレッド・ブルックス『人月の神話』（1975年）：[Wikipediaの要約](https://en.wikipedia.org/wiki/The_Mythical_Man-Month) - Shopify、トビ・リュトケのメモ（2025年4月）：[Business Today](https://www.businesstoday.in/technology/news/story/ai-use-is-no-longer-optional-at-shopify-declares-ceo-tobi-lutke-in-internal-memo-471211-2025-04-08)、[Workplace Journal](https://workplacejournal.co.uk/2025/04/shopify-ceo-calls-for-reflexive-ai-use-as-baseline-expectation-no-headcount-growth-until-options-explored/) - Alphabet、2024年第3四半期の決算説明会：[TechRadar](https://www.techradar.com/pro/alphabet-ceo-says-more-than-a-quarter-of-new-code-at-google-is-ai-generated) - Microsoft、[Work Trend Index 2025: The Frontier Firm is born](https://blogs.microsoft.com/blog/2025/04/23/the-2025-annual-work-trend-index-the-frontier-firm-is-born/) - Google、[DORA 2025 State of AI-assisted Software Development](https://research.google/pubs/dora-2025-state-of-ai-assisted-software-development-report/)、[TechRepublicの要約](https://www.techrepublic.com/article/news-dora-ai-report-2025/) - Faros AI、AI Productivity Paradox（2025年7月）：[Farosの要約](https://www.faros.ai/blog/lab-vs-reality-ai-productivity-study-findings)、[Software Seniの要約](https://softwareseni.com/the-ai-productivity-paradox-in-software-development-and-what-the-research-actually-shows)（原典は未読）