スライドでチーム内のナレッジ共有を加速する：2ヶ月、ひとりから始まったアウトプット文化が定着するまで

2026年2月、株式会社ビズリーチに「AI Product Studio（以下、APS）」が新設されました。「AIでプロダクト創出を常態化する」をミッションに、AIを前提としたプロダクト開発のあり方と新規プロダクトの立ち上げに取り組んでいる組織です。

私は2022年に新卒入社し、複数プロダクトの立ち上げを経て、APSへ異動しました。

この記事では、APSに異動してから2ヶ月間で私がオーナーシップを持って進めた、スライドを軸にしたチーム内ナレッジ共有の取り組みについて書きます。Agent Skill「lt-marp」と共に自分自身が火付け役となり、累計69本のスライド資料が生まれ、その一部を週次のLT会で発表する流れも定着しました。

AI駆動開発への転換期において、個人の試行錯誤をどれだけ早くチームの知識に変えられるかが、組織の競争力を分ける要素になってきていると感じています。本記事はその一例として読んでいただければと思います。

異動して最初に考えたこと

APSのミッションは、AIでプロダクト創出を常態化することです。そのためには、まず私たち自身がAI駆動開発を実践と検証を通じて磨いていく必要があります。一方で、AI駆動開発まわりの動きは速く、新しいツール・モデル・ワークフローが毎週のように登場します。

異動してすぐ強く感じたのは、個人がいくらキャッチアップしても、それだけではチームの開発速度には直結しないということでした。

AI駆動開発で効いてくるのは、ツールそのものより、知っているかどうかです。

• あるツールや概念の存在を知らなければ、そもそも選択肢として検討にすら入らない
• ある実装パターンを知らなければ、自分の問題に応用することもできない
• ある制約や落とし穴を知らなければ、同じ失敗を繰り返してしまう

知らないことすら知らない状態（いわゆるUnknown Unknowns）をどれだけ早く減らせるかが、AI時代のチームの差になると考えました。

知識のメタ認知マトリクス ※4象限の枠組みはラムズフェルド発言を起点に広く知られる概念をもとに作成

私自身、入社してからこれまで、チーム内勉強会の運営や、モブプログラミングを軸に属人性を下げる開発に取り組んできました。ただ正直に書くと、定常的に発信してくれる人を増やすのは難しい、というのが過去の実感です。

• 発表のための試行錯誤に余力が割けない
• 資料化が重い（Googleスライドを真面目に作ると数時間かかる）
• 発信する人がいつも同じメンバーに偏る
• 学びが個人の経験のまま、チームの資産にならない

AI時代になってもここを放置すると、AIによる開発の加速が局所最適に終わってしまうおそれがあります。

それを防ぐために、私は次の二つが重要だと考えました。

一つは、個人の試行錯誤をチームのナレッジに変換する速度を上げること。Unknown Unknownsをチーム全体で早くKnown Unknownsに変えるほど、AI駆動開発の伸びしろが活きます。

もう一つは、アウトプット駆動の文化を作ること。アウトプットすること自体が、書き手にとって最も強い学習装置になります。資料化の過程で自分の理解が構造化され、書き終わった資料は個人ログとしても、他メンバーの探索の入口としても機能する。それ以上に大きいのは、共有するというゴールが先にあること自体が、書き手をいろいろな実験へと駆り立てる点です。来週のLTで話せそうなネタを探そう、という前提があるだけで、日々の試行錯誤の量と方向性が変わります。アウトプットすることが特別ではなく普通のチームになる、という状態を作りたいと考えていました。

この2つを同時に成立させる仕組みとして、まず手をつけたのがスライドでした。

なぜスライドだったのか

チームへの共有手段はいくつもあります。それぞれの長所と短所を考えたうえで、私はスライドを選びました。

スライドの強みは、大きく2つあると考えています。

1つ目は、1スライド1メッセージという制約です。これはプレゼンテーション設計で長く知られたプラクティスですが、LLMにも効くガードレールとして再評価できます。コーディング領域では、AIに対する足場や制約を専門領域として扱うハーネスエンジニアリングの考え方が一般化していますが、1スライド1メッセージは、その発想を資料作成にそのまま当てはめたものとも言えます。情報量の上限が物理的に決まっているため、何を残して何を捨てるかの判断が強制されます。LLMにドキュメントを書かせて、ぼんやり長くて読む気が失せる出力が返ってきた経験はないでしょうか。同じLLMでも、1スライドにまとめてと指示するだけで、情報がぐっと圧縮されます。俳句や昔のTwitterの140字制限と同じで、制約が言葉を研ぎ澄ます原理はLLMにも働きます。

