2年半前、人生で一番大変だった 追い詰められた プロジェクトが終わりました。
少しだけ時間に余裕ができたので、個人で運用していたWebアプリをリプレイスすることにしました。
そしてあれこれ試行錯誤していたら、2年半経っていました。
なにを作った?
Webアプリをたくさん作り、見込みがありそうなものをスマホ・デスクトップと、別のプラットフォームに移植していきました。
例えば、ポモドーロツリー というアプリを作ったのですが、これはWeb、スマホ、デスクトップ全てのプラットフォームでリリースしています。
他にも ひらめき開発 というサイトを運用しています。
当時、興味のあった心理学(ひらめき)と、プログラミング(開発)のツールを配信するサイトとして始めました。
今思うと小っ恥ずかしいネーミングです。笑
しかも心理学のツールは全く伸びなかったので全部削除してしまいました。月間のPVはピーク時で8万PVくらいでした。
知見をまとめた
2年半経ってノウハウが貯まってきたので、一度まとめることにしました。
以下、目次です。とても長いです。興味のあるところから読んでもらって大丈夫です。
目次
アーキテクチャ
アプリをたくさん作るために、アプリを柔軟に開発・配信できる基盤をゼロから作りました。
以下はメイン部分の大まかな構成図です。
キャッシュ戦略
GitHub Packagesでプライベートコードの共通化
公開したくないけど、共通化したいコードはGitHub Packagesから配信しています。npmでプライベートパッケージを配信しようとすると課金する必要があります。GitHub Packagesは無料で始められるのでオススメです。
バックエンドにHonoを使ってみる
バックエンドのAPIは用途によって、いくつかのサービスを使って構築しています。
- Cloudflare Workers
- Firebase Functions
- AWS Lambda
そんな中、「NextのバックエンドにHonoを使う」という記事を読みました。Nextで出来るのであれば、Nuxtでもできるのでは?と思いやってみました。
HonoでAPIを作っておけば、かなり簡単にインフラサービスを移動できるので安心ですね。
- Cloudflare Workers
- Firebase Functions
- AWS Lambda
- Nuxt(Cloud Run) ←New!
開発フロー
モノレポで全コードを一つのリポジトリで管理
基本的にコードをモノレポで管理しています。
モノレポとはプロジェクトに関するコードを全て一つのGitリポジトリで管理する方法です。
例えば、フロントエンド、バックエンドの両コードと一つのGitベースで管理しています。モノレポで管理するとそのアプリに関するコードが一つにまとまっているのでコードが迷子になることがなくて便利でした。
repository
├── backend
├── desktop
├── frontend
└── mobile
こんな感じのディレクトリ構成になります。
モノレポとバイブコーディングは相性が良い
また、2025年ごろからバイブコーディングが広まっていくにつれて、モノレポにしていて良かったと思うことが増えました。
例えば、フロントエンドからバックエンドのAPIを呼び出す時に、バックエンドのコードを直接確認してもらいながらAIにコーディングをお願いできます。
仕様を別途伝える必要がないので楽でした。
ステージング環境で確認してから本番環境へ
変更したコードはまず、stagingブランチにコミットします。その後、pushするとGitHub Actionsでステージング環境にデプロイされます。
ステージング環境で確認して問題なければ、mainブランチにマージします。そうするとまたGitHub Actionsが走って本番環境にデプロイされます。
必ずステージング環境を経てから本番環境にデプロイすることでバグが入り込むのをできるだけ防いでいました。
コードは小さく変更する
Gitのブランチ戦略である トランクベース開発 を参考に、コードを小さい単位で変更しています。GitHub Actionsで自動デプロイを組むことですぐに本番環境に変更を反映します。
コミット履歴を確認してみると2年半で3,600回コミットしていました。モノレポなのも相まってとてもたくさんコミットしていました。
私は今回の開発で、このコードデリバリーの仕組みを考えるのがとても好きになりました。
ソフトウェア開発の生産性について研究しているDORAのサイトには他にもたくさん、生産性向上のヒントが載っているのでオススメです。DORAはGoogle Cloudが母体みたいですね。
改善活動
Lighthouseのスコア改善
ある程度、アクセス数が増えてきてから、Lighthouseのスコア改善に取り組みました。
アクセス数の多いページから改善していくことでコスパ良く改善していきます。その甲斐あって、アクセス数の多いページはさらに大きなキーワードで1位を取れるようになりました。
Lighthouseのスコア自体は検索順位に影響しないらしいので、体験が良くなった結果検索順位も向上したのだと思います。
最近はNuxtのパフォーマンスのチューニングを頑張っています pic.twitter.com/qw9S6AAt7L
— かい (@takasqr) October 11, 2025
スマホアプリ化
Webサイトのアプリ部分をコンポーネントに切り出して、スマホアプリにしてリリースしました。iOS、Android両方のプラットフォームでリリースしています。
Capacitorという、WebViewを使うタイプのフレームワークを使っています。Vueコンポーネントがスマホアプリとして動いているのは面白かったです。
詳しくはこっちの記事に書きました。
おまけ
便利ツールをOSSプロジェクトに
開発していく中で作った便利ツールや共通化できるコードはOSSプロジェクトとして切り出していきました。
詳しくはこっちの記事に書いています。
こっちはVueのUIライブラリのStorybookダッシュボードを公開した時の記事です。
UIライブラリを開発するにあたっては、以前Vuetifyを使い込んでいた経験がとても役に立ちました。使いやすい汎用的なインターフェースを考えて実装しました。
開発知識はZennに
他にも開発する中で溜まった知見はZennに書いています。よかったら覗いてみてください。
確認したら記事が178本ありました。
うまくいかなったこと・やらなかったこと
うまくいかなったこと、やらなかったことも書いておきます。
- 多言語対応
- ダークモード対応
この2つはうまくいきませんでした。
20もの言語に対応させたけどうまくいかなかった多言語対応
多言語対応は「作ってるアプリはツールアプリが大半だし、生成AIも登場して精度もすごく良くなってきているから行けるんじゃないか」と思ってやり始めました。
ちょうどGhatGPTが出てきて、その翻訳精度の高さが騒がれている時です。
日本語から英語に翻訳して、英語からその他の言語に変換するという方法でWebアプリの多言語対応を進めていきました。
対応させた言語は、日本語も含めてなんと20言語。世界中のかなりの人をカバーできる数です。
ですが、ほとんどアクセスを集めることができずに日本語のみに戻してしまいました。定かではありませんが、やっぱり微妙に違和感がある翻訳になってしまっていたのではないかと思います。
また、英語以外の言語は全く読めないので、日本語に逆翻訳してチェックしていたのですが、調子に乗って20言語にも対応させてしまったので作業負担が大き過ぎました。
ただ、今ならClaude Codeなどのバイブコーディングツールもあるし、生成AIの翻訳精度もさらに向上しているのでまた違った結果になるかも知れません。
労力の割にメリットが少ないダークモード対応
ダークモード対応もうまくいきませんでした。
これも多言語対応と同じく、労力にメリットが見合わないと感じてしまい断念しました。
かなりたくさん作ってしまた後に作業を始めたのが失敗でした。
ダークモード対応させるなら初めから対応させるべきだったと学びました。
さいごに
色々やってみることでスキルアップに繋がる
2年半、完全に独学、自力でここまで色々できたことは自分の中で自信につながりました。これからも手を動かしていきたいと思います。
私は普段から仕事で使う技術をプライベートで遊んでみるようにしています。そうすることで躓きポイントや全体的な雰囲気を事前に知っておくことができるのでオススメです。
More Stories
紅白もちのひみつ『めっきらもっきら どおん どん』
奥さんに言われて「はっ」としました。もんもんびゃっこ達は赤いおもちを食べていて、かんたは白いおもち。これはなんらかの意味がこめられてるのでは？と思い考えてみました。
星空写真をAndroid Pixelでキレイに撮る
キャンプ場での夜空はやっぱりキレイでした。星がよく見れます。肉眼で見れるこのキレイな星空を写真に残せたら嬉しいなーと思いながら、タイマーが終わるのを待ちます。
メモは脳の排水
紙、デジタルどちらでもなんでもメモに書き出します。書き出すことで考えが整理され、ネタ帳になってくれるので重宝しています。この「脳の排水」という言葉にグッときました。
リアル書店の選書体験
今回で改めて書店の良さに気付けたのが良かったです。ただ、ネット通販や電子書籍には手軽に買えるなど別の良さがあると思ってます。なのでうまく使い分けていきたいです。