---
title: 個人開発から切り出す個人開発で一石二鳥しよう
tags: 
author: [hirotaka kono](https://image.docswell.com/user/hk_it7)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/GJ5MZX5MJ4.jpg?width=480
description: # 個人開発から切り出す個人開発で一石二鳥しよう！  個人開発LT祭 2026年 / 虎の穴ラボ 河野裕隆 (@hk_it7)  ## このスライドについて  個人開発のポータルサイトを「実験場」として、そこで使った部品を npm パッケージに切り出して公開する開発スタイルを紹介するLTです。  ひとつの開発時間で、 - 自分のためのサイトが充実する - 世の中に OSS が増える という「一石二鳥」を狙えます。  ## 紹介する個人開発  - 🌐 ポータルサイト: https://kouno-log.pages.dev/ - 📦 rough-table … HTML テーブルのボーダーを手書き風に描画する vanilla JS ライブラリ   - https://www.npmjs.com/package/rough-table - 📦 astro-site-shell … サイト上に擬似ターミナルを置いてナビゲーションできる Astro コンポーネント   - https://www.npmjs.com/package/astro-site-shell - 📦 site-shell-core … astro-site-shell からフレームワーク非依存部分を切り出した v0.2.0   - https://www.npmjs.com/package/site-shell-core  ## 話していること  - ポータルサイト中心の個人開発スタイル - 「装飾は別レイヤー / 本体は HTML のまま」という Apple "MacBook Neo" LP から得た設計の着想 - 切り出しやすいコードの "型" 3つ   1. フレームワーク依存は薄い殻に閉じ込める   2. 設定は引数で受け取る   3. DOM・グローバルを汚さない / 後始末できる - 個人開発は「2回目で切り出してもいい」— Rule of Three より早く動ける理由 - dogfooding が生んだ実例: LT 準備中に rough-table のバグを発見し、0.1.2 → 0.1.3 を即日リリース  ## 補足  このスライド上で動いているターミナルデモは、astro-site-shell から 切り出した site-shell-core を Slidev (Vue) に載せたものです。 LT スライド本体が「もうひとつの切り出し成果物」になっています。
published: May 22, 26
canonical: https://image.docswell.com/s/hk_it7/KGNQLP-personal_project
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/GJ5MZX5MJ4.jpg)

個人開発から切り出す
個人開発で一石二鳥しよう！
個人開発LT祭 2026年
「自分のために作ったもの」を「みんなのため」にも届ける
kouno-log.pages.dev


# Page. 2

