第16章: 「仕組み」と「成果物」を分けて考える

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

以下の問いに答えてみてください。

• AI社員の品質サイクルや部署分割は「誰が使っても同じように機能する」仕組みだと認識している
• 自分の会社で作っている記事・資料・提案書は「仕組みの上に載せる成果物」だと認識している
• 仕組み（業務手順書やチェックリスト）を更新するときと、成果物（記事や資料）を更新するときで、やるべきことが違うと分かっている
• 自社のAI活用の仕組みを他社にも提供できる可能性を考えたことがある
• 「仕組みは一度作れば使い回せる。成果物は毎回変わる」という感覚がある

全部チェックが付いた方: 「仕組みと成果物の分離」を直感的に理解しています。この章で、その直感に言葉と構造を与えましょう。

1〜3個の方: AI社員は動いているが、仕組みと成果物が混ざった状態かもしれません。この章で整理すると、次に何をすべきかが見えやすくなります。

チェックがゼロの方: まだ仕組みを作っている途中の段階です。ただし、この考え方を先に知っておくと、仕組みを作るときの設計判断が良くなります。

仕組みの改善にハマって、成果物が止まった

CC Company（シーシーカンパニー）の運用が軌道に乗り始めた頃、ある週に異変が起きました。

note記事のストックが、目標の7本に対して3本まで落ちたのです。

記事を毎日1本投稿するペースで運用していたので、ストック3本は3日分。投稿が止まるまであと3日しかない。なぜこうなったのか振り返ってみると、原因は明確でした。その週、私は1本も記事を書いていなかったのです。

では何をしていたかというと、品質サイクルの改善、業務手順書の作り直し、ワークフローの再設計。つまり「仕組み」ばかり磨いていました。チェックリストの項目を見直し、レビューの手順を整え、新しいスキルを設計する。やればやるほど仕組みは良くなる。でも、肝心の記事が1本も出ていない。

これは「業務効率化ツールの設定に1日かけて、本来の仕事が何もできなかった」という現象と同じです。もし思い当たる方がいたら、この章はきっと役に立ちます。

2つの異なるものが混在している

ストックが3本に落ちた原因を整理してみると、単純な時間配分の問題ではありませんでした。そもそも、自分が2種類のまったく異なる作業をしていることに気づいていなかったのです。

品質サイクルの改善と、note記事の執筆。どちらもCC Companyの仕事です。でも、性質がまったく違います。

品質サイクルは、一度作れば記事にもSNS投稿にも講演スライドにも使い回せます。これは「仕組み」です。一方、note記事のテーマや内容は毎回変わります。これは「成果物」です。

川島さんの会社でも同じことが起きるかもしれません。AI社員の導入が進み、チェックリストを作り、品質サイクルも回り始めた。すると「チェックリストの書き方をもっと良くしよう」「手順書をもっと整理しよう」と、仕組みの改善にハマってしまう。気がつけば、本来やるべき見積書や報告書が後回しになっている。「先週、見積書を1つも出せなかったんですよね」と苦笑するような状況です。

仕組みの改善は楽しいのです。目に見えて整っていくから達成感がある。でも、仕組みだけ磨いても売上は1円も上がりません。仕組みの上で動く「成果物」を作って初めて、仕事として完成する。

「全部100点満点だと思っていた」混乱の正体

仕組みと成果物が混ざっている状態の具体例を、もう1つ紹介します。

CC Companyでは、すべての成果物に品質チェックの仕組みがあります。ある時期まで、私はこれを「どれも100点満点で評価している」と思い込んでいました。ところが実態を調べてみると、まったく違ったのです。

• note記事: 100点満点の採点式（80点以上で合格）
• SNS投稿（X（エックス）、Facebook（フェイスブック））: 18〜19項目の合否式（全項目合格で通過）
• 講演スライド: 130点満点のペルソナ満足度評価（90点以上で合格）

採点のやり方が全部違う。「合格基準を先に決めて、チェックして、不合格なら修正して、再チェックする」という手順は全部同じなのに、チェックリストの中身はまったく別物でした。

この瞬間に気づいたのです。品質サイクルは「仕組み」であり、チェックリストの中身は「成果物」なのだと。

Excel（エクセル）とExcelファイルの関係を想像してみてください。Excelの「表を作る」「計算する」「グラフを描く」という機能は、経理部で使っても営業部で使っても同じように動きます。でも、経理部の売上表と営業部の顧客リストは、中身がまったく違います。Excelを更新してもデータは消えないし、データを更新してもExcelの機能は変わらない。この2つは独立して進化するのです。

AI社員の組織も同じ構造でした。品質サイクル、チェックリスト駆動、部署分割、タスクライフサイクル。これらは誰が使っても同じように機能する「仕組み」です。note記事のテーマ、講演の事例、提案書の内容。これらはあなたの仕事に特化した「成果物」です。

分離して気づいた3つのこと

仕組みと成果物を意識的に分けて管理するようにしたら、3つの変化が起きました。

仕組みは一度作れば、何種類もの仕事に使い回せる

