多様性を力に変える！チームを「自走」させる7つのステップ ~ その7 テクノロジーの積極活用とコラボレーションの促進 ~

この記事について

これはチームや組織が最高のパフォーマンスを発揮するために欠かすことができない7つのステップのうちの七つ目、そして最後のステップである「テクノロジーの積極活用とコラボレーションの促進」です。

• 1. 自身のマインドセットの変革
  プレーヤー気質からの脱却と、コーチングマインドの確立
• 2. 透明性と心理的安全性の確保
  オープンなコミュニケーションと失敗を恐れない環境づくり
• 3. ミッション・ビジョン・バリューの共有
  組織の目的と価値観を全員で作り上げる
• 4. 目標の連携
  組織の目標と個人の目標を結びつける
• 5. 失敗の奨励
  チャレンジを促し、失敗から学ぶ文化の醸成
• 6. 適切な権限委譲と尊重
  次世代リーダーの育成と意思決定の尊重
• 7. テクノロジーの積極活用とコラボレーションの促進　← 今回のテーマ
  最新技術と部門横断の協力で効率と創造性を高める

なぜ最後のステップなのか

「AIを入れれば生産性が上がる」という話は、もう誰も新しいとは思わないと思います。実際、多くのチームがすでに何らかの形でAIを使っています。

それでもこのステップを7番目に置いているのには理由があります。ツールは、チームの状態を増幅する装置だからです。

信頼関係のないチームに強力なツールを入れると、監視の道具になります。目的が共有されていないチームに自動化を入れると、間違った方向へ速く進みます。失敗が責められるチームにAIを入れると、誰もAIの出力に責任を持ちたがらず、結局「使ってみたけど定着しなかった」で終わります。

DORAが2026年に公表したレポートでも、AI投資のリターンは、ツールそのものよりも、その下にある組織のシステム（プラットフォーム、バージョン管理、CI/CD、自動テスト、チームの学習）に左右されると報告されています。同レポートでは、AI導入後にいったん生産性が落ち込み、その後に伸びる「Jカーブ」が起こることや、コードの生成量が増えた結果としてレビューやデプロイの安全装置が追いつかず、変更失敗率が上がる「不安定性の税」についても触れられています。

つまり、ここまでの6つのステップは、テクノロジーの効果を受け取るための準備でもあったということです。

いま、開発チームで実際に起きていること

私が最初にこの7つのステップを書いたときと比べて、この領域の景色は大きく変わりました。かつては「コード補完が賢くなった」という話でしたが、いまはもう少し先に来ています。

チャットから、エージェントへ

いま実務で使われているのは、質問に答えるチャットではなく、作業を任せられるエージェントです。Claude Code や Codex CLI のようなターミナル型、Cursor や GitHub Copilot のようなIDE型、そして計画から実装・テスト・PR作成までを自律的に進めるタイプまで、用途に応じて使い分けられています。

現場を見ていると、「全社で1つのツールに統一」よりも、役割別の使い分けに落ち着くことが多いようです。補完中心の人はIDE型、横断的な調査や改修はターミナル型のエージェント、定型的な作業は自律型に寄せる、といった具合です。

MCPによる「自社の文脈」の接続

もう一つの大きな変化が、MCP（Model Context Protocol）の普及です。AIを自社のリポジトリ、チケット管理、ドキュメント、監視ツールなどに標準的な方法で接続する仕組みで、2026年にはOAuthや権限管理、監査ログといった企業利用に必要な仕組みが整理され、主要ベンダーが軒並み対応する事実上の標準になりました。

これが効くのは、AIの弱点が「能力」ではなく「文脈」だからです。汎用的なコードは書けても、自社の設計思想や過去の判断は知りません。MCPで自社の情報につながって初めて、AIはチームの一員に近い働きをするようになります。

その2でお話しした透明性の話が、ここで思わぬ形で効いてきます。情報が整理され、参照できる形になっている組織ほど、AIから引き出せる価値も大きくなるのです。逆に、暗黙知が人の頭の中にしかない組織では、AIも同じように何も分かりません。

ボトルネックは「書く」から「確かめる」へ

コードを書く速度が上がった結果、多くのチームでボトルネックがレビューと検証に移りました。生成量が増えたのにレビュー体制が変わらなければ、レビュー待ちの列が伸びるだけです。

ですので、いま投資すべきなのは生成側ではなく、確かめる側です。自動テストの拡充、静的解析、AIによる一次レビュー（人のレビューの前に機械的な指摘を済ませておく）、そして小さく出して早く戻せるデリバリー。その5でお話しした「失敗のコストを下げる」という話は、AI時代にますます重要になっています。

