Imported-from-Medium

英語が出来なくても海外向けサービスは作れる

英語が出来なくても海外向けサービスは作れる 個人開発では小さなニッチの領域を攻めるので、サービスが地域依存でもない限りターゲットは日本に絞らず海外も入れたい。自分はInkdropという英語のサービスを一人で作っている。ありがたいことに狙い通り海外ユーザが集まってくれている。すごく楽しい。でも別にTOEICが900点台だとか東大卒で英語が得意という訳でもなく、むしろコンプレックスなぐらい英語が出来ない。ウェブページのサービス紹介文はいろんな所から使えそうな文言を切り貼りして作ったし。 この経験を通して一つ言えることがある。海外向けのサービスを作るためにまず英語を学ぶのではなく、海外向けサービスを作って英語を学ぶのが最短のアプローチだということ。心配しなくていい、海外の人はBroken Englishに慣れている。GitHubでもたまに見かけるでしょ。 実際サービスを公開してみて自分の英語を笑うような人は全然いなかったし、ちゃんと中身で判断してくれていると感じた。だから自分の英語に自信が無くてもまずは作ってしまえばいい。実力は後から付いてくるから。 そもそも日本人は英語コンプレック

Imported-from-Medium

ロンドンのミートアップで自作アプリについて喋ってみた

ロンドンのミートアップで自作アプリについて喋ってみた 兼ねてから計画していた2週間のロンドン旅行で、せっかくだし現地のデベロッパーコミュニティと交流したいなぁと思っていた。フリーランスとして仕事に繋がったら面白いし。で、聴衆としてただ参加したのでは誰からも相手にされず透明人間になってしまうので、発表できる場を探して２つ参加してみた： 1. Mobile App Lightning Talks 2. React Native London Meetup July 2017 どちらも参加者数は80人ぐらい。React Native Londonの方は偶然誘われて参加した。オーガナイザーの人が１つめの方で書いた自分のコメントを見つけてくれたのがきっかけ。二つ返事で参加の意を伝えた。発表した資料はこちら： 内容は、MarkdownノートアプリInkdropのモバイル版をReact Nativeで作った話。滞在先のホテルとか大英図書館で資料を作った。なんとなくセリフを決めてあとはぶっつけで喋った。さほど緊張しなかった。２回とも同じ内容で喋ったんだけど、１回目のMobile App L

Imported-from-Medium

「実装しない」機能の決め方

「実装しない」機能の決め方 個人開発のアプリはシンプルさが肝要。AdobeやMicrosoftのような巨大企業でない限り、機能で勝負しても負けるのは火を見るより明らか。難しいことは他に任せて、自分が解決したい問題にだけ集中する。作りたいアプリ像がはっきりしていれば、機能の取捨選択は簡単にできる。 拙作のInkdropというMarkdownノートアプリも、無駄な機能を付けないように努めている。そのためならユーザの要望も遠慮無く断る。今このアプリにお金を払ってくれている人は、そのシンプルさを買ってくれていると断言できる。ユーザさんにヒヤリングした時、以下のようなメッセージを貰った： My suggestion would be to try to keep the app clean and simple, focus on supporting developers primarily and not to over-complicate things (like basically all the other note-taking systems out there)

Imported-from-Medium

MarkdownノートアプリInkdropで家賃の半分が賄えるようになりました

MarkdownノートアプリInkdropで家賃の半分が賄えるようになりました 4月にInkdropの総売上が10万円を超えた報告をしてから、久々の売上報告です。Inkdropはクローズドソースですが、プロジェクトで得た知見は惜しみなくオープンにしていくつもりです。どんどんやり方パクってください。もし質問などあればコメント欄やTwitterにて受け付けます。 * 驚きの解約率の低さ * 注文の多い少数派を相手にしすぎない * ブログを始めたら日本のユーザが増えた * 1000人のユーザが１人を食わせるモデルを確立したい 既にInkdropについてご存知の方は読み飛ばして下さい。 Inkdropはマルチプラットフォームで動作するノートアプリです。今のところmacOS、Windows、Ubuntu、iPhone、Androidに対応しています。 日々の作業記録や議事録、コードスニペットからブログの下書きまで、技術的な事柄を構文ハイライト対応のMarkdownで快適に書けるようにデザインされたアプリです。美しいUIテーマ、素早いデータ同期、拡張可能なプラグイン機構を備えてい

Imported-from-Medium

美容師の女の子と音楽

