もしあなたがソフトウェアエンジニアなら、自分用の便利なツールを作っているうちに「これを公開したら、世界中の人に喜ばれるかも」と思ったことがあるかもしれません。しかし、2025年の今、優れたアイデアをコードにするだけでは、ユーザーには届きません。 「自分用」を「みんなが使えるOSS」にするまでには、コードを書くこと以上に険しく、泥臭い道のりが待っています。
私は現在、PC作業を自動記録・可視化するツール Quality-Work を個人で開発しています。この開発を通じて思い知らされた「OSS開発の現実」を共有したいと思います。
1.「マルチプラットフォーム × 優れたUI」という技術選定のジレンマ
日々の作業を記録するツールである以上、WindowsとMacの両対応は必須。さらに、一般ユーザーに継続して使ってもらうには、直感的でモダンなUI/UXが不可欠です。
加えて、「自分のPC作業データ（何をしていたかという極めて個人的なログ）を外部に出したくない」というニーズが強そうなので、クラウドサービスではなく、データが手元に残るデスクトップアプリとして完結させる必要があります。
これを実現するために開発者は難しい選択を迫られます。
- WindowsならC# / .NET、MacならSwift / SwiftUIで開発し、ネイティブアプリにするのが理想
- しかし、個人で「2種類のコード」をメンテナンスするのはリソース的に現実的でない
考えた結果、「一つのコードで開発でき、誰もが使い慣れたWebの操作感を提供する」ために、あえてデスクトップアプリの中にWeb3層構造を組み込むというアーキテクチャを選択しました。
- GUI: JavaScript + React（洗練されたWeb UIを提供）
- Logic: Python + Django（強力なバックエンド処理）
- DB: SQLite（ポータブルな組み込みDB）
GUIにQt(PyQtなど)を使う選択肢もあったのですが、どうしても拭えない「独特の業務用ソフト感」を避けるたに採用しませんでした。
2. すぐ使える」形で配布する難しさ
ここで問題は、このようなWeb３層構造を持つようなソフトウェアをどのようにエンドユーザに配布するかということです。ユーザーに「PythonとDjangoを入れて、Webサーバーを設定して……」と求めるても絶望的に難しく、誰も使ってもらえなそうです。
そこで、Python環境を丸ごと実行ファイル（.exe / .app）化する PyInstaller を導入することにしました。しかし、実際にやってみると、これが一筋縄では行きませんでした。
- 依存関係の定義が難しい: 複雑なパッケージ構成を正しく取り込むための、果てしない試行錯誤
- モジュールサイズが大き過ぎ: 放っておくと数百MBに膨らむモジュールを、少しでも軽量化するための試行錯誤
これだけで記事が一本かけるほどの内容なので詳細は別記事にしようと思います。
3. 「安心して使ってもらう」ための高額な「通行料」
ようやく実行モジュールを作り、サイトにアップしても、OSのセキュリティ機能という門番が立ちはだかります。Mac OSやWindowsのセキュリティー機能が「知らない開発者が作ったソフト」の実行に制限をかけるため、以下のような警告を発します。
- 「Appleは、“quality-work”にMacに損害を与えたり、プライバシーを侵害する可能性のあるマルウェアが含まれていないことを検証できませんでした。」
- 「Microsoft Defender SmartScreenは認識されないアプリの起動を停止しました。このアプリを実行すると、PCが危険に晒される可能性があります」
せっかく興味を持ってくれたユーザーも、こんなメッセージを見るとゴミ箱に捨てたくなりますよね。
これを回避するためには、多額の 「課金」 と手間が必要になります。
- Apple Developer Program: 年会費 約13,000円（Macでの警告回避に必須）
- Windows コードサイニング証明書: 年額 約8万〜20万円。しかも個人では審査が通りにくい
- 公証（Notarization）: Macの場合、Appleのサーバーにプログラムを送り、チェックを受けるプロセスも必須
このコストはなかなかに高い壁ですが、私は今、ようやくこれに挑んでいる最中です。無事このクリアできたら、これも別記事として書こうと思います。
2026/12/28 追記
上の「Windowsコードサイニング証明書」とは、EVコードサイニング証明書のことで、この証明書を使ってアプリケーションにサインすることで警告が回避されます。これとは別に、2024年からMicrosoftよりAzure Trust Signingという仕組みが提供されるようになっており、こちらの方が安価で手間もかからないようです。まずは、こちらを試してみようと思います。
4. 盲点になりがちな「アップデート」の設計
初版を公開して終わりではありません。ツールが進化すれば「バージョンアップ」が発生します。ユーザーがこれまで蓄積したデータ（DBや設定ファイル）を、いかに安全に、かつ手間なく新バージョンへ引き継ぐかが問題になります。 「このファイルをバックアップして、新しいフォルダにコピーしてください」という手順を強いた瞬間に、ユーザーは離れていきます。
Quality-Workではデータ移行ツールを用意しましたが、できればユーザーが何もしなくても自動的に移行ができるようにしたいものです。とは言え、機能追加や改善に伴いデータベースに変更があった時などを考えると、自動移行を保証する設計骨の折れる作業になりそうです。
おわりに
エンジニアはどうしても「モノ作り側の視点」で、新しい機能やコードの美しさに目を奪われがちです。 しかし、いざ「多くの人に使ってもらう」ことを目指した時に、本当に必要なのは「配布」「信頼」「保守」といった、難解で泥臭い課題を一つずつクリアしていく地道な作業でした。
このように、ソフトウェアを多くの人に使ってもらうまでには、長い道のりがあります。同じようなことをされる方は少ないかもしれませんが、何かの参考になれば幸いです。
ところで、ここまで読んでいただきQuality-Workに興味を持っていただいた方はぜひ公式サイトをご覧ください。 「自分の働き方を可視化して、生産性を改善したい」という方にはお勧めのツールです。また、開発者として「中身のコードやライブラリ構成に興味がある」という方は、GitHubを覗いていただければと思います。
- Quality-Work 公式サイト （ツールの詳細・ダウンロードはこちら）
- GitHub - K-Kuyama/Quality-Work-Standalone （ソースコードはこちら）