star-history: https://www.star-history.com/#dagu-org/dagu&Date
はじめに
2022年、私は Dagu という名のワークフローエンジンを個人で開発し始めました。そして 2025 年 6 月現在、GitHub でのスターは約 2.3k を超えました。もちろん、世界的な大手OSSと比較すれば、その規模は決して大きくはありません。しかし、企業の内部ツールから個人の Raspberry Pi 上で動く趣味のプロジェクトまで、様々な用途で、そして世界中の多様な地域から、日々 Issue やフィードバックが寄せられています。
この記事は、特別なスキルを持たない、いわゆる「普通」のソフトウェアエンジニアである私が、一つの OSS を4年間諦めずに継続し、どのようにして小さなコミュニティを育んできたか、その過程で得た学びや考えを共有するものです。
Dagu とは何か – Cron と本格ワークフローエンジンの「中間」を埋める選択肢
多くの開発現場で、データの ETL 処理やバッチ処理の自動化は重要な課題です。この領域には、Apache Airflow のような非常に高機能で強力なツールが存在します。
Airflowは、Python の複雑な依存関係、外部データベース、そしてスケジューラーやワーカーといった複数のコンポーネント設定を必要とします。クラウド各社から提供されるマネージドサービスを利用する方法もありますが、その多くは相応のコストがかかります。
このため、特に「手元の Crontab では管理が限界だが、専任の DevOps エンジニアは雇えない」という規模のプロジェクトにとっては、導入や運用のハードルが高いと感じられるケースが少なくありません。
Daguは、まさにこのギャップを埋めるために開発されました。
たとえば、以下のようなシンプルなジョブを毎日 AM 6 時に実行したいとします。
この場合、以下のような YAML を定義できます。
schedule: "0 6 * * *"
steps:
- name: extract-customers
command: sleep 1
description: "顧客レコードを抽出"
- name: enrich-customers
command: sleep 1
description: "顧客データを補完"
depends:
- extract-customers
- name: extract-orders
command: sleep 1
description: "注文レコードを抽出"
depends:
- extract-customers
- name: generate-report
command: sleep 1
description: "統合レポートを生成"
depends:
- enrich-customers
- extract-orders
- name: send-notification
command: sleep 1
description: "完了メールを送信"
これを Web UI 画面から実行したり、CLIから実行したりできます。
Dagu: Web UIからジョブ実行
Dagu: CLIからジョブ実行
これらの実行履歴やログが自動的にディスクに保存されます。
Daguのアーキテクチャは、意図的にシンプルさを追求しています。
- Go言語による単一バイナリ： OSに合わせたバイナリファイルを一つ配置するだけでインストールが完了します。
- データベース不要： 追加のミドルウェアをセットアップする必要がありません。
- シンプルなYAML定義： 実行したいコマンドと依存関係を記述したYAMLファイルを用意するだけで、複雑なジョブパイプライン（DAG: 有向非巡回グラフ）を定義できます。
- 組み込みWeb UI： DAGの可視化、実行、リトライといった操作をブラウザから直感的に行えます。
簡単に使えるワークフロー管理システムにより、開発者が本質的なビジネスロジックに集中できる環境を提供できると考えています。
OSS を始めた理由 – GitHub が荒野だった日
私は、いわゆる「天才プログラマー」ではありません。大学を卒業してから本格的にプログラミングを学び始め、初めて書いた for ループがコマンドプロンプトに文字列を出力しただけで、純粋に「面白い」と感じた、ごく普通のエンジニアです。
これまで転職や業務委託を通じて様々な企業でソフトウェア開発に携わってきましたが、OSS 活動を意識するようになったのは、あるスタートアップ企業の面接で手痛い失敗を経験したことがきっかけでした。当時、私は主に社内システムを開発する SIer に勤務しており、業務で GitHub を利用する文化がなかったため、私個人の GitHub アカウントは、文字通り「無」の状態でした。個人で i アプリなどを開発していましたが、なぜか GitHub を使わずにローカルにコードを保存していました。
技術面接で、面接官から投げかけられたのは「OSS 活動は何かされていますか？」という質問でした。私は何も答えることができませんでした。
この経験は、私に強い危機感を植え付けました。「このままではエンジニアとしての市場価値を失い、詰んでしまうのではないか」。この日から、私の GitHub と OSS 開発に対する意識が変わっていきました。
はじめての OSS – TypeScript Deep Dive 日本語版で見つけた貢献の形
OSS 活動への第一歩は、大手メーカーに勤務していた頃でした。当時は TypeScript が大きな注目を集め始めた時期で、私もその可能性に惹かれ、学習に励んでいました。その過程で、TypeScript Deep Dive (License: CC-BY-4.0) という質の高いオンライン書籍に出会いました。内容は素晴らしいものでしたが、残念ながら英語版しか存在しませんでした。
その時、ある考えが閃きました。「この書籍をフォークして日本語に翻訳すれば、自分の学習が深まるだけでなく、TypeScript コミュニティにも貢献できるかもしれない」。
早速リポジトリをフォークし、本業と並行で翻訳作業を開始しました。当初は Google 翻訳 API を使えばすぐに終わるだろうと高をくくっていましたが、出力された日本語は不自然で理想には程遠いものでした。結局、膨大な文章を地道に翻訳し直すことになり、毎晩の作業は 3 ヶ月ほど続きました。
原著者の許可を得て日本語版を公開した後、しばらくは誰の目にも留まりませんでした。しかしある日、急に「はてなブックマーク」のテクノロジーカテゴリでトレンドに入り、それから多くの開発者からアクセスが来るようになりました。これが、私が OSS 活動を通じて、仕事の外で人の役に立つ喜びを初めて実感した瞬間でした。
ライブラリ開発で学んだ「上位互換に殺される感覚」
次に私がハマったのは、Go 言語製のゲームエンジン Ebitengine を使ったゲーム開発でした。自分の理想の弾幕シューティングゲームを作りたいと思っていましたが、あるあるの例にもれず、いつのまにかゲームそのものよりも、そのゲーム開発のためのアーキテクチャ設計のことばかり考えるようになっていました。
ゲームの開発手法を調べている中で、私は Entity-Component-System (ECS) という設計パターンに出会いました。これは、オブジェクト指向とは異なり、データを中心にコンポーネントを組み合わせてエンティティを表現する、柔軟性とパフォーマンスに優れたアーキテクチャです。この考え方が面白いと思った私は、パフォーマンスが高い ECS アーキテクチャを実現できるライブラリ donburi を開発し、公開しました。
幸運なことに、このライブラリは海外の著名な方のブログでチュートリアル記事のなかで紹介され、それをきっかけに多くのスターを獲得しました。
m110氏により開発された airplanes
しばらく ECS のライブラリでは、パフォーマンスの面で競合がいない状況でした。
しかし、そのような日は長くは続きませんでした。ある日どこかの研究者が開発した、パフォーマンスを極限まで追求した新しい ECS ライブラリが登場しました。そのライブラリは、私のものよりも明らかにパフォーマンスに優れており、donburi の存在価値が薄れていきました。
この経験は、私に OSS の厳しい現実を突きつけました。より優れた上位互換が登場すれば、ユーザーは容赦なく乗り換えていく。作ったものがすぐに陳腐化する。単に機能を提供するだけでなく、そのソフトウェアがどのような独自のポジションを取り、どのような価値を提供し続けるかが、長く存続していくためには不可欠なのだと痛感しました。
Dagu 開発のきっかけ – 「Cron 地獄」 からの脱出
次に私が取り組んだ課題は、より現実的で、切実なものでした。当時勤務していた大手企業で、私は「Cron 地獄」とでも言うべき深刻な問題に直面していました。
そのチームでは、社内の多様なシステムからデータを収集・連携するシステムを運用していましたが、その根幹は10年以上前に構築された無数の Cron ジョブ によって支えられていました。
社内では、何百個もの Cron ジョブが、複数のオンプレサーバーに散在していました。
ジョブ間の依存関係や全体構成を正確に把握しているのは、勤続 10 年を超えるインド出身の協力企業のベテランエンジニアがただ一人という、極端な属人化状態でした。障害が発生した際の復旧は、彼の「頭の中の設計図」に完全に依存していました。
この状況を改善すべく、私は Airflow のようなワークフローエンジンの導入を提案しましたが、調査すればするほど、私たちのチームの規模や要件にぴったりと合うものが見つかりませんでした。高機能なツールは導入が重すぎ、かといって日本市場で実績のある JP1 や Hinemos などの商用製品は高価で、とても手が出せる状況ではありません。
「なぜ、これほどありふれた領域に、シンプルで手軽な選択肢がないのだろう？」
その疑問に対する怒りにも似た感情が強くなりました。そして「無いのであれば、自分で作れるのではないか？」と思うようになりました。
こうして、Go 言語を使い、DAG のスケジューリングと可視化を行うソフトウェア、Dagu の開発を始めました。
最初に参考にした書籍は「Goならわかるシステムプログラミング（渋川よしき氏）」でした。Go 言語であれば、大抵のことはできそうだと感じました。
なぜ Go 言語を選択したのか
私が最初に学んだプログラミング言語は Java ですが、Go 言語の持つシンプルさと強力さに魅力を感じていました。Dagu の開発言語としてGoを選んだのには、明確な理由があります。
- 依存関係の少なさ： 標準ライブラリが非常に充実しており、
net/http を使えばWebサーバー機能も簡単に実装できます。
- シングルバイナリ： Go の
embed パッケージを活用し、Web UIのアセット（HTML, CSS, JS）をバイナリファイルに直接埋め込むことで、すべてを一つのバイナリにパッケージできます。
- 優れた並行処理： goroutine と channel を用いることで、多数のジョブを効率的に並列実行するロジックを、複雑なスレッド管理なしに記述できます。
大きなソフトウェアを小さく作り、拡張していく
Dagu のような比較的大きなソフトウェアを一人で開発し続けるために、私は 2 つの戦略を意識してきました。
1. 小粒なイテレーションで達成感を得る
壮大な計画を立てるのではなく、「小さく始めて、動くものを積み重ねる」ことを徹底しました。これにより、開発のモチベーションを維持しやすくなります。
たとえば、一番最初の開発はこのようなタスクに区切っていました。
第一週: CLI で dagu run workflow.yml が最低限動作する状態を目指す。
第二週: Web UI 上で DAG のグラフ構造が表示されるようにする。
第三週: UI にジョブのリトライボタンを実装する。
このように、毎週具体的な成果をリリースすることで、着実に前進している感覚を得られ、複雑な開発の道のりも苦になりませんでした。
2. Deep Module の思想で変化に強い設計を保つ
ソフトウェア設計においては、書籍『A Philosophy of Software Design』で提唱されている「Deep Module」の概念を常に念頭に置いています。これは、インターフェース（利用者から見える部分）を極限までシンプルに保ち、複雑な実装を内部に隠蔽するという考え方です。
出典: ソフトウェア設計についてtwada技術顧問と話してみた 〜 A Philosophy of Software Design をベースに 〜
Dagu の場合は以下のようなインターフェースを持っています。
-
インターフェース： 利用者は、実行したいコマンドを並べただけのシンプルなYAMLを定義するだけ。
-
複雑さの隠蔽: その YAML を解釈し、依存関係を解決してグラフを構築し、スケジューリングする複雑なロジックは、Dagu の内部に完全に隠されています。
一見単純に見える機能でも、将来的に多くの要求が追加されることを見越しておく必要があります。インターフェースを小さくシンプルに保つことで、モジュール内部の凝集度が高まります。その結果、修正が必要になった際も、影響範囲が限定され、開発者（未来の自分を含む）の認知負荷を最小限に抑えることができます。この設計思想のおかげで、4 年経った今でも、プロジェクトの全体像を明確に把握できています。
OSS を育てる上で最も重要だと気づいたこと
OSS はコードを書くだけでは育ちません。コミュニティとの関わり方が極めて重要ですが、その方法は私も手探りでした。その中で、一つだけ確かな効果を実感したことがあります。
コントリビューションのクレジットを明確にする
Dagu を通じて知り合った、元 Firefox のコミュニティマネージャーを務めていた友人から、「どんなに小さな貢献でも、貢献者の名前を明記して感謝を伝えなさい」という貴重な助言をもらいました。
早速、私はこのアドバイスを実践に移しました。
-
リリースノートでの言及： 新バージョンをリリースする際、バグ報告、機能提案、ドキュメント修正など、関わってくれた全ての人の GitHub アカウント名を記載するようにしました。
-
具体的な貢献内容の記述： 誰が、どのような貢献をしてくれたのかを具体的に記述します。
この取り組みを始めてから、一度貢献してくれたユーザーが、再び別の Issue や Pull Request で関わってくれる「リピート貢献率」が明らかに向上しました。自分の貢献が正当に評価され、感謝されていると感じることが、次の貢献へのモチベーションに繋がるのだと学びました。
OSS 開発を続ける原動力
美しい盆栽
なぜ、私はこの活動を続けるのでしょうか。その原動力は、大きく3つあります。
-
課題への「怒り」： あの「Cron 地獄」のような、属人化と非効率に満ちた運用負債を、二度と経験したくない。エンジニアがもっと創造的で本質的な問題解決に集中できる環境を作るべきだ、という強い思いが根底にあります。
-
利用者の声： 世界中のユーザーから寄せられる「Dagu を開発してくれてありがとう」という感謝の言葉や、「こんな使い方をしています」という報告は、何よりの喜びです。自分では思いもよらなかった使い方や、新たな機能のヒントをもらえることも多く、私自身の学びにも繋がっています。
-
「盆栽」を育てる楽しさ： ソフトウェア開発は、盆栽の手入れに似ていると言われることがあります。自分の美的感覚に従ってアーキテクチャという幹を整え、機能という枝を伸ばし、不要なコードを剪定していく。自分の手で、理想の形をした「作品」を育て上げていく過程そのものが、純粋に楽しいです。
これから OSS 開発を始めたい方への TIPS
もし、この記事を読んで OSS 開発に興味を持ったなら、ぜひ最初の一歩を踏み出してみてください。
-
身近な「小さい課題」を探す： 壮大なソフトウェアである必要はありません。あなたが毎日手作業でやっている面倒なこと、普段使っているツールの「ここが少し不便だな」と感じる点。そうした小さな課題を解決するツールこそ、OSS の絶好のテーマです。
-
README を丁寧に書く： 最初のユーザーは、未来のあなた自身です。READMEやドキュメントを丁寧に書くことは、他の開発者のためだけでなく、自分自身がプロジェクトに立ち返る際の助けにもなります。良いドキュメントは、不要な Issue を減らす効果もあります。
-
世界に発信する： 完成したら、Hacker News、Reddit、X (Twitter) といったプラットフォームで「こんなものを作りました」と投稿してみましょう。批判的な意見も含め、率直なフィードバックは、ソフトウェアをより良くするために貴重です。
AI エージェントを活用した OSS 開発
近年、AI エージェントの進化、とくに Claude Code は、OSS 開発のあり方を大きく変えつつあります。私も Dagu の開発において、AI エージェントを積極的に活用しています。
-
Issue の要約と修正案の検討： ユーザーから報告された複雑な Issue を AI に要約させ、考えられる原因と修正方針のドラフトを作成させる。
-
ドキュメントや Issue の草稿作成： 機能の概要を伝えるだけで、丁寧な英語のドキュメントや Issue テンプレートを生成させる。
-
Pull Request の生成： 具体的な修正指示を与えることで、小規模なバグ修正や機能追加のコードと、それに対応する Pull Request を自動生成させる。
この変化は、ソフトウェアエンジニアの役割が「プログラマ」から、より「プロジェクトマネージャー」や「アーキテクト」に近いものへとシフトしていくことを示唆していると思います。
AI エージェントを使いこなすためには、やりたいタスクを論理的に分割し、依存関係を整理し、明確な指示を与える能力が不可欠です。そして、AI が生成したコードを組み合わせても破綻しない、長期的に進化し続けられるアーキテクチャを設計するのは、依然として人間の重要な役割です。
うまく AI エージェントと協業すれば、個人の開発生産性は、手で書いていたときの 10 倍にもなり得ると私は感じています。
普通のエンジニアでも、OSS で世界と繋がれる
私がこの 4 年間の活動を通じて最も強く感じたのは、「自分一人が感じている課題は、実は世界の誰かも同じように感じている可能性が高い」ということです。
特別な才能や経歴がなくても、身の回りの小さな「不便」や「怒り」を原動力に、それを解決するソフトウェアを作り、発信することで、世界中のエンジニアと繋がり、OSS で価値を生み出すことができます。
言語の壁は、今や ChatGPT のような翻訳ツールがほとんど解消してくれます。Discord のようなコミュニケーションツールを使えば、国境を越えて気軽に海外のエンジニアと繋がることも可能です。
参考資料
本記事を執筆するにあたり、言及したソフトウェア、影響を受けた書籍へのリンクを以下にまとめます。ご興味のある方は、ぜひご覧ください。
告知
6 月 25 日 (水) ― DreamArts Tech Talk
個人で大きめの OSS をゼロから育ててきた経緯や OSS 開発に AI を活用する TIPS についてお話しします。
まだ席に余裕がありますので、ぜひご参加ください！
https://dreamarts-pr.connpass.com/event/357735/
