第17章: この仕組みをあなたの会社に

設計図を渡すのに、4回作り直した

本書を書き終えた直後、私は「この仕組みをクライアント企業にも渡したい」と考えました。品質サイクル、チェックリスト駆動、部署分割。CC Company（シーシーカンパニー）で鍛え上げた設計図を、コマンド1つで相手の会社に移植できたら最高ではないか。

そう思って、セットアップスクリプトを書き始めました。

1回目は.batファイル。動いたが、手順が複雑すぎて初心者にはハードルが高い。2回目はPowerShell（パワーシェル）に書き換えた。動いたが、品質サイクルの設定をスクリプトに入れるか、マニュアルに書くか、どちらが良いか分からない。3回目は品質サイクルの組み込み位置を変えた。動いたが、「いきなり15部署の設計図を渡されても、何をすればいいか分からない」という根本的な問題が残っていた。

4回目で、ようやく気づきました。渡すべきは「完成した設計図」ではなく、「最初の一歩の踏み出し方」だった。

4回目のスクリプトは「ヒアリング型秘書」という設計に変えました。起動すると、まずAI秘書が「あなたの仕事を教えてください」と聞いてくる。会話しながら業務を棚卸しし、最初にAI化する仕事を一緒に選ぶ。完成した設計図を渡すのではなく、相手が自分の手で設計図を描き始める仕組みにしたのです。

この経験で学んだことがあります。渡す側がこれだけ苦労するのだから、受け取る側はもっと大変です。だから、この最終章では「完璧な設計図」ではなく、「最初の一歩を踏み出すための道案内」をお渡しします。

2部署から15部署へ。CC Companyの成長記録

CC Companyの今の組織図をお見せする前に、1つ知っておいてほしいことがあります。この組織図は、最初から設計されたものではありません。

最初に作ったのは、秘書室とマーケティング部の2つだけでした。秘書室はTODO管理と活動ログ。マーケティング部はnote記事の執筆。それだけです。

2部署で回していたある日、事業を進める中で契約書のレビューが必要になりました。NDA（Non-Disclosure Agreement：秘密保持契約）を結ぶ場面です。マーケティング部に「契約書を見て」と言うわけにはいきません。そこで法務部を追加しました。育成マニュアルを書き、秘書室の振り分けルールに「契約書、NDA、利用規約→法務部」と1行加えるだけ。所要時間は約10分でした。

この「仕事が生まれたら、部署を足す」というパターンが何度も繰り返されました。

講演資料を作る必要が出た。クリエイティブ部を追加。競合を調べたい場面が出た。リサーチ部を追加。そして、本書の執筆中にクライアント企業へのAI導入支援が始まりました。打ち合わせの壁打ちや提案書作成を担当する部署が必要になり、コンサルティング部を追加しました。これも約10分です。

こうして、2部署で始まったCC Companyは、今では15部署になっています。

CC Companyの今の姿

重要なのは、上半分（部署構成）はあなたの会社に合わせて自由に変えられるということです。下半分（共通の仕組み）はどの会社でもそのまま使えます。これが第16章で学んだ「仕組みと成果物の分離」です。

そして、最初から15部署を作る必要はまったくありません。私も2部署から始めました。あなたも、そこから始めてください。

引越しの段ボールは、1箱ずつ開ける

新しい家に引っ越したとき、段ボール30箱を一度に開けようとする人はいません。まずキッチン用品を出して、今夜の食事を作る。次にベッドを組み立てて、今日寝る場所を確保する。残りの箱は、生活しながら少しずつ開けていけばいい。

AI社員の組織づくりも同じです。15部署を一度に作ろうとすると、段ボール30箱を前にして途方に暮れるのと同じ状態になります。

CC Companyが2部署から始めて15部署に育った経験から、「最初の3箱」をお伝えします。

最初の1箱: 秘書室を作る

CC Companyでも、一番最初に作ったのは秘書室でした。理由は単純です。「どの部署に頼めばいいか分からない」という問題を、まず秘書室が解決してくれるからです。

秘書室の育成マニュアルに書いたのは、たった4項目です。

# 秘書室

## 役割
オーナーの窓口。TODO管理と活動ログを担当する

## 合格基準
- 指示の意図を正確に汲み取っている
- 記録ファイルに反映漏れがない

## ルール
- オーナーの手を煩わせないことが最優先
- 技術的な判断は自律的に行い、報告する

## 連携先
全部署

