OSS≒盆栽
〜個人的趣味として無理なくOSS開発をするときに意識したいこと〜
- author:
Kazuya Takei / @attakei
- date:
2025/09/26
- event:
PyCon JP 2025
- hashtags:
「OSS≒盆栽」って何?
ミリしら盆栽
※イメージとしては品評会などを目指さない「鑑賞趣味としての盆栽」
小さな目標から始められる
意外とランニングコストが低い
個人のアクティビティ
虫や自然と戦う
なんか似てるかも?
…という、かなり雑なタイトルです。
〜個人的趣味として無理なくOSS開発をするときに意識したいこと〜
はじめに
お前誰よ
Kazuya Takei
attakei (X, GitHub, etc)
株式会社ニジボックス
趣味: OSS作家 <= こっち
ライブラリ・拡張系を作りがち
Sphinx拡張生成マシーン
Sphinxでプレゼンテーションしたがる人
Sphinxで技術同人誌を書く人

株式会社ニジボックス
ニジボックス は「Grow all」をミッションに、企業やサービスの成長に向き合い続けるリクルートグループのデザイン会社です。 お客様のビジネスの成長をUI UXのデザインプロセスから開発・運用・改善までワンストップでサポートします。
話すこと
そもそも「趣味のOSS開発」って?
無理をしないための取り組み方
「こいうこともある」という実例
※技巧的な話はほとんど出ません。
趣味としてのOSS開発
趣味でOSS開発をやっていた結果

OSSを分類する
体制での分類
会社等が組織的に開発している
個人を主体に
個人が気ままに開発している
OSSを分類する
体制での分類
会社等が組織的に開発している
個人を主体に
- 個人が気ままに開発している↑今回はここ
OSSを分類する(2)
影響度の考察
スターなどが多い
「〇〇の人」のような称号になる
別の著名なソフトを支える
…それなりに大変なので、一旦目指さない。
今回の「趣味OSS開発」とは
今回の「趣味OSS開発」とは
程よい開発経験を得られる
周りに迷惑がかからない
とはいえ、ハードルを感じがち。
PyPIに公開するまではだいぶ楽になった…と思う。
「正しさ」みたいなものに囚われる?
「外からの評価」に対する懸念?
※人によっては「当たり前では」と思うかも。
無理をしないための取り組み
基本的な考え方
基本的な考え方
単機能な物を作る
自分の道具を作る
機能の担保にこだわらない
単機能な物を作る
「たった一つのこと」 だけ を実現するものを作る。
単機能な物を作る
「たった一つのこと」 だけ を実現するものを作る。
機能の幅が広いと、完成が遠くなり「達成感を得る」までが遠ざかる。
- 「未完成な多機能」より「完成済み単機能」例: grepよりreplace
「こういうのでいいんだよ」の精神
単機能な物を作る
実例: qrcode
テキストなどを受け取り。QRコードのPNGやSVGを生成する…
…これだけをするライブラリ。
その分。使い方も非常にシンプルだし、他ライブラリとの連携も容易。
単機能な物を作る
import qrcode
img = qrcode.make('Some data here')
img.save("some_file.png")
単機能な物を作る
よくやるアプローチ
〇〇をPythonで扱えるようにする
△△が公開しているWeb APIのラッパー
◇◇上で☓☓を扱えるようにする
自分の道具を作る
「自分が普段遣いする」 ため のライブラリを作る。
自分の道具を作る
「自分が普段遣いする」 ため のライブラリを作る。
「欲しいけど見つからない」は、大事なモチベーションの源泉。
一歩踏み出して「じゃあ作るか」となると良い。
愛着があるものほど、メンテナンスしやすいし、責任感も湧く。
自分の道具を作る
実例: oEmbedPy
サイトURLからoEmbedコンテンツを取得するライブラリ。
SphinxドキュメントにoEmbed対応コンテンツを楽に埋め込みたくて作った。
古いPythonでの実装は存在するが、古すぎるのでPython 3.x系専用に自作。
機能の担保にこだわらない
精緻なユニットテストを書いておけるのは望ましいのだが、ここにリソースを取られると疲れてしまう。
趣味前提なら 「取りあえず動くのでヨシ!!」「公開したので正義」 ぐらいの気持ちで。
機能の担保にこだわらない
気になるなら:
最初のうちは簡単なe2eテストや機能テストっぽいのだけ用意する。
リンターやフォーマッターは導入したほうがいい。
困ったら、Ruffにすべてを委ねよう。
Ex: サブ項目
なるべくさっさと公開する
「PyPIにあるか?」はそれなりに大事。
uvなら割とすぐ公開できる。
公開後の想定利用者数は「2人(自分+α)」ぐらいを想定すると良い。
- 「自分のために作ってとりあえず公開した」ら「実は小さな需要があった」ぐらいの気持ちでいる。
Ex: 慣れてきたら
「型」を作っておく
「必要最低限」を準備する
GitHubのテンプレートリポジトリ
Cookiecutter
ドキュメントとか
ガイドは「ない」より「ある」ほうが良い。
頑張れるなら英語で
Sphinxオススメ
実例: sphinx-revealjs
「こいうこともある」というケース
どんなOSS?
https://attakei.github.io/sphinx-revealjs/
コミット: 2018-10-27 → Now
最初のPyPI: v0.3.1 (2018-11-27)
最初のStable: v1.0.0 (2021-01-03)
最近のStable: v3.2.0 (2025-04-03)
どんなOSS?
https://attakei.github.io/sphinx-revealjs/
- Sphinxの仕組みから、Reveal.jsプレゼンテーションを生成する。
- この発表資料もsphinx-revealjs製。
- テスト周りは、基本的にSphinxのテストーツールを使ったe2e枠がほとんど。
どんなOSS?
- Sphinxの仕組みから、Reveal.jsプレゼンテーションを生成する。→単機能ライブラリ。
- この発表資料もsphinx-revealjs製。→自分が使いたくて作った。
- テスト周りは、基本的にSphinxのテストーツールを使ったe2e枠がほとんど。→内部の精緻なところまで担保していない。
地味な需要が発生したり
GitPitch がサービス終了したタイミングで、移行して使い始めた人。
類似ライブラリのメンテナンスが停滞したので、移行して使い始めた人。
海外で使われるケースがあったり
https://live.osgeo.org/ja/presentation.html

海外で使われるケースがあったり
https://nekmo.github.io/micropython-presentacion/

PyCon JP 2025では
発表者が使っている…かも?
振り返り
伝えたいこと
趣味OSS開発は「無理なく」「楽しく」するアプローチがあれこれある。
長く続けていると、思いもよらないイベントが発生することも。
もし、心の中に「需要」は眠っているなら、君もOSS作家にならないか。