2つ目は、スライドが人間の理解に最適化されたフォーマットである点です。「1枚＝1メッセージ」「見出し＋本文」「図表中心」という構造は、読み手が短時間で要点を掴めるよう長年磨き込まれてきました。さらに、PDFに書き出した瞬間に共有可能な成果物になるため、一次コミュニケーションがそのまま共有物として流通します。

AIによって、文字を書き出すコスト自体は大きく下がりました。代わりに重要度が増したのは、何をどうシャープに伝えるか、という中身の質の部分です。フォーマットや共有設計も引き続き重要ですが、最終的にクリティカルなのは、伝える内容そのものの解像度だと考えています。

PDFは人間に、MarkdownはAgentに

スライドを採用するうえで、もう一つ意識した設計があります。それは、MarkdownをSingle Source of Truth (SSoT) にすることです。

私たちのチームでは、スライドをMarkdownで書き、それをMarpでPDFに変換しています。MarpはMarkdownで書くスライドツールで、ビルドするとPDFが生成されます。重要なのは、元データがMarkdownのテキストで残ることです。

これは単にGitで差分管理できて便利という話を超えて、AI時代に効く設計だと考えています。

従来の資料共有は、読んで理解するためのものでした。AI時代の資料はそれだけでは終わりません。他のメンバーが、そのMarkdownを自分のプロジェクトのAgentに渡して、深掘りしたり再利用したりする素材になります。資料の受け手が、人間とAgentの2種類に増えたとも言えます。

たとえばあるメンバーがFeature Flagについてのスライドを書いてくれたとします。私がそのトピックを自分のプロジェクトに導入したいと思ったとき、PDFを読むだけでなく、Markdownを自分のAgentに渡して、これを踏まえてこのリポジトリで設計案を出して、と頼むことができます。資料は読まれて終わりではなく、次のAgentのコンテキストになるわけです。

この発想を実装に落とすために作ったのが、次に紹介するSkillです。

lt-marp Skill：会社フォーマットで生成する3つの肝

まず、Agent Skillとしてlt-marpを作りました。起動したAgentの中で /lt-marp を実行すると、Skillが呼び出され、対話しながらスライドを生成します。出力は社内テンプレートに沿ったMarp形式のMarkdownで、ビルドすると、ビズリーチのコーポレートカラーやロゴを反映した社内向けPDFになります。

Skillを設計するうえで意識した点は、3つに整理できます。

(a) 会社フォーマットに揃えて認知負荷を下げる

会社フォーマットに合わせた理由は、見た目の統一というより認知負荷の削減のためです。AI生成物は放っておくとフォーマットがばらつきます。聴衆は、内容そのものよりもフォーマットの細かなズレ（フォントが違う、配色が違う、レイアウトが揃わない）に意識を奪われ、肝心の中身に集中しづらくなります。普段見慣れているテンプレートに合わせれば、その認知コストを下げ、内容に注意を向けてもらうことができます。

(b) コンポーネントを良い制約として設計する

Skillには、使えるコンポーネント（2x2マトリクス、ピラミッド、タイムライン、KPIカード、Mermaid図、棒グラフ・折れ線グラフ等）の実例集と、用途別の早見表を同梱しています。

ここでは、スライドで使うコンポーネントの一例をお見せします（スライドテンプレート自体は社内仕様のため、ここではコンポーネント部分のみ掲載しています）。

lt-marpで生成されるコンポーネントの例

Agentはスライドを書き始める前に、必ずこの実例集と早見表を参照する設計です。新しいコンポーネントを追加する際は、実例集にも例を追加します。実例集をSingle Source of Truthとして運用することで、Agentも人間も同じリファレンスを見て資料を作れる状態になりました。

自由に資料を作ってと頼むよりも、用意されたコンポーネントから選ばせる方が、品質と一貫性が両方上がり、人間側のレビューコストも下がります。

(c) 2フェーズに分けて、AIをコンテンツ設計から走らせる

/lt-marp を実行すると、Agentはすぐにスライドを書き始めません。まずフェーズ1として、次のような項目を順にヒアリングします。

• トピック・テーマ
• 発表時間
• 対象者（エンジニア全員か、特定チームか）
• 一番伝えたいこと

そのうえで、トピックに外部サービスや技術が含まれる場合は関連情報調査も行い、アウトラインを出力します。総スライド数、各スライドで何を伝えるか、どのコンポーネントを使うか、想定時間、というレベルまで具体化された設計書です。ここでユーザーが承認してから、フェーズ2のスライド実装に進む流れにしています。

lt-marp の2フェーズ実行

やってみて起きたこと

仕組みを作っただけでは文化は生まれません。私自身が率先して、ほぼ毎日スライド資料を作り、チームに共有しました。