これだけです。完璧なマニュアルではありません。でも、これがあるだけで秘書室は動き始めます。足りない部分は、運用しながら書き足していけばいい。実際、CC Companyの秘書室のマニュアルは、今では初日の10倍以上の分量に育っています。

2箱目: あなたの主力業務の部署を作る

秘書室ができたら、次はあなたが一番時間を使っている業務を担当する部署を作ります。営業なら営業部、コンテンツ制作ならマーケティング部。CC Companyでは、note記事を毎日書いていたので、マーケティング部が2番目でした。

3箱目: 品質チェック用の部署を作る

第7章で学んだ「作る人とチェックする人を分ける」原則です。主力業務の成果物を、別の専門家がチェックする体制を作る。

ここまでで3部署。まずはこれで十分です。あとは法務部やリサーチ部のように、「仕事が生まれたら部署を足す」で自然に育っていきます。

そして、品質サイクルを1回だけ回す

3部署を作ったら、いよいよAI社員に仕事をさせます。ただし、最初は1つだけ。

川島さんの会社での話をしましょう。川島さんは本書を読み、秘書室とマーケティング部と品質チェック部の3部署を作りました。そして最初の仕事として、マーケティング部に「来月のキャンペーンメールの下書き」を頼みました。

合格基準は3項目だけ。「ですます調で統一」「本文500字以内」「件名に日付を入れる」。

AI社員が出してきた下書きは、件名に日付がなく、580字でした。不合格。修正を指示すると、今度は件名に日付が入り、480字になった。合格。

川島さんは言いました。「なるほど。基準を決めておくと、良い悪いの判断が楽になるんですね」。

この1回の体験が、本書の全内容を体感する最速の方法です。合格基準を決め、チェックし、不合格なら修正させ、合格するまで繰り返す。1回やれば「ああ、こういうことか」と分かります。品質サイクルを頭で理解するのと、手を動かして体験するのでは、まったく違うのです。

動き出してからぶつかる壁

最初の品質サイクルが回ったら、次は「続ける」段階です。ここからが本番で、多くの人がぶつかる壁があります。CC Companyの運用と、研修でお会いした経営者の方々の声から、よくあるつまずきを紹介します。

「合格基準を作ったのに、チェックしなくなる」

これが最も多いつまずきです。

ある企業の社長がAI社員を導入して3週間後、こんなことを言っていました。「最初の1週間は面白くてチェックしていたんだけど、慣れてきたら『まあ大丈夫だろう』と思って、そのまま出すようになった」。

CC Companyでも同じことが起きました。品質チェックを飛ばしてそのまま出した記事が、後から読み返すと専門用語だらけで、ターゲットの経営者には伝わらない文章になっていたのです。

なぜこうなるのか。多くの場合、合格基準が曖昧すぎます。「良い感じの文章」は基準になりません。「ですます調で統一されている」「専門用語に括弧書きの説明がある」「1,000字以上3,000字以下」のように、誰が見ても合否が判定できる基準にする必要があります。

CC Companyでの解決策は、「チェックログがないと提出できない」ルールにしたことです。成果物のファイルだけでなく、チェック結果のログファイルがセットで保存されていなければ、その仕事は「完了していない」扱いになる。仕組みで強制したのです。

最初は3項目だけのチェックリストで十分です。慣れてきたら項目を増やす。完璧な基準を最初から作ろうとしないでください。

「テンプレートが自社業務に合わない」

本書のテンプレートや指示文をそのまま使っても、しっくりこない。「うちの業界では、この表現は使わないんだよな」。

これは正常な反応です。CC Companyで使っている指示文は、CC Companyの業務(コンテンツ制作、講演、コンサルティング)に特化しています。あなたの業種、顧客層、社内文化は違うのですから、そのまま合うはずがありません。

ある研修で「テンプレートを配ったのに誰も使わない」と嘆いていた社長がいました。聞いてみると、テンプレートをメールで送っただけで、フォローはしていなかった。テンプレートは引き出しにしまわれ、社員は今まで通りの手順で仕事をしていたのです。

テンプレートは「出発点」であって「完成品」ではありません。使って1回目を実行し、結果を見て「ここが違う」を具体的にメモする。そのメモを指示文に追記する。3回繰り返せば、自社に合った指示文に育ちます。CC Companyの業務手順書も、最初のバージョンから何度も書き直して今の形になりました。第8章で紹介したスライドの手順書は4回作り直しています。

「社員が1ヶ月後に元の手作業に戻っている」