CC Companyで最初に品質サイクルを作ったのは、note記事のためでした。でもこの「合格基準を先に決める、チェックする、不合格なら修正する、再チェックする」という手順は、SNS投稿にも、講演スライドにも、提案書にもそのまま適用できました。チェックリストの項目だけが変わり、手順そのものは変わらない。

新しい種類の仕事が増えても、仕組みを作り直す必要はありません。新しいチェックリスト（成果物側）を追加するだけです。料理のレシピ帳に新しいレシピを追加しても、キッチンの設備を入れ替える必要がないのと同じです。

成果物が毎回変わっても、品質が安定する

note記事のテーマは毎回違います。月曜は「AI導入で社員を責める前に見直すべき3つの仕組み」、火曜は「AIツール5つで仕事が遅くなった経営者が1つに絞った結果」。内容はまったく違いますが、品質チェックの仕組みがあるので、どちらも一定水準の品質が保たれます。

川島さんも、品質チェックの手順が定着した頃に同じことに気づきました。「見積書も報告書も社内メールも、同じ手順でチェックできている。手順は同じなのに、中身が違うだけなんだ」と。この「気づき」が、仕組みと成果物の分離を自分のものにする瞬間です。

仕組みは他の会社にも渡せる

ここが最も重要なポイントです。

品質サイクル、チェックリスト駆動、部署分割。これらの仕組みは、あなたの会社だけでなく、別の会社でも使えます。なぜなら、仕組みの中にはあなたの仕事の具体的な内容が入っていないからです。

成果物はあなたにしか作れません。川島さんの会社の見積書は川島さんの会社のものだし、CC Companyのnote記事はCC Companyのものです。でも、成果物の品質を管理する仕組みは、どちらの会社でも同じように使えます。

1968年にメルヴィン・コンウェイ（Melvin Conway）が「組織の設計するシステムは、その組織のコミュニケーション構造を反映する」という法則を提唱しました（「How Do Committees Invent?」（委員会はどのように発明するのか?）, Datamation誌, 1968年）。この「コンウェイの法則」は、仕組みと成果物の分離を裏付ける視点を持っています。仕組み（組織構造）は汎用的に設計できるが、その上で作られる成果物は各組織のコミュニケーション構造に依存する。だからこそ、仕組みは渡せるけれど、成果物は各社が自分で作る必要があるのです。

仕組み2割、成果物8割のリズムを作る

仕組みと成果物の分離に気づいてから、CC Companyでは時間配分のルールを作りました。

仕組みの改善は全体の10〜20%。残りの80〜90%は成果物の制作に使う。

冒頭で紹介した「ストック3本まで落ちた」失敗は、この比率が逆転していたから起きたのです。仕組みの改善に80%以上の時間を使い、成果物の制作が20%以下になっていた。

日々の運用で「今やっているのは仕組みの改善か、成果物の制作か」を意識するだけで、このバランス崩れに早く気づけるようになります。仕組みの改善は、品質の劣化が見えたとき（第13章で学んだ健康診断）や、新しい業務が増えたときにまとめて行う。普段は成果物を作ることに集中する。このリズムが安定すると、記事のストックも講演資料の準備も滞らなくなりました。

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

個人: まずは自分のAI活用を「仕組み」と「成果物」に分けてみてください。「ChatGPT（チャットジーピーティー）にこう聞く」は成果物寄りの作業です。「聞いた結果を必ずチェックリストで確認する」は仕組み寄りの作業です。分けて意識するだけで、「あ、今週は仕組みばかり触っていて、肝心の仕事が進んでいない」と気づけるようになります。

チーム: チーム内で「共通の仕組み」と「各自の成果物」を分離してください。川島さんの会社でも実践が始まりました。品質チェックの手順やレビューの基準をチーム共通の仕組みとして定義し、各メンバーが扱う案件や担当業務は各自の成果物として管理する。仕組みを共通化すると、メンバーが異動しても品質が維持されます。新人が入ってきたときも、仕組み（手順書）を渡せばすぐに同じ品質で仕事ができる。

組織: 全社の「AI活用プラットフォーム」を定義してください。品質サイクル、タスク管理、レビュー体制を全社共通の仕組みとして整備し、各部署がその上で自部署の成果物を作る。仕組みの更新は全社に影響するため慎重に行い、成果物の更新は各部署の裁量で進めます。2019年に出版された書籍『Team Topologies』（チームトポロジーズ）（マシュー・スケルトン（Matthew Skelton）、マニュエル・パイス（Manuel Pais）著, IT Revolution Press）では、この考え方を「プラットフォームチーム」として体系化しています。仕組みを専門に管理するチームと、成果物を作るチームを分けるという設計です。

コラム: 書籍の売り方をAI社員と考えたら、売り方自体が成果物になった

CC Companyで書籍「AI社員の育て方」の販売戦略を検討していたとき、面白いことが起きました。

6部署に「この本をどう売ればいいか」と投げたのが、第15章で紹介した全社ブレストです。各部署が専門的な視点から提案を出し、秘書がまとめ、第三者がレビューする。約7分で統合レポートが上がってきました。