言語や拠点の壁が、少し低くなった

これは個人的にいちばん大きいと感じている変化です。

私のチームは東京・ホーチミンシティ・ハノイの3拠点、日本・ベトナムの2カ国で、公用語は英語でした。私は英語で仕事をするのが初めてで、「月元が何を話しているのか良く分からない」と第三者から日本語でフィードバックを受けたこともあります。当時は、伝わらないコミュニケーションから逃げるように現場作業にのめり込んでいました。

いまなら、会議の文字起こしと要約、議事録の多言語展開、ドキュメントの翻訳といったことが、その場で当たり前にできます。当時の私が欲しかったものが、そのまま手に入る時代になりました。

ただ、誤解のないように書いておきます。これで解決するのは「言葉が分からない」という問題だけです。なぜこの対応をするのか、これをやるとユーザーが何を嬉しいのかという背景の共有は、AIがやってくれるわけではありません。翻訳できるようになったからこそ、何を伝えるかを決めるリーダーの仕事はむしろ増えます。

チームでAIを使うときのガードレール

個人でAIを使うのと、チームで使うのは別物です。任せる範囲を決めるという意味では、その6の権限委譲とまったく同じ構造の話になります。

• 権限の境界を決める：ファイルの書き込みやコマンド実行を許可制にして、最初は提案のみから始め、信頼できる範囲を少しずつ広げる
• 作業範囲を閉じる：エージェントが触れる範囲をリポジトリ配下などに限定し、本番環境の設定には触れさせない
• 記録を残す：誰が・いつ・どこで使ったのかを組織として把握できるようにする
• データの扱いを確認する：自社のコードや顧客情報がモデルの学習に使われない設定になっているかを、導入前に必ず確認する
• 最終責任は人が持つ：AIが書いたから、で説明が終わらないようにする。出力を理解して説明できる人が必ずいる状態を保つ

このガードレールは、メンバーを縛るためのものではありません。逆です。境界がはっきりしているからこそ、その内側では安心して大胆に使えます。権限委譲で「決めていい範囲」を明示するとメンバーが動きやすくなるのと、まったく同じ理屈です。

学びをチームの資産にする

AIの使い方は、個人の工夫として溜まりやすく、そのままだと組織に広がりません。ここを仕組みにしているかどうかで、半年後の差が大きく開きます。

うまくいったプロンプトや設定ファイルをリポジトリで共有する、レトロスペクティブで「今回AIに任せてよかったこと・任せて失敗したこと」を扱う、月に一度の共有会でお互いの使い方を見せ合う。特別なことではありませんが、これをやっているチームは伸びが早いです。

そして、失敗事例こそ共有してください。「AIの提案をそのまま入れたら事故になりかけた」という話は、成功事例の10倍役に立ちます。その5でお伝えした「失敗の奨励」は、ここでも生きます。

道具は、チームを映す鏡

ここまで7つのステップをお話ししてきました。

最初は自分自身のマインドセットから始まり、透明性と心理的安全性という土台を整え、向かう先を言葉にして、目標をつなぎ、挑戦を歓迎し、判断を委ねてきました。テクノロジーは、その上に乗って初めて力を発揮します。

逆に言えば、テクノロジーの使われ方を見れば、そのチームの状態が分かります。AIが監視の道具として使われているチームは、たぶん信頼関係に課題があります。誰もAIを使っていないチームは、たぶん挑戦が歓迎されていません。使い方がバラバラで共有されないチームは、たぶんコラボレーションの設計がまだです。

道具は、チームを映す鏡です。だから私は、ツール導入の相談を受けたときほど、ツールの前の話をするようにしています。

おわりに

この7つのステップは、最初からこれをやろうと決まっていたわけではなく、チームが良くなるために自分ができることは何かと考えて、一つずつ進めていった結果でした。降給とネガティブフィードバックを受けたあの日から始まった、私のリカバリーの記録です。

あのとき、カオスな状況でも力を尽くしてくれていたメンバーがいなければ、この記録は生まれませんでした。改めて、彼らに感謝を伝えたいと思います。

そして、いまチームのことで悩んでいるあなたへ。順番に、一つずつで大丈夫です。今日できることは、たぶんそんなに大きなことではありません。ただ、その小さな一歩がチームに伝わるまでには少し時間がかかるので、諦めずに続けてみてください。

長い連載にお付き合いいただき、ありがとうございました。

---

連載「多様性を力に変える！チームを『自走』させる7つのステップ」

---