👀10億円買収で話題のSkeb開発者なるがみさんに聞く、「クリエイターファースト」の開発やサービス設計の裏側と、買収の理由
Loading...
いかに無駄なコードは書かないか、運用コストを低く管理しやすくするかを意識しています。 なんでも自前でやらずに、クラウドや外部のAPIを積極的に活用して、多少料金が高くても自分で書くコードの量が少なく安定するものを使っていますね。
エンジニアにはプログラミングを手段と捉える「手段プログラマー」と、プログラミング自体を目的とする「目的プログラマー」がいると思います。 それぞれ塩梅があると思うのですが、僕はかなり手段プログラマー寄りです。 1人でサービスを開発・運営するのであれば手段プログラマーの方が向いていると思いますね
スピード重視でいい意味で雑に仕上げたり、早く出して早く直すことも重要です。 プログラムを書くことは解決手段の一つで、書かずに解決がベストという場合も。 手段プログラマーはそれを考えられるのが良いところです。
例えば、僕が作ったドージン・ドット・タックスという同人作家向けの確定申告サービスは、LPはありますが、アプリケーションのコードは1行も書いていません。
手段プログラマーと目的プログラマー
コミュニティの沼に浸かる
ただ、サービスを大きくしていくなら、どちらかに偏ってもダメで、バランスが重要です。 手段プログラマーは、技術動向を追えていなかったり、スピードを含む実装力が低かったり。 目的プログラマーは、実装力は高い一方で、施策の検討があまりできなかったり。
1人で開発と運営をするためには3つの知識が必要です。 1つ目がプログラミングの知識、2つ目が経営や法律の知識、そして3つ目がその領域についての深い知識です。 この3つが揃わないと、1人で開発・運営はできません。
最初の2つは勉強すれば学べるものですが、3つ目が最も重要で、最も大変です。 個人でサービスを開発・運営するということは、自分がPMであり、開発者であり、運営者です。 全てをバランスよく行うためには、「そのコミュニティの方々や想定のユーザと横に並ぶ当事者」にならないとダメなんです。
考えつくものを全て完璧にやっていたら工数はまったく足りません。 それぞれの機能や施策が、ユーザにとってどれくらい重要なのか、どこまで仕上げると工数と品質や効果のバランスが取れるのか、というのを経験と勘から判断しています。
経験と勘と言うとノリでやっているのかと思われてしまうかもしれませんが、これはユーザと同じコミュニティに浸かっているPM・エンジニアだからこそ分かる感覚です。
それを養うためにも、コミュニティに深く浸かることをまず始めてください。 プログラミングと経営企画の知識は後から勉強すればいいですから。