レポートを見て「良い案が並んだな」と思ったのですが、第三者レビューで指摘されたのはこの一言でした。「良い案が並んだ状態と、戦略が収束した状態は別物です」。鋭い指摘でした。

でも、ここで重要なのは案の良し悪しではありません。この検討プロセス自体が、見事に「仕組み」と「成果物」の分離を体現していたことです。

仕組み（変わらない）: 全社ブレスト、部署並行提案、統合レポート、第三者レビュー。この進め方は、テーマが「書籍の売り方」でも「新サービスの価格設計」でも同じです。

成果物（テーマごとに変わる）: 「講師仲介会社への書籍送付計画」「クライアント企業での導入実証事例の公開」「記事への相談導線の標準化」。これらは「書籍の売り方」というテーマだから出てきた具体策です。

ところが、この検討プロセスを記録していたら、もう1つのことに気づきました。「AI社員と一緒に本の売り方を考えた」というプロセス自体が、読者に見せたい成果物になっている。

仕組みを動かした過程を記録したら、それ自体がCC Companyが動いている証拠になり、note記事のネタ（新しい成果物）になる。

これが「仕組みと成果物の分離」の面白さです。仕組みを通じて成果物を作ると、作るプロセス自体が次の成果物を生む。成果物が成果物を生む構造です。

LLM（Large Language Model：大規模言語モデル）知識: プロンプトエンジニアリングとプロンプトプログラミング

この章で紹介した「仕組みと成果物の分離」は、AIの世界では「プロンプトエンジニアリング」と「プロンプトプログラミング」の違いとして議論されています。

プロンプトエンジニアリングとは

「プロンプトエンジニアリング」は、AIに渡す指示文（プロンプトと呼ばれるもの）を工夫して、より良い出力を得る技術です。たとえば「要約してください」より「3行で要約してください。箇条書きで」と書いた方が、期待に近い結果が返ってきます。

これは本書で言う「成果物」の領域です。今回の記事のテーマに合わせて、指示文を調整する。毎回、指示文が変わる。

プロンプトプログラミングとは

一方、「プロンプトプログラミング」は、AIへの指示文をソフトウェアのように設計する考え方です。2025年に発表されたプレプリント論文「Promptware Engineering: Software Engineering for LLM Prompt Development」（プロンプトウェアエンジニアリング：プロンプト開発へのソフトウェア工学の適用）（チェンら（Zhenpeng Chen et al.）, Nanyang Technological University / Peking University / Microsoft（マイクロソフト）, arXiv:2503.02400）では、プロンプト開発にソフトウェア工学の原則（要件定義、設計、テスト、デバッグ、保守）を適用するフレームワークが提案されています。

プロンプトプログラミングの核心は、再利用可能なテンプレートを作り、変わる部分だけを差し替えるという発想です。

これは本書で言う「仕組み」の領域です。業務手順書は、品質チェックの手順やフォーマットを固定し、記事のテーマやクライアント名だけが変わる。手順書の構造（プログラム）は再利用し、成果物（データ）だけが変わる。

CC Companyでの実装

本書で紹介してきたAI社員の仕組みは、まさにプロンプトプログラミングの実践です。

プロンプトエンジニアリングは「良い指示を出す技術」。プロンプトプログラミングは「良い指示を出す仕組みを作る技術」。

個人でAIを使うならプロンプトエンジニアリングで十分です。しかし、組織でAIを使うなら、プロンプトプログラミング（仕組みの設計）が必要になります。なぜなら、「Aさんが出す指示は良いけど、Bさんが出す指示はダメ」では、組織として品質が安定しないからです。

手順書に従えば、誰が実行しても同じ品質が出る。これがプロンプトプログラミング（仕組み化）の価値です。

なぜ今この考え方が重要なのか

現在のAI活用は、まだ「プロンプトエンジニアリング（指示の工夫）」が主流です。しかし学術研究の分野では、「プロンプトプログラミング（仕組みの設計）」への移行が始まっています。

先述のチェンら（2025）の論文でも、プロンプト開発のほとんどが「試行錯誤ベース」であり、「体系的な手法がない」ことが課題として指摘されています。本書の手順書化、品質サイクル、チェックリスト駆動は、まさにこの課題への実践的な回答です。

AIが進化しても、「仕組みで品質を担保する」という考え方は変わりません。具体的なプロンプトの書き方は時代とともに変わりますが、「手順書を作り、品質をチェックし、合格するまで繰り返す」というフレームワークは普遍的です。

まとめ

• 仕組みの改善にハマると、成果物が止まる。「今やっているのは仕組みか、成果物か」を常に意識する
• 品質サイクルは「仕組み」、チェックリストの中身は「成果物」。ExcelとExcelファイルの関係と同じ
• 仕組みは一度作れば使い回せる。新しい成果物が増えても、仕組みは変わらない
• 仕組みは他の会社にも渡せる。成果物は各社が自分で作る
• 仕組みの改善は全体の10〜20%。残りの80〜90%は成果物の制作に使う
• 学術的には「プロンプトエンジニアリング（指示の工夫）」から「プロンプトプログラミング（仕組みの設計）」への移行が始まっている
• AIが進化しても「仕組みで品質を担保する」考え方は普遍的