![Page Image](https://bcdn.docswell.com/page/9E29RXNR7R.jpg)

自己紹介
河野 裕隆
虎の穴ラボ 通販チーム テックリード
🐦 X: @hk_it7
🌐 kouno-log.pages.dev
📋 今日話すこと
🌐 ポータルサイト中心の個人開発スタイル
📦 そこから切り出した npm パッケージ 2 つ
💡 切り出すための 設計のコツ
🔁 dogfooding が生む "もう一個の個人開発"


# Page. 3

![Page Image](https://bcdn.docswell.com/page/D7Y4D8P5EM.jpg)

何をしている人？
ポータルサイトを作って、自分が欲しいと思った
ものを開発している
そして、開発した中で汎用的なものは 切り出して
公開 している
🌐 ポータルサイト
切り出し
📦 npm pkg
📦 npm pkg
📦 ..


# Page. 4

![Page Image](https://bcdn.docswell.com/page/VENY6Q54J8.jpg)

一石二鳥とは？
自分が欲しいものを作る → ポータルサイトが充実する
汎用的な部分を切り出す → OSSとして世に出る
ひとつの開発時間で 2つの成果物 が生まれる
「自分のために作ったもの」を「みんなのため」にも届ける


# Page. 5

![Page Image](https://bcdn.docswell.com/page/Y79PLDY4E3.jpg)

紹介する個人開発


# Page. 6

![Page Image](https://bcdn.docswell.com/page/G78DX36V7D.jpg)

ポータルサイト
1.
母艦となるサイト
URL: kouno-log.pages.dev
自分のためのハブ
ここで使うために部品を作る
そしてその部品を npm に公開していく
↑ ここで使った部品を切り出して公開


# Page. 7

![Page Image](https://bcdn.docswell.com/page/L7LM8V9RJR.jpg)

2. rough-table
HTMLテーブルのボーダーを 手書き風 に描画する vanilla JS ライブラリ
特徴
を使った SVG オーバーレイ
元の <table> 要素の
セマンティクスを壊さない
テキスト選択も生きたまま => コピペできる
クラスを 1 つ追加するだけで動く
Rough.js
📦 npmjs.com/package/rough-table
ライブデモ
Item
Status
Design
Done
Implementation
In progress
Release
Planned
↑ ふつうの Markdown テーブルがそのまま手書き風に


# Page. 8

![Page Image](https://bcdn.docswell.com/page/4EMY6GZPEW.jpg)

のポイント
rough-table
「ポータルサイトの表をちょっと味のある見た目にしたい」が出発点
でも アクセシビリティは絶対に犠牲にしたくなかった
→ SVGオーバーレイ方式で <table> をそのまま活かす設計に
切り出して npm 公開 → 同じ悩みの人に届く


# Page. 9

![Page Image](https://bcdn.docswell.com/page/PER9PZ6YJ9.jpg)

着想元: MacBook Neo の LP
🔗 apple.com/jp/macbook-neo/
Apple
の "こんにちは、Neo。" の見せ方
<span class="gradient-text">
<span class="html-copy">こんにちは、Neo。</span>
</span>
mask-image: url(.../hero_text_mask.png);
見た目は 画像でピクセル制御
中身は 実テキスト (mask で隠す)
→ SEO・スクリーンリーダー・コピペ全部生きる
の発想
表を手書き風にしたい
でも <table> の
セマンティクスは壊したくない
→ 線だけ SVG で重ねて、
本体の <table> はそのまま
rough-table
「装飾は別レイヤー / 本体は HTML のまま」
同じ哲学を別の領域に応用 した形


# Page. 10

![Page Image](https://bcdn.docswell.com/page/P7XQ39M4EX.jpg)

3. astro-site-shell
擬似的なターミナルをサイト上に作って ナビゲーションできる npm パッケージ
特徴
向けのコンポーネント
ブラウザ上に "シェル風 UI"
cd / ls のようなコマンドで
サイト内を遷移できる
help でコマンド一覧、 sl で SL も走る
Astro
ライブデモ クリックして操作 →
Welcome to the terminal. Type 'help' for available commands.
📦 npmjs.com/package/astro-site-shell
※
このスライド版は Slidev 用に Vue 移植
lt2026@kouno:~$


# Page. 11

![Page Image](https://bcdn.docswell.com/page/37K9YPGP7D.jpg)

のポイント
astro-site-shell
「ポータルサイトの導線を、自分らしい見せ方にしたい」が出発点
サイトに面白さがなかったので、面白くしたかった
普通のナビではつまらない → ターミナル UI に
AIはCLIのほうが操作しやすいらしい → ならWebUIにCLIをつけてしまえというジョーク
Astro のサイトに組み込みやすいよう切り出して公開
ニッチだけど "刺さる人には刺さる" タイプの OSS


# Page. 12

![Page Image](https://bcdn.docswell.com/page/LJ3W9XN4J5.jpg)

おまけ: このスライド自体が "切り出し" の例
今出てきたターミナルは Slidev (Vue) で動いている
元の astro-site-shell は Astro 用 のコンポーネント
なのにこのスライドに乗っているのはなぜ？
→ コアロジックがフレームワーク非依存 だったから
Astro 固有なのは propsの受け取り方と <script> 構文だけ
ファイルシステム / コマンド / 補完 / 履歴 は 全部 vanilla JS
Vueに移植するのは数十分、しかも今回の LTスライド本体 がそのまま「もうひとつの切り出し」になった
→ 実際に site-shell-core v0.2.0 として切り出して npm に公開しました
（公開してすぐ、このスライドも依存させました）


# Page. 13

![Page Image](https://bcdn.docswell.com/page/8JDKG2W5EG.jpg)

ここから少し
"学び" の話
自慢話で終わらせないために


# Page. 14

![Page Image](https://bcdn.docswell.com/page/VEPK319D78.jpg)

個人開発の最強の強みは
自分が一次ユーザー であること
業務開発
作る人 ≠ 使う人
ニーズが伝聞になる
多くの OSS
作者 ≠ 主要ユーザー
メンテで疲弊しがち
個人開発
作る人 = 使う人
リアルなユースケースが
手元にある
→ ポータルサイトは 「ユースケースの源泉」 になる


# Page. 15

![Page Image](https://bcdn.docswell.com/page/27VV4YMG7Q.jpg)

は最強のテスト
dogfooding
自分のサイトで使う = 毎日 e2e テストしているのと同じ
別の文脈で使うと 想定外の境界条件 が出る
例: 今日まさに rough-table を Slidev に乗せたら
transform: scale() 配下でズレるバグ を発見
🐛 github.com/h-kono-it/rough-table/issues/1
LT準備中に見つけて、自分でissueを上げました
→ 即日 0.1.2 → 0.1.3 をリリース、このスライドも修正版に乗せ替えました
複数の場所で使う = 自分が 多様なテスター になれる


# Page. 16

![Page Image](https://bcdn.docswell.com/page/5JGL19XD7L.jpg)

Before / After: issue #1
Before — rough-table@0.1.2
の修正
After — rough-table@0.1.3
← 今このスライドで動いてる
Item
Status
Design
Done
Implementation
In progress
Release
Planned
に viewBox + preserveAspectRatio を設定するだけ。
同じデータで枠線がセルにピタリと重なる
SVG
オーバーレイが transform: scale() 配下で
本体テーブルとズレて描画されている
SVG


# Page. 17

![Page Image](https://bcdn.docswell.com/page/47QYDW8XEP.jpg)

切り出しやすいコードの "型" 3つ
① フレームワーク依存は "薄い殻" に閉じ込める
中身は vanilla JS / 純粋関数。propsの受け取りと描画の入口だけが framework特化
さっきの site-shell-core + astro-site-shell の分割がまさにこれ。
「Astro 用だから他では無理」と思い込みがちだが、今日の Vue 移植が 20 分 で終わったのはこれが効いた
② "設定" は引数で受け取る
グローバル変数や暗黙のimportに依存しない。
「呼び出し側が全部渡す」ようにすれば移植もテストも楽
③ DOM・グローバルを汚さない / 後始末できる
例: rough-table は元の <table> を一切書き換えず
SVGをオーバーレイするだけ → セマンティクスもaxe検査も無傷


# Page. 18

![Page Image](https://bcdn.docswell.com/page/KE4WZK22J1.jpg)

いつ切り出すか？
業務開発の定石
1回目: 普通に書く
2回目: コピペ＆少し違う
3回目: ようやく抽象化
→ "Rule of Three"
（早すぎる抽象化はYAGNI違反）
個人開発の特権
2回目で切り出してもいい
時間軸が長いから回収しやすい
ハズレても傷が浅い
そして切り出す = 公開して
他人にも使ってもらえる
「業務でやると怒られる早めの抽象化」が
個人開発では戦略的に効く


# Page. 19

![Page Image](https://bcdn.docswell.com/page/L71YRXMKJG.jpg)

まとめ


# Page. 20

![Page Image](https://bcdn.docswell.com/page/G7WG1N3PE2.jpg)

一石二鳥のすすめ
ポータルサイトを 「実験場」 にする
自分の欲しい機能を作る → そのまま自分が使う
汎用化できる部分は npm パッケージとして切り出す
結果: 自分のサイトが育つ + OSS が増える
個人開発から個人開発を産もう


# Page. 21

![Page Image](https://bcdn.docswell.com/page/4JZLP3V6E3.jpg)

ありがとうございました
🌐 ポータル : ko u n o - l o g . p a g e s . d ev
📦 rough-table
📦 astro-site-shell