• "We Worship One Thing: Technology"

チームを“疑似BMI”化してみる話

  • Home
  • Docs
  • チームを“疑似BMI”化してみる話

チームを“疑似BMI”化してみる話

3 min read

※本記事の内容は、筆者の個人的な経験や考えに基づくものであり、所属組織や特定ベンダーの公式見解を示すものではありません。また、ここで紹介する方法があらゆる組織に対して有効・安全であることを保証するものではありません。実際の導入にあたっては、自社の状況・契約・法規制・セキュリティポリシー等を踏まえてご判断ください。

はじめに：一番ムダなのは「認識合わせ」なんじゃないか問題 #

弊社のようなインフラ・アプリ・ストレージが入り混じる現場で仕事をしていると、
頻繁にこんな光景があります。

  • 「これって結局どういう方針で決めたんでしたっけ？」

  • 「そのチケットってどこまで進んでます？」

  • 「この設計、誰が何を前提に考えたのか分からない…」

実装時間より“認識合わせ”に時間を溶かしている感覚、ありませんか？

そこでふと出たアイデアが、

「関係エンジニアの脳と身体をリンクして集合体として行動できたら最強では？」

という、もはやSF寄りの発想です。
もちろん、現実には Brain Machine Interface（BMI）で脳を物理的にリンクするのはまだ相当先の話です。

しかし、ツールと運用と文化を組み合わせれば「疑似的なリンク状態」には近づけるのでは？
ということで、10名以下のチームを対象にした「疑似BMIチーム運用モデル」を考えてみました。

対象となるチームの条件 #

今回想定しているのは、だいたいこんなチームです。

  • メンバー：10名以内

  • 役割：インフラもアプリもストレージもごちゃ混ぜ（クラウドもオンプレも触る）

  • 利用ツール（一例）

    • GitHub

    • Slack

    • Notion

    • Teams / SharePoint（他部署や外部との連携用）

    • Nextcloud（ファイル共有など）

要するに、**「全員なんでも触るフルスタック寄りの小チーム」**を想定しています。

コンセプト：チームの“集合脳”を外部に作る #

目指したい状態を一言でいうと、

「誰かの脳みその中にしかない情報」を減らして、
チーム全体の“外部脳”に寄せていく。

というものです。

BMIの代わりに、

  • ツール（GitHub / Slack / Notion / ダッシュボード）

  • プロトコル（どう情報を流すか）

  • 文化（どう振る舞うか）

を組み合わせて、**“疑似的なリンク状態”**を作っていきます。

ツールの役割分担：どこを「脳」とみなすか #

まずは、手元にあるツールにきちんと役割を与えます。

1. GitHub：タスクとコードと決定の「中枢神経」 #

  • Issue / Projects：タスク管理（インフラ・アプリ混在でOK）

  • 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

    • 定例MTGごとのメモ

    • 各ページの最後に「決定事項」セクション

  • ✅ Playbooks

    • 障害対応や定期メンテの手順

「3回以上同じ説明をしたものは Notion に昇格させる」
という雑な基準を作るのもアリです。

4. Teams / SharePoint / Nextcloud：外部とのインターフェース & 倉庫 #

  • Teams：他部署 / 顧客とのやりとり用（外向けの窓口）

  • SharePoint / Nextcloud：ドキュメント・ファイルの置き場

内側の“エンジニア脳”は GitHub / Slack / Notion に集約し、
その他のツールは「外の世界との接続点」と位置づけると整理しやすくなります。

疑似BMI的な「1日の動き」の設計 #

朝：チームの“脳波合わせ”（約15分） #

1. #daily-sync に各自ポスト #

フォーマット例：

[今日やること] - ISSUE-1234 Proxmox ストレージ構成調整
- ISSUE-1201 API レイテンシ調査

[昨日詰まっていること] - DBの接続制限の件、決定待ち（@○○さん）

[相談・ヘルプ] - SWIFT連携バッチのジョブ設計、誰か 30分レビューお願いしたい

これだけでも、

  • 誰が何を意識して動いているか

  • どこがボトルネックになりそうか

が、テキストベースでざっと見えるようになります。

2. ダッシュボードを一瞥する #

監視・CI・主要メトリクスをまとめたダッシュボードを1枚用意し、
誰か1人（ローテーションでも可）が朝一で眺めて、怪しいところがあれば Slack に一言流す：

「DBレイテンシ、昨日より悪化傾向。今日は様子見ながら原因探ります」

これだけで、「なんとなく不安」を共有せずに済みます。

日中：タスク着手〜完了の動き #

タスク開始時 #

  1. GitHub Projects のカードを Doing に動かす

  2. Issue の冒頭に、現時点で分かっているコンテキストを書く：

