組織導入の現実
「会社全体で Linux に移行する」── この大規模プロジェクトは、ほぼ必ず失敗する。 業務ソフト互換性、社内サポート、ユーザー教育、予算、稟議 ── どれか一つが 詰まった時点で頓挫する。
しかも、Linux 移行を最初に持ち出すのは順番が悪い。OS の入れ替えは 変化の中でも一番大きい。先にやるべきは別にある。
第一節 Linux 移行よりも、道具の変更を先に
本書の主張は単純だ ── OS の入れ替えを推す前に、まず道具を変える。 それは AI ネイティブな仕事の作法 に書いた通りで、 Windows のままでも今日から始められる。
「道具」の中身
- 文書: Word → Markdown(配布時だけ pandoc で .docx)
- 表計算: Excel → CSV + Python(uv + pandas)(配布時だけ .xlsx)
- スライド: PowerPoint → Markdown + Marp
- 図解: Visio / PPT 図形 → Mermaid
- メール: Outlook → Thunderbird(両 OS で同じ)
- チャット: Slack → Element / Matrix(自前ホスト可、データの所有権)
- ブラウザ: Edge → Firefox + Chrome(両 OS で同じプロファイル)
- エディタ: VS Code → Zed(両 OS で動く)
- パッケージ: pip → uv(両 OS で動く)
- AI: → Claude Code(
curl https://claude.ai/install.sh | bash、両 OS)
これらは 全部 Windows 上でも動く。Linux に乗り換える必要は、まだ 無い。
なぜこの順序が効くのか
- 互換性問題が消える ── 中身が Markdown / CSV になれば OS は問わない。 取引先が Word でくれても、自分は Markdown で受け取って Markdown で 返せる(pandoc で変換)。
- 撤退コストが小さい ── 道具の変更は「気に入らなければ Word に戻す」 が可能。OS 入れ替えは戻すのが大変。
- 説得が要らない ── 「Word より速く書ける」「来月の自分が同じ集計を 再実行できる」── 成果が先に出る。稟議が要らない。
- IT 部門と衝突しない ── 「OS は変えない、書き方を変えるだけです」と 言える。
- Linux 移行の準備になる ── 道具が動く OS は Linux でも同じ。中身が 先に移っていれば、OS 移行は デスクトップの外装を変えるだけ の小さな 仕事になる。
段階の地図
段階 0(現状):
Windows + Office + 専用ソフト
段階 1(道具を変える、本書の主推奨): ← Windows でもできる
Windows + Markdown + CSV + Python(uv) + Claude + Element + Zed
Office は入口/出口の互換層に縮小
段階 2(OS を変える、希望者から):
Debian + Flatpak + 同じ道具一式
すでに段階 1 が動いているので、外装の入れ替えだけ
段階 3(1 人 + AI の単位、組織が変わる):
各員が自律ユニット、組織は調整層
組織での導入の 9 割は段階 1 で果たされる。Linux 移行(段階 2)を 強制しなくても、段階 1 だけで業務生産性とセキュリティの大半が改善する。
Claudeに聞いてみよう①:道具の変更プラン(Linux 抜き)
私の職種〔業種・役割〕、主な業務〔内容〕、組織の規模〔人数〕を前提に、 OS は Windows のまま で、次の道具を導入する 90 日プランを作って ください:
- Markdown(文書)、CSV + Python uv(表計算)、Marp(スライド)、Mermaid(図)
- Thunderbird(メール)、Element(チャット)、Firefox / Chrome(ブラウザ)
- Zed(エディタ)、Claude Code(AI 同伴)
各週でやることと、最初の成果物(社内に見せる小さな実績)を具体的に。 既存の Office / Outlook / Teams との 入口・出口の互換層 も含めて。
第二節 自分の業務 PC から始める(段階 2)
道具の変更が定着し、それでも Linux に移りたい人だけ 段階 2 に進む。 強制ではなく、希望者から個人判断で。
稟議よりも、既成事実
所属、業務内容、社内ルールによって可否は変わるが、多くの企業では「業務 PC の OS は自己裁量」とまでいかなくても、個人の開発環境や業務に支障がなければ 黙認される。
- 開発者: 業務 PC を Linux にしているのは珍しくない
- データ分析: Python / SQL の環境は Linux の方が自然
- ウェブ運用: サーバー管理は Linux 必須なことも多い
- 管理・営業: Office 依存が強いが、段階 1 が済んでいれば 移行のハードルは 劇的に下がる(中身が Markdown / CSV になっているため)
Mythos 時代との整合
第11章「Claude Mythos — WordPress+AI」、 第13章「AI 時代のデスクワーク」 で 書いた通り、Mythos 時代に Windows 依存はセキュリティリスクが高い。 この構造を IT 部門が理解し始めているなら、段階 2(Linux 移行)は正当な 選択肢になる。
Claudeに聞いてみよう②:Linux 移行(段階 2)の判定
私はすでに段階 1(Markdown / CSV / Python uv / Claude / Element / Zed)を 〔X ヶ月〕運用しています。職種は〔業種・役割〕で、組織は〔人数〕。
業務 PC を Debian に切り替える価値があるか、次を整理してください: (1) 段階 1 のままでも残るペイン (2) Linux に移って消えるペイン (3) Linux に移って新たに出るペイン (4) 半年で達成可能な目標 (5) 段階 2 の現実的な確率(高・中・低)
第三節 小さな成功を見せる
成果物で語る
Debianに移行したあなたが、次を見せる。
- 速くなった：起動時間、アプリ立ち上げ、処理速度
- ミスが減った：ドキュメントがテキストで管理されバグが追える
- コストが下がった：ライセンス費の削減
- 新しいことができる：Claudeと連携して自作ツール、データ処理
数字で示す。 「なんとなく速い」ではなく「起動が45秒→12秒になった」と。
ブログか社内Wikiで記録
あなたの移行と運用の記録を、社内Wikiやチームのドキュメントに残す。他の人が読めば、それ自体がサンプルになる。
第四節 二人目、三人目を作る
興味を示した人を支援する
あなたの成果を見て「自分もやってみたい」という人が出てきたら、第21章の「周囲に伝える」を実行する。
- この教科書を渡す
- 一緒にインストール日を設定する
- 困ったら一緒にClaudeに聞く
- サポート役になりすぎない
一人ずつ確実に。 慌てて「希望者全員一斉インストール会」をやると失敗する。
三人で「Debianユーザー会」になる
社内に三人 Debian ユーザーがいれば、非公式の集まりができる。
- 週 1 の昼休みに 15 分集まる
- Element / Matrix に部屋を作る(Slack でも可だが、本書は Element 推奨。 自前ホスト可能、E2EE、フェデレーション、データの所有権 ── すべて Mythos 時代の "下からのサポート体制" と整合する)
- 困ったことを共有、知見を蓄積
これが組織内の「下からのサポート体制」になる。
なぜ Slack ではなく Element か Slack は便利だが、データはクラウド事業者の支配下に置かれる。 Element + 自前ホストの Matrix サーバなら、メッセージの履歴も検索も 自分たちのものになる。Linux クライアントが Flatpak で簡単に入り、 業務メッセージから家庭の連絡まで一台に収まる。Slack の無料枠制限 (90 日でメッセージが消える)も無い。
第五節 IT部門との関係
敵にしない
IT部門は、安定運用の責任を持つ人たちだ。彼らにとって新しいOSの導入は責任範囲の拡大を意味する。反対されるのは当然。
「許可」ではなく「相談」で入る
「Debianに変えてもいいですか」と聞くと、前例がない限り否定される。代わりに「こういう業務課題があって、Linuxで解決できそうなのですが、相談に乗ってもらえますか」と聞く。
彼らの懸念を理解する
IT部門が心配するのは：
- セキュリティパッチの適用保証
- 社内システムへの接続（VPN、ドメイン認証、証明書）
- サポート窓口（誰が面倒を見るか）
- インシデント時の対応
- ライセンス管理（企業としての法的責任）
これらを一つずつ潰す提案を Claude と作る。
Claudeに聞いてみよう③：IT部門への提案書
私の所属：〔〕。IT部門に、私の業務PCをDebianにする提案をしたいです。 IT部門が懸念しそうな項目（セキュリティ、サポート、接続、ライセンス）について、 それぞれに対する私の回答／対処を提案書形式でまとめてください。 口調は「相談」のトーン、決して要求ではなく。 失敗時の切り戻し計画（Windowsに戻す手順）も添えて。
第六節 業務アプリとの折り合い
社内専用アプリ
多くの組織は、社内でしか使わないWindows専用アプリを持つ。対処は：
- 代替があるか調査：Claudeに聞く、実際に試す
- 仮想マシンで動かす：KVM/virt-manager でWindows VM
- 別PC（Windows残し）：そのアプリだけ別機
- Webアプリに移行する：長期的には社内システムもWeb化
Microsoft 365 / Teams
業務で Teams 会議が必須なら、Linux でも動く。公式ネイティブアプリは終了したが、Web版は動作する。PWA としてインストールすれば、アプリに近い使い勝手。
メールとカレンダー
Exchange Online は IMAP 設定があれば Thunderbird でアクセス可能。カレンダー（CalDAV）は設定次第。
Claudeに聞いてみよう④：業務アプリの対処マップ
私の組織が使う業務アプリは〔リスト〕です。 各アプリについて、Linux対応の現状と、対処案（代替／VM／別機／Web版）を表にしてください。 社内システムへの接続（VPN、ADドメイン、証明書）の対処も含めて。
第七節 コスト分析で動かす
組織の意思決定は数字で動く
論理では動かない組織も、数字なら動く。Debian移行の試算を作る。
- ライセンス費削減：Windows Pro、Office 365、セキュリティソフト
- ハードウェア延命：古いPCの買い替えが不要に
- サポートコスト：トラブル時の外注費削減（Claudeでの自己解決）
- リスク削減：Mythos時代のゼロデイ被害の期待値減
一人あたり年額数万円〜十数万円の削減が現実的。社員100人なら数百万円〜数千万円。これが経営層に刺さる数字。
Claudeに聞いてみよう⑤：自組織のコスト試算
私の組織の規模〔人数〕と、主要なライセンス〔Windows Pro、Office 365、セキュリティソフト〕を前提に、 全員または一部をDebian + 代替ソフトに移行した場合の年額削減を試算してください。
(1) 直接的な削減（ライセンス費） (2) 間接的な削減（サポート、トラブル対応） (3) 移行コスト（教育、移行作業） (4) 5年間の累積損益
保守的な前提と、楽観的な前提の二通りで。
第八節 長期戦の覚悟
五年で組織は変わる
小規模組織なら1〜2年、大企業なら5年かかる。一斉移行は無理だが、毎年1〜2割ずつの増加は現実的だ。
あなたが最初の一人として、2〜3年かけて仲間を増やし、5年経ったとき組織の3割がLinuxになっている——これが現実的な成功像。
続けられる仕組みを作る
あなたが辞めたら組織の Linux文化が消える、では困る。
- ドキュメントを残す（社内Wiki、運用手順）
- 複数人が運用できる体制にする
- 新人にも移行の選択肢を提示する
一人の活動ではなく、継続する仕組みとして育てる。
第九節 失敗したときの撤退
撤退も戦略
組織のDebian導入が失敗することはある。ITの方針転換、業務アプリの更新で動かなくなる、キーマンが辞める、経営が代わる——様々な理由で。
失敗したとき、感情的にならず、撤退する。自分だけはDebianを続ければいい。組織全体の方向性と、自分のPC環境は別だ。
Claudeに聞いてみよう⑥：撤退の基準
私が組織でDebian導入を推進するとして、どの条件が揃ったら「撤退すべき」と判断すべきですか。 明確な基準を5つ挙げてください。 また、撤退時に自分のPCだけは継続するための、組織との関係の整え方を教えてください。
まとめ
この章でやったこと：
- 組織の一斉 Linux 移行が失敗する理由を理解した
- Linux 移行よりも先に道具(Markdown / CSV / Python uv / Claude / Element / Zed)を変える 戦略を確認した(段階 1、Windows 上で開始可能)
- 段階 2(Linux 移行)は希望者の個人判断で進めると整理した
- 小さな成功を数字で示す方法を整理した
- IT 部門を敵にしない関係の作り方を確認した
- 業務アプリとの現実的な折り合いを設計した
- コスト試算で経営層を動かす作法を掴んだ
- 長期戦の覚悟と撤退条件を決めた
手元に残ったもの：
- 自分の業務でのDebian運用
- 社内向け提案書／ドキュメント
- 撤退基準
- 二人目・三人目の候補
次の第23章——教科書の最終章——では、次世代への継承を扱う。あなたが学んだことを、子供や後進にどう渡すか。Claudeと一緒に学ぶ時代の、学びの継承のあり方を考える。
シリーズ全体はClaudeと一緒に学ぶDebian 一覧から辿れる。コメント・議論は Facebook グループへ：AISeed — 生物多様性・食料・AIと暮らし