slidictとは？

slidictは、もともとエンジニア同士の情報共有をもっと軽くできないか、という思いから始まりました。

会社員時代、ちょっとした知見や調査結果を共有したい場面は多くありましたが、
Wikiやドキュメントは重くなりやすく、「書くまでのハードル」が高いと感じていました。

その中で、「数枚のスライドでサクッと共有できる形」があれば、
もっと知識共有が自然に回るのではないかと考えるようになりました。

また、個人開発やOSS、技術検証など、
エンジニアには発信したい内容が日々大量にあります。

しかし実際には、
記事を書くのが大変だったり、
デザインを整えるのが面倒だったりして、
発信が止まってしまうケースも多いです。

slidictでは、
AIによる補助やテンプレート化によって、
「作る大変さ」を減らし、
もっと気軽にアウトプットできる世界を目指しています。

スライド形式を重視している理由は、
「短時間で理解しやすい形」に向いていると考えているためです。

長文の記事は情報量を多く載せられる一方で、
読む側にも一定の集中力や時間が必要になります。

一方、
スライド形式では、
1ページごとに情報を区切れるため、
全体像を素早く把握しやすくなります。

また、
箇条書きやdiagramを使うことで、
文章だけでは伝わりづらい構造や流れも、
直感的に説明できます。

さらに、
エンジニア同士の情報共有では、
「全部をしっかり読む」というより、
まず流し読みして必要な部分だけ深掘りするケースも多いと感じています。

そのため、
SNSやチャットに貼られた際にも、
軽く眺めながら内容を把握しやすい形を目指しています。

slidictでは、MarkdownやAsciiDocを使ってスライドを作成できます。

一般的なスライドツールのようにGUI中心ではなく、
テキストベースで管理できることを重視しています。

そのため、
文章を書く感覚に近い形で、
スライドや図を編集できます。

また、
スライドだけでは補足しきれない内容については、
記事形式で詳細を書けるようにしています。

「まずは数枚のスライドで共有し、
必要なら深掘りする」という流れを想定しています。

diagramについては、
krokiを利用することで、
MermaidやPlantUMLなどの図をテキストとして管理できます。

画像を毎回作り直す必要がなく、
文章を編集する感覚で図を更新できます。

さらに、
スライド自体にも変更履歴を持たせることで、
「どのように内容が変化していったか」も管理可能にしています。

用途については、
最初から「しっかりしたプレゼン資料」を作ることだけを想定しているわけではありません。

むしろ、
日々の開発の中で出てくる、
ちょっとした知見やメモを、
気軽に残せることを重視しています。

例えば、
技術的にハマったことを共有したり、
個人開発やOSSの内容を軽く紹介したり、
LT資料をまず雑に作って後から育てたりする使い方です。

また、
調べた内容や検証ログを、
自分用メモとして残しておき、
必要になったらそのまま共有できる形も想定しています。

「完成された資料を作る」というより、
まずアウトプットを始めやすくすることを大事にしています。

今後については、
まだかなり試行錯誤している段階です。

特に、
「最初から完成された資料を作る」のではなく、
雑に作ったメモをあとから少しずつ育てていける形にしたいと考えています。

また、
面白い技術情報が自然と集まり、
気軽に眺められる場所にもしていきたいと思っています。

現在は、
スライドと記事を分けて考えるのではなく、
行き来しながら知識を整理できる形も模索しています。

AIについても、
単純な自動生成というより、
壁打ちしながら一緒にスライドを作れる体験を作りたいと思っています。

ただ、
このあたりはまだ「これだ」というUXが固まっておらず、
試しながら考えている段階です。

また、
URLやGitHubから自然にスライド化する仕組みも考えていますが、
単なる模倣コンテンツにならない形をどう作るかは悩んでいます。

diagramについても、
現状はコードを書く必要があるため、
もっと直感的に扱えるように改善したいと考えています。