このサイトを作り始めたのは、2025年の秋でした。
リードエンジニアとして週60時間近く働きながら、毎日のように「こんな小さなツールがあれば5分で終わるのに」という瞬間がありました。その不満が積み重なって、「ならば自分で作ろう」という結論に至るまでに時間はかかりませんでした。
ただ、作るだけなら以前もやっていました。今回が違ったのは、「ちゃんと公開する」という決断です。自分だけが使うツールは雑でいい。でも人に使ってもらうとなると、考えることが一気に増える。その違いを、3ヶ月かけて痛感しました。
この記事では、utily.net を作った経緯と各ツールの開発秘話、そして公開後に気づいたことを書きます。技術的な詳細は別の記事で書くとして、ここでは「なぜ作ったか」「実際にどうだったか」に絞ります。
utily.net を作ろうと思ったきっかけ
最初の「あれ」は、履歴書でした。
30代になって転職市場を意識し始め、久しぶりに履歴書を用意しようとしました。「無料で使えるオンラインツール」を検索すると、出てくるのは会員登録必須のサービスや、入力したデータをサーバーに送っているもの。バックエンドエンジニアとして普段からデータの流れを意識して仕事しているので、「この個人情報はどこに保存されているんだろう」という疑念が拭えませんでした。
ブラウザだけで動いて、データをどこにも送らない履歴書ツール。そういうものを探しましたが、見当たりませんでした。「ならば自分で作るか」。これが最初の1本、履歴書ジェネレーターの始まりです。
そしてひとつ作ると、「これも作れそうだ」「あの不満もツールで解決できる」と芋づる式にアイデアが出てきました。結果として6本のツールをほぼ同時並行で設計することになりました。我ながら無謀だったと思います。
各ツールを作った本当の理由
履歴書ジェネレーター
「個人情報をサーバーに送りたくない」という一点から
ブラウザ上で完結し、PDFとして出力できる履歴書ツール。Jotaiで状態管理し、Google Driveへの保存にも対応。
技術的に一番大変だったのがこれです。ブラウザだけでPDFを生成するというのは、やってみるまで「まあできるだろう」と甘く見ていました。実際には日本語フォントの問題、A3横レイアウトとA4縦レイアウトの両対応、バンドルサイズの肥大化と、次々と壁が立ちはだかりました（技術的な詳細は別の記事に書きました）。
ただ、「完成したときの達成感はほかのツールの比ではありませんでした」。フォームに入力してボタンを押すと、きれいにレイアウトされた履歴書PDFがブラウザ内で生成される。それが実現したとき、久しぶりに「作ってよかった」という感覚が戻ってきました。
Palette（クリップボード管理）
「また同じコメントを書いた」という日常の気づきから
よく使うテキストをタブで整理して、クリックでコピーできるクリップボード管理ツール。URLで共有も可能。
コードレビューをしていると、毎回ほぼ同じコメントを書いていることに気づきました。「このimport文は上に書いてください」「変数名をもう少し具体的に」「コミットメッセージのフォーマットは...」。これをNotionのページから毎回コピーしていたのですが、ページを開いて、スクロールして、見つけて、コピーして、の手間が馬鹿にならない。
クリップボード管理ツールは市場にたくさんありますが、「軽くてシンプルで、チームと共有できる」ものが欲しかった。URL に状態を持たせることで、アカウント不要で共有できる設計にしました。この「URLで共有」機能は、実装してから思いの外便利で、自分でも毎日使っています。
FlowTick（時間計算ツール）
「勤怠入力のたびに電卓を叩いていた」という情けない現実から
作業の開始・終了時刻を入力するだけで時間を自動計算。日跨ぎにも対応し、カレンダーで過去データを管理できる。
毎月末の勤怠システムへの入力が面倒でした。特に日跨ぎの作業（夜中まで残業して翌日扱いになる時間）の計算が、毎回電卓を使わないとできていなかった。バックエンドエンジニアが勤怠計算を手計算するというのは、なかなか情けない話です。
FlowTick を作ってから、勤怠入力の時間が半分以下になりました。「カテゴリ別の時間集計」機能は、自分がどの仕事に何時間使っているかを可視化するために追加したものです。意外なことに、ミーティングに費やしている時間が、コーディングとほぼ同じだとわかりました。リードエンジニアとしては当然かもしれませんが、数字を見ると少し複雑な気持ちになります。
GuideKnot（マニュアル作成）
「引き継ぎのたびにマニュアルを作り直している」という非効率から
業務手順を分岐・ネスト構造で表現できるマニュアル作成ツール。実行追跡機能で「読むだけ」から「使うマニュアル」へ。
エンジニアとしてキャリアを積むにつれ、引き継ぎの機会が増えました。毎回Confluenceや Notion にマニュアルを書くのですが、「手順A → 条件によってB または C → B の場合はさらにD」という分岐をテキストで表現するのが難しい。フローチャートを書くほどでもないが、箇条書きでは伝わらない。そういうケースが多い。
GuideKnot はその「ちょうど中間」を狙いました。ネスト構造で分岐を表現でき、実際に手順を実行しながら「今どこまでやったか」を追跡できる。作ってみると、自分自身が「障害対応手順」や「デプロイ手順」をここに書くようになりました。
6本の中で一番複雑なデータ構造が必要なツールで、ストレージには IndexedDB（Dexieを経由）を採用しました。なぜ localStorage ではなく IndexedDB かはストレージの比較記事に書いています。
Modtimer（可変速度時計）
「時間の流れ方を変えたら、集中力はどうなるか」という実験から
時・分・秒それぞれに速度倍率を設定できる可変速度時計。スライダーと数値入力の2モード対応。
これは完全に実験的なアイデアから生まれました。「時計の速さを2倍にして仕事したら、時間の感覚が変わるだろうか」という、実用性とは少し離れた動機です。
実際に使ってみると、時計が速く進んでいると「早くやらないと」というプレッシャーが増し、遅く進んでいると「まだ時間がある」という余裕が生まれました。プラシーボかもしれませんが、集中したいときに少し時計を速めにすると、不思議と作業ペースが上がる気がします。
エンジニア占い
「息抜きを全力で作る」という矛盾したモチベーションから
エンジニア向けの日替わり占い。その日の運勢とエンジニアらしいアドバイスを毎日お届け。SNSシェア機能付き。
実用ツールばかり作っていると、だんだん「役に立つものを作らなければ」というプレッシャーがかかってきます。そのプレッシャーをリセットするために作ったのが、エンジニア占いです。
「今日のデプロイは吉です」「コードレビューは北方向に向かって行うと良い」という、完全にエンジニアに向けたネタコンテンツ。でも全力で作りました。日付をシード値にした疑似乱数でメッセージを選ぶ仕組みと、友人へのシェア機能。見た目のシンプルさに反して、結構時間をかけています。
予想外に時間がかかったこと
ブラウザでのPDF生成（履歴書ジェネレーター）
一番詰まったのがここです。日本語フォントを埋め込む必要があること、フォントファイルが数MBにもなること、A3とA4でまったく異なるレイアウト計算が必要なこと。「1週間で終わる」と見積もっていたのが3週間かかりました。
IndexedDB の非同期API（GuideKnot）
Dexie.js を使ってもなお、IndexedDB の非同期な性質に慣れるまで時間がかかりました。「データを取得してから画面を描画する」という順序がうまく制御できず、Reactのライフサイクルとの噛み合わせで何度も詰まりました。
バックエンドエンジニアがフロントエンドを作る難しさ
普段はバックエンドとシステム設計を担当しているので、フロントエンドは「書ける」けれど「得意ではない」という状態でした。TypeScript の型定義でハマる、Tailwind CSS のクラス名を覚えられない、コンポーネントの分割粒度がわからない。これらを解決しながら進めるのが、想定以上に時間を食いました。
6本を同時並行でメンテナンスすること
各ツールは別々の React アプリとして動いており、パッケージのアップデートや共通コンポーネントの変更が入ると、全部に反映しなければなりません。モノレポ構成にしてある程度は楽になりましたが、それでも「あのツール、最近バグってないかな」という気になる感覚が常にあります。
公開して3ヶ月、正直な話
使ってもらえているか
Search Console を見ると、じわじわとインデックスされ始めています。友人や同僚に紹介したところ、「履歴書のやつ、便利だった」「Palette、チームで使ってる」という言葉をもらいました。派手な数字はありませんが、誰かの日常に少し入り込んでいるのを感じると、作ってよかったという気持ちになります。
「完成」という概念がない
リリースしたら終わりかと思っていたら、全然そうではありませんでした。「ここに機能があればもっと便利」「このUX、使いにくい」という改善点が次々と見えてきます。自分で使うたびに気になる点が出てくるので、週末のたびに何かしら更新しています。
メンテナンスのコストを甘く見ていた
6本のツールを公開するということは、6本分のバグ対応とセキュリティ対応が発生するということです。本業を抱えながら6本を維持するのは、正直言って少し重い。新しいツールを追加する前に、今あるものをしっかり磨くことを優先しようと方針転換しました。
「なぜ無料なのか」とよく聞かれる
「どこで収益化するの？」という質問をよくもらいます。今のところは広告を検討しています。ただ、ツール自体はずっと無料で提供し続けるつもりです。「日常の不便を解決する」というコンセプトは変わりません。
個人開発を続ける理由
本業では、チームの意思決定や技術的な制約の中で仕事をします。それは当然のことで、チームで作るからこそ大きなプロダクトができる。でも個人開発では、すべての決断を自分でします。技術選定も、UIのデザインも、機能の優先順位も。その自由さと、ユーザーの反応が直接返ってくる感覚は、本業では得られないものです。
誰かの日常に「これ便利だな」という瞬間を作れる可能性がある。それが、続ける一番の理由です。
よくある質問
Q. なぜモノレポ構成にしたのですか？
6つのアプリで共通のコンポーネントやカスタムフックを使いたかったからです。モノレポにすることで、共通の `apps/shared/` ディレクトリにまとめ、各アプリから参照できるようにしました。CI/CDの設定も1箇所で管理できます。
Q. なぜすべてのデータをローカルに保存するのですか？
プライバシーへのこだわりが最初の動機ですが、サーバー運用コストをゼロに抑えられるという実際的な理由もあります。個人開発で月々の固定費が発生すると、継続のプレッシャーになる。ブラウザだけで完結する設計は、サステナブルな個人開発を可能にします。
Q. 次はどんなツールを作りますか？
今は既存の6本を改善することを優先しています。ただ、「文章の読み上げ速度を練習できるツール」「ポモドーロタイマーで日々の集中記録を残せるツール」というアイデアは温めています。需要があればそちらに移りたいと思っています。
Q. 個人開発を始めたい人へのアドバイスは？
「自分が本当に困っていること」から始めることを強くすすめます。他人が困りそうなことを想像して作るよりも、自分が毎日使うものを作った方が、モチベーションが続きます。そしてできるだけ早く公開する。完成度が6割でいい。残り4割はユーザーに使ってもらって初めてわかります。
Q. コードはオープンソースですか？
現時点では公開していませんが、個別のコンポーネントや技術的な実装については、このブログで随時紹介していくつもりです。
まとめ
3ヶ月経って思うのは、「個人開発は思ったより大変で、思ったより楽しい」ということです。
自分の不満から生まれたツールが、見知らぬ誰かの日常に役立っている。それだけで、週末を費やした価値があります。まだまだ改善の余地だらけですが、地道に続けていくつもりです。
もし使ってみて「ここがわかりにくい」「この機能が欲しい」と感じたら、お問い合わせフォームから教えてください。実際に使っている人の声は、どの分析ツールの数字よりも参考になります。