Claude Codeで「会社のDNA」を可視化した1年

属人化に限界を感じていた株式会社コミクス代表・鈴木章裕（すずき あきひろ）さんが、Claude Codeを使い倒し「鈴木仕様」の判断基準を32個のスキルへ言語化した1年間を振り返る。会社のDNAが初めて可視化されるまでの軌跡とは。

スタッフ退職で見えた属人化の限界

「鈴木さんじゃないとわからない」が多すぎた。提案書のトーンも、メール返信の温度感も、議事録の粒度も、ぜんぶ僕のなかにしかなかった。スタッフが悪いわけではない。僕が言語化してこなかっただけだ。

企業ごとに対応が異なる。丁寧な書面を好む企業もあれば、口頭で済ませたい企業もある。社内規定やマニュアルを作ろうとしたことは何度もあるが、実際に起きた場面には対応できないものができあがるだけだった。スタッフが初稿を作っても「ここが違う」という指摘が10カ所以上出て、結局全文書き直しになることも珍しくなかった。

2024年春、転機が訪れた。長年一緒に働いていたスタッフが退職したのだ。引き継ぎ期間は3週間。しかし「なぜこの順番か」「このクライアントにはなぜこのトーンか」という判断軸までは、とても時間内に伝えきれなかった。後任が仕事を覚えるまでの3カ月間、僕はほぼ全件をチェックし続けなければならず、新規商談の時間も気力も削られていった。「このままでは会社が僕に依存したまま成長できない」――そのとき初めて、強い危機感を覚えた。

「鈴木仕様」をスキルとして言語化

ちょうどその頃、Claude Codeの存在を知った。転機になったのは、知人の経営者の一言だった。「プロンプトをファイルに保存すれば、自分の仕事の仕方をチームで使い回せる」。この一言で見え方が変わった。「僕の判断基準」「僕の文章トーン」を書き出し、誰でも呼び出せる状態にする――それが「スキル化」の本質だと気づいた。

最初に作ったのは提案書スキルだ。文体ルール、構成、禁止事項まで細かくプロンプトに落とし込み、Markdownファイルとして登録した。初めてスタッフが使ったとき、「これ、鈴木さんが書いたのかと思いました」と言われた。これだと思った。

次に取り組んだのは、メール返信のトーン管理だ。5年つきあいのある企業と、商談2回目の企業では、当然温度感が変わる。過去2年分の送信メールを企業別に抽出し、Claude Codeに文体プロフィールを分析させたところ、「A社へは必ず近況確認から書き出す」「苦情対応は謝罪、共感、解決策の順」など、自分でも気づいていなかった癖まで言語化された。以降、スキルは提案書、メール返信、議事録の次アクション抽出、月次レポートの構成、採用面談の評価コメントへと広がった。

個人のローカル環境に留めず、GitHubに全スキルを保存し、スタッフが改善提案を出す仕組みも作った。「あのスキル使った？」という会話が自然に生まれ、「鈴木さんのやり方」がチームの共通言語になっていった。現在、スキルは32個になった。これは同時に、32個の「鈴木仕様の判断基準」が言語化されたということだ。

1年間で変わった数字と役割

提案書作成は、僕が1〜2時間かけていた作業がスタッフの初稿30分＋レビュー15分に短縮され、月15〜18時間、年間200時間以上が戻ってきた。メール対応は月30時間から月5時間へ、確認待ちの案件は月平均12件から3件に減った。商談翌日まで抜け漏れが出ていたフォローアップも、当日中の共有でほぼゼロになり、複数のクライアントから「連絡が早い」という声をもらえるようになった。新入社員のオンボーディングも、以前は5〜6カ月かかっていたが、スキル集を使った最近のスタッフは3カ月で一人前になった。

数字以上に大きかったのは、僕自身の仕事の定義が変わったことだ。以前は「クオリティを保証するために全件チェックする人」だった。今は「スキルの品質を上げ続ける人」「AIに任せない領域を守る人」だ。感情が重要な場面――クライアントとの信頼関係が必要な交渉や、スタッフが落ち込んでいるときは、今もあえてスキルに任せていない。どこをAIに渡し、どこを自分でやるか。その判断自体が、経営者の仕事だと思う。

もうひとつ気づいたことがある。スキルとして言語化された判断基準は、将来の事業承継の準備にもなるということだ。「こういうとき、鈴木ならどう判断するか」を言葉だけで伝えるのは限界があるが、スキルなら後継者が読み込んで学べる。32個のスキルは、いまの効率化であると同時に、この先の会社の資産でもある。

属人化は悪ではない。むしろその人の価値観が染み込んだ仕事は強みだ。問題は、それが一人の頭にしか入っていないことだった。この1年、僕がやってきたのは、その強みをチームに広げる作業だったのだと思う。あなたの会社のDNAも、きっとコードにできる。