導入直後は興味を持って使うが、1ヶ月後には元の手作業に戻っている。多くの会社がAI導入に取り組んでも上手くいかないケースは、実はここに集中しています。

川島さんの会社でも、同じことが起きました。事務チームの3人にAI社員を使った業務フローを導入したところ、2人は1ヶ月後に元の手作業に戻ってしまったのです。

「AIが嫌い」「使い方が分からない」ではありません。心理学の研究によると、習慣は意識ではなく環境（同じデスク、同じPC、同じ手順）に紐づいて自動的に発動します（ウッド（Wood）& ニール（Neal）, 2007）。見積書の仕事が来た瞬間、社員の手はメール→Excel（エクセル）→手入力という従来の手順を反射的になぞってしまう。研修で「AI活用は大事です」と伝えても、翌日同じ環境に戻れば旧来の習慣が優先されます。信念や意図を変える介入は、既に習慣化した行動に対してはほぼ無効であることも示されています（フェルプランケン（Verplanken）& ウッド（Wood）, 2006）。

つまり、意識の問題ではなく業務手順の設計の問題です。今までのやり方で仕事が回る以上、AIを使う理由がない。これが定着しないメカニズムです。

「意識を変える」のではなく「AIを使わざるを得ない仕組みを作る」。これが唯一の解決策です。

たとえば「日報を毎日提出すること」を評価基準にする。手で書くのは面倒ですが、普段の仕事をAI社員の秘書経由でやっていれば、秘書が活動ログから日報を自動で作ってくれます。提案書なら「AI社員のチェックログがないと提出できない」ルールにする。「使う・使わない」を毎回判断させない設計がポイントです。

川島さんの会社では、「月次報告書はAI秘書経由で作成すること」をルール化しました。AI秘書を使わなければ月次報告書が出せない。すると、報告書を作るためにAI秘書と仕事をするようになり、他の業務でもAI秘書を使い始めたのです。

私自身も同じでした。noteの記事を毎日更新すると決め、しかもネタはCC Company自体の体験記録にした。AI社員と仕事をしないとネタが生まれず、記事が書けない。自分を「使わざるを得ない環境」に置いたのです。すると使い続けるうちに、良さがどんどん分かってくる。心理学では「単純接触効果」と呼ばれますが、好きだから使うのではなく、使うから好きになるのです（ザイアンス（Zajonc）, 1968）。

「でも、切り替えたら一時的に仕事が回らなくなるのでは？」。第2章で選んだ「AIに向いている業務」を対象にしている限り、その心配はありません。AI社員は今までのやり方より速く、しかも品質の高い成果物を出してくれます。もしパフォーマンスが落ちたとしたら、それは本来AIにやらせない方がよい業務を任せてしまっている合図です。第2章の業務の切り分けに立ち返ってください。

「仕組みを整えることに没頭して、成果物が出てこない」

CC Companyでも一時期、この罠にはまりました。育成マニュアルを書き直し、チェックリストの項目を追加し、部署間の連携ルールを設計し直す。「仕組みの改善」に毎日何時間も使っていた時期があります。

ふと気づくと、肝心のnote記事が3日間更新されていない。仕組みは磨かれたが、成果物が出ていない。

仕組みの改善は「仕事をしている感覚」が得られやすい。整理すればするほど気持ちいい。しかし、仕組みはあくまで手段です。仕組みを使って何を作るかが本質です。

第16章で学んだ「仕組みの改善は全体の10〜20%」のルールが効きます。残りの80〜90%は成果物の制作に使う。仕組みの改善は「品質が劣化したとき」や「新しい業務が増えたとき」に限定し、普段は今ある仕組みで回すことを優先しましょう。

「完璧な設計図を描こうとして、何も動かない」

15部署を一度に作ろうとする。完璧なマニュアルを書こうとする。すべてのチェックリストを事前に用意しようとする。結果、いつまでも「準備中」のまま、AI社員が1人も動いていない。

これは冒頭でお話しした、私自身の失敗と同じ構造です。クライアントに「完成した設計図」を渡そうとして4回作り直した。でも本当に必要だったのは「最初の一歩の踏み出し方」でした。

イノベーション普及理論（ロジャーズ（Rogers）, 2003）では、新しい技術の導入は「試用可能性」が高いほど普及しやすいことが示されています。全体像を理解してから始めるのではなく、小さく試して「これは使える」と実感してから広げる。CC Companyも、秘書室とマーケティング部の2部署で「これは回る」と確信してから、3部署目、4部署目を追加していきました。

