footer: YAPC::Fukuoka 2025 – azu
slidenumbers: true
autoscale: true
theme: Plain Jane, 1
15年続けて分かった持続可能なオープンソース開発
azu (@azu_re)
YAPC::Fukuoka 2025
azu
15年間オープンソース活動のうち
作ったもの（アウトプット）ではなく実際の影響（アウトカム）を目指している
[.column]アウトプット
作ったもの
（記事、ツール、書籍）
アウトカム
実際の影響・成果
（信頼、エコシステム、教育）
アウトカムは評価されるまで時間がかかる
→ だから持続可能性が必要
- 数年で更新が止まる
- メンテナーの燃え尽き
- 心理的負荷の増大
なぜ燃え尽きるのか？
Burnout is the experience of being pulled between expectation and reality at work.
— Jonathan Malesic, The End of Burnout
[.column]
期待
- 「自分がやらなければ」
- 「全てに対応すべき」
- 「常に最新に保つべき」
現実
- 時間がない
- 対応できない
- 追いつけない
→ このギャップがBurnoutを引き起こす
Burnoutは真偽値ではなく、複数の状態の組み合わせで現れる
^ バーンアウトには3つの次元がある: 疲弊（Exhaustion）、シニシズム（Cynicism/他者を問題として捉える）、無力感（Ineffectiveness/達成感の低下）
^ 5つのプロファイル: 健全、過負荷（疲弊のみ高）、シニカル（シニシズムのみ高）、徒労感（無力感のみ高）、完全燃焼（全て高）
^ 労働者の約50%がこのスペクトラムのどこかに位置している
^ 心理的負荷が増えると、これらの次元のスコアが上がり、バーンアウトへと進行する
[fit] 技術的依存を増やし
[fit] 心理的負荷を減らす
^ これを JSer.info、textlint、jsprimer の3つのプロジェクトでの話を紹介する
定義：
- 自動化できる部分は自動化する
- ツールや(エコ)システムを育てる
- 再現可能なプロセスを構築する
特徴：
- スケールする
- 疲れにくい
- 他者も利用できる
定義：
- 「自分がやらなければ」というプレッシャー
- 完璧主義
- 義務感
特徴：
- スケールしない
- 疲れやすい
- 燃え尽き(Burnout)につながる
- ゼロにはできない
前提：心理的負荷をゼロにはできない
→ でも、技術的依存に変換できる部分は存在する
心理的負荷の特徴
- コントロールが難しい
- スケールしない
- バーンアウトリスク
技術的依存の特徴
- コントロールしやすい
- スケールしやすい
- 設計次第で明確化できる
-
JSer.info – 読む技術
→ データドリブン、退屈な部分の自動化 -
textlint – 書く技術
→ No core rules、エコシステム -
jsprimer – 伝える技術
→ Living Standard、既知→未知
[.hide-footer]
JSer.info
整理されたデータである「情報」を伝えること
2011年1月16日創刊
- 750記事、14年継続
- 12,429サイト紹介
- 一度も欠かさず週刊配信
[.column]
3つのレイヤーから情報を収集：
- Awareness層: 新規公開直後の情報（GitHub中心）
- Interest層: トレンドと話題性（SNS、記事）
- Comparison層: 比較検討された実践的情報（書籍、メディア）
詳細はJSer.info 10周年記事を参照
^ 情報というとざっくりしているので主に3つの層に分類しています
^ JSer.infoの紹介記事のカテゴリもこの流れに沿っていています
^ 上から新しい情報となることが多い、下に行くほど濃度が高い情報になります
[.column] RSS [.column] GitHub
RSSをIrodr（LDR風リーダー）で読んで判断
なぜ人間が判断？
→ 目的は「紹介」ではなく「知ってもらう」こと
人間が判断する価値
- 単なるリンク集ではなく、文脈を説明/整理/なぜ興味深いかを伝える
- 読者はAIではなく、人間だから
- 増やすのではなく、少なくすること
一例: 「技術的な嘘はつかない」
使わない言葉：
- “is Dead”、最強、熱い
慎重に扱う情報：
- ベンチマーク数値（マイクロベンチマークは難しい）
[.hide-footer]
^ JSer.info 2011年ごろの更新フロー
[.hide-footer]
^ JSer.info 2025年ごろの更新フロー
✓ 紹介文を書く
- 専用エディタ(Postem) (2019〜)
- MCP執筆補助 (2025〜)
✓ PRを作る
✓ タグ・グループ分け
- タグ推論 (2023〜)
- グループ学習 (2020〜)
- ヘッドラインをAIで書く (2025〜)
段階的に自動化を進めて継続性を確保
- 見る
- 調べる
- 検証する
- 説明文を書く
[.column]
❌ 従来
「毎週月曜日に公開」
→ 書けない週のプレッシャー
✅ JSer.info
「13記事集まったら公開」
→ 品質でリリース判断
結果: 14年間の継続
- 振り返って一番大きかったのは、日付ベースではなく記事数ベースの公開基準にしたこと
- この13記事という基準は初めてから4-5年ぐらい経って、中央値を見るとここに安定していたことに気づいた
- この発見で心理的なプレッシャーが大きく軽減できて続いたと感じている
- https://github.com/jser/status-of-post
- https://jser.info/status-of-post/
^ その13記事っていうのは、始めてから4、5年ぐらい経って初めて、なんか13記事、毎週13記事ぐらいだなって感じになって、ちょうど安定したんですけど
^ この一回更新を止めた時にやっぱ復旧するのはめちゃくちゃ難しいんですね。ダイエットとかもそうだけど
^ 一回なんかやめてしまうと、そこをずっとやめてしまうんで、その、なんか、やめた後にすぐ復旧できるっていうのが13記事っていう基準だとやりやすい
技術的依存は、継続によって育つ
[.column]1. 継続する
↓
2. データが蓄積
↓
3. 自動化の材料が増える
↓
4. 自動化が進む
↓
5. 作業が楽になる
↓
6. 続けやすくなる
↓
1. 継続する（最初に戻る）
^ 「データ無い！ 腹立つ！ 推論する！」から 「データ無い！ 腹立つ！ データを作る」へ チームでデータを作り、育てられるようにするまで / How can we create, use, and maintain data ourselves? – Speaker Deckでデータがないと自動化できない。データがないとわからないという話がありましたが、それと同じ話で、データが蓄積すると自動化ができるようになります。
技術的依存を増やした：
- データ基準（13記事で公開判断）
- 退屈な部分の自動化（収集、PR作成、分類）
- 継続による技術的依存の改善（蓄積 → 自動化 → 継続）
心理的負荷を減らした：
- 週次固定締切（毎週月曜のプレッシャー）を廃止
- JSer.info Policyを作り、基準を明確化
[.hide-footer]
textlint
読む → 書く
きっかけ：
- JSer.infoで情報を読み続けていた
- 「読むだけでは物足りない」
- 「自分でも書いてみよう」
2014年3月：JavaScript Promise本の執筆開始
書くと、読む量が増える
なぜ？
- 調べる（情報を読む）
- 検証する（ドキュメントを読む）
- 自分が書いたものを読み返す
書くことは、読むことの延長
JavaScript Promise本執筆時の問題：
- 表記揺れが気になる
- 「JavaScript」vs「Javascript」
- 「コールバック」vs「callback」
解決策：ツールを作ろう
- 自然言語(日本語や英語など)に対するLinter
- MarkdownやHTMLなどのマークアップ言語に対応している
- ビルトインのルールは0
- 利用できるルールは200以上ある
- CI/CDに組み込める自然言語のチェッカー(表記揺れ、スペルチェック、誤用、読みやすさのチェックなど)
「自然言語には正解がないため、
拡張の柔軟性を持つこと」
コア原則：
- ルールをコアで持たない
- プラグインで拡張できるようにする
「楽に使える」より「適切に使える」
[.column] 従来のLinterインストール
→ デフォルトルール
→ すぐ使える [.column] textlint
インストール
→ 何も起きない
→ ルール選択
- ESLint/RuboCop/Pylintなどはコアにルールを持っている
- コアにルールを持つとルールのIssueもコアに集まる = 心理的負担が集中する
- コアでやらないことではっきりさせることで、責任を分離できる
- そもそもあらゆる自然言語に対応したルールをコアに持つことは不可能
- textlint – Linterの作り方
^ 考え方的には、絵文字言語というような未知の言語が出てきた時にtextlintはそれに対応できるという目的を持って設計しています。
^ 今朝yusukeさんが話していたようにコアに色々な機能があるとコアに全てのissue集まってしまってトリアージが大変になります。(登山すれ違い問題)
- ルールは200以上
- エディタの拡張や言語サポートもコアから分離
- 責務が分散するとメンテナンスも分散される
- コアから切り離せると、ルールの追加とかはやりやすくなる
- 一方で、ルールが個人に紐づくとメンテナンスが止まる確率は高くなる
- → ルールをOrganizationに集めるなど、緩いまとまりを持ったコミュニティを作ることでバランスをとっている
- プラガブルの弱点は、ユーザーがプラグインを選択しないといけない点
- 人間が選択するのは大変
- ルールによって求める文章の質が異なるので、目的に合ったルールを選ぶのが難しい
- 改善するにはエコシステムの拡充が重要になっていく
- エディタの拡張、手軽に使えるような仕組み(Easy)
- コアでやると、メンテナンスが大変になるので、できるだけ外部化を維持していた
- 改善するべきかをずっと耐えてコアにフォーカスしていたら、ユーザーが変化した
- 2023年以降、AIがユーザーになることで難しさが変化
- 人間にとっては選択が難しいが、AIがベースラインを上げる
- それによってコアでやるべき方向性を変えた
- 人間とAIを繋ぎやすくする方向へ
2025年1月：textlint v14.8.0でMCPサーバー対応
npx textlint --mcp
- AI Agentがtextlintを使えるように
- AIがtextlintでチェックして修正できるようになったが、AI固有のエラーも増えた
[fit] ✅ ❌ 🚀 🎯 🔥 💡 ⚡ 🌟
^ AIは絵文字を多用する傾向がある
AI特有の文章構造を検出するtextlintルールセット
- 絵文字の多用 – ✅ ❌ 🚀 🎯🔥
- 過剰表現 – 革命的、民主化、大幅な改善、非常に重要
- 強調構文の多用 – 太字、斜体、下線
- コロンの直後にブロック要素が続く英語的なパターン:
[.column]
従来（〜2022年）
[.column]AI時代（2023年〜）
- AIはルールのエラーメッセージを理解して瞬時に修正できる
→ 人間は書くことに集中できる - 一方で、新しいAI固有のエラーが増える
→ textlint-rule-preset-ai-writingを作成
- Linterはエラーが発生した時にエラーメッセージをドキュメントとして提供する
- 人間もAIもエラーメッセージを読んで理解し、修正する
- エラーメッセージの質が重要になる
- 自然言語は不定な部分が多い。実装に落とすのも工夫が必要
- それ以上に、エラーとなった場合のメッセージが難しい
- 例えば「xxxは冗長な表現です」というルールがあった場合に、なぜ冗長なのか？どう直せば良いのか？を説明するのが難しい
- また、人間は柔軟すぎてメッセージの質を評価しづらい
^ 人間は自然言語をパターンで認識するので、間違っていても読めてしまう
- 人間は自然言語をパターンで認識するのでなんか読めてしまう
- 人間は文章の質を数値として評価することが難しい
- そのため、人間がエラーメッセージの質を上げるには量が必要
- 量が必要だと、過剰な負担になる
- 技術的に改善するにはエラーメッセージの質を数値で評価したい
- LLM as a Judgeでエラーメッセージの質を評価する仕組みを作成中[^promptfoo]
- エラーメッセージの質をLLMで評価し、スコアを元に改善を繰り返す
- 技術的改善を回しやすくする
技術的依存を増やした：
- プラガブルアーキテクチャ
- MCP適応/AIの活用
心理的負荷を減らした：
- コアとルールの分離 = 心理的負荷の分散
- コアにフォーカスし続けて、エコシステムを外部化
- エラーメッセージの改善とLLM as a Judgeの実装
[.hide-footer]
JavaScript Primer
読む → 書く → 伝える
転換点：
- 個人で書く → 相手に伝える
- 一人で書く → 共著で書く
- 「読者」を強く意識する瞬間
2016年：JavaScript Primer開発開始
- 2016年から執筆、6 つのメジャーバージョンを経て更新され続けている JavaScript 入門書
- 書籍版 (amazon.co.jp/dp/4048931105) も販売中
- ウェブ版 (jsprimer.net) は無料で公開
- GitHub: asciidwango/js-primer
- 書籍版とウェブ版の内容に違いはなく、オープンソースで開発中
目的:新しくJavaScriptを学ぶ人が迷わないようにするための入門書
- 書き方：基本文法などのJavaScriptの書き方
- 作り方：アプリケーションの作り方
- 学び方：JavaScriptの進化を自分で知る学び方
- Living Standard戦略
- Design Doc（設計文書）
- 既知→未知の原則
- 自動テストによる品質保証
リリースサイクルもECMAScript仕様策定プロセスを模倣
[.column] ウェブ版 (jsprimer.net)- 常に最新版を維持
- Living Standard
- ECMAScript仕様と同様に継続更新
- 安定版として時々リリース
- Snapshot
- ES2024のようなリリース
効果: 完成しないと公開できないという心理的負担を減らす
- 書籍のような文章を書くにも設計が必要
- 書籍は章ごとに分かれているので、各章ごとにDesign Docを作成
- これによって、章の方向性を明確化し、書きやすくなる
[.column]
各章/
├── README.md（本文）
├── OUTLINE.md（設計文書）
meeting-notes/
└── YYYY-MM-DD.md（ミーティング記録）
OUTLINE.mdの役割：
- なぜこの章が必要か
- 何を学ぶか
- どう教えるか
すべての議論を公開：
- Issue/PRでの議論
- Meeting Notesも記録して公開
- Design Docがあることで書いてる途中でブレにくい
- 章の目的が明確なので、書き始めるハードルが下がる
- それでも、章の最初の一歩は重い
- → そこでAIを活用して最初の一歩を軽減
[.column]
未知→既知の例
- Promiseは非同期処理を扱うオブジェクトです
- 非同期処理とは、処理の完了を待たずに次へ進むものです
- Promiseは、その状態や結果を表現します
既知→未知の例
- 今まで書いていたコードは、処理が終わるまで待ってから次に進みます。これを同期処理と呼びます
- 一方で処理の完了を待たずに次の処理に進むこともできます。これを非同期処理と呼びます
- この非同期処理の状態や結果を表現するのがPromiseです
8種類のテストを組み合わせて品質を保証
[.column]文章の自動テスト
- textlint: 文章の品質チェック
- ESLint: JavaScriptコードの品質チェック
コードの自動テスト
- Doctest: コード例の出力検証
- Unit Tests: Mochaによるテスト実行
- Executable Code: サンプルコードの実行確認
Markdown内のコード例を実際に実行して検証
// コメントで期待値を記述
const result = 1 + 1;
console.log(result); // => 2
特徴:
- ドキュメントと実装の乖離を防ぐ
- リファクタリング時の安全性を確保
すべてのテストはPull Requestごとに自動実行
- GitHub ActionsまたはNetlifyでビルド
- textlint、ESLint、Doctestなど全テストを実行
- プレビュー環境で実際のレンダリングを確認
使っているから続く、続いているから使う
技術的依存で解決できたこと：
- 品質保証の自動化（CI/CD）
- Living Standardによる継続更新
- Design Docによる設計の明確化
目的はJavaScriptの変化に対応できるようにすること
- JavaScriptは毎年更新される仕様
- 今時オープンソースソフトウェアを使わない開発はほぼない
- オープンソースへコミットすることも学びの1つ
著者を増やすことで、変化への対応と心理的負荷を分散
[.column]
年間コスト試算：
- 約30日分の労力
- 約70万円相当[^wage]
収入源：
- 書籍売上
- Open Collective
- GitHub Sponsors
具体例：https://opencollective.com/jsprimer
仕組み：
- プロジェクト単位の資金管理
- 企業向けスポンサー特典
- 透明な収支公開
年間想定：60ポイント分の作業（目安：2ポイント ≒ 1日分の作業）
タスク複雑度：1, 2, 3, 5, 8ポイント
1ポイント = 約$7(2025年の予算$ / 60ポイント)
仕組みの特徴：
- 金銭的還元の仕組み化
- 報酬を受け取る代わりに、別のオープンソースへ寄付することも可能
どうやって？
- ハードルを下げる
- 透明性を保つ
- すべての議論をGitHub上で
- Meeting Notesも公開
- 判断理由の記録
- Meta Issueで方針決定 → ES2025の新機能7個の対応方針を決定
- ブログで募集 → コントリビューター募集
- Discussionで認識合わせ → 役割分担
- 個別Issueで並行作業 → 1機能 = 1人 = 1Issue (#1783、#1788 など7機能)
- PRレビュー → textlint/DocTestで自動チェック済み、人間は読みやすさに集中
- 結果: v7.0.0リリース
技術的依存を増やした：
- 継続仕様（Living Standard、ES2025対応）
- 自動品質（CI/CD、3層チェック）
- 設計文書（OUTLINE.md、AI活用）
- 経済透明化（Fibonacci報酬、Open Collective）
心理的負荷を減らした：
- 一度で完成要求（継続更新前提）
- 著者を増やす（100人以上のコントリビューター）
[.hide-footer]
段階的発展と相互強化
2011: JSer.info
読むことから始まった
↓
2014: textlint
書くことで読む量が増える体感
↓
2015: JavaScript Primer
伝えることで読む・書くの質が上がる
- JSer.info/textlint/JavaScript Primerはどれもオープンソース
- しかし、それぞれのプロジェクトはやり方が異なる
| モデル | ユーザー | 貢献者 | 特徴 |
|---|---|---|---|
| TOYS | Low | Low | サイドプロジェクト |
| STADIUMS | High | Low | 集中型メンテナンス |
| CLUBS | Low | High | 重複コミュニティ |
| FEDERATIONS | High | High | 複雑なガバナンス |
最適な規模を保つ設計：
- データドリブンな公開（GitHub Actionsによる自動化）
- 趣味であるから続けるという範囲に保つ
- 心理的プレッシャーを発生させない設計
安定した規模を維持することで、心理的負荷を排除
週85,000ダウンロード、少数のメンテナー：
- No core rules戦略
- コアを最小化しフォーカス、エコシステムへ委譲
- 200以上のルールをコミュニティが作成
技術的依存は高いが、心理的負荷を下げる設計
100人以上のコントリビューター：
- Living Standard（常に更新）
- Design Docで貢献のハードルを下げる
- ユーザーと貢献者が重複するコミュニティ
貢献しやすい構造で心理的負荷を分散
^ モデルごとに異なる戦略で持続可能性を確保
^ プロジェクト間の循環：
^ 読む → 書く → 伝える → 読むの質向上
どれか一つが止まると全部止まる可能性
これは受け入れているリスク
トレードオフの認識
ただし…
技術的依存は心理的負荷と異なり、代替可能性が高い
ツールが止まっても別のツールに置き換えられる
[.column]
心理的負荷 ✗
- スケールしない
- 疲れる
- バーンアウトを生む
- 自動化できない
- コントロールが難しい
- 持続が難しい
技術的依存 ✓
- スケールする
- 疲れにくい
- 継続で改善しやすくなる
- 自動化できる
- 交換可能・差し替え可能
- 持続がし易い
[.hide-footer]
[.column] 読む技術（JSer.info）：
- データドリブンな公開基準 [技術]
- 退屈な部分だけ自動化 [技術]
- 小さなイテレーション [技術]
書く技術（textlint）：
4. デフォルトルールなし戦略 [心理]
5. 最小コア、豊かなエコシステム [技術]
6. 検証可能なことを自動化 [技術]
7. 最小限の依存関係 [心理]
[.column]
伝える技術（jsprimer）：
8. Living Standard戦略 [心理]
9. 既知→未知の原則 [心理]
10. 自動テストによる品質保証 [技術]
11. 透明な経済モデル [心理]
12. 使って改善する循環 [技術/心理/循環]
[技術]: 技術的依存を育てる (1,2,3,5,6,10,12)
[心理]: 心理的負荷を減らす (4,7,8,9,11,12)
- データセット蓄積 → 自動化促進
- エコシステム成長 → 対応範囲拡大
- AI時代への適応力 → 新技術との統合
- プロジェクト間の相互強化 → 学びの循環
そのための設計原則：
- 技術的依存を積極的に育てる → スケールする、疲れにくい、改善が加速する
- 心理的負荷を意識的に減らす → バーンアウト回避、長期継続
この発表準備プロセス自体が「読む→書く→伝える」の実証
[.column]15年間publicに書き続けた:
- GitHubのコミット・Issue・PR
- ブログ記事・書籍
- スライド・ドキュメント
それをAIが読んで:
- 過去の判断理由を理解
- パターンを発見
- 新しい視点で構造化
→ 自分が読んで新たな気づきを得る
Publicの過去が、未来の価値を生む
- Inoreader: RSSリーダサービス
- irodr: LDR風RSSリーダをフロントエンドとして自作
- Iroreaderの値上げが不安になったきたので、バックエンドも含むRuri Readerを作っている
- GitHub Sponsorsには見返りをなくした
- 見返りを用意すると心理的負荷が高くなる可能性がある
- 短期的な関係ではなく長期的な関係を重視するため
- https://efcl.info/2021/10/01/github-sponsors/
@azuのTier設計：
- ✨ Supporter：$1/月
- ☕ Coffee：$5/月
- 🌐 Domain：$10/月
- 📖 Book：$30/月
- 💚 JSer.info：$100/月
- ❤️ Open Source：$300/月
- 金額が大きくなってもほぼ行動に影響がなくなると感じたら小さな見返りを設定する
- e.g.
- JSer.info は長期間続けて、内向的なプロジェクトなので外的要因がほぼ影響しない
- jsprimer はサイクルを増せるようになって、より外部のContributorを増やすために設定
- 自分のためではなく、他者のためというマインドだと行動はしやすい
- Ref. Work Design
- アウトカムを達成するには、まず持続することが前提にある
- この方法がいいというわけではない
- 引き継ぐ難易度が結局高いという問題がまだ未解決
- サプライチェーンの問題もあり、難易度がかえって上がっている
YAPC::Fukuoka 2025 – 読む技術・書く技術・伝える技術
プロジェクト公式サイト
JSer.info
textlint
JavaScript Primer
関連ツール・プロジェクト
情報収集ツール
文章品質ツール
書籍・ドキュメント関連
関連する記事・発表資料
JSer.info関連
textlint関連
JavaScript Primer関連
その他の振り返り記事
技術仕様・プロトコル
個人リンク
関連書籍
継続すること・公開すること (Austin Kleon 3部作)
オープンソース開発・持続可能性
燃え尽き症候群・心理的プレッシャー
アウトカム志向・長期的視点
エーザイの熱帯病治療薬事例（アウトカムの時間軸を示す実例）
- IMPACT STARTUP SUMMIT 2025
- エーザイのインパクト会計の事例が紹介された
- 2014-2018年: 熱帯病治療薬16億錠以上を無償配布(コスト約24億円)
- 2025年(約10年後): 社会的インパクト7兆円相当と評価、PBRに反映
- 「評価される場面に到達するには、まず生き残る必要がある」を示す事例
- https://www.camri.or.jp/files/libs/1886/202302271343235637.pdf
- エーザイの熱帯病治療薬の社会的インパクトの柳モデルについての解説
文章・コミュニケーション
JavaScript
元の記事を確認する
