OSSを公開したら使いにくかった話｜ドッグフーディングで改善する
2026-03-22
はじめに
「利用者の視点に立つことが大事」
これは誰もが理解していると思います。そして、自分は利用者の気持ちを理解していると考えがちだと思います。この記事は、実際は全然理解していなかったということを反省した記事となります。
OSSライブラリ「SoundMaker」の開発を通じて、自分で使い倒す「ドッグフーディング」の重要性を痛感しました。利用者視点を理解しているつもりでも、実際に使ってみないと気づけない問題があります。テストでは見つからない使い勝手の問題を発見するためには、開発者自身が一番のユーザーになることが大切です。
開発中のOSS
C#でチップチューンサウンド（昔のゲームのようなピコピコするサウンド）を生成するためのライブラリ、「SoundMaker」を開発しています。
なぜ作ろうと思ったのか
高校生の時に基本情報技術者試験の勉強をしていた際、リニアPCMの仕組みを学びました。そこで、息抜きを兼ねて音を生成してWAVファイルで書き出せるプログラムを書いてみよう！となり、爆誕しました。
致命的やらかしポイント：使いづらくね？
使いづらポイント①：初期バージョンはファイル出力のみに対応
何故か当時はStreamへの出力に未対応。利用者の方に指摘頂いて初めて修正しました。
以下のリンクはStream未対応を指摘してくださったQiitaの記事です。
なんと、このライブラリはニーズなどを一切考慮せず
完成したからとりあえず公開しちゃえ
というノリで公開したのです。今回は「運が良く」指摘いただきましたが、もしこの指摘がなければ、長い間使いづらい状態で放置することになっていたと思います。
使いづらポイント②：楽譜をそのままデータ構造にしてしまった
ファイル出力の問題は指摘で気づけました。では、ドッグフーディングで自力で見つけた問題は何か。それが楽譜構造の問題でした。
見つけた内容は、音を鳴らさない時間を作るために必ず休符を入れる必要がある仕組みにしてしまったという内容です。つまり、本来なら「4小節目から音を鳴らす」と時間を直接指定したいのに、そこまでの空白をわざわざ休符データで埋めないといけない構造になっていました。このような構造では、DAWソフトのようなユースケースに対応できません。
自分でライブラリを使い倒すことが重要
これがこの記事の主旨となります。実際に使い倒さなければわからなかったということです。 このように、自分(達)の製品を自分(達)で使い倒すことを ドッグフーディング と言います。
経緯
気軽にチップチューン音楽を作成できるWEBアプリ「PICOM」を開発し始めました。PICOMの音声生成エンジンとして、自作したSoundMakerを組み込んだ流れです。
下記動画はPICOMの宣伝動画です。動画内BGMは実際にPICOMを利用して作成したもので、チップチューンのイメージがわかない方は、どのような音楽か聞いてみてください。
このアプリにピアノロールを実装する際に、「このAPIでピアノロール実装無理じゃね？」となったのが経緯です。
自分で使い始めて変わったこと
これをするだけでなんでこんな手順を踏まないといけないんだ？みたいな改善点が見つかりやすくなったことが一番のメリットだと思います。一応結合テストでAPIのテストはしていましたが、このテストはそのAPIが存在していることが前提なので、こういったことに気づくことができませんでした。
また、ライブラリ開発時は内部のprivateやinternalなプロパティ、メソッドを確認できます。しかし、利用する際は公開APIのみを利用できます。この時に初めて「このプロパティを外部に公開して欲しいな」とかにも気づくことができました。
とはいえ、実際は多くの人に利用してもらえたほうが楽では？
ほぼ自分だけが使っていたら自分のユースケースに特化してしまうというのは仕方がない側面もあります。ただ、この記事ではそういうことを言いたいのではなく、開発者サイドで利用者視点に立つためには実際に使い倒すことが大事だと言いたいです。できることなら、利用者には「使いやすい」とだけ感じられることが理想です。利用者からするとFBすることもコストです。
そして、これは二者択一の問題ではなく、両取りすることで相互作用を生み出せると思います。「利用者からのFB✖️自分のFB」を組み合わせることで、改善点が見つかりやすくなるのだと感じました。
OSSに限らず個人開発全般に言えること
ドッグフーディングの考え方はOSSに限った話ではなく、個人開発全般に当てはまります。自分で作ったものを日常的に使い続けることで、「動くけど使いにくい」部分が自然と浮き彫りになります。
例えば、私がClaude Codeを活用して開発した家計管理アプリ「Portal」でも、実際に毎日の家計管理に使い始めてから多くの改善点に気づきました。AIエージェントに実装を任せれば「動くもの」は簡単に作れますが、使い勝手の良し悪しは使ってみないとわかりません。
Portalの開発についてはこちら⬇️
まとめ
- 「利用者の視点に立つ」ことは、頭で理解しているだけでは不十分で、実際に自分で使い倒して初めて本当の課題が見える
- 自動テストは正確性を証明できても、使いやすさは証明してくれない。ユースケースを実際に動かして初めてわかる問題がある
- ドッグフーディングと利用者からのフィードバックは二者択一ではなく、両方を組み合わせることで改善の質が上がる
