---
title: 將團隊「擬似BMI」化的話題
description: "※本文內容基於筆者個人經驗與觀點，不代表所屬組織或特定廠商的官方見解。此外，這裡介紹的方法不保證對所有組織都有效且安全。實際導入時，請根據貴公司的狀況、合約、法規、安全政策等進行判斷。 --- ## 前言：最浪費的其實是「認知同步」這個問題 在本公司這種基礎架構、應用程式、儲存混雜的現場工作時， 經常會遇到這樣的情況。 - 「這個最後到底是根據什麼方針決定的？」 - 「那張工單進展到哪裡了？」 - 「這個設計，不知道是誰基於什麼前提思考的…」 **比起實作時間，更多時間消耗在「認知同步」上的感覺**，你有過嗎？ 於是突然產生了一個想法， > 「如果能把相關工程師的大腦和身體連結起來，作為集合體行動不是最強嗎？」 這已經是偏向科幻的發想了。 當然，在現實中透過 Brain Machine Interface (BMI) 將大腦物理連結還是相當遙遠的未來。 不過，**如果結合工具、營運和文化，應該能接近「類似連結的狀態」吧？** 因此，我們針對 10 人以下的團隊，思考了一個「類 BMI 團隊營運模型」。 --- ## 目標團隊的條件 這次假設的團隊大致如下。 - 成員：**10 人以內** - 角色：**基礎架構、應用程式、儲存混雜**（雲和地端都會接觸） - 使用工具（範例）…"
url: "https://bestnetllc.co.jp/zh-hant/docs/%e5%b0%87%e5%9c%98%e9%9a%8a%e3%80%8c%e6%93%ac%e4%bc%bcbmi%e3%80%8d%e5%8c%96%e7%9a%84%e8%a9%b1%e9%a1%8c/"
updated: "2026-10-19"
category: Tech Blog
---

# 將團隊「擬似BMI」化的話題

※本文內容基於筆者個人經驗與觀點，不代表所屬組織或特定廠商的官方見解。此外，這裡介紹的方法不保證對所有組織都有效且安全。實際導入時，請根據貴公司的狀況、合約、法規、安全政策等進行判斷。

---

## 前言：最浪費的其實是「認知同步」這個問題

在本公司這種基礎架構、應用程式、儲存混雜的現場工作時，
經常會遇到這樣的情況。

- 「這個最後到底是根據什麼方針決定的？」
- 「那張工單進展到哪裡了？」
- 「這個設計，不知道是誰基於什麼前提思考的…」

**比起實作時間，更多時間消耗在「認知同步」上的感覺**，你有過嗎？

於是突然產生了一個想法，

> 「如果能把相關工程師的大腦和身體連結起來，作為集合體行動不是最強嗎？」

這已經是偏向科幻的發想了。
當然，在現實中透過 Brain Machine Interface (BMI) 將大腦物理連結還是相當遙遠的未來。

不過，**如果結合工具、營運和文化，應該能接近「類似連結的狀態」吧？**
因此，我們針對 10 人以下的團隊，思考了一個「類 BMI 團隊營運模型」。

---

## 目標團隊的條件

這次假設的團隊大致如下。

- 成員：**10 人以內**
- 角色：**基礎架構、應用程式、儲存混雜**（雲和地端都會接觸）
- 使用工具（範例）

  - GitHub
  - Slack
  - Notion
  - Teams / SharePoint（與其他部門或外部協作用）
  - Nextcloud（檔案共享等）

簡單來說，假設的是**「全員什麼都碰的全端型小團隊」**。

---

## 概念：在外部建立團隊的「集合大腦」

希望達成的狀態用一句話來說，

> **「減少只存在某人腦中的資訊」，
> 將其集中到團隊整體的「外部大腦」。**

就是這樣。

代替 BMI，

- 工具（GitHub / Slack / Notion / 儀表板）
- 協定（如何流通資訊）
- 文化（如何行動）

