個人開発を7年以上続けて分かった技術選択のコツ
個人開発を7年以上続けて分かった技術選択のコツ
InkdropというMarkdownノートアプリを作り続けて7年になる。 お陰さまでその売上でずっと生活できている。 これまで個人開発でどう継続していくかについて「ユーザの退会理由をあれこれ考えない」とか「アプリの売上目標を立てるのをやめました」とか、ビジネス面あるいはメンタル面からいろいろ書いてきた。 今回は、技術面にフォーカスして、どう継続して開発していくかについてシェアしたい。
TL;DR
- 最初はとにかく最速でリリースする事を最優先する
- 迷ったら「ときめく方」を選べ
- 程よいところで切り上げて開発を進める
- 使っているモジュールがdeprecatedされるなんてザラだと覚悟する
- 古いから悪いとは限らない
- シンプルにしていく
- 老舗から継続の秘訣を学ぶ
- 運ゲー要素は排除しきれない
最初はとにかく最速でリリースする事を目標に技術選定する
開発計画とビジネス計画は切っても切り離せない。 コーディングに傾倒するあまり完璧主義に陥って結局リリース出来ないまま頓挫してしまう個人開発者は多いようだ。 最初から完璧なものを作って周りを驚かせたい気持ちはわかる。でも諦めよう。 個人開発で食っていきたいのなら、まずはPMF(Product Market Fit)を達成しなければならない。 PMFというのは要するにあなたのアプリがお金になるのかどうかを確かめる or お金になるように方向性を修正するという事だ。 PMFするためには、とにかくリリースしなければ何も始まらない。 考えるだけではマネタイズ出来ない。
最速でリリースするためには、あなたの使い慣れた言語、今ある便利なライブラリやフレームワーク、あるいはテンプレートなどを恐れずに採用しよう。 それが長期的に最善の選択かどうかは今は気にしなくていい。 とにかくMVP(Minimum Viable Product=最小限動くプロダクト)を作り、世に出す(shipする)事が第一だ。
クレジットカード決済プラットフォームのStripeの最初のバージョンはとてもラフだったし、Mailchimpのv1.0もすごくシンプルだった。これでいいのだ。 Inkdropの初期バージョンはノートアプリなのにまともな設定画面すら無かったし、とにかく早くリリースしたかったので決済の実装は後回しにしてクローズドβでHacker Newsに投稿してテスターを募って反応を見た。
雑に作れと言っているのではない。 あなたのアプリは課題を解決するのだ。 課題を解決する最小限のものを作れと言っている。
自問する：
- アプリで解決したい課題は何だ？
- 課題を解決する最短の実装方法は何だ？
- 今やっているそれは課題解決と関係があるか？
- 見栄(他人によく思われるため)に時間を割いていないか？
- そのリファクタリングを今する必要が本当にあるか？
- リリースする事自体を恐れて後ろ倒しにしていないか？
迷ったら「ときめく方」を選べ
特に初期段階の開発は、どの技術を採用するかという選択の連続だ。 その選択に迷う事も多い。
よく「AとB」どっちがベストか？と聞かれる。 例えば「React NativeかFlutterか」「VimかVS Codeか」「ReactかVueか」などなど。 こういった質問は初心者に多く見受けられ、前提も要件も何も説明無しに投げかけられる。
誰にとってもベストな人生の選択なんて無いように、技術の選定においても万人にベストなものなんて存在しない。 「どの国（あるいは街）に住めばよいか？」という質問に絶対がないのと同じだ。 もし「絶対にXXXを使え！」と言ってくる人がいたら、利害関係を疑ったほうが良い。
じゃあ何を基準に選べば良いのか？自分は「ときめき」だと思う。 「使っていて面白い」とか「楽しい」「気持ちがいい」、もしくはコミュニティの雰囲気が良い、ウェブサイトがかっこいい、何でも良い。自分が直感的に「良いな」と感じる方を選ぶ。 個人開発はモチベーションが大事だ。チームメイトが励ましてくれる事も無い。 逆に言えば、チームの空気を読まずに自由に選択できるのだ。 せっかくの個人開発なのだから、自分が楽しいと思える方を選んだほうが継続しやすい。 そのモーメンタムを絶やさないでメンテし続けられる選択が、あなたとアプリにとっての「ベスト」だ。
ときめき？意味がわからない。具体的な比較基準は？
とは言え、技術にときめきなんて求めていないとか、これまでときめいた事なんてないという人もいるだろう。（そういう人が個人開発に向いているかは疑問だが）ある程度客観的な比較検討基準を列挙しておく。
1. 公式ドキュメントの詳しさ
- いくら新しくてイケてる雰囲気があっても、困ったときに参照するドキュメントが無ければ使いようがない
- アクション: 公式ドキュメントを読む癖をつけろ
2. コミュニティの雰囲気の建設的さ
- GitHubのIssuesやフォーラムの議論を眺めたり、作者のX(Twitter)での活動をチェックする
- バグ報告がずっと放置されているとか、本筋と関係ない話題で荒れてたりしたら避ける
- アクション: 問題にぶち当たったら本家のIssuesや作者の動向を参照する癖をつけろ
3. 開発の活発さ
- リポジトリの最終更新日が半年〜1年以上前のものは無条件に切り捨てる
- InsightsタブのContributors欄を見て、コミット数やコントリビュータの変遷を時系列に俯瞰する (例: React Native)
- アクション: 技術は結局人。人に着目しろ
スターの数はどちらかというと新規性や話題性を示すものであり、継続性とは相関があまりないから参考にしない。
それでもやはり究極的には分からない。 作者が解雇されたり転職してOSSに時間を割けなくなる事もあるし、地震災害・戦争の影響も起こり得る。 最初はシンプルだったのに、バージョンアップするうちに複雑になってバグが増えるなんてケースもある。 がんばってPull Requestを送っても無視される事もザラにある(気にしない)。 一方、Evan YouやMarijn Haverbekeのように神すぎて全ての悪い予想を裏切る人もいたりする。
だから上記をチェックすれば安心という事はなく、せいぜい打率が5~10%ぐらい上がる程度だと思っておくと良い。
程よいところで切り上げて開発を進める
こういうのは、調べれば調べるほど分からなくなったりする。 候補の技術を片っ端から試してPros&Consを書き出した所で、「やはりベストは無いな・・」となり、余計に分からなくなる。 その時間を、さっさと決めて実装を進めた方が学びになるしユーザのためになる。 だから、ざっくり調べて、あとは直感で選んでしまって良い。 無知が推進力になる事だってあるのだ。
自分は「無知の力」は時に有用だと思っている。 知りすぎると動けなくなるからだ。 知らないのは悪いことではない。 「学んでからやる」ではなく、「試行錯誤しながら学ぶ」が良い。
とりあえずときめくモノを選んで、試行錯誤して詳しくなり、その経験を元に必要なら選定を改めれば良い。
使っているモジュールがdeprecatedされるなんてザラだと覚悟する
リリースし、無事お金になりそうな事がわかって方向性が固まったら、クオリティを上げる段階になる。 この時、開発を始めた当初はフレッシュだったライブラリやフレームワークが既に廃れている可能性は結構ある。 あるいは、使っているフレームワークがメジャーバージョンアップして、後方互換性が無くなっている事も頻繁にある。 つまりあなたは既に技術負債を抱えているのだ。 これは経験上避けられない。
ここで、「絶対に廃れ無さそうな技術」を見つけようとするのは間違いだ。 残念ながら未来は誰にも予想できない。 例えばAtom Editorは7年前は物凄くポピュラーで、これがその後開発終了してしまうなんて誰も予想していなかった。 InkdropはAtom Editorの内部モジュールをベースに開発したが、これを受けて代替モジュールへの入れ替えを段階的に行っている（まだ終わっていない）。 反対に、React Nativeは出た当初「トンデモ系フレームワーク」なんて言われたりしていて懐疑的な人が多かったけど、今ではMetaをはじめMicrosoftやAmazon、Shopify、Discordなどで採用されている。 それでもなお、今後も絶対に廃れないかと言われたら、誰も分からないのだ。 この事実をまずは認識するべきだ。
古いから悪いとは限らない
古くて枯れていても、jQueryのように細々とメンテされているライブラリもある。 あるいは、Semantic UIのように完成の域に達してしまったのでメンテが終わったライブラリもある。 「古いから良くない」という思想に囚われて、何でも入れ替えようとするのは間違いだ。 実際に問題が起きていないのなら、そのまま使い続ければ良い。
例えば、Inkdropの場合はUIフレームワークにSemantic UIを使用していて、そのコンポーネントの一部がjQueryに依存していた。 ノートアプリは多機能な上に起動速度も軽視できないので、冗長なライブラリ依存は削いでいく必要があった。 そこで、jQuery依存の部分だけを最小限のReactの実装で置き換えた。 それでも、機能上は問題なかったので、優先度はかなり低かった。 ほとんど自己満足の領域だ。
車輪の再発明も可能な限り避けるべきだ。 こういうのは無意識に始めてしまうから厄介だ。 でもHeadless UI、Radix UI、React Ariaのソースコードを読んでいて、気軽に始めたら確実に沼にハマるのを強く認識した。 もしJust another dropdownを作ろうとしたらグーで自分を殴りたい。
シンプルにしていく
最短リリースで作り、スピード重視で機能追加してきたものは、至る所で冗長だったり無駄が多い部分がどうしても多発する。 しかしPMF出来てビジネスとして成り立つ事が分かった段階なら、ここからリファクタリングして削れる所をどんどん削っていこう。 PMFもしてないのにリファクタリングに長い時間を割くのはお勧めしない。根本的な問題はそこじゃない。 また、この辺りからパフォーマンスも気になり出して、ユーザからも苦情が来る頃だ。 バージョン違いの重複した依存関係などを整理したり、使ってないモジュールをどんどん落としていく。 今までブラックボックスで使ってきたライブラリの中身を理解して、処理の無駄を削ぐ。
一方、リファクタリングに時間を割くと外部から見た開発スピードはどうしても落ちる。「いつまで待たせるんだ！」とお叱りを受けたりもする。そこでサービス精神から派手な新機能をバンバン付けたくなるが、我慢だ。 もどかしい気持ちになるが、新規ユーザ獲得よりも既存のハッピーカスタマーを更に幸せにすることを忘れないようにしよう。 機能を増やすという事は指数関数的に複雑性が増える。 あなたはその複雑性と継続して付き合っていく覚悟があるのか。
Each time you increase the amount of code, your software grows exponentially more complicated.
— DHH, Getting Real
機能を一度増やしたら、後戻りが難しくなる。ここからは既存実装のメンテと機能追加のバランス感覚が必要になる。
自問する: 多機能だけど重くて不安定なアプリと、シンプルで軽快に安定して動作するアプリ、あなたはどっちを使いたいか？
老舗から継続の秘訣を学ぶ
Inkdropの開発が7年を超え、いくつものライブラリのdeprecatedを経験し、考え方が少しずつ保守的になっていくのを自覚していた。 しかし本当にそれで大丈夫なのかという不安があったので、先人から学ぶことにした。
ところで、日本は世界一長寿企業の多い国だ。世の中の老舗と言われるお店や会社は、自分のような悩みを乗り越えて来たに違いない。 そこで個人開発を長く続けるために、下記の本を読んだ：
Amazon.co.jp: 創業三○○年の長寿企業はなぜ栄え続けるのか eBook : グロービス経営大学院, 田久保 善彦: Kindleストア
月桂冠は1637年（寛永14年）創業の日本を代表する日本酒メーカーだ。 日本酒メーカーと言うと堅くて保守的なイメージがあるが、そんな事はない：
明治時代には酒造りに科学技術を導入して、樽詰全盛の時代に防腐剤なしのびん詰を開発し、日本で初めて年間を通じて酒造りを行う四季醸造システムを実現しました。 近年ではアメリカで酒造蔵を稼働させ、世界に日本酒を広めるなど、堅実さと革新性の両面を合わせ持った企業と言えるでしょう。
このように、伝統を守りつつ技術革新を怠らない姿勢が見て取れる。 創業300年超えだから、産業革命と情報革命の中を生き抜いた事になる。凄い。
エンジン部品や自動車部品を手掛けるヤマトインテックは1584年（天正12年）創業だ。
社員は入社後、五年間にわたって鋳物製造の現場を必ず経験します。 営業採用の社員も例外ではなく、全社員です。 これが、誰にも負けない鋳物への想い、家族のような絆が感じられる社風につながっています。 インタビューした多くの社員から、鋳物への想い、鋳物への愛情という言葉を何度も耳にしました。 まさに、「鋳物にこだわり抜く」ということが、組織文化として根付いている証だと言えるでしょう。
変化を恐れず技術革新に挑む一方で、鋳物へのこだわりを捨てない強さが長寿の秘訣らしい。
最も強い者が生き残るのではなく、最も賢い者が生き延びるのでもない。唯一生き残るのは、変化できる者である
— チャールズ・ダーウィン
進化論では、変化に適応できる生物が生き残ると言われている。
これら先人の知恵を借りれば、保守一辺倒では駄目で、本質的な価値は何なのかを見失わず、かつ技術革新にも果敢に挑む事が大事なようだ。
直近ではGenerative AIの進化が目覚ましい。 しかし今はまだ変化が早すぎて、新しいものが雨後の筍のように出てきている状況だ。 あとはApple Vision Proなど、新しいプラットフォームの登場も気になる所だろう。 こう言った身近な技術革新と程よい距離感を保ちながら適応していかなければならない。
InkdropはプレーンテキストのMarkdownである事にこだわりを持っていて、オフラインで軽快に動作して、柔軟にノートの整理が出来るのをウリにしている。 新しい技術を取り入れるときは、このコアバリューに本当に貢献するものを取り入れるようにしたい。
AIの活用で言うと、最近はアプリの動画チュートリアルを作った。そこにコンパニオンとしてイヌのマスコットを登場させて、AIで生成した音声を乗せて喋らせた。 この動画の評判は良くて、楽しみながら使い方を学べるエデュテイメントの新しいフォーマットを開拓したと思っている。
運ゲー要素は排除しきれない
ここまで書いたものの、いくら入念に検討しても失敗するときは失敗する。 だから失敗する前提で技術は選定していくものだと考えよう。
ここで大好きな進撃の巨人からリヴァイのセリフを引用して終わりにしたい。
ここまで読んでくれてありがとう。 もし技術ノート用のアプリをお探しなら、ぜひInkdropをチェックしてくれると尚嬉しい。
それでは良い個人開発ライフを。