美容師の女の子と音楽 美容院に行って髪を切った。初めて眉カットをしてもらったら印象がスッキリしてびっくりした。眉って大事なんだな。 シャンプーを担当してもらった女の子がものすごいバンド好きで、ずっと音楽の話をしていた。たぶん歳は二十代前半。この時代にしては珍しく、デジタルではなくCDをこだわって集めていて、部屋がCDだらけらしい。今よく聴いているのはSuchmosとかペトロールズ。まぁ流行りどころだよねと思いきや、toeのドラムの柏倉さんの情熱っぽいところが大好きというマニアックな一面も覗かせていて興味深い。先日はSpecial Othersのワンマンを観に行ったとのことで、かなり共感を覚えた。 洋楽の話になったのでLimp BizkitやRage Against the Machine、Franz Ferdinandあたりの名前を出したけど、全く知らない様子だった。彼らも当時は一斉を風靡したけどビートルズのような世代を超えたビッグネームにまではなりきれていないんだなと感じた。Radioheadに望みが託される。 普段何気なく聴いてる音楽を若い子も聴いてると知れて、なんだか嬉し

Imported-from-Medium

一人で開発していて寂しくないのか

一人で開発していて寂しくないのか 自分は独立してから6年間、基本的に一人でサービスを作りながらたまに受託をする生活をしてる。受託以外は誰とも連絡を取らず黙々と開発してる。人によってはこんな生活、孤独でやりたいとも思わないらしい。 でもそういう孤独と戦ってる人って案外身近にいる。ユーチューバーとか。映像ではすっごい楽しそうにしてるけど、編集とか真顔で一人でもくもくやってる訳だし。個人で活動してる人には逃れることの出来ない孤独問題。 で、俺は平気かって？そんなことない。面と向かって「寂しくない？」って訊かれるとつい「寂しくなんかねえよ！」って答えたくなるけど、正直それは嘘。別にメンタルが人一倍強いわけでもない。 というか、人なんていくらグループの中に居ても時折寂しさを感じてしまう生き物だ。なのにその気持ちから逃げたり否定するなんて不健全だと思う。 で、この寂しさとうまく付き合っていく方法はいくつかある。徐々に分かってきた。性格的な個人差はしょうがない。置いとこう。 まず寂しさって相対的な一面がある。誰かとずっと一緒に過ごした後に別れたら寂しさを感じる。でも一人が当たり前だとその

Imported-from-Medium

フリーランスの立場を利用して意見を言う

フリーランスの立場を利用して意見を言う 何か意見を言うのって割とハードルが高い。それを言ったら関係がこじれてしまうんじゃないかとか、雰囲気が悪くなってしまうんじゃないかとか心配してしまう。 こういう悩みは誰かと関わっている以上、生じてしまうもの。特に組織の中において。で、スタートアップも例外ではない。自分の周りでも、メンバーへの不満だったり意見の不一致にどう折り合いをつけるのかについて話を聞くことがある。議論が苦手と言われる日本の文化的背景もあるかもしれない。 フリーランスでもこういう悩みはある。先方と意見が折り合わなくて、下手したら取引を切られるかもしれない。だから思ってることが中々言えない人って多いんじゃないだろうか。 それでも、自分は言いたいことは出来るだけ全部言うようにしてる。いや、怖い。でも見方によってはフリーランスの方が言いやすい立場にある。例えばもし自分がスタートアップのメンバーで、会社の中で仲違いしたら後に尾を引いて困る。でもフリーランスなら最悪関係を切れば済む。いい意味で外野として振る舞える。メンバー間で胸の奥に閉まわれていた事を、フリーランスなら全部言える。

Imported-from-Medium

個人でプロダクトを作りながらフリーランスする生活って実際どうなの

個人でプロダクトを作りながらフリーランスする生活って実際どうなの 自分のライフスタイルは、最終的に自分のプロダクトだけで生計が立てられるようになる事を目指している。でもまだ売上が足りないのでたまにフリーランスとして受託をしているという感じ。さて、この生活を６年間続けてるわけだけど、実際どうなのか書いてみたい。 まずプロダクト作りとフリーランシングは協調関係にある。片方が上手く行けば、もう片方も良くなる。なぜならプロダクトを自分で作ることは以下の恩恵が得られるから： 1. 新しい事に挑戦して能力が上がる 2. プロダクトが実績になる 個人開発では誰も怒る人がいない。なので思う存分挑戦できる。それに対して受託開発では新しいことに挑戦しにくい。失敗したら最悪報酬がもらえなくなってしまうから。受託では挑戦しない代わりに、現時点で知りうる最短距離で最高品質なモノを提供する。 また、個人で作ったプロダクトが何らかの成果を上げれば、全て自分の実績になる。「これ俺がやった」とバイネームで語れる実績というのは貴重。実績が出来るとより条件のいい仕事が貰いやすくなる。 一方、受託の仕事がうま

Imported-from-Medium

フリーランスの報酬額の見積もり方と考え方