## 現状
- X環境のDB接続エラーが特定時間帯だけ増えている
- ログ上は connection limit に近い値

## 仮説
- 接続プール設定との不整合
- バッチジョブの増加

## 完了条件
- 原因特定
- 対応方針の決定（必要ならADR作成）

「コンテキストパケット」を残しておくと、
あとから誰が見ても状況を追いやすくなります。

詰まったとき #

  • Issue のコメントに「どこまでやったか」「どこで詰まったか」を書く

  • そのコメントをコピーして #infra や #dev-general に貼る：

ISSUE-1234 の件、ここまで調査しました：

- A案（接続数増やす）は一時しのぎにしかならなそう
- application側のプール設定がRDSとズレている可能性あり

ここから先、アプリ側の設計詳しい人に少し相談したいです

「作業ログ＋思考ログ」を一緒に出すことで、
他のメンバーが「頭の中ごと共有」しやすくなります。

方針が決まったとき #

  • Issue に結論を書く

  • 重要なものは ADR を1つ作る

  • Slack に「ADR書きました」とリンクを貼る

こうすることで、
“一度話して合意したこと” が、チームの長期記憶に残るようになります。

終業前：小さな“脳のスナップショット”（5分） #

各自がやることはシンプルです。

  • Doing のIssueに「明日やること」を一行メモする

  • 余裕があれば #daily-sync に「今日やったこと」をざっくり追記する

[今日やったこと] - ISSUE-1234 Proxmox ストレージ設計を固めてPR作成
- DB接続上限、RDS側パラメータ候補をNotionに追記

翌日朝に自分やメンバーが状況を再構築しやすくなり、
脳内コンテキストのリロードコストが下がります。

決定を忘れないための「ADR」という仕組み #

議論の時間がもったいないのは、
**「前に決めたはずのことをもう一度説明しているとき」**です。

そこで導入したいのが ADR（Architecture Decision Record） です。

  • 各リポジトリに docs/adr ディレクトリを作成

  • 「あとで揉めそう／忘れそうな決定」だけでもいいので記録する

ファイル例：docs/adr/0001-choose-proxmox-as-hypervisor.md

# 0001: ハイパーバイザーとして Proxmox VE を採用する

- 日付: 2025-12-11
- ステータス: Accepted

## 背景

〜（略）

## 決定

〜（略）

## 採用した理由

〜（略）

## 却下した選択肢
- VMware ESXi:
- 理由:
- Hyper-V:
- 理由:

## 影響範囲

〜（略）

Slack での議論が終わったら、誰かが ADR を書き、
#dev-general にリンクを貼るだけでも効果は大きいです。

「なぜこれを選んだのか」が、
一人の脳内からチームの“外部脳”に移されるイメージです。

段階的に導入するなら #

いきなり全部やろうとすると大変なので、
フェーズを分けるとスムーズです。

Phase 1（最初の2週間）：入口を1つにする #

  • GitHub Projects を作り、
    新しいタスクは必ず Issue にするルールを試す

  • Slack に #daily-sync を作り、1日1行でも投稿してみる

Phase 2（次の2〜4週間）：決定を記録に残す習慣 #

  • 重要な技術判断が出たら、最低でも1本ADRを書いてみる

  • Notion に以下3つだけ作る：

    • システム一覧

    • Runbook

    • Meeting Notes

Phase 3：ダッシュボードとPlaybookを育てる #

  • 監視・CIのダッシュボードを1画面にまとめる

  • 繰り返す作業を Notion のPlaybookとして残していく

まとめ：BMIの代わりに「外部脳」を鍛える #

本記事で紹介した疑似BMIモデルは、
ザックリ言うと次のような考え方です。

  • タスク・決定・設計を、特定の人の頭から GitHub / Slack / Notion に移す

  • 1日の始まりと終わりに、小さな“脳のスナップショット”を共有する

  • 大事な決定はADRとして記録し、何度も同じ議論をしない

これによって、

  • 認識合わせMTGの時間が縮む

  • 「誰かの脳内だけにある前提」が減る

  • チーム全体が、ひとつの“集合知”として動きやすくなる

本当にBMIで脳を直結する時代が来るかどうかは分かりませんが、
ツールと運用と文化を組み合わせれば、
今でも十分「疑似リンク状態」に近づけるのではないかと思っています。

もし似たような課題感を持っているチームがあれば、
ぜひ一部だけでも試してみてください。
何かしらの“認識合わせのムダ”が見えてくるはずです。

Updated on 2025年12月11日

What are your feelings

  • Happy
  • Normal
  • Sad
目次
Services
Integration
Resources

©2020 BESTNET.LLC . All Rights Reserved.

Linkedin-in