Mjusui's Blog
個人開発はフルスクラッチが一番

Mjusui's Blog by Mjusui is licensed under CC BY-SA 4.0

個人開発はフルスクラッチが一番

written at


――個人開発における技術戦略を考察してみました

大学在学中から、ずっと空き時間を利用して個人開発をしてきて、最近ようやく自分の求めるスピード感で開発ができるようになってきた(気がする)。その経験から、個人開発において採用すべき(と私が考える)技術戦略について書いてみようと思います

結論から言うと、個人開発においては(チーム開発は知らん)、フルスクラッチが一番です。それはなぜでしょうか?

1. フレームワークやライブラリは、バージョン管理に時間がかかる割に、その作業は一銭にもなりません。特に個人開発の場合、売上額の少ないプロダクトを何個も積み上げて利益を確保することが多いので、よりバージョン管理のコストは増大する傾向があります

オープンソースで公開されているコードというのは、世界中のあらゆるユーザのユースケースを想定して、バージョンが上がる毎に、内部実装は抽象化され、オプションパラメータが増大し(デフォルト値もしばしば変更され、挙動が変わる)、複雑化します。その一つひとつの変更に対応するには、膨大な時間と労力がかかります

2. フルスクラッチのコードであれば、一度書いてしまえば、変更しない限り安定して動き続けてくれる上に、自分に取って必要ない機能は実装する必要がないこともあり、コストパフォーマンスが良いです。副業で開発をしている場合などは、そもそも開発に使える時間が限られているので、利益にほとんど影響しないリファクタリングなどの作業は、可能な限りやりたくないことでしょう

3. 個人開発では、人と仕様や設計情報の共有、すり合わせをする必要ないので、独自性の強いコードを書いてもコミュニケーションコストがかからないというのも、フルスクラッチの採用を後押しする理由となるでしょう

以上のように、徹底的にメンテナンスコスト(ランニングコスト)をおさえることで、売上が軽微でも利益を確保できるというのが個人開発においては重要です。実際このブログもフロントエンドもサーバサイドともHTML,CSS,JavaScript(Node.js含む)のみで開発されています

そうはいっても、ReactとかVue、あるいはFlutter、TypeScriptなどなどを自作するかというと、それは現実的ではないですけどね(ちなみに私は、偉そうなことを言っておきながら、個人開発で利益が出たことは一度もありません)

ブログ始めました!

written at


――The first post

最近、仕事をしていると、今の職場のことや日本のITエンジニア市場のこと、IT業界のことを思って感傷的になることが多く、そのときの出来事や感情、それについて本を読んだり調べたりした情報や、私の個人的な意見などを書いていくことにしました

エンジニアに限った話ではないとは思うのですが「こうあるべき」とか「こうしなければならない」という盲目的な正義感を持った方から「お前はここが駄目だから、こう直せ」といった類のことをよく言われ、そのたびに腹が立っています

「便利なサービスがあるのに、車輪の再発明はするな」とか「モダンな技術を取り入れないなんて、こんなレガシーな技術を使いつづけるなんてありえない」とか......皆さんも一度は聞いたことがあるのではないでしょうか?

ここで、もう一つ深く掘り下げて考えたいと思います。「その便利なソフトウェアやサービスは、どうやって作られたでしょうか?」「どれもはじめは、うまくいく確証のない中で、常識とは違った方向に突き進んだ人たちによって作られたのではないでしょうか?」

さらに問いたいと思います。「その便利なソフトウェアやサービスを作った人は、開発の際に、あなたと同じ問題意識を持っていたでしょうか」「あなたの解決したいことと、開発者の解決したいことは同じでしょうか?」

どこにどう問題を感じるかは人それぞれ。だからこそ他人と違う解決方法を思いつく人がいて、違うからこそ既存のものより良くなる可能性があるわけです。そういったものの中から次のイノベーションが生まれるのではないでしょうか?

Appleの製品は、ノートPCでもスマートフォンでも、競合製品より高価なのに売れます。それは他とは明確に異なる独自のデザインによって、一種の独占的な市場を形成しているからでしょう

人まねをするだけなら、ちょっと勉強できれば誰にでもできます。しかし、そのやり方の先に待っているのは、自分と似たり寄ったりな量産型の人材との骨身を削るような厳しい競争市場です

しかも、そういうことを言う人に限って「使っている技術の制約上、その機能は実現できません(導入した自分は悪くない)」と、簡単に顧客からの要望を突っぱねてしまいます。そのシステムで問題が起こっても「技術がいけてない(技術選定した自分は悪くない)」と何の反省も改善もありません

技術の子守をするためにエンジニアをしているのでしょうか? 少なくとも私は違います。顧客のためにエンジニアをしています。だからといって顧客の要望を鵜呑みにしろというわけではありません。顧客自身も気づいていない要望に気づかせてあげる(その結果、自分たちも楽になる)、そういう提案も必要です。ですが足枷になるような技術ならモダンもレガシーも関係なく使うべきではないのでは? 既存の車輪が使えないなら、自分たちにとって使いやすい車輪を再発明すべきでは? と思うのは極端すぎるでしょうか

流行の技術に使われるだけの量産型のエンジニアに、私は絶対なりたくない。私が技術を使うのであって、技術に使われるのではありません(※私は別にApple製品は好きではありません)


これはテストです

written at


――This is a test post.

This is

a Test

Page.