フリーランスの報酬額の見積もり方と考え方 フリーランスになってかれこれ６年目。それでも毎回悩むのが仕事の報酬の見積もり。永遠のテーマ。たぶん人それぞれ考え方は違うかもしれない。あれこれ悩みたくないし交渉が苦手だからと、人月単位で単価を固定してる人とかもいると思う。以前書いた通り、自分は人月単価で仕事を受けていない。全て案件の内容に応じて報酬額を提示させていただいている。その理由も必要なら納得してもらえるまで先方に説明する。ちなみに自分の場合、最初から報酬額が決まっている案件はあんまりない。 この６年で仕事を見積もる際の考え方はだいたい出揃ってきたので、紹介してみたい。 依頼内容を詳しく聞いたら、軽く設計して実際のタスクがどのようになるか検討する。それを元に効率性・緊急性・専門性・有効性の４軸で仕事を評価する。詳しくは後で説明するとして、まずは希望的価額を自分の中にイメージするのが大切。つまり、「この仕事を自分ならいくらで引き受けたいか」をざっくり決める。 で、その希望的価額ってのは自己評価に大きく影響を受ける。その仕事をやり切る自信が全然なければ、プレッシャーや責任を避けるため

Imported-from-Medium

ネットの評価システムが破綻してきた

ネットの評価システムが破綻してきた 人のアカウントやコンテンツを見る時、そのフォロワー数とかブクマ数とかって、気にしてる？俺は最近あんまり信じなくなってきた。だって、一過性の注目だったり作られたものだったりすることが多いから。スマホが普及してSNSが広く使われるようになってから、今まで機能していたネットの評価システムが徐々に破綻してきているように感じる。 ブログを書くとブクマ付くかな〜とか思ってはてブをチェックしたりする。最近はよく書くからチェックの頻度も高まった。で、iOSアプリを起動すると初期画面でホットエントリの一覧が表示される。普段は見ないけど、目に入ると刺激的な記事が並んでいて、ついつい開いてしまう。 しばらくして、明らかに辟易している自分に気づいた。別に読まなくてもいいやん、と。読まなければ生活に困るような事はまずないような内容ばかり。ブクマ数が多いと、つい自分も読まなければと思ってしまう。でもそんな事は全く無い。 SNSに詳しい人なら共感してもらえると思う。たまに、フォロワー数が多いけどほとんどがゾンビアカウントの人がいる。そういうフォロワー数を増やすツールを使っ

Imported-from-Medium

サーバレスでベンダーロックインを避ける方法

サーバレスでベンダーロックインを避ける方法 ここ数日、ノートアプリInkdropを題材にしてAWS Lambdaを触っていた。まずはherokuで運用してるAPIをLambdaで動かすことに成功した。良かった点は、koa.js製のコードベースをほぼ変更する必要が無かった事。小さなfunctionに小分けする必要すら無かった。思ってたよりすんなり行って拍子抜けしてる。 見方を変えると、このAPIがHerokuとLambdaの両方で動くようになったと評価できる。これは嬉しい誤算。帰り道が残されたのは安心感がある。サーバレスには興味あるけど、移行コストがかかりそうとかロックインされるんじゃないかと思っている人が多いと思う。でも工夫すれば案外手軽にできることが分かったので、参考にしてもらいたい。 アーキテクチャについては先日こちらに書いたとおり、AWS Lambda + API Gatewayという構成。APIを動かすにあたって以下の記事を参考にした。 * Going Serverless: Migrating an Express Application to Amazon API

Imported-from-Medium

Inkdropサーバレス化計画

Inkdropサーバレス化計画 サーバレスアーキテクチャが自分の中で急に熱い。運用もうやりとうない。業界での知見もぼちぼち出揃ってる感じがあるので自分でも挑戦してみたい。MarkdownノートアプリのInkdropを題材にしてやってみる。 サーバレスアーキテクチャとは、その名の通りサーバが無いアーキテクチャのこと。ここでのサーバとは、apacheやnginxなどのサーバプロセスから、LinuxマシンなどのVMを含めたコンピュータを指す。これらを自分で運用する必要がない。まじかよ。 じゃあどうやって提供するのかというと、サーバの代わりにHTTP(S)に応答したりイベントに反応するサービスを使う。処理を行うプログラムは、APIや機能単位で別々にデプロイしたものを使う。これらのプログラムが予め設定した条件で駆動する。つまり、今まで自分でサーバにやらせていたことを、サービス側でやってもらうということ。 メリットは主に３つある。まずスケールの心配が要らない。サービスが勝手に負荷に合わせてリソースを調整してくれるから。次に、コストを最小限に抑えられる。使われていないサーバの稼働時間にお金を