組合這些要素，建立**「類似連結的狀態」**。

---

## 工具的角色分擔：將哪裡視為「大腦」

首先，為手邊的工具明確分配角色。

### 1. GitHub：任務、程式碼與決策的「中樞神經」

- Issue / Projects：任務管理（基礎架構與應用程式混合也可以）
- PR：程式碼與設定的變更點
- `docs/adr`：架構的「決策日誌」（ADR）

重點在於，

> **基礎架構與應用程式，首先全部放在 GitHub Issue 上**

制定這樣的規則。
「將任務的入口統一在 GitHub」，就能讓認知的入口一致。

---

### 2. Slack：即時的「腦內聊天」

Slack 是用來共享對話與「現在腦中想法」的地方。

**範例：頻道結構**

- `#dev-general`：開發與基礎架構總覽
- `#infra`：網路、虛擬機基礎架構、儲存系統
- `#alerts`：監控與警報整合
- `#daily-sync`：每日「腦中想法」共享（後述）
- `#random`：閒聊

重要的是，

> 在 Slack 討論後如果產生「決定事項」，
> **必須記錄到 GitHub Issue / ADR / Notion**

這個步驟很重要。
**「討論完就結束」的話，會立刻被遺忘。**

---

### 3. Notion：設計與知識庫的「長期記憶」

在 Notion 中，放置**多次重複使用的知識與設計**。

結構範例：

- `📚 Knowledge`

  - 系統清單（URL、負責人、概要）
  - 常見流程（Runbook）
- `🧠 Architecture`

  - 整體架構
  - 網路概要
  - 認證／權限的整體架構
- `📝 Meeting Notes`

  - 定期會議的備忘錄
  - 各頁面最後加上「決定事項」區塊
- `✅ Playbooks`

  - 障礙應對及定期維護程序

> 「同樣的說明重複3次以上就提升至 Notion」
> 這樣的簡易標準也是可行的。

---

### 4. Teams / SharePoint / Nextcloud：對外介面 & 倉庫

- Teams：與其他部門/客戶溝通使用(對外窗口)
- SharePoint / Nextcloud：文件與檔案的存放處

**內部的「工程師思維」集中在 GitHub / Slack / Notion**,
將其他工具定位為「與外部世界的連接點」,會更容易整理。

---

## 擬似BMI式「一天的流程」設計

### 早晨：團隊的「腦波同步」(約15分鐘)

#### 1. `#daily-sync` 各自發文

格式範例：

```
[今日預定事項]
- ISSUE-1234 Proxmox 儲存結構調整
- ISSUE-1201 API 延遲調查

[昨日卡關事項]
- DB連線限制的問題,等待決定(@○○)

[諮詢、協助]
- SWIFT整合批次的作業設計,希望有人能協助30分鐘檢視
```

光是這樣,

- 誰在留意哪些事項
- 哪裡可能成為瓶頸

就能透過文字快速掌握。

#### 2. 瀏覽儀表板

準備一頁彙整監控、CI、主要指標的儀表板,
由某人(也可輪流)在早上先瀏覽一遍,如有異常就在 Slack 發個訊息：

> 「DB延遲比昨天惡化。今天會一邊觀察一邊找原因」

光是這樣,就能避免「莫名的不安」擴散。

---

### 日間：任務著手～完成的流程

#### 任務開始時

1. 將 GitHub Projects 的卡片移至 `Doing`
2. 在 Issue 開頭寫下目前已知的背景資訊：

```
## 現狀
- X環境的資料庫連線錯誤僅在特定時段增加
- 日誌顯示接近 connection limit 的值

## 假設
- 與連線池設定不一致
- 批次作業增加

## 完成條件
- 確定原因
- 決定對應方針（必要時建立ADR）
```

保留「上下文資訊包」，
之後任何人都能輕鬆追溯狀況。

---

#### 遇到瓶頸時