まず1部署、1業務、1つの品質サイクルだけ回してください。そこで得た「ここが足りない」「ここは不要だった」という気づきが、次の部署を作るときの最良の設計図になります。

なぜ全部出すのか

本書では、CC Companyの設計図をすべてお渡ししました。品質サイクルの考え方、チェックリスト駆動の原則、部署分割の方法、タスクライフサイクル、提案の仕組み。隠し球はありません。

サービス設計の壁打ちでAI社員たちに「この仕組みをどう売ればいいか」と聞いたとき、4部署が同じ結論を出しました。「全部出しましょう。読んだ人が自分で気づき、自分で始める。それでもカスタマイズが必要な人だけが連絡してくる。それが一番信頼されます」。

考えてみれば当然です。料理のレシピは公開できます。材料の分量も、手順も、温度も、すべて書いてあります。しかし、御社の厨房の広さ、調理器具の種類、スタッフの経験レベルに合わせた段取りは、レシピには書けません。一緒に厨房に立って、御社の状況を見ながら考える必要がある。

仕組みは真似できる。でも、御社の文脈に合わせたカスタマイズは、御社にしかできない。

本書のレシピ（仕組み）は全部お渡ししました。このレシピで自分で作れる方は、ぜひ作ってください。付録のテンプレート集を使えば、すぐに始められます。

自社に合わせるのに外部の視点が欲しいと感じたら、お気軽にご相談ください。

あなたの現在地を確認する

本書を読み終えた今、以下の項目に正直にチェックを入れてみてください。

• 自分の業務を10個以上書き出し、AI化する最初の3つを選べた
• AI社員の合格基準を1つ以上、具体的な数値で定義できた
• 品質チェックを実施し、不合格なら修正→再チェックのサイクルを1回以上回せた
• 1つの業務手順書（スキル）を完成させ、繰り返し使えている
• AI社員の出力を別の仕組みでレビューする体制がある
• ここまでの活動を記録に残している

5つ以上チェックが付いた方: 自走できます。この章の俯瞰マップと付録のテンプレートを使って、自分のペースで拡張してください。

3〜4つの方: 基盤はできています。noteの連載で追加の事例を読みながら進めると、つまずきポイントを予防できます。

0〜2つの方: 外部の視点があると立ち上がりが速くなるかもしれません。著者紹介のリンクからご相談ください。

規模に応じた実践: 個人、チーム、組織

個人で始める場合: まずは秘書室1つだけで十分です。TODO管理と活動ログを秘書に任せ、品質サイクルを1つの業務で回してみてください。CC Companyの最初の1ヶ月がまさにこの状態でした。

チームで導入する場合: 全員に同じ仕組みを押し付けないでください。まずリーダーが1人で試し、「これは使える」と実感してから、チームメンバーに品質サイクルの体験を1回だけさせる。先ほどのつまずき3で話した「使わざるを得ない仕組み」を、チーム単位で設計するのがポイントです。

組織全体に展開する場合: 段階的に広げてください。イノベーション普及理論（ロジャーズ（Rogers）, 2003）で示されている通り、最初に試す少数のアーリーアダプター（早期採用者）が「うまくいった」と語ることで、次のグループが動き出します。全社一斉導入は最も失敗しやすいパターンです。1部門で成功事例を作り、その部門のメンバーが社内で語る。それが最も自然な広がり方です。

コラム: 設計図を渡す仕組みを4回作り直した話

冒頭でお話しした「セットアップスクリプトの4回の作り直し」を、もう少し詳しくお伝えします。

最初のバージョン（.batファイル）は、CC Companyの全フォルダ構成を一気にコピーする設計でした。秘書室、マーケ、営業、開発、法務、全部。動きはしたが、初めて触る人には「いきなり15部署のフォルダが並んでも、どこから手をつければいいか分からない」。

2回目は、PowerShellスクリプトに書き換え、対話形式で「どの部署を作りますか？」と聞く設計にしました。技術的にはきれいだが、「部署って何を作ればいいんですか？」という質問に答えられない。仕組みの知識がない人には使えなかったのです。

3回目は、品質サイクルの設定をスクリプトに組み込みました。ところが「品質サイクルとは何か」が分からない人にとっては、設定項目が意味不明になる。

4回目。発想を変えました。「仕組みを渡す」のではなく、「秘書を渡す」。起動すると秘書AIが「お仕事を教えてください」と話しかけてくる。業務を棚卸しし、最初にAI化する仕事を一緒に選ぶ。品質サイクルもチェックリストも、会話の中で自然に導入される。