具体的には、異動してすぐの段階で、それまで自分で温めていた検証ネタを一気に資料化し、1日で数本のスライド資料を投下しました。その後も数週間、ひとりでスライド資料を出し続けました。資料の質は100%でなくていい、70%でも共有するというスタンスで、未完成・試行錯誤の状態のままチームに流しました。これは外向きにも、完成度を待たないという規範を作るためでした。

実際にリポジトリ内のスライド資料の本数を、7名のメンバーで週ごとに集計するとこうなります。

週ごとのスライド資料投下本数

最初の3週間は私が中心ですが、4週目以降は完全に主役が交代しています。週10本前後のLTが他メンバーから生まれ、私の本数は1本に落ち着きました。発表者の顔ぶれも特定の数名に偏らず、週ごとに複数のメンバーが入れ替わりで資料を出しています。仕組みと火付け役が揃うと文化は自然に伝播していく、ということを数字で確認することができました。

題材も多彩でした。AI駆動開発のトレンドに加えて、開発基盤・運用・品質・検索・プロダクト運営から、社外発表や業務外の話題まで、事業ライン横断のテーマや業務外のトピックも含めてスライド資料が生まれるようになりました。

並行して、毎週のLT会も定着しました。蓄積された資料のなかから今週話したいものを各自が選び、発表する形式です。発表しなくてもPDFが共有されている時点で資料は読めるため、前述の最初から共有前提というスライドの強みが活きている部分だと感じています。

学び

2ヶ月この仕組みを動かしてみて、いくつか学んだことがあります。

一つ目は、仕組みと規範はセットでないと動かないということです。lt-marpだけ用意しても、誰も使わない可能性は十分にありました。私自身がほぼ毎日資料を出し続け、完成度を待たずに共有するという規範を体現したことで、チームメンバーもより /lt-marp を叩くようになりました。仕組みを置くだけでは文化にはならない、ということを改めて実感しました。

二つ目は、AI時代の資料は次のAgentのコンテキストになるということです。最初は人間が読むためだけを考えていたのですが、Markdownを元データとして運用したことで、他メンバーのスライド資料が自分のAgentへの入力としても使えるようになりました。資料が連鎖して別の資料を生むという流れが見え始めています。

うまくいかなかったこと

すべてが上手くいったわけではありません。残っている課題も正直に書きます。

• 読む側にも時間が要ります。共有のコストは下げられましたが、受け取って咀嚼する側のコストは存在します。ここは未解決です
• 最初の一歩としてSkillを叩いてもらうまでが、いちばんの山でした。私が日々使い倒している様子を見せ続けることで、次第に他メンバーも /lt-marp を叩くようになりました
• AIに任せきりで出てきた資料は、そのままだと微妙になることがあります。記事作成と同じで、人間が「何を一番伝えたいか」をシャープにしてからAIと一緒に練り上げるフェーズは、結局のところ省けません

これらは続けながら直していくテーマだと考えています。

おわりに

AI時代の競争力は、AIを使えること自体ではないと感じています。個人の試行錯誤を、どれだけ早くチーム全体の知識に変換できるか。Unknown UnknownsをKnown Unknownsに変えていく速度です。

そのために私たちがAPSで実装したのは、次のような構造でした。

仕組み：

• スライドを共有の標準フォーマットにする（1スライド1メッセージという制約をガードレールに）
• Markdownを元データに、PDFを人間向けの書き出しとして扱う（受け手を人間とAgentの2系統に分ける）
• Skillで会社フォーマットを再現可能な制約にする（コンポーネント制約、実例集駆動、2フェーズ実行）

規範：

• 完成度を待たずにほぼ毎日共有する状態を、自分が先に体現する

仕組みだけでも、規範だけでも、文化にはなりません。両方を揃えた結果、2ヶ月で69本というスケールに育ちました。

ビズリーチが所属するVisionalグループには、「変わり続けるために、学び続ける」というバリューがあります。今回の試みは、その学び続ける営みを、AIを前提とした時代に合った形でチームに実装した一例だと考えています。

AI Product Studioでは、AIを前提とした開発を、自分たちのチームで日々検証しています。少しでも面白いと感じていただけた方は、ぜひ採用情報からご確認ください。

ビズリーチでは、新しい仲間を募集しています。

お客様にとって価値あるモノをつくり、働く環境の変革に挑戦する仲間を募集しています。
募集中のポジションやプロダクト組織の詳細は、ぜひキャリア採用サイトをご覧ください。

• BizReach
• AI
• Culture

内田 大暉

2022年新卒エンジニア。プログラミング、プロダクトづくり、コンピュータが好きです。