- 在 Issue 的留言中寫下「做到哪裡」「卡在哪裡」
- 將該留言複製並貼到 `#infra` 或 `#dev-general`：

```
關於 ISSUE-1234，已調查到這裡：

- A方案（增加連線數）似乎只能暫時應急
- application端的連線池設定可能與RDS不一致

接下來想向熟悉應用端設計的人請教一下
```

**「作業記錄＋思考記錄」一起呈現**，
其他成員更容易「連同思路一起共享」。

---

#### 方針確定時

- 在 Issue 寫下結論
- 重要事項建立一份 ADR
- 在 Slack 貼上「已撰寫ADR」的連結

如此一來，
**「一次討論達成的共識」就會成為團隊的長期記憶**。

---

### 下班前：小型「大腦快照」（5分鐘）

每個人要做的事很簡單。

- 在 `Doing` 的Issue中記下一行「明天要做的事」
- 有餘力的話在 `#daily-sync` 簡單補充「今天做了什麼」

```
[今日做的事]
- ISSUE-1234 確定 Proxmox 儲存設計並建立 PR
- 在 Notion 補充 DB 連線上限、RDS 端參數候選
```

隔天早上自己或成員能更容易重建狀況，
**腦內脈絡的重新載入成本**就會降低。

---

## 為了不忘記決策的「ADR」機制

討論時間最浪費的情況是，
**「又在說明之前已經決定過的事」**。

這時可以導入 **ADR（Architecture Decision Record）**。

- 在各儲存庫建立 `docs/adr` 目錄
- 只記錄「日後可能爭論／可能忘記的決策」也可以

檔案範例：`docs/adr/0001-choose-proxmox-as-hypervisor.md`

```
# 0001: 採用 Proxmox VE 作為 Hypervisor

- 日期: 2025-12-11
- 狀態: Accepted

## 背景

～（略）

## 決定

～（略）

## 採用理由

～（略）

## 否決的選項
- VMware ESXi:
  - 理由:
- Hyper-V:
  - 理由:

## 影響範圍

～（略）
```

Slack 討論結束後，只要有人撰寫 ADR，
並在 `#dev-general` 貼上連結，效果就很顯著。

> 「為何選擇這個」，
> 會從個人腦內移至團隊的「外部大腦」的形象。

---

## 若要分階段導入

一次全部進行會很辛苦，
分階段進行會比較順利。

### Phase 1（最初 2 週）：入口統一為一個

- 建立 GitHub Projects，
  試著建立**新任務必定建立 Issue** 的規則
- 在 Slack 建立 `#daily-sync`，試著每天發文一行也好

### Phase 2（接下來 2～4 週）：養成記錄決策的習慣

- 出現重要技術判斷時，至少撰寫一份 ADR
- 在 Notion 只建立以下 3 項：

  - 系統清單
  - Runbook
  - Meeting Notes

### Phase 3：培養儀表板和 Playbook

- 將監控、CI 的儀表板整合到一個畫面
- 將重複性作業以 Notion 的 Playbook 形式保存下來

---

## 總結：以「外部大腦」取代 BMI 的鍛鍊

本文介紹的擬似 BMI 模型,
簡單來說就是以下的概念。

- **將任務、決策、設計從特定人員的腦中移轉到 GitHub / Slack / Notion**
- **在一天的開始和結束時,分享小型的「大腦快照」**
- **重要決策以 ADR 形式記錄,避免重複相同討論**

透過這樣的做法,

- 認知對齊會議的時間縮短
- 「只存在於某人腦中的前提」減少
- 整個團隊更容易作為一個「集體智慧」運作

雖然不知道真正以 BMI 直接連結大腦的時代是否會到來,
**但我認為只要結合工具、營運和文化,
現在就足以接近「擬似連結狀態」**。

如果有團隊也面臨類似的課題,
請務必嘗試看看,即使只實施部分內容也好。
一定能發現某些「認知對齊上的浪費」。