立上げすぐの起業で人を増やすのは難しい、そこで部門を作りました。
理由は単純で、従業員を増やすと固定費がある。
ですが、人がいないと仕事が回らない。
複数案件をこなすと何をやっているのかわからなくなる。
例えば、
・提案の場で聞いた一言が、研修の教材に反映し忘れる。
・研修で出た質問を、次の提案の仮説に設定し忘れる。
担当者は最初から最後まで自分ひとりなのに、情報や知見が引き継がれていない。
中堅企業の現場でよく見る「部署の壁」は、
人数の問題ではなく、知見が渡る道が設計されていないという問題
なのだと、自分の会社で思い知りました。
一人会社の限界は、時間ではなく「切り替え」にある
午前に提案書を書き、午後に研修を設計し、
夕方に請求と支払いを処理する。
作業そのものにかかる時間より、
役割を切り替えるたびの立ち上がりのほうが重い。
そして切り替えた瞬間に、直前の役割で得たものが落ちます。
落ちたことにも気づきません。
記録が残らないからです。
時間を増やす方向で解こうとすると、
この問題は解けません。
切り替えの前提を変えるしかない。
そう考えて、会社の中に部門を置くことにしました。
組織図ではなく、フォルダとルールで部門をつくる
分け方の基準は
「知見が生まれる場所」と「知見を使う場所」です。
この基準で切ると、6つになりました。
- コンサルティング：案件の設計と実行／顧客別の提案・成果物・議事録
- 研修：研修の企画・設計・実施／カリキュラム、教材、実施記録
- ライティング：執筆・出版／原稿、企画書
- マーケティング：発信と接点づくり／投稿・記事・メルマガ・計測
- オペレーション：契約・請求・支払い・情報管理／契約書、請求、規程
- 共通資産（ナレッジ）：方法論・ひな形・用語の単一ソース／方法論、テンプレート、ブランド、知見集
実体は、フォルダの構造と、そこに置いた運用ルールだけです。
組織図ではありません。
そのうえで、部門ごとに「入口の問い」を決めています。
マーケティングの部門に入るときの最初の問いは、
「この施策は、誰のどの課題に、どの価値を約束するのか。停止条件は何か」。
オペレーションの部門なら、
「これは契約と個人情報の扱いとして問題ないか」。
同じ問いが毎回同じ順番で出るようにしておくと、
切り替えの立ち上がりが目に見えて短くなります。
頭の中でやっていたことを、部門の側に持たせただけです。
核は、知見が循環すること
部門を分けただけなら、分断が進むだけ。
核心は、部門をまたいで知見が回る道をつくることです。
- 顧客案件で実務をする
- そこから一次知見が出る
- 顧客の固有情報を落として抽象化する
- どの案件でも使える共通資産にする
- 研修・執筆・発信で外に出す
- それが次の相談・案件を呼ぶ
いちばん重要なのは3番目です。
ここを飛ばすと、資産化ではなく流用になります。
顧客の資料をそのまま別の顧客に見せることはしない。
一段抽象化して、構造だけを取り出す。
この工程は人にもAIにも任せていません。
そして、この3番目こそが
「顧客情報をAIに入れてよいのか」という問いに直結します。
答えは次回に書きます。
AIに任せたこと、任せなかったこと
任せているのは、調査の下ごしらえ、
下書き、形式の統一、抜け漏れの点検です。
任せていないのは、
・お客様と何を約束するか
・どの案件を受けるか
・顧客に出す成果物としてふさわしか
の最終判断です。
この仕組みの狙いは、速く安く作ることではありません。
一人でも判断の質を落とさないこと、
そして一度出した知見を二度と落とさないことです。
前者は経験で担保できますが、後者は仕組みでしか担保できませんでした。
これを構築してきた手順を連載で書きます
隔週で、実際に使っているルール、
うまくいかなかったところも含めて書きます。
第2回は「顧客情報をAIに入れてよいのか」。
守秘とガバナンスをどう設計したか、
判断の分かれ目を具体的に書きます。
第3回は、この知見の循環を、実際にどうフォルダに落としたか。
きれいに動いた話より、動かなかった話のほうが役に立つはずなので、
そちらを多めに書きます。
自社の業務をどこから仕組みにすればよいか迷っている段階でも構いません。
個別相談（壁打ち）でお話しください。
資料の準備は不要です。現状をうかがって、どこから手を付けると効くかを、その場で一緒に整理します。