面白いことに、この設計プロセス自体が「品質サイクル」そのものでした。合格基準（初心者が1人で使える）を決め、作ってチェックし、不合格なら修正して再チェックする。本書で繰り返し伝えてきた仕組みが、「仕組みの渡し方を設計する」場面でも機能したのです。

LLM（Large Language Model：大規模言語モデル）知識: Transfer Learning（トランスファーラーニング：転移学習）。仕組みの移植をAIの用語で理解する

この章のテーマ、「ある組織で作った仕組みを別の組織に移植する」は、AIの世界では「Transfer Learning（転移学習）」と呼ばれる技術に似ています。

転移学習とは

AIの大規模言語モデル（LLM）は、大量のテキストデータから「言語の一般的な知識」を学びます。これを「事前学習」と言います。しかし、このままでは特定の業務には使いにくい。そこで、特定のタスク（たとえば医療文書の要約や法律相談）に合わせて、追加の学習を行います。これが「Fine-tuning（ファインチューニング：微調整）」です。

事前学習で得た汎用的な知識を、別のタスクに「転移」させて使う。これがTransfer Learningの核心です。

CC Companyは「事前学習済みモデル」

本書でお渡ししたCC Companyの仕組みは、いわば「事前学習済みモデル」です。品質サイクル、チェックリスト駆動、部署分割。これらは「業務をAIで回すための一般的な知識」にあたります。

しかし、これをそのままあなたの会社に持っていっても、完全には機能しません。あなたの業界用語、業務フロー、品質基準に合わせた「Fine-tuning（微調整）」が必要です。

なぜFine-tuningが必要なのか

転移学習の研究では、事前学習で得た知識が「元のタスクと類似した領域」であるほど、Fine-tuningの効果が高いことが分かっています。逆に、元のタスクとまったく関係のない領域に転移しようとすると、性能が落ちることもあります（Negative Transfer（ネガティブトランスファー：負の転移））。

本書の仕組みは「業務をAIで回す」という汎用的な知識なので、ほとんどの業種に転移できます。ただし、「チェックリストの項目」「合格基準の数値」「部署の構成」は、あなたの会社に合わせたFine-tuningが必ず必要です。

本書を読んだだけ（事前学習だけ）では、あなたの会社で最高のパフォーマンスは出ません。最初の3部署を作り、品質サイクルを回し、「ここが違う」「ここは合っている」を見つけていく。この作業がFine-tuningであり、それを経て初めて「あなたの会社のAI組織」が動き始めるのです。

付録も活用してください

ここまで本書17章で、AI社員を育てる考え方と仕組みの全体像をお話ししました。実際に自社で立ち上げるときは、本書の付録が実装の近道になります。

• 付録A「はじめに読むガイド」: 本書の地図帳。自分の現在地（レベル0〜5）を確認し、どの章から読み直すかを決めるときに戻ってきてください。本書を読み終えた後も、新しい業務領域に取り組むたびに立ち返れる道しるべです
• 付録B「環境構築ガイド」: 実際にあなたのパソコンにAI秘書を立ち上げる手順。約30分で秘書が動き始めます。付録Cの秘書室テンプレートをCLAUDE.mdの核として使う構成なので、付録Cと合わせて読むと効率的です
• 付録C「育成マニュアルテンプレート集」: 15部署分のひな形と導入ロードマップ。Phase 1の3部署（秘書室・CEO・プロジェクト管理）から始めて、自社に必要な部署を順次追加していけます

付録D（品質基準）、付録E（業務手順書）、付録F（クイックリファレンス）、付録G（9つの性質詳細）も、本書各章で紹介した仕組みを実装するためのテンプレート・チェックリスト・詳細リファレンスとして用意しています。必要な場面で辞書のように引いてください。

最後に

第16章でお話しした通り、本書でお渡ししたのは「器」です。品質サイクル、チェックリスト駆動、部署分割、タスクライフサイクル。これらはすべて、あなたの業務とあなたの判断基準を入れるための器にすぎません。

この器に何を入れるかは、あなたが決めることです。あなたの業界の知識、あなたの会社の文化、あなたが大切にしている品質の基準。それを入れた瞬間、器はあなただけのAI組織に変わります。私のCC Companyのコピーではない、あなたの会社のAI組織です。

最初の1部署、最初の1つの品質サイクルを、今日回してみてください。そこから始まります。